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.

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?

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.

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?

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.

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.

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.

8. What are you trying to provide with MPEG-2 TS that can't be accomplished
with the ISO BMFF?
  a. What are the tradeoffs?
  b. Why is it beneficial for UAs to take on the burden of supporting
another format?


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.

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> 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
>