> On May 20, 2024, at 12:01 PM, Rémi Denis-Courmont <r...@remlab.net> wrote: > > Le maanantaina 20. toukokuuta 2024, 21.39.18 EEST Cosmin Stejerean via ffmpeg- > devel a écrit : >> The same way using FDK-AAC as a decoder works, if you want to use it as the >> *AAC decoder you have to specify the decoder with -c:a libfdk_aac before >> the input.- > > AFAIK, we don't have hwaccel for audio codecs. That sentence makes zero sense.
This is unrelated to hwaccel, I'm illustrating how a non-default decoder is selected in practice. It just so happens I always need to do this for audio currently. > > And again, you can't expect users to select decoders manually. If vvdec is > the > default, hwaccel won't work. If vvdec is not the default, then it's dead code. Not sure why you keep returning to this false dichotomy. You absolutely can have a decoder that's not the default, there is a facility for selecting it, and I use this to select the non-default decoder despite you claiming that non-default decoders are dead code, or that manually selecting them isn't a thing that users do. >> Where is the "requiring" part coming in? I'm saying that manual decoder >> selection is an option in the ffmpeg CLI, and can be used to select an >> alternate decoder if the default one is not sufficient for some reason. > > So most people use libavcodec through higher-level frameworks or > applications, > not the CLI tool, and that is especially true for playback. If that's the > super-niche use-case for vvdec, then I agree with Kieran that it's just bloat. Yes, the use case would be to be an alternate decoder that's available to users that want to use it. If that's not your use case that's ok, don't build with --enable-libvvdec. - Cosmin _______________________________________________ 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".
