[Webkit-unassigned] [Bug 66230] Also release media resources when media is completely loaded.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=66230





--- Comment #11 from Hin-Chung Lam <hclam at google.com>  2011-08-17 10:41:03 PST ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (From update of attachment 103918 [details] [details] [details])
> > > Changing the behavior everywhere, in a way that breaks compatibility with the spec, is the wrong way to fix a problem that only happens in DRT on some platforms.
> > 
> > I suppose that a media resource never is loaded unless it's from a local file system. This effectively means that in all cases except for file:// URLs MediaPlayer is deleted.
> > 
> 
>   No, what makes you say that? 
> 
>   HTMLMediaElement::m_completelyLoaded is set when the media engine reports that the networkState is MediaPlayer::Loaded. This can potentially happen for any file, it is up to the media engine.
> 
> > If this is the final result then why do we treat file:// differently? This seems to fall into a grey area where the spec doesn't specify the behavior regarding media resources / cache when user leave the page.
> > 
>   I don't think the spec is at all vague. It says to run the steps we have in HTMLMediaElement::userCancelledLoad if the "fetching process is aborted by the user". To me this means the steps should not be run if the fetching process is not aborted, hence if the data has all been fetched we do not run it.
> 
> > I think we should just treat the logic for file:// the same as other URLs. Logic in this piece of code seems to be coming the old spec where there was a loaded event.
> 
>   As noted this is not caused by file: urls, and it does not come from the old spec. 
> 
>   I think this is a usability issue. When navigating back to a page it is a good thing if the page can reload without having to refetch the media, eg. the user's place in the media is not reset so they can resume watching/listening where they were, etc.
> 
>   If you don't like this behavior, change your media engine so the networkState never reaches MediaPlayer::Loaded.

(In reply to comment #8)
> (In reply to comment #7)
> > If the media resource is loaded from a data: URL, going to a loaded state is the right thing to do since there's no network activity and no progress event. When a site loads some data: URL objects for games, and user leaves the page that would leave a lot of media engines remain in memory, which can be quite heavy.
> > 
> > Currently there's no way for a media engine to know that it can clean up safely once it reached loaded state, what about we call cancelLoad() and let the media engine to decide what to do with its internal resources?
> 
> That isn't a good idea, cancelLoad() is currently called from HTMLMediaElement::prepareForLoad to tell a media engine to clean up in preparation for a new url. Apple's media engines dispose of all assets in cancelLoad, so all state is lost. I assume at least some others do the same.
> 
> We could add a new media engine function that is called when its document becomes active/inactive.

That seems to be a better solution in terms of flexibility for the media engine to unload resources if it chooses to.

Also my other question is that instead of a m_player.clear(), should it be a cancelLoad()? Conceptually doing a destruction seems to be doing more than just cancel the resource fetch.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.