[webkit-dev] Media elements meeting notes

[Alpha Lam]

2010年4月13日17:04 pnormand <pnormand at igalia.com>:

> On Tue, 2010-04-13 at 14:52 -0700, Eric Uhrhane wrote:
>
> > New topic: Loader.
> >
> > Things that would be improved by unifying loading between media elements
> and the
> > rest of webkit:
> >   Unified resource security model.
> >   Make application cache work for media.
> >   Make WebCore cache work for media, better cache balancing by unifying
> caching
> >   with that of the platform MediaEngine cache.
> >   Make Inspector work better for media.
> >   Make authentication work [cookies, referrer, http-auth].
> >   Easier to add new schemes [data://, file URNs], since it would work
> with all
> >   protocols supported by the loader.
> >
> > We have another list of requirements for the loader before it could be
> used.
> > Requirements and drawbacks of unification:
> >   Need to support non-web protocols such as rtsp.
> >   May need 2 code paths.
> >   Need to add byte-range and discontinuous cache support.
> >   Need to support files > 2GB.
> >   May be difficult to hook our loader into platform media engine.
> >   Some media engine's loaders are optimized for media playback
> heuristics; we'd
> >   need to match that behavior.
> >   Andrew: Threading limitations on resource loaders?
> >
> > Michael Nordman said something here about using ResourceHandle for this.
>  He can
> > flesh that out, as I didn't follow the discussion.
> >
>
> The GStreamer-based MediaPlayerPrivate has a source element in
> WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp that
> uses the WebCore infrastructure to load the resources from http(s)
> servers and feed the data into the gst pipeline. This way we can reuse
> the http session (cookies, referer, ...).
>
> We can probably use it for data: uris too (we currently have a specific src
> element
> for this).
>
> Philippe
>

I totally think we should do this instead of implementing resource loading
on each port. As a matter of fact, in Chromium we use ResourceHandle
directly and provides a layer of buffering and for doing range requests.
This allows us to support http:// https:// data://, cookies, referrer,
http-auth and even AppCache.

Unifying the resource loader also helps pushing a HTTP streaming standard. I
think this has great benefits, media resource loading is well within web
standard, basically just HTTP range requests, having a common code path that
handles buffering, caching and range requests will benefit all.

Alpha


>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100414/8775396f/attachment.html>