- From: Abello, Jean-Pierre <Jeanpierre.Abello@nielsen.com>
- Date: Tue, 3 Mar 2015 22:08:40 +0000
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Bob Lund <B.Lund@CableLabs.com>, Cyril Concolato <cyril.concolato@telecom-paristech.fr>, Eric Carlson <eric.carlson@apple.com>, "giuseppep@opera.com" <giuseppep@opera.com>
- CC: "public-inbandtracks@w3.org" <public-inbandtracks@w3.org>
- Message-ID: <D11B8786.5D031%JP.Abello@nielsen.com>
Hello Silvia, Bob, Cyril, Eric and Giuseppe, I hope you are all doing well. Did you see the Jan 29 announcement about Microsoft adding native support for HLS and DASH in Internet Explorer on Windows 10? http://blogs.msdn.com/b/ie/archive/2015/01/29/simplified-adaptive-video-streaming-announcing-support-for-hls-and-dash-in-windows-10.aspx In the light of this new development, it might make more sense now to add HLS along with DASH in http://dev.w3.org/html5/html-sourcing-inband-tracks<http://dev.w3.org/html5/html-sourcing-inband-tracks/>? Silvia had also proposed back in November to move DASH and HLS into their own dedicated section in the document: On 11/2/14, 2:45 AM, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>> wrote: For the record: I do have some reservations about adding DASH and HLS support, since browsers do not typically support these formats natively. Actually, HLS is supported in Safari, so it has some excuse, but DASH is only supported via Media Source Extensions. I have been worried about that a bit. I think these facts probably need to be explained better in the document. This is particularly important, since different target audiences are addressed with the different formats: DASH and HLS address Web Developers (+Safari), MPEG-4, WebM and Ogg address Browser developers, and MPEG-2 addresses Web-enabled set-top box vendors (these are still UA devs). So, DASH and HLS are bascially in a league of their own and should probably be moved to an appendix or so. Silvia. Thanks, JP From: <Abello>, Jean-Pierre <Jeanpierre.Abello@nielsen.com<mailto:Jeanpierre.Abello@nielsen.com>> Date: Wednesday, December 3, 2014 at 11:08 PM To: Giuseppe Pascale <giuseppep@opera.com<mailto:giuseppep@opera.com>>, Silvia Pfeiffer <silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>>, Cyril Concolato <cyril.concolato@telecom-paristech.fr<mailto:cyril.concolato@telecom-paristech.fr>>, Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>, Eric Carlson <eric.carlson@apple.com<mailto:eric.carlson@apple.com>> Cc: "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>> Subject: Re: Wiki update Resent-From: <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>> Resent-Date: Wednesday, December 3, 2014 at 11:17 PM My apologies for the delayed response. Great discussion. I have entered this in bugzilla for further tracking: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27509 I also share concerns about allowing non-"standard" mappings in the webapp. In addition, wouldn't UA native mappings likely consume much less CPU and memory? This still matters on resource constrained devices such as Smart TVs. JP From: Giuseppe Pascale <giuseppep@opera.com<mailto:giuseppep@opera.com>> Date: Monday, November 3, 2014 at 3:04 AM To: Silvia Pfeiffer <silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail..com>> Cc: Cyril Concolato <cyril.concolato@telecom-paristech.fr<mailto:cyril.concolato@telecom-paristech.fr>>, "Abello, Jean-Pierre" <Jeanpierre.Abello@nielsen.com<mailto:Jeanpierre.Abello@nielsen.com>>, Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>, Eric Carlson <eric.carlson@apple.com<mailto:eric.carlson@apple.com>>, "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>> Subject: Re: Wiki update there might be devices/specs (e.g. HbbTV) where dash is supported natively and NOT via MSE, hence a "standard" mapping may still be useful, to avoid people come up with their own. On Sun, Nov 2, 2014 at 9:30 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>> wrote: On 3 Nov 2014 03:42, "Cyril Concolato" <cyril.concolato@telecom-paristech.fr<mailto:cyril.concolato@telecom-paristech.fr>> wrote: > > Hi Bob, Silvia, > > Le 02/11/2014 16:57, Bob Lund a écrit : >> >> >> On 11/2/14, 3:45 AM, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>> wrote: >> >>> On Wed, Oct 29, 2014 at 8:48 AM, Cyril Concolato >>> <cyril.concolato@telecom-paristech.fr<mailto:cyril.concolato@telecom-paristech.fr>> wrote: >>>> >>>> Yes, I do think HLS is another format that we should target. It has some >>>> commonalities with existing formats that we target: DASH for the use of >>>> manifests and adaptative streaming aspects; and MPEG-2 TS as a segment >>>> format. The basics of exposing tracks from TS should be reusable. It >>>> might >>>> need some tweaking compared to what we started specifying, for instance >>>> to >>>> expose ID3 Tag PES streams. In an informal discussion with Eric (in >>>> copy), I >>>> discovered that WebKit already exposes them using some API, see: >>>> >>>> http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/media/track-i >>>> n-band-hls-metadata.html >>> >>> For the record: I do have some reservations about adding DASH and HLS >>> support, since browsers do not typically support these formats >>> natively. > > [CC] I've heard that Webkit/GTK has some native support for DASH, but I couldn't verify it. I would expect that in the future some browsers have native support for DASH or HLS. But I agree with you that support for DASH/HLS is different from direct support for TS/MP4/OGG... > >>> Actually, HLS is supported in Safari, so it has some excuse, >>> but DASH is only supported via Media Source Extensions. I have been >>> worried about that a bit. >> >> There has been text added to the spec for DASH using MSE. MSE behavior is >> that the UA sources tracks based on information in Initialization >> Segments. The application may specify default track attributes for those >> tracks, which the UA will use if those same attributes are not sourced >> from Initialization Segment data. It seems useful to me for the sourcing >> spec to describe this. >> >> On a related note, I plan to submit an MSE bug so that it references the >> sourcing spec for sourcing tracks as described above. > > What about adding a diagram like this one to the introduction: > http://concolato.wp.mines-telecom.fr/files/2014/11/inband-sourcing.png > and maybe indicating that some implementations may use one path or the other. > Adding a diagram like this is useful, but I don't understand the one you made. In particular, all the media format parsing is happening in the UAs and not in an app. I'll have a go at it later. Cheers, Silvia.
Received on Tuesday, 3 March 2015 22:12:15 UTC