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

[Torbjörn Jansson]

> On Mon, 5 Jan 2004 12:39:48 +0100, "Torbjörn Jansson" said:
> > 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
> > 
> Well, from my recent expereinces with MPEG2 (and previous experineces
> with my crappy bttv card), I wouldn't recommend seeking based 
> on the pts.
>  The pts is best used for a/v syncing, but if the stream is 
> broken, the
> pts may not be continuous.  Some mpeg2 editors will cut 
> sections out of a
> file, mark the next gop broken, and not update the  pts.  This is
> apparently legal.  Of course the nuv used by myth is a custom 
> format, and
> we can do what we like, but the pts won't necessarily be 
> continuous there
> either (if your card starts dropping frames, the pts can have gaps).
> 

pts==timecode?

It's a good thing that the timecode has gaps if there is dropped frames
because that will make the video rendere display the frame at the right
time, even if there was dropped frames.

> So I would recommend seeking using frame numbers, and syncing with
> timestamps.
> 
> However, I don't think it would be hard to fix the 
> timestamps.  I didn't
> do so before, because I thoughtit might be useful to preserve 
> the orginal
> timestamps for some future purpose (also, I didn't have an easy way to
> update them).  I don't think it would be too hard to update them now. 
> Even still, it'd mean you'd need to have some way to deal with the
> current way, since there are (maybe) lots of recordings out there that
> have been transcoded.
> 
> Let me know what you want me to do.
> 

I'm going to use frames and ignore the timecode, this will make it work with
existing files.
I wounder how this will work for the audio timestamps, they need to be
corrected too.
If I use video frames as a reference then maybe several audio samples will
have the same timestamp, not sure if that's a good thing.

I'll have to do some more testing.