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

[Michael Niedermayer]

On Fri, Feb 20, 2009 at 08:46:29PM +0100, Ivan Schreter wrote:
> Michael Niedermayer wrote:
> > On Fri, Feb 20, 2009 at 06:52:30PM +0100, Ivan Schreter wrote:
> >   
> >> Michael Niedermayer wrote:
> >>     
> >>> On Fri, Feb 20, 2009 at 04:00:34PM +0100, Ivan Schreter wrote:
> >>>   
> >>>       
> >>>> Michael Niedermayer wrote:
> >>>>     
> >>>>         
> >>>>> On Fri, Feb 20, 2009 at 03:30:16PM +0100, Ivan Schreter wrote:
> >>>>>         
> >>>>>           
> >>>>>> solution giving parser the control of frame duration seems cleaner to 
> >>>>>> me.
> >>>>>>             
> >>>>>>             
> >>>>> considering that your code depends on a 90khz clock which is not 
> >>>>> guranteed
> >>>>> and that repeat_pict must be fixed and unambigously specified for fields
> >>>>> anyway i dont see any advantage of ignoring a existing field ans 
> >>>>> introducing a
> >>>>> new one
> >>>>>
> >>>>>         
> >>>>>           
> >>>> That was also my question in another post - where do I get the clock in 
> >>>> lavc?
> >>>>     
> >>>>         
> >>> do you really need it?
> >>>   
> >>>       
> >> Not for convergence, since we can express it via frame count. But for 
> >> pts/dts computation, definitely. For H.264 case, the stream must have 90kHz 
> >> clock according to H.264 standard, so it should be OK. But for other 
> >> codecs, I don't know.
> >>
> >> Alternative would be to scale pts/dts to some common unit (e.g., 
> >> 1/1000000th second) and then rescale back.
> >>     
> >
> > the container timebase in which pts/dts are specified is not
> > guranteed to be 90khz, even if h264 says it is so, it just isnt in practice.
> > things may work out because only mpeg-ps/ts ommit pts/dts "randomly" and
> > mpeg-ps/ts have 90khz but .mp4/mov/nut/mkv do normally not use 90khz timebase
> >
> >   
> True, I downloaded some MOV AVCHD trailers and they don't work with 
> timestamping code correctly. Seem to use 1MHz clock, or so.
> 
> > also rounding is not ok
> >
> >   
> We'll need to communicate proper timebase for timestamping from lavf to 
> lavc in AVCodecParserContext, then, so it can compute timestamps correctly.

hmm i think the parser should export its dts/pts correction in 
AVCodecContext.time_base units (i think this is the correct one)
and the code in lavf should then merge that into its dts/pts


[...]
> > [...]
> >   
> >>> if its just for convergence_duration, then maybe a convergence_frames
> >>> (different name and frame count instead of time) could be used.
> >>>
> >>>   
> >>>       
> >> OK, I've changed it, since it's not 100% sure the codec knows the time 
> >> base. Patch attached.
> >>     
> >
> > after rereading the text of the recovery SEI i think there is a more
> > fundamental problem in h264 with convergence_*
> > the way they specify it, is via frame_num, but frame_num does not
> > increase for non reference pictures thus one not only can not infer
> > the duration from it but not even the number of frames unless one
> > knows which are reference frames (and one does not without scaning ahead).
> > considering this, exporting the value makes no sense.
> >
> >   
> :scratch, scratch:
> 
> It's very weird, true, but I have to agree with you. All consecutive 
> B-frames effectively have the same frame_num and recovery_point is 
> really defined via frame_num. The only thing we could do is to somehow 
> infer something like GOP structure (pattern of reference and 
> non-reference frames) and then use it to approximate.
> 

> Alternatively, instead of using "convergence_duration" we could define 
> "convergence_flag" and then it's relatively easily possible. Simply, 
> note down the frame number from SEI recovery point and when we reach it, 
> we set the flag. Thus, application can test this flag after seek after 
> decoding each picture, if it already reached the convergence point.

yes, this sounds possible, but i think we should ignore convergence currently
and try to get the rest working and into svn first ...


> 
> I'm getting more and more the feeling that the designers of H.264 
> standard were quite detached from reality.

yes
when its about compression vs. quality h264 shines but all the surrounding
stuff is kinda uhm

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- 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/20090220/03e75aaf/attachment.pgp>