Document mapping into containers

[JeromeMartinez]

As we did for FFV1, we should document mapping into common containers in order to be clear about how to do so.

"fLaC", METADATA_BLOCK_STREAMINFO, METADATA_BLOCK in track header
FRAME in container "blocks".

And document the known issues e.g. METADATA_BLOCK_STREAMINFO info is sometimes (file "cut") not relevant.

[ktmf01]

There is an ogg mapping document here: https://www.xiph.org/flac/ogg_mapping.html
There is a draft MP4 mapping here: https://github.com/xiph/flac/blob/master/doc/isoflac.txt

[ktmf01]

I can write something for ogg, perhaps the matroska-codecs RFC should be referenced, that's all well defined. I can't figure out the status of FLAC-in-MP4 though, it seems quite a mess with lots of bits and pieces. I have zero knowlegde of MP4, so I'd appreciate some help. Does anybody know who to contact on this matter?

There is a draft mapping: https://github.com/xiph/flac/blob/master/doc/isoflac.txt
There is an experimental muxer in ffmpeg
There is apparently an issue with the draft mapping: xiph/flac#38 and w3c/media-source#188

I've read the issue reports multiple times, but I don't understand what is what, and what the actual problem is. Similarly, I'm at a loss about whether code-points can be already registered, or whether this should happen after the flac specification becomes an RFC.

[phschafft]

Little note on mappings: The current documents are a bit unclear to me how the SEEKPOINTs are to be understood when in a container. Also given the problem of re-muxing which might change the offsets on the physical bitstream but not on the logical bitstream.

[ktmf01]

I would argue seekpoints are not in any way usable for FLAC files embedded in a container. First because the container will provide its own seeking method, and second because as you say the offsets are changed on remuxing, especially when other streams like video are also placed in that container. The seektable is embedded in Ogg/Matroska/MP4 streams but it serves no purpose other than being handy on demuxing the FLAC stream back to a file (which I presume is not a use case encountered often).

Case in point: libFLAC only uses a seektable in a non-embedded FLAC stream. For Ogg FLAC streams, it ignores the seektable altogether.

Perhaps a note should be added to the spec that a seektable metadata block may be encapsulated, but that is serves no purpose at all? Maybe we should even recommend to drop the seektable on embedding?

[phschafft]

I think clarification is needed. However I'm not sure about "that is serves no purpose at all":

• It may become relevant after demuxing. So it should be made clear if the seekpoint values refer to muxed or unmuxed byte offsets (physical offsets or per-logic stream offsets).
• Containers only ever add overhead. So the offsets are still valid in a "there or later" sense. So they can still be helpful for seeking as they allow an area of the file being skipped. If the demuxer/decoder has additional details it might even use a more precise guess. e.g.: "the correct position should be at the given offset plus 5%".
• In containers that store the data non-interleaved such as RIFF/WAVE the offsets are byte perfect valid as-is.

I think that a simple clarification would allow for all the above and keep being compatible without any downsides. It could read something similar to this: The offsets are within the FLAC bitstream. Any overhead added by containers is not included. Therefore when used inside containers the offsets provide a minimal offset in the physical bitstream which can aid seeking even when used within containers. It is save to restore seektables as-is when a) demuxing to native FLAC, b) remuxing into a different container.

Side note: Offsets are stored relative to the first audio block. So even if the container stores the headers in a different section (e.g. in the tail of the file, or provide them externally (think SIP/SDP)) the offsets are still valid.

PS: Maybe this discussion should go into it's own ticket.

[ktmf01]

I can't figure out the status of FLAC-in-MP4 though, it seems quite a mess with lots of bits and pieces. I have zero knowlegde of MP4, so I'd appreciate some help. Does anybody know who to contact on this matter?

There is a draft mapping: https://github.com/xiph/flac/blob/master/doc/isoflac.txt There is an experimental muxer in ffmpeg There is apparently an issue with the draft mapping: xiph/flac#38 and w3c/media-source#188

I've read the issue reports multiple times, but I don't understand what is what, and what the actual problem is. Similarly, I'm at a loss about whether code-points can be already registered, or whether this should happen after the flac specification becomes an RFC.

The registration of the IDs used in MP4 is complete, fLaC and dfLa are now listed at https://mp4ra.org/#/codecs