- From: <bugzilla@jessica.w3.org>
- Date: Tue, 23 Jul 2013 11:29:04 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22136 Chris Poole (BBC) <bbcrdchris@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bbcrdchris@gmail.com --- Comment #12 from Chris Poole (BBC) <bbcrdchris@gmail.com> --- For us as a content provider, this issue is primarily about content interoperability. We want to be sure that MPEG DASH content can be created once and played by both MSE and non-MSE based clients. We do not want to have to create separate versions of our content for different devices where the actual codecs used are the same. This interoperability was one of the main aims of MPEG DASH in the first place of course. We know that use of the traditional 'avc1' sample entry creates challenges for implementations on some classes of device and that the in-band carriage of codec parameter sets enabled by the 'avc3' option addresses those problems. As Jon Piesing notes at the top of this bug, the DASH Industry Forum also recognised this issue and the DASH 264 interoperability document expects clients to support in-band carriage of the codec parameter sets. So we believe MSE needs to support this if it is to allow for MPEG DASH implementations that are widely interoperable. There are a few other points in favour of this: - it's a more appropriate way of delivering a continuous live stream of segments as it allows changes to be made to the codec parameters over time - looking ahead, using the avc3 approach is consistent with what is required for HEVC - implementing avc3 is likely to be straightforward since the avc3 format is closer to what is generally required as input to the video decoder. In constrast to the older 'avcn' approach, there are no new data structures to parse as the codec parameters are delivered in NAL structures which video decoders already handle. In fact we were able to add support for avc3 in two open source projects simply by making them accept the 'avc3' identifier for the sample entry - everything else was handled correctly by existing code. As far as we're aware the spec is stable for this and it is just progressing through the final stages of the ISO process. Building on Aaron's proposed text in comment 6, I'd propose the following: "Implementations supporting content packaged according to ISO/IEC 14496-15 must support in-band carriage of codec Parameter Sets. Media segments that contain in-band Parameter Sets must contain this information at every random access point. In-band Parameter Sets must not apply across media segment boundaries. An initialization segment containing Parameter Sets must be appended before any sequence of media segments that do not contain in-band Parameter Sets." It's hard to see how having this as a 'should' would address the content interoperability issues so I'm suggesting it should remain a 'must', as originally proposed. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 23 July 2013 11:29:21 UTC