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

[luke wilson]

I just wanted to add because I missed answering your Constant Frame Rate
question.
I do understand that there is a variable frame rate in h264. Now you can
correct me if
I'm wrong but in my testing and reading of the MPEG 4 part 10 ISO spec. It
seems that
if you utilize sps and pps headers parsing these segments will get you
constant amounts
of time. Knowing the frames between these constants you can get the
timesstamp
close enough that the file will play without noticeable choppiness. This
seems to be
working fine in my scenario where I have created keyframes with sps and pps
headers
I know this will not work in all cases, but I'm guessing that it will get
you close enough.
BTW doesn't the frame rate only change by a few frames a second anyways?
I might be wrong but I don't think that anyone would be the wiser on
anything
above an average 20 FPS with a syncroniziation at keyframes? I'm just
asking these
questions because its seems like you have a lot of experience with h264. I
have
only been working with it for the last month.

-Luke

On Wed, Feb 29, 2012 at 5:22 PM, luke wilson <lukec.wilson86 at gmail.com>wrote:

> Great Mike thanks for the feedback. I do understand that my formula is
> overly
> 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
> bit
> 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
> build
> 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
> the
> future)?
> .
>
> 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>
>>
>
>