Bug 17094 - Define segment formats for MPEG2-TS
Summary: Define segment formats for MPEG2-TS
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P1 normal
Target Milestone: ---
Assignee: Bob Lund
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard: tpac2012
Keywords:
Depends on:
Blocks: 20253
  Show dependency treegraph
 
Reported: 2012-05-18 10:30 UTC by Duncan
Modified: 2012-12-13 02:39 UTC (History)
9 users (show)

See Also:


Attachments
Proposed text for MPEG-2 TS segment format (1.94 KB, text/plain)
2012-05-24 15:20 UTC, Alex Giladi
Details
Updated version of the MPEG-2 TS text (2.34 KB, text/plain)
2012-06-07 16:05 UTC, Alex Giladi
Details
Updated version of the MPEG-2 TS text (2.72 KB, text/plain)
2012-09-07 21:15 UTC, Bob Lund
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Duncan 2012-05-18 10:30:37 UTC
From a broadcasters perspective it would be of great interest to add a section under chapter "6. Byte Stream Formats" that describes MPEG2-TS.

If that's acceptable, I can suggest some non-normative text to be included.
Comment 1 Alex Giladi 2012-05-24 15:20:11 UTC
Created attachment 1134 [details]
Proposed text for MPEG-2 TS segment format
Comment 2 Mark Watson 2012-06-05 00:35:19 UTC
"If for some reason a web application doesn't want to append data at the beginning of the timeline, it can derive the starting timestamp from the earliest PTS of the Media Segment."

I don't understand this sentence. Can you explain ? Specifically, how does it work if I seek into the middle of a piece of on-demand content and later want to seek to an earlier position in the content ?
Comment 3 Alex Giladi 2012-06-05 14:02:25 UTC
(In reply to comment #2)
> "If for some reason a web application doesn't want to append data at the
> beginning of the timeline, it can derive the starting timestamp from the
> earliest PTS of the Media Segment."
> 
> I don't understand this sentence. Can you explain ? Specifically, how does it
> work if I seek into the middle of a piece of on-demand content and later want
> to seek to an earlier position in the content ?

The meaning is: the smallest value of PTS within the segment is its starting timestamp (a.k.a. earliest presentation time). I guess it is a redundant statement. I don't think this statement helps seeking in any way -- EPT of a segment doesn't help you here.
Comment 4 Alex Giladi 2012-06-07 16:05:59 UTC
Created attachment 1142 [details]
Updated version of the MPEG-2 TS text
Comment 5 Aaron Colwell (c) 2012-06-07 16:34:00 UTC
(In reply to comment #4)
> Created attachment 1142 [details]
> Updated version of the MPEG-2 TS text

Are these requirement compatible with the HLS spec (http://tools.ietf.org/html/draft-pantos-http-live-streaming-08)? 

While I'm not a huge fan of including MPEG-2 TS in the spec, I can understand why some would want it. I want to make sure HLS can be supported if we decide to include this.
Comment 6 Alex Giladi 2012-06-07 17:26:06 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > Created attachment 1142 [details] [details]
> > Updated version of the MPEG-2 TS text
> 
> Are these requirement compatible with the HLS spec
> (http://tools.ietf.org/html/draft-pantos-http-live-streaming-08)? 
Yes, they are.(In reply to comment #5)
> (In reply to comment #4)
> > Created attachment 1142 [details] [details]
> > Updated version of the MPEG-2 TS text
> 
> Are these requirement compatible with the HLS spec
> (http://tools.ietf.org/html/draft-pantos-http-live-streaming-08)? 
Yes, they are -- they are actually a bit stricter than HLS.

> While I'm not a huge fan of including MPEG-2 TS in the spec, I can understand
> why some would want it. I want to make sure HLS can be supported if we decide
> to include this.
+1.
Comment 7 Mark Watson 2012-06-19 15:29:15 UTC
When you say "compatible with HLS" do you mean
(1) Any segments compatible with HLS will also be compatible with the requirements here, or
(2) Segments compatible with the requirements here are also compatible with HLS, or
(3) both of the above

?

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Created attachment 1142 [details] [details] [details]
> > > Updated version of the MPEG-2 TS text
> > 
> > Are these requirement compatible with the HLS spec
> > (http://tools.ietf.org/html/draft-pantos-http-live-streaming-08)? 
> Yes, they are.(In reply to comment #5)
> > (In reply to comment #4)
> > > Created attachment 1142 [details] [details] [details]
> > > Updated version of the MPEG-2 TS text
> > 
> > Are these requirement compatible with the HLS spec
> > (http://tools.ietf.org/html/draft-pantos-http-live-streaming-08)? 
> Yes, they are -- they are actually a bit stricter than HLS.
> 
> > While I'm not a huge fan of including MPEG-2 TS in the spec, I can understand
> > why some would want it. I want to make sure HLS can be supported if we decide
> > to include this.
> +1.
Comment 8 Aaron Colwell (c) 2012-06-19 20:34:21 UTC
(In reply to comment #7)
> When you say "compatible with HLS" do you mean
> (1) Any segments compatible with HLS will also be compatible with the
> requirements here, or
> (2) Segments compatible with the requirements here are also compatible with
> HLS, or
> (3) both of the above
> 

Ideally (3) if that is reasonable to do. If not then I'd prefer to fall back to (2) so that existing content could be slightly modified to work with existing clients and the Media Source Extensions.

The only reason I'm willing to consider MPEG2-TS is because there is HLS content  on the Web and a major media engine implementation that is driving its creation. Content providers might want to reuse this HLS content with the Media Source Extensions so it seems reasonable to explore the idea.

Personally I'd prefer to stop pushing MPEG2-TS's legacy into the future, but I realize this decision isn't only up to me.
Comment 9 Alex Giladi 2012-07-03 22:47:21 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > When you say "compatible with HLS" do you mean
> > (1) Any segments compatible with HLS will also be compatible with the
> > requirements here, or
> > (2) Segments compatible with the requirements here are also compatible with
> > HLS, or
> > (3) both of the above
> > 
> 
> Ideally (3) if that is reasonable to do. If not then I'd prefer to fall back to
> (2) so that existing content could be slightly modified to work with existing
> clients and the Media Source Extensions.
(2), with (3) happening nearly always.

The difference is that HLS does not disallow "bad practices" that makes switching problematic (e.g. starting a segment in the middle of a picture). In practice, I have never seen an encoder that does this.
Comment 10 Mark Watson 2012-07-03 23:02:07 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > When you say "compatible with HLS" do you mean
> > > (1) Any segments compatible with HLS will also be compatible with the
> > > requirements here, or
> > > (2) Segments compatible with the requirements here are also compatible with
> > > HLS, or
> > > (3) both of the above
> > > 
> > 
> > Ideally (3) if that is reasonable to do. If not then I'd prefer to fall back to
> > (2) so that existing content could be slightly modified to work with existing
> > clients and the Media Source Extensions.
> (2), with (3) happening nearly always.
> 
> The difference is that HLS does not disallow "bad practices" that makes
> switching problematic (e.g. starting a segment in the middle of a picture).

On indeed somewhere that does not have an I-Frame.

(2) is reasonable, but I think if we are not planning to *guarantee* (1) we should be clear about that, even if you think that in practice a lot of existing HLS content will work.

 In
> practice, I have never seen an encoder that does this.
Comment 11 Alex Giladi 2012-07-03 23:28:14 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > (In reply to comment #7)
> > > > When you say "compatible with HLS" do you mean
> > > > (1) Any segments compatible with HLS will also be compatible with the
> > > > requirements here, or
> > > > (2) Segments compatible with the requirements here are also compatible with
> > > > HLS, or
> > > > (3) both of the above
> > > > 
> > > 
> > > Ideally (3) if that is reasonable to do. If not then I'd prefer to fall back to
> > > (2) so that existing content could be slightly modified to work with existing
> > > clients and the Media Source Extensions.
> > (2), with (3) happening nearly always.
> > 
> > The difference is that HLS does not disallow "bad practices" that makes
> > switching problematic (e.g. starting a segment in the middle of a picture).
> 
> On indeed somewhere that does not have an I-Frame.
> 
> (2) is reasonable, but I think if we are not planning to *guarantee* (1) we
> should be clear about that, even if you think that in practice a lot of
> existing HLS content will work.
Agreed.
Comment 12 Aaron Colwell (c) 2012-08-18 16:50:14 UTC
Assigning to Bob Lund since he volunteered to champion this.
Comment 13 Bob Lund 2012-09-07 21:15:18 UTC
Created attachment 1183 [details]
Updated version of the MPEG-2 TS text
Comment 14 Aaron Colwell (c) 2012-12-13 02:39:46 UTC
Changes committed
http://dvcs.w3.org/hg/html-media/rev/e1c91093dfdc

I used the text attached to this bug as a starting point and then I integrated various things from the many emails we've exchanged on this topic. I believe I've covered everything, but please reopen the bug with some comments if you believe I've missed something.