[FFmpeg-user] Noticed TimeStamp Issue When Muxing Raw h.264 into MKV

luke wilson lukec.wilson86 at gmail.com
Wed Feb 29 23:22:01 CET 2012

Great Mike thanks for the feedback. I do understand that my formula is
simplified. I think in the short term I could at least parse to check if
the h264
stream is encoded in the most simplistic of cases, and use my logic to mux
the h264 stream. For a more robust solution I would have to spend quite a
of time on it as you noted. I guess what I would be interested to know is A:
Would this simplified mux be useful to the community and  B: If I were to
a more robust version do you see anyone utilizing the feature (grant it
this more
robust solution would probably not cover every situation but at least it
would give
muxing an honest try plus it could probably be used by other containers in

On Wed, Feb 29, 2012 at 5:00 PM, Mike Scheutzow <
mike.scheutzow at alcatel-lucent.com> wrote:

> luke wilson wrote:
>> To Whomever,
>> I hope I'm in the right place with this. Anyway I noticed that you can not
>> mux a raw h.264 streams into MKV because of the lack of a TimeStamp.
>> Correct me if I'm wrong but I believe this error(see error below) is due
>> to
>> raw h.264 streams not containing any specific timestamp information.
> Yes, you are correct.
>   If this is the case I believe I have a proof of concept for creating
>> timestamps
>>  data for a MKV mux.
>> Proof Of Concept:
>> 1. Get FPS from (Annex E) VUI   FPS = time_scale / num_unit_in_tick * 2
>>    (I know this isn't perfect but it gets it close enough)
>> 2. Take stream within each given cluster in MKV and count frames
>>    (There are a few variations)
>> 3. Create a TimeStamp for Segments based on frame count against FPS
> Your algorithm will work for the simplest cases, but not for many others.
> Generating timestamps for H264 is more difficult than I think you realize,
> at least if you want to do it correctly. This is because H264 supports
> (almost) arbitrary frame reordering in the decoder.
> Also, are you aware that h264 streams do not have to be Constant Frame
> Rate?
> Please work on this if you're interested, but be aware that it's a hard
> problem. You will need to parse deep into the bitstream to gather all the
> info necessary to figure out the decoded frame order.
> Mike Scheutzow
> ______________________________**_________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/**listinfo/ffmpeg-user<http://ffmpeg.org/mailman/listinfo/ffmpeg-user>

More information about the ffmpeg-user mailing list