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

+Ryan and David, who might have informed opinions about Will's feedback. :)

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Thu, Sep 17, 2015 at 10:42 PM, Nottingham, Mark <mnotting@akamai.com>
wrote:

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