Suggestion: Add WebPAnimEncoderGetMuxer

[midora]

There is a WebPAnimDecoderGetDemuxer but no WebPAnimEncoderGetMuxer function.

gif2webp shows that you have to remux after WebPAnimEncoderAssemble to add xmp/exif data. This looks like a step you like to avoid.

[Pascal Massimino]

Hi Martin,

On Wed, Jan 5, 2022 at 7:42 AM midora <martin...@proregia.ch> wrote:

There is a WebPAnimDecoderGetDemuxer but no WebPAnimEncoderGetMuxer function.

gif2webp shows that you have to remux after WebPAnimEncoderAssemble to add xmp/exif data. This looks like a step you like to avoid.

IIRC, the risk is that, unless one successfully returns from  WebPAnimEncoderAssemble(), the internal mux_ to be exposed is in an

unfinished state. In particular (anim_encode.c:1559), the final canvas size is not finalized. Surfacing this unfinished object could be

doable, but risky. Another option would be to add loop_count, EXIF/XMP/ICC to the anim_options, so that they can be used during

WebPAnimEncoderAssemble() without having to expose any internal object.

Note that re-muxing is not a heavy operation, just clutter code that could be avoided, agreed.

skal/

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/701c5abd-a17f-4d77-8222-69649deaa57an%40webmproject.org.

[midora]

Hi Pascal,

I would prefer a solution which doesn't change the existing interface. I do not know quite well the internals, I just thought that adding an exif/xmp chunk wouldn't have an effect to the encoder muxer if you are doing it in front of WebPAnimEncoderAssemble.

But if this is the case then WebPAnimEncoderAssemble could be splitted in a part A which cleans up the state and a part B which does WebPMuxAssemble (line 1566). WebPAnimEncoderGetMuxer could do part A and set a flag in the encoder that this part has been done already. WebPAnimEncoderAssemble could use the flag to skip part A.

BTW: Setting the loopcount not immediately after WebPAnimEncoderOptionsInit is really special. Up to now I expected that the extension record containing the loopcount in gif must be in front of the first image record but you never know what gif creators are producing.

BTW2: I'm doing a c# plugin interface.

[midora]

Hi Pascal,

in the meantime I checked again the libwebp code and finally added WebPAnimEncoderGetMuxer. It works as expected.

I prefer symmetric interfaces... ;-)

Martin

[James Zern]

Hi,

On Mon, Jan 10, 2022 at 1:19 PM midora <martin...@proregia.ch> wrote:

Hi Pascal,

in the meantime I checked again the libwebp code and finally added WebPAnimEncoderGetMuxer. It works as expected.

I prefer symmetric interfaces... ;-)

I'm glad you got something to work for your use case. As Pascal was suggesting another option would be to instantiate a new muxer for the result of WebPAnimEncoderAssemble() [1]. This is hinted at in the example given for the API [2]. There isn't much overhead in the instantiation or mux process.

[1] https://developers.google.com/speed/webp/docs/container-api#mux_creation

[2] https://developers.google.com/speed/webp/docs/container-api#webpanimencoder_api

 

To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/f627133c-f784-4eda-a428-60bb30464c1dn%40webmproject.org.

[midora]

My first implementation followed somehow the example but then I switched to my patched libwebp containing WebPAnimEncoderGetMuxer. Already published the plugin. To keep the patch alive for new libwebp versions shouldn't be a big deal.

Will now check how I can load just the delta frames of the animation using a modified WebPAnim interface.