[FFmpeg-devel] Question regarding ogg cover art implementation
Jesse Obic
jesseaobic at gmail.com
Mon Aug 23 02:49:04 EEST 2021
Hi,
First time using a mailing list and (properly) working with C, so please
forgive me if I've done something wrong.
I'm looking at implementing https://trac.ffmpeg.org/ticket/4448
<https://trac.ffmpeg.org/ticket/4448>, and I understand what I need to
do but I'm on the fence about how I should go about doing it.
For the OGG container, cover art is embedded into the file by adding a
METADATA_BLOCK_PICTURE tag in the vorbis comment section. The data of
this tag is a base64 representation of the FLAC embedded image data
structure, which includes the data of the image itself.
I looked at how vorbis comments are currently written, and it's lead me
to `ff_vorbiscomment_write`. It takes in an AVDictionary for metadata,
and an array of AVChapters for chapter writing. This is where I get a
bit concerned.
I see two options as to how I could handle this:
1. Place the METADATA_BLOCK_PICTURE tag in the metadata AVDictionary.
This would be the easiest functionality wise, however it feels like a
bad idea in my gut because the dictionary would be housing a value that
is 1.33 * the size of the image(s) being embedded. So for example, if
you wished to embed a 12 MB image it would require a 16MB malloc which
doesn't feel right.
The ogg specification allows for multiple embedded images by specifying
the same METADATA_BLOCK_PICTURE tag multiple times, which would require
me to use AV_DICT_MULTIKEY when adding values to the dictionary. I
couldn't find any examples of using it within the source code for either
writing or reading (which I will have to handle in oggdec.c as well), so
I'm not sure if other parts of the codebase will handle it well. This is
probably more paranoia than anything.
2. Change ff_vorbiscomment_write to take in an array of AVStream /
AVPacket to write it directly to the output IO stream
As far as I know this would classify as an API/ABI change. However it
would mean that I don't have to allocate such a huge array upfront, and
can encode smaller chunks at a time as I write them to the output stream.
To mitigate it, it could be created as a new function with the
additional parameters, and the old function pointing towards the new one
instead. I'm not entirely sure how APIs / ABIs are exposed and consumed
in C, so I'm not sure if this will fix the issue.
I'm interested in what people think about how I should tackle this
issue. It was annoying enough that I downloaded the source code and set
up a compilation environment, so I'd like to get working on this.
More information about the ffmpeg-devel
mailing list