Re: [mixed-content] DASH Players and Mixed Content

Will says that's correct – in-band events are used with mostly with Live services. However, once a live event is complete, the archive can still be played back. So it won’t be a "live service” any more, it will still require box parsing on the client side for correct playback. 

Cheers,


> On 19 Sep 2015, at 7:09 pm, Göran AP Eriksson <gaperik@gmail.com> wrote:
> 
> Just to handshake:
> 
> The "problem" is limited to *Live DASH*, not any offline DASH usage?
> 
> BR
> Göran
> 
> 2015-09-17 22:42 GMT+02:00 Nottingham, Mark <mnotting@akamai.com>:
> Hey,
> 
> Sorry for the delay, but some feedback forwarded from one of our DASH folks:
> 
> Regarding this statement,
> 
> > The "opaque" response prevents direct access to the Response data. Similarly, the SourceBuffer object does not allow direct access to the data - this is only passed on to the audio/video decoders, same as the existing <audio>/<video>/<source> tags today. I realize this may prevent access to the full capabilities of MSE; indeed, some use cases require access to the content in order to do adaptive streaming.
> 
> The "some use cases" turn out to be the majority of future anticipated live service streaming. The DASH-AVC/264 Interop Guidelines v3.0 <http://dashif.org/wp-content/uploads/2015/04/DASH-IF-IOP-v3.0.pdf> split live services in to two major groups; those which rely on MPD update only, and those which rely on MPD updater and the ability to parse segments to retrieve both inband events and timestamp information.
> 
> 1. There are in-stream event messages are carried in there 'emsg' box of the ISOBMFF container. MSE-based players must parse the XHR response and extract these messages prior to appending the data to the source buffer. These messages are used to convey triggers for ad ­insertion, manifest refresh, stream associated metadata such as sports scores etc.
> 
> 2. SegmentTimeline mode of live operation can be conducted in such a manner that the address of the the next segment is constructed by parsing the tdft timestamp of the latest segment described in the manifest. This is an efficient mode of live stream operation, as the client only needs to download the manifest once (until signaled to refresh it for ad insertion or EOS)
> 
> If the proposal is implemented then a live service which is targeting a mixture of MSE and non-MSE clients would be forced to comply with the lowest common denominator (MSE with opaque response data) and would be unable to use inband events. Since the majority of future distributions are likely to involve MSE clients, this proposal effectively limits live DASH deployments to their simplest mode of operation and negates a body of features based on inband event signalling.
> 
> Hope this helps,
> 
> 
> > On 21 Jul 2015, at 12:11 pm, Brad Hill <hillbrad@gmail.com> wrote:
> >
> > There was a proposal of this sort (not a blanket exception, but a safer way to allow for video-over-HTTP to HTTPS pages) by Ryan Sleevi, the start of the thread can be found here:
> >
> > https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0371.html

> >
> > We discussed this last week at our face-to-face in Berlin, and the feel of the room seemed to be that the proposal was technically sound, we weren't sure who exactly the customers of it would be.  I think Ryan had Netflix in mind given their previous reluctance to move to TLS for delivery, but with that resolved, nobody has publicly stepped up as wanting to adopt such a solution.  Our informal rule of thumb in this group is that we've wanted expressions of interest from two "customers" of a feature before we start working on something.
> >
> > Ben, do you maintain a player like this, or know someone who does, who would be willing to examine and comment on Ryan's proposal?
> >
> > thanks,
> >
> > Brad Hill
> >
> > On Tue, Jul 21, 2015 at 1:45 AM Ben Gidley <ben@gidley.co.uk> wrote:
> > I'd like to ask if you've considered how this proposal effects MPEG-DASH players using Media Source Extensions?
> >
> > I've been using DASH players and they generally all break with today's behavior on Chrome/Firefox is you're using a HTTPS page with a HTTP CDN for the video content. This is because they mostly fetch content via XHR for processing in their media source extension.
> >
> > It's not very desirable to push all video over SSL (as it breaks in network caching commonly deployed by Telco's/ISP's) - is it possible to consider a scheme to allow a media source extension to tech video?
> >
> >
> >
> > --
> > Ben Gidley
> >
> > www.gidley.co.uk
> > ben@gidley.co.uk
> 
> --
> Mark Nottingham    mnot@akamai.com   https://www.mnot.net/

> 
> 

--
Mark Nottingham    mnot@akamai.com    https://www.mnot.net/

Received on Tuesday, 22 September 2015 23:44:52 UTC