On Fri, Dec 02, 2011 at 07:25:11AM -0800, Ronald S. Bultje wrote: > Hi, > > first part committed separately. > > On Wed, Nov 30, 2011 at 3:51 PM, Ronald S. Bultje <[email protected]> wrote: > > On Wed, Nov 30, 2011 at 3:26 PM, Alexander Strange > > <[email protected]> wrote: > >> On Wed, Nov 30, 2011 at 1:22 AM, Ronald S. Bultje <[email protected]> > >> wrote: > >>> Fixes fate-h264-conformance-{mr2_tandberg_e,mr3_tandberg_b} without > >>> requiring -strict 1. > >>> --- > >>> libavcodec/h264.c | 69 > >>> +++++++++++++++++++++++++++++++++++------------ > >>> libavcodec/h264.h | 1 + > >>> libavcodec/h264_refs.c | 6 +--- > >>> 3 files changed, 53 insertions(+), 23 deletions(-) > >>> > >>> diff --git a/libavcodec/h264.c b/libavcodec/h264.c > >>> index ad1ab69..acd7179 100644 > >>> --- a/libavcodec/h264.c > >>> +++ b/libavcodec/h264.c > >>> @@ -1348,6 +1348,7 @@ static void decode_postinit(H264Context *h, int > >>> setup_finished){ > >>> Picture *out = s->current_picture_ptr; > >>> Picture *cur = s->current_picture_ptr; > >>> int i, pics, out_of_order, out_idx; > >>> + int invalid = 0, cnt = 0; > >>> > >>> s->current_picture_ptr->f.qscale_type = FF_QSCALE_TYPE_H264; > >>> s->current_picture_ptr->f.pict_type = s->pict_type; > >>> @@ -1438,7 +1439,7 @@ static void decode_postinit(H264Context *h, int > >>> setup_finished){ > >>> > >>> if( s->avctx->strict_std_compliance >= FF_COMPLIANCE_STRICT > >>> && !h->sps.bitstream_restriction_flag){ > >>> - s->avctx->has_b_frames= MAX_DELAYED_PIC_COUNT; > >>> + s->avctx->has_b_frames = MAX_DELAYED_PIC_COUNT - 1; > >>> s->low_delay= 0; > >>> } > >>> > >> > >> This part looks OK. > >> > >>> @@ -1451,31 +1452,54 @@ static void decode_postinit(H264Context *h, int > >>> setup_finished){ > >>> if (cur->f.reference == 0) > >>> cur->f.reference = DELAYED_PIC_REF; > >>> > >>> + /* Frame reordering. This code takes pictures from coding order and > >>> sorts > >>> + * them by their incremental POC value into display order. It > >>> supports POC > >>> + * gaps, MMCO reset codes and random resets. > >>> + * A "display group" can start either with a IDR frame (f.key_frame > >>> = 1), > >>> + * and/or can be closed down with a MMCO reset code. In sequences > >>> where > >>> + * there is no delay, we can't detect that (since the frame was > >>> already > >>> + * output to the user), so we also set h->mmco_reset to detect the > >>> MMCO > >>> + * reset code. > >>> + * FIXME: if we detect insufficient delays (as per > >>> s->avctx->has_b_frames), > >>> + * we increase the delay between input and output. All frames > >>> affected by > >>> + * the lag (e.g. those that should have been output before another > >>> frame > >>> + * that we already returned to the user) will be dropped. This is a > >>> bug > >>> + * that we will fix later. */ > >>> + for (i = 0; i < MAX_DELAYED_PIC_COUNT; i++) { > >>> + cnt += out->poc < h->last_pocs[i]; > >>> + invalid += out->poc == INT_MIN; > >>> + } > >>> + if (!h->mmco_reset && !cur->f.key_frame && cnt + invalid == > >>> MAX_DELAYED_PIC_COUNT && cnt > 0) { > >>> + h->mmco_reset = 2; > >> > >> You set mmco_reset to 1 and 2 but I only see comparisons of it against 0. > > > > The 2 is only so I can (while debugging) distinguish between these set > > by "real" mmco resets and these set by this artificial detector. In > > practice there is never a need to distinguish. I can change this to 1 > > if you want, but figured it would be useful in the future to be able > > to distinguish between these two, especially since it adds no > > overhead. > > > > (I should probably document it, though.) > > > >> What samples does this fix? > > > > If you remove -strict 1 from tests/fate/h264.mak: > > make: *** [fate-h264-conformance-mr2_tandberg_e] Error 1 > > make: *** [fate-h264-conformance-mr3_tandberg_b] Error 1 > > This is fixed by this patch. > > > > (Note that I consider -strict 1 a hack, consider what happens if you > > play back a .h264 file in VLC; will it automatically add -strict 1 for > > you?) > > Ping re: this, tandberg still fails sporadically and I believe my > patch fixes it - I haven't seen it fail with my changes yet.
If other samples are fine too then OK (maybe). _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
