New issue
Advanced search Search tips

Issue 594472 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Derived classes of media::VideoDecodeAccelerator and media::VideoEncodeAccelerator need custom deleters

Project Member Reported by dcheng@chromium.org, Mar 14 2016

Issue description

Last week, I reviewed https://codereview.chromium.org/1784193003/diff/100002/content/common/gpu/media/gpu_video_decode_accelerator.cc#newcode465. I thought it was odd, because without the explicit template parameter to make_scoped_ptr, the code did not compile.

It turns out this is because media::VDA and media::VEA have custom deleters. I investigated if it would be possible to remove them, but some implementations to take advantage of async delete: https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu/media/vt_video_decode_accelerator_mac.cc&sq=package:chromium&l=1128&q=VTVideoDecodeAccelerator::Destroy

However, because the classes derived from VDA and VEA do not have custom deleters themselves, that means that code like this:
  scoped_ptr<DerivedFromVDA> vda(new DerivedFromVDA);

will call the destructor directly instead of using Destroy(). If the Destroy() semantics are important, then this becomes a bug.

Some options:
1) We should get rid of Destroy() and require that deletion of this object always take place via a posted task (e.g. via a helper such as DeleteSoon).
2) Derived subclasses need to have custom deleters as well.

P.S.
I also noticed some weird code like https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/media/rtc_video_decoder.cc&l=682&cl=GROK and https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/media/rtc_video_decoder.cc&l=706&cl=GROK. This should just call vda_.reset().
 

Comment 1 by dcheng@chromium.org, Mar 14 2016

Components: Internals>Media
Cc: liber...@chromium.org

Comment 3 by danakj@chromium.org, Apr 23 2016

Cc: dalecur...@chromium.org m...@chromium.org

Comment 4 by m...@chromium.org, Apr 25 2016

Cc: posciak@chromium.org
Project Member

Comment 5 by sheriffbot@chromium.org, Apr 25 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 6 by xhw...@chromium.org, Apr 25 2017

Owner: sande...@chromium.org
sandersd: could you please help triage this?
Owner: emir...@chromium.org
Status: Assigned (was: Untriaged)
The use of Destroy() for VDAs is not going away. VDA hosts should not be holding references to subclasses without calling Destroy() explicitly, as the API specifies.

It is plausible to remove the default deleter though, it is really just a convenience helper, and I agree that it could lead to mistakes.

I know less about the VEA situation. emircan@, care to comment?
Cc: -posciak@chromium.org emir...@chromium.org
Owner: posciak@chromium.org
posciak@ would know better about VEA deleters and the interface. Passing to him.

Sign in to add a comment