Tighten media Renderer interface API |
||||||||
Issue descriptionThe media Renderer interface and implementations have gone through many changes since it's born and over time it's less clear about what the API expects. Here are some issues that I see: 1. Historically we require all one-time callbacks to be fired asynchronously (after the call is returned). The current comment is ambiguous on this now [1]: // |init_cb| must only be run after this // method has returned. Firing |init_cb| may result in the immediate // destruction of the caller, so it must be run only prior to returning. Also, I think we disallow OnError() to be called during initialization. Now this is missing. Actually, shall we disallow any RendererClient() method to be called during initialization? 2. Now we have the RendererCient interface. It's very natural that the Renderer calls into RendererClient at any time. This can easily cause reentrance into the caller given that typically the caller implements the RendererClient as well, e.g. caller -> Renderer::Foo() -> RendererClient::Bar() -> caller. This is fine in most cases but is definitely error prone. Shall we mention this in the API, either somehow prevent this from happening, or at least let people know this could happen? 3. Since RendererClient and Renderer are defined in two files. It's less clear about the interaction between them, especially for error handling. For example, after RendererClient::OnError() is called, can the caller call into Renderer again? If so, will the calls just be no-op, or fail (for calls that returns results synchronously, or returns results through callbacks asynchronously)? Today looking at RendererImpl, it seems we allow calling Renderer after OnError(). This was partly because OnError() is posted so we cannot guarantee Renderer() is not called before OnError() is executed. But then in RendererImpl::Flush(), if we are in the error state, we just return without even fire the |flush_cb|, which seems wrong [2]. [1] https://cs.chromium.org/chromium/src/media/base/renderer.h?rcl=0&l=34 [2] https://cs.chromium.org/chromium/src/media/renderers/renderer_impl.cc?rcl=0&l=173
,
Jun 17 2016
I would like to expand the discussion to mojo versions of Renderer and RendererClient. 1. Should we continue to have the non-mojo interface? I believe mojo team would like to avoid duplicate interfaces. 2. If we have both interfaces, they should be the same to avoid complicated shim layers. This means media::Renderer interface should not have synchronous getters. 2a. One such problematic member function is GetMediaTime ( issue 616959 ). 2b. HasAudio and HasVideo are not hard to implement in the shim layer but are they even necessary?
,
Jun 19 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 20 2017
give back to xhwang@, if this bug is not valid anymore, can you resolve it?
,
Oct 10 2017
This is still a valid issue, but I don't have time to work on it any time soon. +dalecurtis for thoughts.
,
Oct 10
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Yesterday
(35 hours ago)
Based on age, lowering pri to 3, and moving to "Available". Dale, can you confirm whether this is work that is intended to be done at some point? Thanks.
,
Yesterday
(35 hours ago)
,
Yesterday
(33 hours ago)
No plans to work on this, but can be kept open. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by xhw...@chromium.org
, Jun 15 2016