[FFmpeg-devel] [PATCH] libavcodec/videotoolbox: let VideoToolbox choose a decoder for us

[王 氚]

I can observe GPU consumption and lower CPU consumption in this case just like decoding 640x480 which obviously using hardware decoding(since it succeed in first attempt) in my MacBook.

So from my point of view, it still uses hardware decoding.

I’m still not sure whether or not all apple’s device following this behavior. But maybe this is user’s responsibility to choose which type of decoding they want. If they want to use hardware decoding, we can try to find one, if they feel not good, it’s freely to change it, especially for the case https://trac.ffmpeg.org/ticket/8789
On Aug 2, 2020, 3:09 PM +0800, Hendrik Leppkes <h.leppkes at gmail.com>, wrote:
> On Sun, Aug 2, 2020 at 7:54 AM 王 氚 <ouchuanm at outlook.com> wrote:
> >
> > Just dig it a little bit, and I found that the first attempt of [VTDecompressionSessionCreate] is always ok, if we try to decode some normal size of video(for example, 640x480, 1280x720...)
> >
> > But it will fail, it we try to decode h264 video with some special size(for example, 300x180).
> >
> > So it seems like there are some limitations in [VTDecompressionSessionCreate], but if we give VideoToolbox freedom to choose a decoder, it's always OK.
> >
>
> What other decoders could it possibly pick? Is it still using hardware
> decoding, or is that a software decoder then?
> Our software decoders are likely better then running software decoding
> through VT, so falling back to that would be better.
>
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".