WebPDemux - user provided "Read" function

[lixo...@gmail.com]

I've been reading the samples here: https://developers.google.com/speed/webp/docs/container-api

Apparently there is no "stream" interface for the demux API. By that I mean a way to be able to provide some sort of
ReadInputData callback to WebPDemux and that function would be called whenever more data was needed. Pretty much the
inverse of the WebPWriterFunction we can use while encoding.

The "raw" API at least supports something like that through the use of WebPIAppend. Not ideal, but is better than nothing.
Unfortunatelly the demux API does not have something like that.

Was the lack of such feature a design decision? 

In the comments of WebPDemuxPartial you say: "Note that WebPDemuxer keeps internal pointers to data memory segment"
That lead me to believe that having a feature like the one I am asking for would require at least some extra memory 
allocations to keep track of such data, since the API would not have access to the whole buffer at once anymore. 

Maybe that was the reason? By forcing the whole data to be provided at once you are avoiding unnecessary memory 
allocations?. I can see that being a valid reason and I do agree with it (handling small images/animations probably 
corresponds to 99.999999% of the planned uses cases). The only problem is that it reduces the API usage to only 
relatively small image/animations, while the format itself supports much bigger sizes.

Am I right about my assumptions? Is there no way to provide some sort of ReadInputData function?

[Pascal Massimino]

Hi,

Yes, this is more or less the historical reason. The Muxing API was mostly designed for having a look inside the file and indexing its chunks

in order to retrieve some info about the WebP file structure. That's why we keep pointers to the input data, in particular, to avoid memory copies

since we're only analyzing the structure and parsing high-level syntax elements.

So, the strong assumption was that all the data is available (even if it turned out we could have 'partial' demuxing support rather easily by aborting

the parsing at the end of the available data).

Adding a ReadInputData is probably a bit stretchy here, all the more that we're trying to freeze the API.

thanks for the input!

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+unsubscribe@webmproject.org.
To post to this group, send email to webp-d...@webmproject.org.
Visit this group at https://groups.google.com/a/webmproject.org/group/webp-discuss/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.