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
_______________________________________________
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".
