9 ms·

As a streaming industry software engineer: File based streaming is done not for DRM but because of distribution cost and user experience. A segmented ABR video

by zbobet2012 7y ago

As a streaming industry software engineer: File based streaming is done not for DRM but because of distribution cost and user experience. A segmented ABR video delivery massively decreases CDN costs (which is why Youtube, which is drm free does it). Video startup times, seek times, thumbnail scrubbing, fast forward, clip previews, ad insertion and many other things don't work in a file based experience. In addition subtitles, secondary audio, descriptive video, and multi-view video etc. are all things which we mandate by law which do not work well in a file base expierenced. Peer to peer as a distribution method is not only know, but there are plenty of providers that use peer to peer like streaming setups (see https://streamroot.io/streamroot-dna/ https://streamroot.io/streamroot-dna/). You may be using something like BitTorrent and _not even know it_. Distribution is 1/10th the story and DRM is only a small part of it as well. BitTorrent does nothing to solve the other 9/10ths and removing DRM doesn't either.

DevoidSimo 7y ago
Why do you say subtitles and secondary audio (I assume you mean multiple language tracks) don't work well? I've downloaded files with multiple subtitles and audio tracks, which VLC makes easy to switch between. Admittedly, many/most torrents don't offer these but that doesn't mean they can't.
- developer2 7y ago
  Subtitles are not a burden; downloading a single torrent with a dozen subtitle tracks adds negligible bytes to the overall download size. Audio tracks are a tad rougher; the good torrents come with multiple tracks, but you are downloading all audio tracks even if you only play a single language–and the size of those audio tracks is not as negligible. Most people with large or unlimited bandwidth simply don't care about "paying the price" for multiple audio tracks; it takes a few extra minutes, at $0 additional financial cost. The rest is your parent justifying their job/industry as if they're a Godsend–perhaps as compared to cable? It's an indefensible position thus far. The streaming services are all trash with pathetic bitrates; all streams average the same ridiculously low bitrate over the entire stream, without accounting for dark scenes that require orders of magnitude more bandwidth. Every Netflix (and competitors') 1080p streams with dark scenes are unwatchable. It's highway robbery to deliver what looks like 180p frames for a 1080p stream. We're supposed to be at 4K these days, yet they can't even deliver acceptable 1080p. Until the streaming services are willing to stop compressing everything far beyond watchable levels, they don't deserve anyone's business. Netflix, I believe, averages ~3-5 GB for a 90-120 minute movie? That number should be, at least via opt-in to those with the bandwidth for it, 20-40+ GB. I don't necessarily expect fully uncompressed Blu-ray quality, but the standard should be to deliver something watchable, without banding artifacts. At a minimum that would mean massively variable bitrates, where the highest bitrate of a stream should be allowed to be 10-20x+ its minimum bitrate. Compressing a 60+ GB original file into a download of than 5 GB is flat out unacceptable and unjustifiable.
  - zbobet2012 7y ago
    Netflix and other (similar) streaming services which user per-title encoding technologies deliver a harmonic mean PSNR of greater than 45 and greater than 94 VMAF on their highest rendition, which most well connected users pull. This is visually indistinguishable from a lossless encode. Complaining about the _size_ or _bitrate_ of encoded file isn't worthwhile. Encoding technology has advanced substantially since blue-ray days and we simply no longer needs the 40mbps bitrate. Indeed HEVC can offer a mathematically lossless encode at around 90mbps for most content.
    - krageon 7y ago
      I'm sure you're very knowledgeable and correct about a lot of things, but where your argumentation falls down most is user experience. A concrete example: You say here that what Netflix provides is "visually indistinguishable from a lossless encode". Try actually doing this with an open mind and then make this claim again. It was definitely not the case when I last tried it (very recently). Argumentation of this nature is sort of endemic in the tech industry: "You think you see or experience this, but I know what you see and experience and you are wrong". It happens in discussions about battery life, visual appeal of different encoding options, basically anything which is at some point subjective and while the people claiming to see a difference could be (factually) wrong in a lot of cases (I often cannot tell), it is very arrogant to sit/stand there and tell them that you know better than them what they see.
      - dual_basis 7y ago
        But what about when it has been tested and proven that people cannot discern the difference? I don't know if this is what was done with the per-title encoding that the parent comment was referring to, but I know it is the situation with audio. So many audiophiles swear they can hear a difference between FLAC and high quality VBR MP3, but it has been repeatedly demonstrated that, when presented with both, humans cannot distinguish them better than chance.
        krageon 7y ago
- zbobet2012 7y ago
  VLC works for the subset of subtitles you, an English speaking user, uses. VLC subtitle support does not support things like ASA or EBU subtitles which are used in other parts of the world. In addition rendering of those subtitles is very constrained. These can be added or configured of course. Secondary audio is not only additional languages but things like descriptive video services (narration for the blind). VLC does not generally support having multiple active audio tracks without flagging things on the command line.
  - mijamo 7y ago
    Arabic/chinese/japanse subtitles work perfectly in VLC work perfectly and look much nicer tahn on Netflix for instance. I have never seen descriptive video services in any streaming service so I very much doubt it is a major issue, and even in that case why wouldn't you be able to mix it with the main track in a separate channel (which is what is done on TV, as TV does not support multiple active tracks either) ?
    - afiori 7y ago
      > I have never seen descriptive video services in any streaming service netflix has them
      - fooker 7y ago
        What if some particular video doesn't? If I have a file I can download a .srt and have the video player display it.
    - zzo38computer 7y ago
      Even so, being able to mix the premixed descriptive video track with the normal audio track may still be helpful to users who want different mixing levels than what they used (because sometimes the music is too quiet, for example). (I don't like descriptive video so much myself, but some people do use it, and so may wish to alter the setting.)
  - imtringued 7y ago
zeptomu 7y ago
> In addition subtitles, secondary audio, descriptive video, and multi-view video etc. are all things which we mandate by law which do not work well in a file base expierenced. That's just not true - VLC has many more features than all the web-based (or "app"-based) popular streaming players. Granted, I checked and my VLC does not have "thumbnail scrubbing", but although that is nice, I don't think this is a big deal and if it's really popular, it will be added to VLC (or it may already be there, I did not check).
- JohnBooty 7y ago
  I'm a big fan of torrents and would prefer them to streams! I'm a bit of a data hoarder. But there are clear reasons why Netflix et al don't simply have you downloading massive files. It would definitely be simpler, but that doesn't mean it's an adequate engineering choice. Lot of smart people working there and they don't jump through all those extra hoops just for fun. 1. You can't play a torrented file until the download is 100% complete. (Well, maybe 95% complete, depending on how tolerant you and your software are when it comes to malformed files) That's the way it was designed to work. Otherwise, the bits at the beginning of the file would be much more common amongst your non-seeding peers and the bits at the end would be much rarer amongst your non-seeding peers. Your downloads would start crazy fast and would get progressively slower. Some clients let you abuse the protocol and "stream" torrents sequentially, but if significant percentages of torrenters (such as literally every Netflix user, in an imaginary world where Netflix simply served everything via torrents) did that it would be an issue. That's a great way to deliver big files in their entirety via P2P, but that is pretty much the pathological opposite of what is requred for streaming. For streaming you obviously need that sequential access. You need to optimize for the beginning of the file, since people want to start watching right away. People do not want to wait 60 or 30 or even 10 seconds for a YouTube vid to start streaming. 2. Think about your actual viewing habits. How many times have you watched the first 1% of a video on YouTube or Netflix, and then decided to watch something else instead? Even if we (probably generously) assume most users watch an average of 50% of a given video (I suspect it's much less) that's still 2x wasted bandwidth per video, on average, if video providers blasted out entire files. Netflix's infrastructure (or rather, their AWS monthly bill) is massive already. Imagine it being asked to blast out 2 or 5 or 10x as much data per video as it's already doing. 3. There's also the rather important matter of many (most?) playback devices not having huge gobs of local storage with which to hold complete movie downloads. I've got probably 20TB of hard drives scattered around this place, but that's not the norm. 4. Can't adapt to changing bandwidth conditions by scaling video quality up and down midstream. Personally, I wish I had more control over this as a customer, as sometimes I'd rather just wait than watch a compromised stream, but Average Joe is not going to want to muck around with that sort of choice, or even understand what it means.
mdorazio 7y ago
> Video startup times, seek times, thumbnail scrubbing, fast forward, clip previews, ad insertion and many other things don't work in a file based experience. Not a single one of these things is true. In fact, file-based delivery offers a superior experience in several of them with proper implementation. Streaming is popular because it lowers distribution costs, decreases piracy, and allows rights holders to pull content whenever they want. Personally, I hate streaming. Buffering sucks. Bitrates suck. Audio quality sucks. Never knowing how long something I like will actually be available sucks. It's just an all-around bad experience if you care about your media.
- zbobet2012 7y ago
  Video startup times are kept low in modern clients by starting at low bitrates and then seamless adaptation up. This is very important for advertising companies, social media, live streams, etc. Every second of startup time cost massive user loss in live streaming (this is well researched and documented). Additionally streaming protocols (HLS/DASH) force files to be encoded such that a full download is not required for a decode to happen. This is not a requirement (and pretty rare unless you know what you are doing with an encoder) for file based workflows. Fast forward for low power clients relies on an "iframe only" track as there decoders can't do many x realtime decode. This is not present in modern file based work flows. Seeks use the same startup/segmentation requirements as video startup. Thumbnail scrubbing requires a thumbnail track and is not supported by file based workflows at all. Clip previews on sites load at low resolution/bitrates and can be poped up to "full resolution" via ABR. Doing a preview of 10x 4k streams without abr wouldn't work even on a modern gaming rig. I'd love to hear how you'd do SSAI on top of a file based workflow. You could of course build a "file based" implementation that had all of these features, but you would just be rebuilding DASH or HLS.
  - ryantriangles 7y ago
    Popular video file players have supported generating iframe tracks for fast forwarding and thumbnail scrubbing for many years now, is there something about the way eg MPCBE and PotPlayer operate that is somehow unreasonable?
ngcc_hk 7y ago
P2P solves it. Just not the payment side. Only if one can pay. I do not even mind it is drm as long as I can get a good quality one in 10 minutes. Even if I contribute bandwidth (as long as controller and during my download) and paid. There is always someone not paid. But it is those who can and willingly do which oddly leave out. Like Mp3 in 1990s.
- TheOtherHobbes 7y ago
  P2P could have totally transformed the industry if it had worked out a way to pay creators - especially niche creators and beginners. It would have owned discovery, which would have badly damaged the big studios. And Netflix would probably have never happened. It would have been a similar story in music. But P2P was always about people who think a file is a file is a file, and creation costs are an externality, which can be ignored as irrelevant. So now we have TPB limping along, and new creators are mostly owned by YT - which is legendary for draconian application of copyright in the favour of fellow corporates.
mises 7y ago
> In addition, subtitles, secondary audio, descriptive video, and multi-view video etc. are all things which we mandate by law which do not work well in a file base expierenced. Since when are subtitles mandated by law? "Multi-view video"? Maybe I'm just missing something, but I've never heard of any law mandating any of the things you listed above (except maybe from a government-funded project, but I'm not sure either, that just seems more likely to require it).
- dylz 7y ago
  There's been stuff like this: https://www.insidehighered.com/news/2017/03/06/u-california-berkeley-delete-publicly-available-educational-content https://www.insidehighered.com/news/2017/03/06/u-california-...
  - mises 7y ago
    That's pretty crazy. I understand "reasonable accommodation", but doing that for so much content is beyond. Better most of the population gets it that no one can because a few edge cases can't consume it normally. I understand the need for wheelchair ramps, but this is like saying that every building that doesn't have one must add one or be torn down.
feanaro 7y ago
> Video startup times, seek times, thumbnail scrubbing, fast forward, clip previews, ad insertion and many other things don't work in a file based experience. One of these things is not like the others.
zzo38computer 7y ago
Subtitles, secondary audio, etc can work in files if those things are encoded in the file. Something like the television captions could be work and then the playback software can be configured what fonts and colours to use to display them, or to not display them at all, and possibly implement stuff such as caption scrollback that the provider did not put in, even. Still, there is many reason for having the streaming, although it should be a open protocol and not too complicated. And then, if you write a client software and program it to save the file to disk, it can do that too, possibly during playback, and you can program in other stuff too if you want to do. I thought of idea of Live Audio Video Protocol (but have not actually written any part of it yet, but have some ideas about it), that you can use Ogg streams and you can initiate with file selection, format/quality negotiation, etc, and then receive the stream but you can also send commands to select a channel or subchannel, pause, seek, request data, rate of keyframes (if the server supports changing this, which it might not), and change other settings. (Actually, I find a few problems with Ogg, and everything else is too complicated, so I made up something which is slightly more complicated than Ogg but not too much, which is called GLOGG; it is mostly like Ogg, but uses UUIDs to identify codecs, allows identifying how individual streams are related (the relation codes are specific to the codec, and are not defined by the container format; you can also specify if a program that does not understand it should ignore it), and a few other things, but still simple compared to most other container formats.) And about ad insertion, they do that on television without any problem, so I don't know how that is a problem any differences whether it is a stream or file. (Although sometimes they put stuff within the show itself and damaging the picture, they should not do, but that is only my opinion and is unrelated to the protocols.)

DevoidSimo 7y ago

Why do you say subtitles and secondary audio (I assume you mean multiple language tracks) don't work well? I've downloaded files with multiple subtitles and audio tracks, which VLC makes easy to switch between. Admittedly, many/most torrents don't offer these but that doesn't mean they can't.

developer2 7y ago
Subtitles are not a burden; downloading a single torrent with a dozen subtitle tracks adds negligible bytes to the overall download size. Audio tracks are a tad rougher; the good torrents come with multiple tracks, but you are downloading all audio tracks even if you only play a single language–and the size of those audio tracks is not as negligible. Most people with large or unlimited bandwidth simply don't care about "paying the price" for multiple audio tracks; it takes a few extra minutes, at $0 additional financial cost. The rest is your parent justifying their job/industry as if they're a Godsend–perhaps as compared to cable? It's an indefensible position thus far. The streaming services are all trash with pathetic bitrates; all streams average the same ridiculously low bitrate over the entire stream, without accounting for dark scenes that require orders of magnitude more bandwidth. Every Netflix (and competitors') 1080p streams with dark scenes are unwatchable. It's highway robbery to deliver what looks like 180p frames for a 1080p stream. We're supposed to be at 4K these days, yet they can't even deliver acceptable 1080p. Until the streaming services are willing to stop compressing everything far beyond watchable levels, they don't deserve anyone's business. Netflix, I believe, averages ~3-5 GB for a 90-120 minute movie? That number should be, at least via opt-in to those with the bandwidth for it, 20-40+ GB. I don't necessarily expect fully uncompressed Blu-ray quality, but the standard should be to deliver something watchable, without banding artifacts. At a minimum that would mean massively variable bitrates, where the highest bitrate of a stream should be allowed to be 10-20x+ its minimum bitrate. Compressing a 60+ GB original file into a download of than 5 GB is flat out unacceptable and unjustifiable.
- zbobet2012 7y ago
  Netflix and other (similar) streaming services which user per-title encoding technologies deliver a harmonic mean PSNR of greater than 45 and greater than 94 VMAF on their highest rendition, which most well connected users pull. This is visually indistinguishable from a lossless encode. Complaining about the _size_ or _bitrate_ of encoded file isn't worthwhile. Encoding technology has advanced substantially since blue-ray days and we simply no longer needs the 40mbps bitrate. Indeed HEVC can offer a mathematically lossless encode at around 90mbps for most content.
  - krageon 7y ago
    I'm sure you're very knowledgeable and correct about a lot of things, but where your argumentation falls down most is user experience. A concrete example: You say here that what Netflix provides is "visually indistinguishable from a lossless encode". Try actually doing this with an open mind and then make this claim again. It was definitely not the case when I last tried it (very recently). Argumentation of this nature is sort of endemic in the tech industry: "You think you see or experience this, but I know what you see and experience and you are wrong". It happens in discussions about battery life, visual appeal of different encoding options, basically anything which is at some point subjective and while the people claiming to see a difference could be (factually) wrong in a lot of cases (I often cannot tell), it is very arrogant to sit/stand there and tell them that you know better than them what they see.
    - dual_basis 7y ago
      But what about when it has been tested and proven that people cannot discern the difference? I don't know if this is what was done with the per-title encoding that the parent comment was referring to, but I know it is the situation with audio. So many audiophiles swear they can hear a difference between FLAC and high quality VBR MP3, but it has been repeatedly demonstrated that, when presented with both, humans cannot distinguish them better than chance.
      - krageon 7y ago
zbobet2012 7y ago
VLC works for the subset of subtitles you, an English speaking user, uses. VLC subtitle support does not support things like ASA or EBU subtitles which are used in other parts of the world. In addition rendering of those subtitles is very constrained. These can be added or configured of course. Secondary audio is not only additional languages but things like descriptive video services (narration for the blind). VLC does not generally support having multiple active audio tracks without flagging things on the command line.
- mijamo 7y ago
  Arabic/chinese/japanse subtitles work perfectly in VLC work perfectly and look much nicer tahn on Netflix for instance. I have never seen descriptive video services in any streaming service so I very much doubt it is a major issue, and even in that case why wouldn't you be able to mix it with the main track in a separate channel (which is what is done on TV, as TV does not support multiple active tracks either) ?
  - afiori 7y ago
    > I have never seen descriptive video services in any streaming service netflix has them
    - fooker 7y ago
      What if some particular video doesn't? If I have a file I can download a .srt and have the video player display it.
  - zzo38computer 7y ago
    Even so, being able to mix the premixed descriptive video track with the normal audio track may still be helpful to users who want different mixing levels than what they used (because sometimes the music is too quiet, for example). (I don't like descriptive video so much myself, but some people do use it, and so may wish to alter the setting.)
- imtringued 7y ago

zeptomu 7y ago

> In addition subtitles, secondary audio, descriptive video, and multi-view video etc. are all things which we mandate by law which do not work well in a file base expierenced. That's just not true - VLC has many more features than all the web-based (or "app"-based) popular streaming players. Granted, I checked and my VLC does not have "thumbnail scrubbing", but although that is nice, I don't think this is a big deal and if it's really popular, it will be added to VLC (or it may already be there, I did not check).

JohnBooty 7y ago
I'm a big fan of torrents and would prefer them to streams! I'm a bit of a data hoarder. But there are clear reasons why Netflix et al don't simply have you downloading massive files. It would definitely be simpler, but that doesn't mean it's an adequate engineering choice. Lot of smart people working there and they don't jump through all those extra hoops just for fun. 1. You can't play a torrented file until the download is 100% complete. (Well, maybe 95% complete, depending on how tolerant you and your software are when it comes to malformed files) That's the way it was designed to work. Otherwise, the bits at the beginning of the file would be much more common amongst your non-seeding peers and the bits at the end would be much rarer amongst your non-seeding peers. Your downloads would start crazy fast and would get progressively slower. Some clients let you abuse the protocol and "stream" torrents sequentially, but if significant percentages of torrenters (such as literally every Netflix user, in an imaginary world where Netflix simply served everything via torrents) did that it would be an issue. That's a great way to deliver big files in their entirety via P2P, but that is pretty much the pathological opposite of what is requred for streaming. For streaming you obviously need that sequential access. You need to optimize for the beginning of the file, since people want to start watching right away. People do not want to wait 60 or 30 or even 10 seconds for a YouTube vid to start streaming. 2. Think about your actual viewing habits. How many times have you watched the first 1% of a video on YouTube or Netflix, and then decided to watch something else instead? Even if we (probably generously) assume most users watch an average of 50% of a given video (I suspect it's much less) that's still 2x wasted bandwidth per video, on average, if video providers blasted out entire files. Netflix's infrastructure (or rather, their AWS monthly bill) is massive already. Imagine it being asked to blast out 2 or 5 or 10x as much data per video as it's already doing. 3. There's also the rather important matter of many (most?) playback devices not having huge gobs of local storage with which to hold complete movie downloads. I've got probably 20TB of hard drives scattered around this place, but that's not the norm. 4. Can't adapt to changing bandwidth conditions by scaling video quality up and down midstream. Personally, I wish I had more control over this as a customer, as sometimes I'd rather just wait than watch a compromised stream, but Average Joe is not going to want to muck around with that sort of choice, or even understand what it means.

mdorazio 7y ago

> Video startup times, seek times, thumbnail scrubbing, fast forward, clip previews, ad insertion and many other things don't work in a file based experience. Not a single one of these things is true. In fact, file-based delivery offers a superior experience in several of them with proper implementation. Streaming is popular because it lowers distribution costs, decreases piracy, and allows rights holders to pull content whenever they want. Personally, I hate streaming. Buffering sucks. Bitrates suck. Audio quality sucks. Never knowing how long something I like will actually be available sucks. It's just an all-around bad experience if you care about your media.

zbobet2012 7y ago
Video startup times are kept low in modern clients by starting at low bitrates and then seamless adaptation up. This is very important for advertising companies, social media, live streams, etc. Every second of startup time cost massive user loss in live streaming (this is well researched and documented). Additionally streaming protocols (HLS/DASH) force files to be encoded such that a full download is not required for a decode to happen. This is not a requirement (and pretty rare unless you know what you are doing with an encoder) for file based workflows. Fast forward for low power clients relies on an "iframe only" track as there decoders can't do many x realtime decode. This is not present in modern file based work flows. Seeks use the same startup/segmentation requirements as video startup. Thumbnail scrubbing requires a thumbnail track and is not supported by file based workflows at all. Clip previews on sites load at low resolution/bitrates and can be poped up to "full resolution" via ABR. Doing a preview of 10x 4k streams without abr wouldn't work even on a modern gaming rig. I'd love to hear how you'd do SSAI on top of a file based workflow. You could of course build a "file based" implementation that had all of these features, but you would just be rebuilding DASH or HLS.
- ryantriangles 7y ago
  Popular video file players have supported generating iframe tracks for fast forwarding and thumbnail scrubbing for many years now, is there something about the way eg MPCBE and PotPlayer operate that is somehow unreasonable?

ngcc_hk 7y ago

P2P solves it. Just not the payment side. Only if one can pay. I do not even mind it is drm as long as I can get a good quality one in 10 minutes. Even if I contribute bandwidth (as long as controller and during my download) and paid. There is always someone not paid. But it is those who can and willingly do which oddly leave out. Like Mp3 in 1990s.

TheOtherHobbes 7y ago
P2P could have totally transformed the industry if it had worked out a way to pay creators - especially niche creators and beginners. It would have owned discovery, which would have badly damaged the big studios. And Netflix would probably have never happened. It would have been a similar story in music. But P2P was always about people who think a file is a file is a file, and creation costs are an externality, which can be ignored as irrelevant. So now we have TPB limping along, and new creators are mostly owned by YT - which is legendary for draconian application of copyright in the favour of fellow corporates.

mises 7y ago

> In addition, subtitles, secondary audio, descriptive video, and multi-view video etc. are all things which we mandate by law which do not work well in a file base expierenced. Since when are subtitles mandated by law? "Multi-view video"? Maybe I'm just missing something, but I've never heard of any law mandating any of the things you listed above (except maybe from a government-funded project, but I'm not sure either, that just seems more likely to require it).

dylz 7y ago
There's been stuff like this: https://www.insidehighered.com/news/2017/03/06/u-california-berkeley-delete-publicly-available-educational-content https://www.insidehighered.com/news/2017/03/06/u-california-...
- mises 7y ago
  That's pretty crazy. I understand "reasonable accommodation", but doing that for so much content is beyond. Better most of the population gets it that no one can because a few edge cases can't consume it normally. I understand the need for wheelchair ramps, but this is like saying that every building that doesn't have one must add one or be torn down.

feanaro 7y ago

> Video startup times, seek times, thumbnail scrubbing, fast forward, clip previews, ad insertion and many other things don't work in a file based experience. One of these things is not like the others.

zzo38computer 7y ago

Subtitles, secondary audio, etc can work in files if those things are encoded in the file. Something like the television captions could be work and then the playback software can be configured what fonts and colours to use to display them, or to not display them at all, and possibly implement stuff such as caption scrollback that the provider did not put in, even. Still, there is many reason for having the streaming, although it should be a open protocol and not too complicated. And then, if you write a client software and program it to save the file to disk, it can do that too, possibly during playback, and you can program in other stuff too if you want to do. I thought of idea of Live Audio Video Protocol (but have not actually written any part of it yet, but have some ideas about it), that you can use Ogg streams and you can initiate with file selection, format/quality negotiation, etc, and then receive the stream but you can also send commands to select a channel or subchannel, pause, seek, request data, rate of keyframes (if the server supports changing this, which it might not), and change other settings. (Actually, I find a few problems with Ogg, and everything else is too complicated, so I made up something which is slightly more complicated than Ogg but not too much, which is called GLOGG; it is mostly like Ogg, but uses UUIDs to identify codecs, allows identifying how individual streams are related (the relation codes are specific to the codec, and are not defined by the container format; you can also specify if a program that does not understand it should ignore it), and a few other things, but still simple compared to most other container formats.) And about ad insertion, they do that on television without any problem, so I don't know how that is a problem any differences whether it is a stream or file. (Although sometimes they put stuff within the show itself and damaging the picture, they should not do, but that is only my opinion and is unrelated to the protocols.)