[FFmpeg-devel] [PATCH] lavc: Fix ticket 6024

[Hendrik Leppkes]

On Thu, Dec 15, 2016 at 4:07 PM, Paul B Mahol <onemda at gmail.com> wrote:
> On 12/15/16, Michael Niedermayer <michael at niedermayer.cc> wrote:
>> On Wed, Dec 14, 2016 at 10:05:50PM -0700, pkoshevoy at gmail.com wrote:
>>> From: Pavel Koshevoy <pkoshevoy at gmail.com>
>>>
>>> ---
>>>  libavcodec/utils.c | 2 --
>>>  1 file changed, 2 deletions(-)
>>>
>>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>>> index 44ecc09..2ad96e4 100644
>>> --- a/libavcodec/utils.c
>>> +++ b/libavcodec/utils.c
>>> @@ -2788,8 +2788,6 @@ static int do_decode(AVCodecContext *avctx, AVPacket
>>> *pkt)
>>>      if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) {
>>>          ret = avcodec_decode_video2(avctx,
>>> avctx->internal->buffer_frame,
>>>                                      &got_frame, pkt);
>>> -        if (ret >= 0)
>>> -            ret = pkt->size;
>>>      } else if (avctx->codec_type == AVMEDIA_TYPE_AUDIO) {
>>>          ret = avcodec_decode_audio4(avctx,
>>> avctx->internal->buffer_frame,
>>>                                      &got_frame, pkt);
>>
>> This breaks fate
>>
>> --- ./tests/ref/fate/rscc-32bit 2016-12-15 04:39:33.924670759 +0100
>> +++ tests/data/fate/rscc-32bit  2016-12-15 15:59:04.507407670 +0100
>> @@ -3,11 +3,3 @@
>>  #codec_id 0: rawvideo
>>  #dimensions 0: 320x240
>>  #sar 0: 0/1
>> -0,          0,          0,        1,   307200, 0xe36c2c38
>> -0,          1,          1,        1,   307200, 0xa2e3476b
>> -0,          2,          2,        1,   307200, 0x65167c95
>> -0,          3,          3,        1,   307200, 0x6acd02ac
>> -0,          4,          4,        1,   307200, 0x37935e0b
>> -0,          5,          5,        1,   307200, 0x8e6918bc
>> -0,          6,          6,        1,   307200, 0x0a246578
>> -0,          7,          7,        1,   307200, 0x9c1a2f4c
>> Test rscc-32bit failed. Look at tests/data/fate/rscc-32bit.err for details.
>> make: *** [fate-rscc-32bit] Error 137
>> make: *** Waiting for unfinished jobs....
>> --- ./tests/ref/fate/rscc-16bit 2016-12-15 04:39:33.924670759 +0100
>> +++ tests/data/fate/rscc-16bit  2016-12-15 15:59:04.491407670 +0100
>> @@ -3,18 +3,3 @@
>>  #codec_id 0: rawvideo
>>  #dimensions 0: 320x240
>>  #sar 0: 0/1
>> -0,          0,          0,        1,   153600, 0x33759daf
>> -0,          1,          1,        1,   153600, 0x43e0c910
>> -0,          2,          2,        1,   153600, 0x6c75a8f0
>> -0,          3,          3,        1,   153600, 0xaace1255
>> -0,          4,          4,        1,   153600, 0x42d3f439
>> -0,          5,          5,        1,   153600, 0xb225b396
>> -0,          6,          6,        1,   153600, 0xa615221c
>> -0,          7,          7,        1,   153600, 0x5401f5a9
>> -0,          8,          8,        1,   153600, 0xd274cef3
>> -0,          9,          9,        1,   153600, 0x7935f992
>> -0,         10,         10,        1,   153600, 0x7669e7c6
>> -0,         11,         11,        1,   153600, 0x527bd6a1
>> -0,         12,         12,        1,   153600, 0x0f33b2ed
>> -0,         13,         13,        1,   153600, 0xe62ddb32
>> -0,         14,         14,        1,   153600, 0x81541aa2
>> Test rscc-16bit failed. Look at tests/data/fate/rscc-16bit.err for details.
>> make: *** [fate-rscc-16bit] Error 137
>> --- ./tests/ref/fate/iscc       2016-12-15 04:39:33.920670759 +0100
>> +++ tests/data/fate/iscc        2016-12-15 15:59:04.479407669 +0100
>> @@ -3,8 +3,3 @@
>>  #codec_id 0: rawvideo
>>  #dimensions 0: 1760x968
>>  #sar 0: 0/1
>> -0,          0,          0,        1,  6814720, 0x1365f8ef
>> -0,          1,          1,        1,  6814720, 0x90838983
>> -0,          2,          2,        1,  6814720, 0xf0cc3131
>> -0,          3,          3,        1,  6814720, 0xc07e404d
>> -0,          4,          4,        1,  6814720, 0x945962dd
>> Test iscc failed. Look at tests/data/fate/iscc.err for details.
>> make: *** [fate-iscc] Error 137
>>
>> [...]
>
> Those are bugs in decoders.

Technically yes, however it has always been assumed that video
decoders consumer entire packets - with the exception of truncated
mode.
Personally I think we should be deprecating truncated mode, the new
API cleanly specifies always consuming full packets anyway.

In the meantime if this should be fixed, it should check for the flag
being set and then change behavior, because only truncate-aware video
decoders in truncate mode should really ever consume less then the
full packet.

- Hendrik