Can a read API be created instead of using avifRawData? about libavif HOT 10 CLOSED

I thought a lot about this, and it might not be too awful to hook up. The plan (for read) would be to leave the memory streams and parsing code intact, but add in a layer specifically for avifParse() and the sample gathering code. Seeing as avifParse() simply skips over the largest part of the file (mdat) and the other top-level boxes are "small", a little bit of cleverness at the toplevel parse function should buy quite a lot.

I'd probably make the reader/writer API itself responsible for the buffer it returns to libavif, to facilitate the avifROStream mechanisms that exist, and to allow the current fully-in-memory path to exist. It should be as simple as Dale suggests (please give me x bytes from offset y).

from libavif.

Writing will be trickier, as the current flow requires that I know all of the final sample sizes and offsets in order to generate the correct meta box. It'd be easy to put in a writer API, but without any kind of significant memory savings, it'd just be "for show". I'll have to think about that one.

from libavif.

Yes.

from libavif.

It would be great if libavif provides API allowing to pass our own reading/writing/seeking i/o functions. Like it does libpng (png_set_read_fn, png_set_write_fn) or libtiff (TIFFClientOpen).

from libavif.

@joedrago I'm less concerned about the output AVIF buffer but would prefer a way to stream the input file (which is uncompressed) into the decoder. Is this already possible?

from libavif.

@joedrago I'm less concerned about the output AVIF buffer but would prefer a way to stream the input file (which is uncompressed) into the decoder. Is this already possible?

Hi Moritz: Did you mean the input file is compressed or uncompressed? The input to the decoder should be a compressed image file.

from libavif.

Right, but let's say I have a 10MB PNG file then preferably I'd be able to feed it to the encoder in chunks instead of loading the image in memory and passing it to the encoder. I assume that's problematic because we also have to go through the RGB -> YUV conversion.

from libavif.

libavif itself has no PNG support; only the command line tool avifenc does. If your goal is to read in a non-AVIF and give it to libavif in your own tool, you can read the image in however you want. I don't see how streaming PNG input is relevant to libavif?

from libavif.

It looks like the recently added avifIO functionality fixes the issue?

from libavif.

Great! :) I guess this issue could be closed then.

from libavif.