RE: FW: [w3c/media-source] Restore auto-revoking behavior of createObjectURL(MediaSource) to revert breaking change introducing memory leaks (#156)

Please state your position on ISSUE-156 so that we can close out this item ASAP.
https://github.com/w3c/media-source/issues/156#issuecomment-244512364


/paulc

From: Matt Wolenetz [mailto:wolenetz@google.com]
Sent: Friday, September 2, 2016 7:57 PM
To: Paul Cotton <Paul.Cotton@microsoft.com>
Cc: Mark Watson <watsonm@netflix.com>; Jerry Smith (WPT) <jdsmith@microsoft.com>; public-hme-editors@w3.org
Subject: Re: FW: [w3c/media-source] Restore auto-revoking behavior of createObjectURL(MediaSource) to revert breaking change introducing memory leaks (#156)

I've replied on the issue<https://github.com/w3c/media-source/issues/156#issuecomment-244512364>, and encourage my co-editors to assist in triage.

Thanks,
Matt

On Thu, Sep 1, 2016 at 6:06 PM, Paul Cotton <Paul.Cotton@microsoft.com<mailto:Paul.Cotton@microsoft.com>> wrote:
How are the Editors planning to handle this request?

From: Karl Tomlinson [mailto:notifications@github.com<mailto:notifications@github.com>]
Sent: Wednesday, August 31, 2016 7:42 PM
To: w3c/media-source <media-source@noreply.github.com<mailto:media-source@noreply.github.com>>
Subject: [w3c/media-source] Restore auto-revoking behavior of createObjectURL(MediaSource) to revert breaking change introducing memory leaks (#156)


#10 (comment)<https://github.com/w3c/media-source/issues/10#issuecomment-151735372>
pointed out that removing the auto-revoking behavior would be a breaking
change.

#10 (comment)<https://github.com/w3c/media-source/issues/10#issuecomment-189219426>
used two arguments to say this would not be a breaking change:

1.     That clients already needed to revoke explicitly anyway, due to a bug in
the File API spec.

2.     That three existing UAs did not implement the auto-revoking behavior.

Firefox does auto-revoke, and so 2 was incorrect. This is tested in
w3c/web-platform-tests@7ca2c25<https://github.com/w3c/web-platform-tests/commit/7ca2c25204985477514ddb4e9171e7544d98a8e5>

I am also not convinced by 1. Whether the precise time of revocation was
clear or not, it was clear that the intention was that the client need not
revoke.

MSE does not need object URLs of infinite lifetime because these merely
provide a mechanism of associating the MediaSource with a media element.

As referenced in
#10 (comment)<https://github.com/w3c/media-source/issues/10#issuecomment-201024017>
removing the auto revocation leads to memory leaks.
These leaks extend to objects affecting and affected by the MediaSource object.

The second sentence of
#10 (comment)<https://github.com/w3c/media-source/issues/10#issuecomment-208923486>
is also incorrect because Firefox, at least, revokes the object URL on the
next stable state, and so there is nothing to keep the objects alive.

I don't know the reasons for requiring explicit revocation of File URLs, but I
doubt they apply to MSE.

Keeping track of strings for object URLs created, or immediately explicitly
revoking, is an unnecessary burden for clients, one that is unexpected in a
garbage collected world. This outweighs benefits of a breaking change to
be consistent with the File API.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://github.com/w3c/media-source/issues/156>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AH6r-EM9a19OS2c2dHbouApAOCNLVYTkks5qlhEygaJpZM4JyLPS>.