On Thu, Dec 15, 2016 at 4:07 PM, Paul B Mahol <one...@gmail.com> wrote:
> On 12/15/16, Michael Niedermayer <mich...@niedermayer.cc> wrote:
>> On Wed, Dec 14, 2016 at 10:05:50PM -0700, pkoshe...@gmail.com wrote:
>>> From: Pavel Koshevoy <pkoshe...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
