[mythtv] Keyframe adjust table (posibel bug(s))

[Torbjörn Jansson]

> On Sun, 4 Jan 2004 23:13:11 +0100, "Torbjörn Jansson" said:
> > So how shoud this be fixed?
> 
> Well, I have just committed fixes for all the bugs you mentioned.
> Specifically, the seek-table should correctly mark 'SV' frames again,
> and the KFA table will function properly.
> 
> This won't fix the files that are already broken, although it would be
> pretty easy to rebuild the seek table.  
> 
> I am unsure why you are having an issue though.  The seektables in
> transcoded files do point at a valid frame.  It just may not be a sV
> frame (specifically, it may be an 'A' or 'R' frame).  But you are
> gauranteed that there is an SV frame between the seektable 
> position and
> the next 'V' frame.
> 
> You do need to account for the kfa stuff, but if you look at
> nuppeldecoder now, it should be obvious how to do so (I changed the
> handling to be more intuitive)
> 

Looks better now

> > Shoud I just ignore the seektable and kfa table if
> > keyframeadjust_offset>0 ?
> You can do this if you like, but don't assume that they come every
> keyframedist.

No, I don't asume that.
Internaly the seektable is kept as frame numbers so it's easy to apply the
kfa table.


> > The problem is that this broken seektable messes up the timestamp
> > calculations, so with my sample file (Antz) if I seek to a 
> position near
> > the
> > end of the file, I will have to wait 8-9 minutes afte a 
> seek before the
> > video starts.
> I'm not sure why.  As I said above, while it wasn't right, it 
> wasn't THAT
> wrong.

I have found the cause of the problem.

When directshow does a seek all timestamps on the samples is reset to zero,
so the first video sample shoud be at time zero or prety close.
When I timestamp the video frames I use the timecode in rtframeheader but
that field is not updated after a file has been transcoded, so this results
in samples with timestamps from the orginal untranscoded file.

So as I seek past more and more cutpoints the timestamps drift and becomes
more off and that's why I had to wait about 8-9 minutes yesterday for the
video to start playing (I cut off 2 comercials of about that lenght)

So to answer your question "Is it necessary to change the timecodes?" in
transcode.cpp yes, atleast for the directshow filters.

I gues I coud modify it so it uses video frame numbers instead of timecodes,
but the question is, what is most accurate? Timecode or framenumbers