Hi,
first part committed separately.
On Wed, Nov 30, 2011 at 3:51 PM, Ronald S. Bultje <rsbul...@gmail.com> wrote:
> On Wed, Nov 30, 2011 at 3:26 PM, Alexander Strange
> <astra...@ithinksw.com> wrote:
>> On Wed, Nov 30, 2011 at 1:22 AM, Ronald S. Bultje <rsbul...@gmail.com> 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.
Ronald
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
