[FFmpeg-devel] [RFC/PATCH] matroska timestamps not always pts

elupus elupus
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 
>> since
>> 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 
>> remember
>> 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...
>
> Rich


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.

Joakim 






More information about the ffmpeg-devel mailing list