This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
Created attachment 1134 [details] Proposed text for MPEG-2 TS segment format
"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 ?
(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.
Created attachment 1142 [details] Updated version of the MPEG-2 TS text
(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.
(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.
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.
(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.
(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.
(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.
(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.
Assigning to Bob Lund since he volunteered to champion this.
Created attachment 1183 [details] Updated version of the MPEG-2 TS text
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.