Re: [MSE] Updated MPEG-2 TS Byte Stream Requirements

Hi Aaron,

See in-line for responses to your questions from Alex and me.

Thanks,
Bob

From: Aaron Colwell <acolwell@google.com<mailto:acolwell@google.com>>
Date: Wednesday, September 19, 2012 7:33 PM
To: Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>
Cc: "public-html-media@w3.org<mailto:public-html-media@w3.org>" <public-html-media@w3.org<mailto:public-html-media@w3.org>>
Subject: Re: [MSE] Updated MPEG-2 TS Byte Stream Requirements

Hi Bob,

Thanks for doing this. Sorry it has taken me a little while to respond. I've got a few questions and hopefully they won't seem too silly since I have no experience with MPEG-2 TS. I'll blame the MPEG-2 TS Wikipedia articles if I get something totally wrong. ;)

Many of these questions come from looking at the differences between the old proposal and your new version. My understanding of the old version mapped easily to my understanding of HLS. The new text signals to me that you are going for something more complex.

Here are the questions that came to mind:

1. Why is PSI included in both media segments and initialization segments? All these tables look like initialization segment only material.

PSI is required by MPEG-2 Systems to appear very frequently inband. So, every media segment longer than ~100ms will contain PSI.


2. Why was the 'transport_error_indicator set to 0' requirement removed?
 a. Why do we want to pass data we know is corrupt to the UA?
 b. Why can't the service the web application is talking to simply strip these bad packets?

The flag set means that the stream is broken. This should be taken care of at the fragmentor, before ever being segmented.


3. How is the "self-initializing" media segment different from an initialization segment before a standard media segment? I don't really understand this distinction.

 It’s same, but “self-initializing” implies having PSI prior to media packets in the media segment.


4. How is the boundary between media segments detected? Does the Random Access indicator in the Adaptation Field mark the beginning of a new media segment?

No. Segment boundary is unmarked; the random access indicator indicates the beginning of an AU that has SPS and PPS in front of it in the AVC case. So in our case the first packet carrying media data will have this bit on, but the opposite is not necessarily true.


5. What restrictions are put on the continuity counter & discontinuity indicator fields? It seems like these could confuse the UA if the web application tried to do "out of order" media segment appending. It seems to me that there should be no jumps in the counter or discontinuities inside a single media segment.

We put none. We can explicitly disallow random jumps, but explicitly signaled discontinuities can stay – they are perfectly legal, and will arise if two parts of the segment were “glued” together from different sources.


6. Can you provide a little more background about why "The media segment will not rely on initialization information in another media segment." was added? I don't really understand. This implies to me that the bytestream would have to constantly alternate between initialization segments and media segments.

This implies that PSI appearing in the media segment describes the content of this segment entirely and completely. You don’t need to alternate, as the frequency of PSI repetition within the segment is fairly high.


7. What do expect a deployment that uses MPEG-2 TS as you describe w/ MSE to look like? I'm trying to get a sense of how the web application will fetch the media and what type of infrastructure you expect it to be talking to.

One use case is MPEG DASH distribution using one of the two DASH MPEG-2 TS profiles. Another use case is HLS.


8. What are you trying to provide with MPEG-2 TS that can't be accomplished with the ISO BMFF?

A considerable amount of video content in use today uses MPEG-2 TS.

  a. What are the tradeoffs?

Only supporting ISO BMFF means transmuxing this MPEG-2 TS content.

  b. Why is it beneficial for UAs to take on the burden of supporting another format?

Some UAs support MPEG-2 TS. Some UAs will be required to support MPEG-2 TS. Defining the MPEG-2 TS byte stream requirements doesn't require a UA to support that format, does it?



I'd also like to request that the Encrypted Media Segments section be removed and the discussion of that part be moved to the EME spec work. I understand it is important, but I'd like to keep encryption topics outside of MSE. Your definitions for initialization segments appear to be broad enough to include the necessary information just like the WebM & ISO BMFF sections are.

OK.


That's all I've got for now. I think it is enough to start a good discussion.

Aaron





On Fri, Sep 7, 2012 at 2:25 PM, Bob Lund <B.Lund@cablelabs.com<mailto:B.Lund@cablelabs.com>> wrote:
Hi,

I've uploaded new proposed text for MPEG-2 TS Byte Stream requirements in MSE. The attachment link can be found in comment 13 of bug 17094 (https://www.w3.org/Bugs/Public/show_bug.cgi?id=17094#c13) . This is an update to the original proposal by Alex Giladi and incorporates input from Duncan Rowden and myself.

Bob Lund