[FFmpeg-devel] [PATCH] H.264 timestamps in h264_parser - complete set
Tue Feb 24 08:26:44 CET 2009
Michael Niedermayer wrote:
> On Mon, Feb 23, 2009 at 09:00:03PM +0100, Ivan Schreter wrote:
>> Michael Niedermayer wrote:
>>> also ive just tried to change tb & repeat_pict in mpeg2 and the regression
>>> tests passed so iam not sure what problems you speak of (mpeg2 patch below,
>>> its just a quick thing not well tested ...)
>> Doesn't work for H.264. Frame rate is computed directly from time_base,
>> in contrast to MPEG-2, where it's found out by looking at durations of
>> single frames (tb_unreliable).
>> What do you suggest?
>> Setting tb_unreliable for H.264 works for progressive (correct
>> framerate), frame doubling (halving framerate) and frame tripling (1/3
>> of framerate),
> yes, i suggest setting tb_unreliable for H.264
Then we would have a special case for H.264 in lavf...
But (see below):
>> but not for interlaced and only partially for TBT and BTB
>> pictures. Reason: interlaced frame has time_base duration and we don't
>> communicate "field flag" to lavf. If we define duration of interlaced
>> frame == duration of frame (instead of 1/2 frame), then it will work. Is
>> this in your opinion OK?
> my oppinion is that having r_frame_rate = 50 for a 25fps interlaced or
> TBT/BTB video is correct.
Using tb_unreliable would use 25fps for 25fps progressive, 50fps for
25fps interlaced, 16.67fps for 25fps TBT/BTB, 12.5fps for doubling and
8.33fps for tripling. This is not what we want, I suppose.
So I'd then suggest letting tb_unreliable return 0 and simply use the
50fps, and (see below):
> also frame duplication as ffmpeg does depends on the value of -vsync
> change it to 2 or 0 and the frame dups are gone. This should work fine
> with all common container formats, and i wanted to change the default
> already a few times.
> Maybe a simple AVFMT_VARIABLE_FPS could be added and then vsync
> default changed to 2 for containers having that flag set.
> If this would help i can add that flag and change ffmpeg.c.
I like this AVFMT_VARIABLE_FPS...
However, how does the _encoder_ then know it should encode 25fps, when
input is 50i? Player is obviously no problem in that sense. I don't
quite understand vsync values, as they seem undocumented.
Another question, how does the player (or user application) know, after
avcodec_decode_video() returns a picture, which timestamp and duration
this picture has (OK, duration is expressed in repeat_pict, but where
does it get the PTS - pts field in picture is currently not filled at
all or wrong)? Pictures are being reordered for MPEG/H.264... I'm
afraid, this needs to be fixed as well.
More information about the ffmpeg-devel