[FFmpeg-devel] [RFC/PATCH] matroska timestamps not always pts
Wed Nov 21 15:32:38 CET 2007
"Rich Felker" <dalias at aerifal.cx> wrote in message
news:20071121023602.GG246 at brightrain.aerifal.cx...
> On Tue, Nov 20, 2007 at 11:50:32PM +0100, elupus wrote:
>> "Uoti Urpala" <uoti.urpala at pp1.inet.fi> wrote in message
>> news:1195598562.18396.9.camel at symbol.nonexistent.invalid...
>> > On Sun, 2007-11-18 at 23:11 +0100, elupus wrote:
>> >> Apperently the timestamps stored in matroska container can mean
>> >> different
>> >> things. For native tracks they normally mean pts, while for others
>> >> this
>> >> isn't always the case.
>> >> The case i'm trying to nail here is the ms compatibility case. In this
>> >> case,
>> >> timestamps should correspond to the frame numbers in avi. This patch
>> >> makes
>> >> demuxer only set the correct timestamp (dts/pts) in the packet.
>> > Does some spec say they "should correspond" to frame numbers? Or are
>> > you
>> > only saying this because you've seen (invalid?) files generated by
>> > someone which do this?
>> Well, i didn't get that exact wording from Haali, what I got was that
>> "timestamps should be treated as timestamps are treated in avi." And
>> there is no such thing as timestamps in avi, the closes thing you got is
>> frame number. (hmm or is it packet number in stream perhaps, don't
>> how vfr files in avi are encoded) .
> AVI has 'timestamps' in the form of dts implicit from the position of
> the frame in the file and the timebase in the header. Are you saying
> Matroska timestamps should be treated as dts-in-timebase rather than
> as pts for the MS/FOURCC case?? This sounds rather stupid, but perhaps
> the design is that bad...
That is how I understood it. Remember thou that this isn't the normal native
way of storing data in matroska. It's only when the stream was in ms
compatibility mode. I will check with the matroska people once again to make
sure i understood it right. In either case i have a sample that is stored
like that, so either that is how timestamps should be interpreted, or there
is a broken muxer out there.
More information about the ffmpeg-devel