[FFmpeg-devel] pts handling (reordered_opaque) and frame duration calculation

[Michael Niedermayer]

On Wed, Apr 01, 2009 at 07:46:06PM +0200, Reinhard Nissl wrote:
> Hi,
> 
> a few weeks ago I added code to xine-lib's FFmpeg interface to
> make use of reordered_opaque. It worked like a charm for the
> H.264 samples I used for testing.
> 
> Now I got reports that A/V sync seems to be broken for other
> codecs (e. g. XviD). After some investigation I found out that I
> always get back 0 from frame->reordered_opaque, no matter what I
> set avctx->reordered_opaque to before calling avcodec_decode_video().

ive just tested and reordered_opaque works as expected with my sample mpeg4
asp file
you can just try:
Index: ffplay.c
===================================================================
--- ffplay.c	(revision 17672)
+++ ffplay.c	(working copy)
@@ -1372,7 +1372,7 @@
         len1 = avcodec_decode_video(is->video_st->codec,
                                     frame, &got_picture,
                                     pkt->data, pkt->size);
-
+av_log(NULL, AV_LOG_ERROR, "%Ld -> %Ld\n",  pkt->pts, frame->reordered_opaque);
         if(   (decoder_reorder_pts || pkt->dts == AV_NOPTS_VALUE)
            && frame->reordered_opaque != AV_NOPTS_VALUE)
             pts= frame->reordered_opaque;

with ffplay and your file


> 
> Is reordered_opaque only supported by certain codecs?
> 
> In that case, how can I check whether a certain codec supports it?
> 
> Regarding frame duration calculation: some months ago I added
> code to xine-lib's FFmpeg interface which takes into account
> avctx->time_base. I used that code to calculate frame duration in
> pts units:
> 
> 	90000ll
> 	* avctx->time_base.num
> 	/ avctx->time_base.den
> 
> But this seems to be no longer correct for recent FFmpeg and
> H.264. After looking through the changes to h264.c, I see that
> time_base.den has been doubled and ticks_per_frame has been set
> to 2 too. So I changed the calculation to:
> 
> 	90000ll
> 	* avctx->ticks_per_frame
> 	* avctx->time_base.num
> 	/ avctx->time_base.den
> 
> This works for my samples, but I doubt that this is correct in
> general, as I came across the following comment while looking
> through the ML for the first mentioned issue:
> 
> 	frame_duration = (1 + repeat_pict) * time_base
> 
> Does this mean that my calculation should look like that to be
> correct in general?
> 
> 	90000ll
> 	* (1 + frame->repeat_pict)
> 	* avctx->ticks_per_frame
> 	* avctx->time_base.num
> 	/ avctx->time_base.den
> 
> Thanks in advance.

you can look at compute_frame_duration() from lavf
and grep for ticks in ffmpeg.c

(iam refering to these as this code might change as more h264 and timestamp
 issues become fixed)
also not all codecs have the ability to store frame durations so it may be
that what you calculate with all this is still off in some cases.

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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- 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/20090401/d9fb31d8/attachment.pgp>