[FFmpeg-devel] [PATCH] H.264 timestamps in h264_parser - complete set

[Michael Niedermayer]

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.

see reordered_opaque

[...]
-- 
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
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090224/518cfb54/attachment.pgp>