4 ms·

Container formats for video often need to: - contain multiple streams of synced video, audio, and subtitles - contain alternate streams of audio - contain ch

Container formats for video often need to: - contain multiple streams of synced video, audio, and subtitles - contain alternate streams of audio - contain chapter information - contain metadata such as artist information For web distribution of static images, you want almost none of those things, especially regarding alternate streams. You just want to download the one stream you want. Easiest way to do that is to just serve each stream as a separate file, and not mux different streams into a single container in the first place. Also, I could be wrong on this part, but my understanding is that for web streaming video, you don't really want those mkv* features either. You typically serve individual and separate streams of video, audio, and text, sourced from separate files, and your player/browser syncs them. The alternative would be unnecessary demux on the server side, or the client unnecessarily downloads irrelevant streams. The metadata is the only case where I see the potential benefit of a single container format. * Not specific to mkv, other containers have them of course

oefrha 3y ago
> You typically serve individual and separate streams of video, audio, and text, sourced from separate files, and your player/browser syncs them. That's one school of thought. Some of the biggest streaming providers simply serve a single muxed video+audio HLS stream based on bandwidth detection. Doesn't work very well for multi-language prerecorded content of course, but that's just one use case.
- dundarious 3y ago
  That's true, but my understanding is they serve a specific mux for a specific bandwidth profile, and serve it by just transmitting bytes, no demux required. I didn't mean to imply that wasn't a common option. I only meant to say I don't think a common option is to have a giant mux of all possible bandwidth profiles into one container file, that has to be demuxed at serve time. My understanding is that YouTube supports both the "separate streams" and "specific mux per-bandwidth profile" methods, and picks one based on the codec support/preferences of the client.
pixl97 3y ago
Container formats increase size. Now for video that doesn't matter much because it doesn't move the needle. For images a container format could be a significant percentage of the total image size.
- dundarious 3y ago
  Yes, I focused mostly on the lack of benefit, but even for a single stream, size is another important cost.
bmacho 3y ago
> The alternative would be unnecessary demux on the server side, or the client unnecessarily downloads irrelevant streams. HTTP file transfer protocols support partial downloads. A client can choose just to not to download irrelevant audio. I think most common web platforms already work this way, when you open a video it is likely to be in .mp4 format, and you need to get the end of it to play it, so your browser gets that part first. I am not entirely sure.
- toast0 3y ago
  I believe mp4 files can be repackaged to put the bookkeeping data at the front of the file, which makes them playable while doing a sequential download.
  - Tigress8780 3y ago
    That metadata is usually put around the end of the file for compatibility reasons, but one can use ffmpeg's `-movflags faststart` option to move it to the beginning (very common in files that are meant to be served on the web).

oefrha 3y ago

> You typically serve individual and separate streams of video, audio, and text, sourced from separate files, and your player/browser syncs them. That's one school of thought. Some of the biggest streaming providers simply serve a single muxed video+audio HLS stream based on bandwidth detection. Doesn't work very well for multi-language prerecorded content of course, but that's just one use case.

dundarious 3y ago
That's true, but my understanding is they serve a specific mux for a specific bandwidth profile, and serve it by just transmitting bytes, no demux required. I didn't mean to imply that wasn't a common option. I only meant to say I don't think a common option is to have a giant mux of all possible bandwidth profiles into one container file, that has to be demuxed at serve time. My understanding is that YouTube supports both the "separate streams" and "specific mux per-bandwidth profile" methods, and picks one based on the codec support/preferences of the client.

pixl97 3y ago

Container formats increase size. Now for video that doesn't matter much because it doesn't move the needle. For images a container format could be a significant percentage of the total image size.

dundarious 3y ago
Yes, I focused mostly on the lack of benefit, but even for a single stream, size is another important cost.

bmacho 3y ago

> The alternative would be unnecessary demux on the server side, or the client unnecessarily downloads irrelevant streams. HTTP file transfer protocols support partial downloads. A client can choose just to not to download irrelevant audio. I think most common web platforms already work this way, when you open a video it is likely to be in .mp4 format, and you need to get the end of it to play it, so your browser gets that part first. I am not entirely sure.

toast0 3y ago
I believe mp4 files can be repackaged to put the bookkeeping data at the front of the file, which makes them playable while doing a sequential download.
- Tigress8780 3y ago
  That metadata is usually put around the end of the file for compatibility reasons, but one can use ffmpeg's `-movflags faststart` option to move it to the beginning (very common in files that are meant to be served on the web).