[webkit-dev] Media elements meeting notes
hclam at chromium.org
Wed Apr 14 13:51:42 PDT 2010
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
> > 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
> > 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
> for this).
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.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev