Summary: | Restore MediaPlayer totalBytesKnown and totalBytes methods | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Eric Carlson <eric.carlson> | ||||
Component: | Media | Assignee: | Eric Carlson <eric.carlson> | ||||
Status: | RESOLVED WONTFIX | ||||||
Severity: | Normal | CC: | hausmann, ossy, vestbo | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Attachments: |
|
Description
Eric Carlson
2010-01-21 11:09:03 PST
Created attachment 47141 [details]
Possible patch
Possible patch. Not flagging r? until Simon and/or Tor Arne chime in about whether or not they want it.
I'm fine with removing these for the Qt port too, they were implemented just to have a complete overview of the MediaPlayerPrivate interface when I was doing the Phonon port. For phonon there's actually no way to get these things anyways when the media is loaded by Phonon by passing a URL. I'm hoping we'll will be able to load the media in WebCore in the future, in which case these kind of things would be in platform-independent code. Eric, do you know anything about the possibly of feeding QuickTime data instead of passing it a URL? I tried poking at NewMovieFromUserProc but didn't get too far. (In reply to comment #2) > > Eric, do you know anything about the possibly of feeding QuickTime data instead > of passing it a URL? I tried poking at NewMovieFromUserProc but didn't get too > far. The only way to do this is to write a QuickTime datahandler component, which is a PITA but doable. The bigger problems are that it won't work in 64-bit, and WebKit's resource loader isn't ideally suited for loading media data right now - data is loaded sequentially, can't load more than 2GB, all data kept in memory, etc. |