On Friday, December 15th, 2023 at 10:12 PM, Leo Izen <leo.i...@gmail.com> wrote:
> On 12/15/23 11:40, Zsolt Vadász via ffmpeg-devel wrote:
>
> > On Friday, December 15th, 2023 at 12:20 AM, Leo Izen leo.i...@gmail.com
> > wrote:
> >
> > > > + AVFrame *last;
> > >
> > > I don't see the purpose of keeping this here.
> >
> > The name is misleading, I should have named it `previous`, since it always
> > contains the previous frame.
> > I did it this way so I could call JxlEncoderCloseInput when the callback
> > received NULL.
>
>
> This isn't needed to call JxlEncoderCloseInput, as it takes one
> argument, which is JxlEncoder *.
Indeed, but according to the docs[0]:
"If the last frame or last box has been added, JxlEncoderCloseInput,
JxlEncoderCloseFrames
and/or JxlEncoderCloseBoxes must be called before the next
JxlEncoderProcessOutput call,
or the codestream won’t be encoded correctly."
When the encoder eventually receives NULL, there isn't anything left to add,
unless I store the previous frame,
is there?
> > > > +
> > > > + if(!ctx->last && !avctx->internal->draining) { > + ctx->last =
> > > > av_frame_clone(frame);
> > > > + *got_packet = 0;
> > > > + return AVERROR(EAGAIN);
> > >
> > > It looks like you're trying to emit one packet per image, rather than
> > > one packet per encoded frame. This is fine, but you should not be
> > > calling av_frame_clone, and there's no reason to use
> > > avctx->internal->draining here. If you are doing this, you also have no
> > > reason to cache ctx->last at all.
> >
> > It's the opposite, I'm trying to emit a packet for each frame of the
> > animation.
>
>
> Libjxl provides no promise of doing this meaningfully, by the way. You
> may end up with arbitrary subdivisions, not subdivisions on frame
> boundaries.
>
Well that's one thing I didn't account for, a real pity. Do you recommend
emitting a
single packet instead?
> > > > +const FFCodec ff_libjxl_animated_encoder = {
> > > > + .p.name = "libjxl_animated",
> > > > + CODEC_LONG_NAME("libjxl Animated JPEG XL"),
> > > > + .p.type = AVMEDIA_TYPE_VIDEO,
> > > > + .p.id = AV_CODEC_ID_JPEGXL,
> > > > + .priv_data_size = sizeof(LibJxlEncodeContext),
> > > > + .init = libjxl_animated_encode_init,
> > > > + FF_CODEC_ENCODE_CB(libjxl_animated_encode_frame),
> > > > + .close = libjxl_encode_close,
> > > > + .p.capabilities = AV_CODEC_CAP_OTHER_THREADS |
> > > > + AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE |
> > > > + AV_CODEC_CAP_DELAY,
> > > > + .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
> > > > + FF_CODEC_CAP_AUTO_THREADS | FF_CODEC_CAP_INIT_CLEANUP |
> > > > + FF_CODEC_CAP_ICC_PROFILES | FF_CODEC_CAP_EOF_FLUSH,
> > >
> > > Why FF_CODEC_CAP_EOF_FLUSH?
> >
> > So the encoder receives a NULL after the last frame has been submitted,
> > so JxlEncoderCloseInput can be called and the final frame properly emitted.
>
>
> Ah, that makes sense, thanks.
> _______________________________________________
> 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".
[0]
https://libjxl.readthedocs.io/en/latest/api_encoder.html#_CPPv423JxlEncoderProcessOutputP10JxlEncoderPP7uint8_tP6size_t
_______________________________________________
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".
