[FFmpeg-devel] [PATCH v10 2/5] libavcodec/webp: add support for animated WebP
Thilo Borgmann
thilo.borgmann at mail.de
Mon Feb 26 17:54:31 EET 2024
Am 19.02.24 um 19:01 schrieb Andreas Rheinhardt:
> James Almer:
>> On 2/19/2024 1:50 PM, Andreas Rheinhardt wrote:
>>> a) Use the receive frame callback for this decoder. This will
>>> necessitate changes to pthread_frame.c (which currently can't handle
>>> receive_frame decoders)
>>
>> There's a patch for this that i think Anton wrote and then Timo
>> improved. It was posted sometime ago.
>>
>>> Notice that the BSF I have in mind would not be a public BSF, but a
>>> private one (given that the output of the BSF would be spec-incompliant
>>> due to the wrong ordering it should not be public), i.e. one not
>>> accessible via av_bsf_get_by_name() or av_bsf_iterate().
>>
>> How do you propose to do this? And would you be willing to write the
>> framework for it?
>> It certainly sounds useful, as existing bsfs like vp9_superframe_split
>> already generate spec non-compliant packets, and they ideally should not
>> be publicly available.
>
> The way I envision is by using a const FFBitStreamFilter* instead of the
> name of the bsf in FFCodec.bsfs. (Of course, one can keep the
> open-by-string method (which also works for filterchains as long as they
> only use static arguments), too; it is also possible (by currently
> unneeded) to add bsfs during init with non-static arguments (based upon
> codec options etc.).)
> I'd be willing to write the code for this.
If that is useful for other codecs as well, let's do that.
Generating one packet per animation containing all frames+meta should be easy enough in the demuxer.
What do you expect the bsf to do exactly?
IIUC generate packets with one frame + meta for all frames in the animation from the big packet coming from the demuxer?
Thanks,
Thilo
More information about the ffmpeg-devel
mailing list