[FFmpeg-devel] [PATCH] avcodec/av1dec: export pixel format even if no hardware decoder is present
James Almer
jamrial at gmail.com
Thu Sep 7 17:30:02 EEST 2023
On 9/7/2023 5:06 AM, Andreas Rheinhardt wrote:
> James Almer:
>> And remove the AVOID_PROBING flag, given it's the last av1 decoder to be tested
>> either way.
>> This fixes a regression introduced in 1652f2492f88434010053289d946dab6a57e4d58,
>> where even if forcing the native av1 decoder, if another decoder was present,
>> like libdav1d or libaom-av1, they'd be used for probing and some fate tests
>> would have different results.
>>
>> Signed-off-by: James Almer <jamrial at gmail.com>
>> ---
>> libavcodec/av1dec.c | 8 ++++----
>> tests/fate/lavf-container.mak | 8 ++++----
>> tests/ref/fate/av1-annexb-demux | 2 +-
>> tests/ref/lavf-fate/av1.mkv | 4 ++--
>> tests/ref/lavf-fate/av1.mp4 | 4 ++--
>> 5 files changed, 13 insertions(+), 13 deletions(-)
>>
>> diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
>> index ec8401f4e0..a1e08185a7 100644
>> --- a/libavcodec/av1dec.c
>> +++ b/libavcodec/av1dec.c
>> @@ -612,6 +612,9 @@ static int get_pixel_format(AVCodecContext *avctx)
>> if (ret < 0)
>> return ret;
>>
>> + s->pix_fmt = pix_fmt;
>> + avctx->pix_fmt = ret;
>> +
>> /**
>> * check if the HW accel is inited correctly. If not, return un-implemented.
>> * Since now the av1 decoder doesn't support native decode, if it will be
>> @@ -623,9 +626,6 @@ static int get_pixel_format(AVCodecContext *avctx)
>> return AVERROR(ENOSYS);
>
> Is the log message here actually accurate? The get_format callback
> choosing the software pixel format does not mean that the hardware this
> is run on or the lavc binary in use do not support hardware accelerated
> AV1 decoding.
It's not, but that's also unrelated to this patch.
> (How is an API user actually supposed to know that decoding will fail if
> the software pixel format is selected?)
Other than the first returned ENOSYS, nothing. I could make it always
return ENOSYS, same as before this patch, but anything we do will
probably be hacky unless we add an actual software implementation.
More information about the ffmpeg-devel
mailing list