[FFmpeg-devel] [PATCH]Assume STRICT for h264.c

[Michael Niedermayer]

On Sun, Nov 08, 2009 at 12:36:46PM +0000, Carl Eugen Hoyos wrote:
> Michael Niedermayer <michaelni <at> gmx.at> writes:
> 
> > We should have code that increases has_b_frames in h264.c, ive not looked at
> > this issue at all, but if you want to work on this, try to find out why this
> > code doesnt increase has_b_frames or if it does why it isnt enough
> 
> Following inlined trial-and-error variant also fixes the issue:
> 
> Index: libavcodec/h264.c
> ===================================================================
> --- libavcodec/h264.c   (revision 20475)
> +++ libavcodec/h264.c   (working copy)
> @@ -7906,6 +7906,7 @@
>              if(h->sps.bitstream_restriction_flag && s->avctx->has_b_frames >=
> h->sps.num_reorder_frames)
>                  { }
>              else if((out_of_order && pics-1 == s->avctx->has_b_frames &&
> s->avctx->has_b_frames < MAX_DELAYED_PIC_COUNT)
> +               || h->sps.ref_frame_count > s->avctx->has_b_frames + 1
>                 || (s->low_delay &&
>                  ((!cross_idr && out->poc > h->outputed_poc + 2)
>                   || cur->pict_type == FF_B_TYPE)))

ref_frame_count is as the name indicates something about reference frames
has_b_frames represents the size of the reordering buffer and thus is a
very poor name (historic reasons why its as it is, if it wherent public API
we could fix it ...)
these 2 are independant, you can have 10 reference frames and a reorder
buffer of 0 or you can have 1 reference frame and a reorder buffer of 10
also the number of actual reference frame (sps.ref_frame_count is the
maximum) can change while the size of the reorder buffer does not change
(well ignoring randomly concatenated files and the fact that we are
 increasing it when we realize it was too small)

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- 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/20091109/e2697b1c/attachment.pgp>