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

[Michael Niedermayer]

On Fri, Feb 20, 2009 at 06:52:30PM +0100, Ivan Schreter wrote:
> Michael Niedermayer wrote:
>> uOn 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

also rounding is not ok


>
>> 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.


>
>> [...]
>>
>>   
>>> So the decoding of AVCodecParserContext.repeat_pict in H.264 must 
>>> actually go to the parser (as done for MPEG video).
>>>     
>>
>> yes
>>
>>
>>   
>>> BTW, H.264 currently only sets Picture.repeat_pict (and this one 
>>> correctly), but no AVCodecParserContext.repeat_pict.
>>>     
>>
>> indeed
>>   
> I'll resend new parser patches set in answer to the other post.
>
> Regards,
>
> Ivan
>

> Index: libavcodec/avcodec.h
> ===================================================================
> --- libavcodec/avcodec.h	(revision 17471)
> +++ libavcodec/avcodec.h	(working copy)
> @@ -30,7 +30,7 @@
>  #include "libavutil/avutil.h"
>  
>  #define LIBAVCODEC_VERSION_MAJOR 52
> -#define LIBAVCODEC_VERSION_MINOR 18
> +#define LIBAVCODEC_VERSION_MINOR 19
>  #define LIBAVCODEC_VERSION_MICRO  0
>  
>  #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> @@ -3035,12 +3035,12 @@
>      int key_frame;
> 
>      /**
> -     * Time difference in stream time base units from the pts of this
> -     * packet to the point at which the output from the decoder has converged
> +     * Time difference in frames from the pts of this
> +     * frame to the point at which the output from the decoder has converged
>       * independent from the availability of previous frames. That is, the
>       * frames are virtually identical no matter if decoding started from
>       * the very first frame or from this keyframe.
> -     * Is AV_NOPTS_VALUE if unknown.

> +     * Is -1 if unknown.

even though it doesnt make much of a difference ...
this should be INT_MIN, -1 can be ambigous in light of frame reordering
(coded: IBBPBB display BBIBBP here it is possible that convergence_frames is
 -2 when the B frames are decodeable after the I frame)

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/eed8dafd/attachment.pgp>