>fre 2023-03-10 klockan 10:17 +0100 skrev Nicolas Gaullier:
>> +                if (i == c->nb_groups - 1
>> +                    && count * size1 > get_bits_left(&s->gb)
>> +                    && get_bits_left(&s->gb) >= 0
>> +                    && (int)(mnt - c->mantissas) >= MIN_MANTISSAS) {
>> +                    av_log(s->avctx, AV_LOG_WARNING, "Truncated
>> mantissas @%d, "
>> +                        "highest frequencies not recoverable\n",
>> (int)(mnt - c->mantissas));
>> +                    break;
>> +                }
>
>Surely there's a proper way to fix this rather than having an arbitrary 
>threshold. At the very least the get_bits_left() check could be moved to 
>before parse_mantissas(). If get_bits_left() is < 0 after
>parse_mantissas() then a warning could be issued instead of erroring out, 
>which should have an effect similar to this.
>
>Is there a spec saying what to do with truncated packets? Since this is 
>Dolby-E I suspect the answer is "no".
>
>/Tomas

Thank you for inspecting the patch.
Concerning the arbitrary threshold: it may be understood as a very high level 
safeguard, but my intend was mostly to make the code more easily understandable.
Actually, the fix is restricted to the last audio band (see "i == c->nb_groups 
- 1") and, at the end, the MIN_MANTISSAS condition could be simply removed with 
no audible risk, I guess.
But to get this precision, the fix cannot be moved elsewhere. The idea here is 
to still be able to detect harsh packet truncation with full errors and keep 
current code behaviour in that case.

Of course, this patch looks as a work-around, but a work-around that make it 
possible to decode the official reference bitstream implementation (dp600 at 
least, but maybe they are no different ones).
So, this is a somewhat special scenario. Sadly, I don't see any another way to 
handle this.

To conclude, I don't have any other idea than the complete removal of the 
arbitrary threshold. Would it make the patch more acceptable ?

Nicolas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to