[FFmpeg-devel] [PATCH 1/2] Add experimental muxing support for FLAC in ISO BMFF (MP4).

James Almer jamrial at gmail.com
Tue Nov 1 05:56:45 EET 2016

On 10/31/2016 10:11 PM, Matthew Gregan wrote:
> At 2016-10-31T11:04:16-0300, James Almer wrote:
>>> +static int mov_write_dfla_tag(AVIOContext *pb, MOVTrack *track)
>>> +{
>>> +    const size_t FLAC_STREAMINFO_SIZE = 34;
>>> +    int64_t pos = avio_tell(pb);
>>> +    avio_wb32(pb, 0);
>>> +    ffio_wfourcc(pb, "dfLa");
>>> +    avio_w8(pb, 0); /* version */
>>> +    avio_wb24(pb, 0); /* flags */
>>> +
>>> +    /* Expect the encoder to pass a METADATA_BLOCK_TYPE_STREAMINFO. */
>> The encoder may (or most likely will) also pass an updated streaminfo as
>> packet side data.  See the flac muxer, you'll have to do the same here.
> Thanks.  It looks like libavcodec/flacenc.c#flac_encode_frame updates the
> extradata at the same time it emits the packet side data, so I'm slightly
> confused why this is needed.

The muxer gets the extradata as created by the encoder only during init().
Even if the encoder changes it in any way afterwards, it will never make
it to the muxer. That's why packet side data is used for this.

The reason the encoder used the AVCodecContext extradata to store the
updated Streaminfo before creating the packet side data is most likely
because it was an already allocated buffer. Technically, it's not the
"proper" thing to do, but it also doesn't seem to make a difference.

> Seems to be easy to handle by extending the existing case for
> AV_CODEC_ID_MP4ALS in mov_write_single_packet.  That assumes pkt->size == 0,
> which seems to be true when the packet side data is emitted in
> flac_encode_frame.
> Updated patch attached.

Looks like it works now.

No comments about the actual implementation or the spec. I'll let someone
more familiar with mp4/mov do that instead.

More information about the ffmpeg-devel mailing list