New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 620439 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Tighten media Renderer interface API

Project Member Reported by xhw...@chromium.org, Jun 15 2016

Issue description

The 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
 

Comment 1 by xhw...@chromium.org, Jun 15 2016

Let's discuss here about what kind of API we want to have. I probably don't have time to do this any time soon so please feel free to assign to yourself if you are interested.

Comment 2 by alokp@chromium.org, 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?
Project Member

Comment 3 by sheriffbot@chromium.org, Jun 19 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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
Cc: -xhw...@chromium.org
Owner: xhw...@chromium.org
Status: Assigned (was: Untriaged)
give back to xhwang@, if this bug is not valid anymore, can you resolve it?

Comment 5 by xhw...@chromium.org, Oct 10 2017

Cc: xhw...@chromium.org
Owner: ----
Status: Available (was: Assigned)
This is still a valid issue, but I don't have time to work on it any time soon.

+dalecurtis for thoughts.
Project Member

Comment 6 by sheriffbot@chromium.org, Oct 10

Status: Untriaged (was: Available)
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

Comment 7 by dbbrooks@chromium.org, Yesterday (35 hours ago)

Labels: -Pri-2 Pri-3
Owner: dalecur...@chromium.org
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.

Comment 8 by dbbrooks@chromium.org, Yesterday (35 hours ago)

Status: Available (was: Untriaged)

Comment 9 by dalecur...@chromium.org, Yesterday (33 hours ago)

Owner: ----
No plans to work on this, but can be kept open.

Sign in to add a comment