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 <[email protected]>, wrote: > On Sun, Aug 2, 2020 at 7:54 AM 王 氚 <[email protected]> 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 > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
