[FFmpeg-devel] [PATCH] H.264 timestamps in h264_parser - complete set
Tue Feb 24 14:36:00 CET 2009
On Tue, Feb 24, 2009 at 08:26:44AM +0100, Ivan Schreter wrote:
> 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):
I ve just added h264 to tb_unreliable()
> > 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.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel