[foms] Fwd: [RTW] Fwd: I-D Action:draft-zong-httpstreaming-gap-analysis-01.txt
watsonm at netflix.com
Thu Nov 4 15:31:25 PDT 2010
The design is such that the manifest format and presentation model is independent of the data file format. The manifest declares the data file format using a MIME type (which also specifies the contained codecs with the codecs parameter).
MPEG is working on details of how this is used with the ISO Base Media FIle format (mp4) and with MPEG 2 Transport Streams. MPEG won't specify these details for other formats. Those details come down to specification of how compact time/byte range index information is carried and all the gnarly rules about alignment of different media types within fragments (if you do multiplexing in the files), positions of Random Access Points (handling things such as Open Gops etc.).
PS: The way it works with MPEG2 Transport Streams is open right now. Some people have proposed using the same index data format for both MP4 and MPEG2 TS files, so that the procedures of the HTTP Streaming engine could be independent of the media format: the HTTP streaming engine just requests opaque byte ranges according to the index and feeds them out to a player which knows whether it is expecting MP4 Movie Fragments or an MPEG2 Transport Stream (or whatever). The would mean that what is stored on the web server for the MPEG2 TS case is not exactly an MPEG2 TS, but a concatenation of an index and an MPEG2 TS. Since the index is defined in the form of an ISO Base Media File Format "box", you get something like an mp4 file containing an MPEG2 TS, which sounds very weird. Actually, it's not really a full mp4 file, just that the wrapper around the MPEG2 TS uses MP4 format data structures.
On Nov 4, 2010, at 3:08 PM, Silvia Pfeiffer wrote:
> Hi Mark,
> I wonder if "the" MPEG DASH solution is restricted to MPEG file
> formats or generally applicable. If it doesn't at least apply to FLV,
> Ogg and WebM, I don't think it's appropriate as a generic solution. I
> am worried that since this effort is happening in MPEG it is
> restricted to the use of MPEG TS units. Can you clarify?
> On Thu, Nov 4, 2010 at 5:26 PM, Mark Watson <watsonm at netflix.com> wrote:
>> Hi Christopher,
>> Yes, we decided to get involved in MPEG DASH as it seemed to be the most advanced standards effort which came close to meeting the requirements we have. The work there is 1.5+ years ahead, looking from the start date of the baseline taken from 3GPP.
>> MPEG is a lot more than H.264. For example, the mp4 file format is quite successful. Also, I'm not sure who you mean by "they": the composition of the DASH working group is very different (people and companies) from the composition of the video group.
>> On IPR, it's clear to me and I believe the other main participants in DASH that if anyone tried to charge license fees for that specifically it would kill it immediately, because there are plenty of proprietary alternatives. There may well be IPR issues with adaptive HTTP streaming that we will all have to deal with in the future, but they are independent of which standards group does the work.
>> Current status at IETF is that there's an informal "Bar BoF" at the current meeting. I doubt there will be consensus to work on this there, not least because there would undoubtedly not be harmony between specifications without considerable effort.
>> On Nov 3, 2010, at 2:46 PM, Christopher Blizzard wrote:
>>> On 11/3/2010 2:32 PM, Mark Watson wrote:
>>>> It's relevant, but that document does contain quite a number of errors and omissions - not least that it is very out-of-date with respect to MPEG DASH. Some of these have been pointed out on the IETF list discussing this issue (
>>> Are you part of the DASH group?
>>> There was an earlier question about DASH and if we knew about it and about MPEG in general which I meant to respond to.
>>> I can't speak for others but I can't say that I haven't been involved there. I'm generally skeptical of MPEG because they failed in their attempt to make an H.264 baseline available on an RF basis. (One of their original goals, as I understand it.) It's clear they are relevant. It's not clear to me if I should spend any time or effort working with them, even on something like DASH.
>>> So if the IETF is working in that space it's fine with me, especially if there's some harmony between various specs.
>> foms mailing list
>> foms at lists.annodex.net
> foms mailing list
> foms at lists.annodex.net
More information about the foms