Hi, 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?) Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
