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

Issue 600323 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

WebRTC H.264 DXVAVideoDecodeAccelerator/GLFenceNV crash on Debug/Windows

Project Member Reported by hbos@chromium.org, Apr 4 2016

Issue description

Steps to reproduce:
1. Build a Debug build of Chromium on Windows with flags: proprietary_codecs=1 ffmpeg_branding=Chrome.
2. Run chrome with --enable-features=WebRTC-H264WithOpenH264FFmpeg.
3. Go to https://apprtc.appspot.com/r/<room id>?debug=loopback&vsc=H264&vrc=H264 and join, let it run for a couple of minutes

Expected result:
  Running a video loopback call with H264 video normally. Perhaps not the greatest performance since the OpenH264 encoder is compiled with non-optimized code and its in Debug mode, but it should work fine for lower resolutions. (It should in that case go down from 720p to 540p or 360p after a few seconds of low framerate.)

Actual result:
  Terrible performance, at best a couple of frames per second, freezes after a while. Shortly we get a crash (stacktrace below). This is when HW decoding is available.

Additional results:
  If we hack the code so that it uses SW decoder instead of HW we don't get the crash, but we still get terrible performance and the entire browser lags. Pressing [i] in call to get info, the "End to end" time goes down with 1000 ms per second (after a few minutes it can say: -444072 ms). I get 720p3 at first, 360p13 later. It periodically freezes for 5-10 seconds sometimes. chrome://webrtc-internals shows encoding takes 50-200 ms. Decoding typically takes 1-2 ms.

NOTE: Neither results are reproducible on a Release build. Still not great performance, but it can run 720p15 or 520p30. In both builds there is a small but noticable delay between local preview and loopback video.

A separate bug should be filed for performance problems with encoding, but we shouldn't get a crash in Debug mode.

--- Stack Trace ---

[1368:7020:0331/114148:FATAL:gl_fence_nv.cc(52)] Check failed: glIsFenceNV(fence_). 
Backtrace:
  base::debug::StackTrace::StackTrace [0x100A1641+33]
  logging::LogMessage::~LogMessage [0x100FA9DB+75]
  gfx::GLFenceNV::~GLFenceNV [0x11960CF9+297]
  gfx::GLFenceNV::`vector deleting destructor' [0x11960E14+84]
  std::default_delete<gfx::GLFence>::operator() [0x179D0EBD+61]
  std::unique_ptr<gfx::GLFence,std::default_delete<gfx::GLFence> >::~unique_ptr<gfx::GLFence,std::default_delete<gfx::GLFence> > [0x179CD1C2+50]
  content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer::~DXVAPictureBuffer [0x179CD37A+250]
  content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer::`scalar deleting destructor' [0x179D16D6+22]
  linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer>::depart [0x179F20AA+74]
  linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer>::~linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer> [0x179CC7B6+22]
  std::pair<int const ,linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer> >::~pair<int const ,linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer> > [0x179CC899+25]
  std::pair<int const ,linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer> >::`scalar deleting destructor' [0x179D1686+22]
  std::allocator<std::_Tree_node<std::pair<int const ,linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer> >,void *> >::destroy<std::pair<int const ,linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer> > > [0x179C88B8+24]
  std::allocator_traits<std::allocator<std::_Tree_node<std::pair<int const ,linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer> >,void *> > >::destroy<std::pair<int const ,linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer> > > [0x179C88EF+15]
  std::_Wrap_alloc<std::allocator<std::_Tree_node<std::pair<int const ,linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer> >,void *> > >::destroy<std::pair<int const ,linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer> > > [0x179C887B+27]
  std::_Tree<std::_Tmap_traits<int,linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer>,std::less<int>,std::allocator<std::pair<int const ,linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer> > >,0> >::_Erase [0x179EF5E5+133]
  std::_Tree<std::_Tmap_traits<int,linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer>,std::less<int>,std::allocator<std::pair<int const ,linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer> > >,0> >::_Erase [0x179EF5AF+79]
  std::_Tree<std::_Tmap_traits<int,linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer>,std::less<int>,std::allocator<std::pair<int const ,linked_ptr<content::DXVAVideoDecodeAccelerator::DXVAPictureBuffer> > >,0> >::clear [0x179F1BFC+44]
  content::DXVAVideoDecodeAccelerator::DismissStaleBuffers [0x179DDE26+550]
  content::DXVAVideoDecodeAccelerator::ConfigChanged [0x179D34B6+294]
  base::internal::RunnableAdapter<void (__thiscall content::DXVAVideoDecodeAccelerator::*)(media::VideoDecodeAccelerator::Config const &)>::Run<media::VideoDecodeAccelerator::Config const &> [0x179C68C8+40]
  base::internal::InvokeHelper<1,void,base::internal::RunnableAdapter<void (__thiscall content::DXVAVideoDecodeAccelerator::*)(media::VideoDecodeAccelerator::Config const &)> >::MakeItSo<base::WeakPtr<content::DXVAVideoDecodeAccelerator>,media::VideoDecodeA [0x179C5737+55]
  base::internal::Invoker<base::IndexSequence<0,1>,base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall content::DXVAVideoDecodeAccelerator::*)(media::VideoDecodeAccelerator::Config const &)>,void __cdecl(content::DXVAVideoDecodeAccele [0x179EC6DF+95]
  base::Callback<void __cdecl(void),1>::Run [0x1007271F+47]
  base::debug::TaskAnnotator::RunTask [0x100A6AB3+387]
  base::MessageLoop::RunTask [0x1012A602+706]
  base::MessageLoop::DeferOrRunPendingTask [0x10127D54+52]
  base::MessageLoop::DoWork [0x1012851D+221]
  base::MessagePumpForUI::DoRunLoop [0x10134F94+84]
  base::MessagePumpWin::Run [0x10136EE9+121]
  base::MessageLoop::RunHandler [0x1012A29E+238]
  base::RunLoop::Run [0x101D6146+70]
  base::MessageLoop::Run [0x1012A10F+239]
  content::GpuMain [0x173497B6+3158]
  content::RunNamedProcessTypeMain [0x15673EE9+169]
  content::ContentMainRunnerImpl::Run [0x15673D06+598]
  content::ContentMain [0x1565E160+144]
  ChromeMain [0x0676E6E8+168]
  MainDllLoader::Launch [0x00432F21+1025]
  wWinMain [0x0042CF97+903]
  invoke_main [0x005B0BFE+30] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:128)
  __scrt_common_main_seh [0x005B0A4A+346] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:264)
  __scrt_common_main [0x005B08DD+13] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:309)
  wWinMainCRTStartup [0x005B0C18+8] (f:\dd\vctools\crt\vcstartup\src\startup\exe_wwinmain.cpp:17)
  BaseThreadInitThunk [0x7548338A+18]
  RtlInitializeExceptionChain [0x77869A02+99]
  RtlInitializeExceptionChain [0x778699D5+54]
 

Comment 1 by hbos@chromium.org, Apr 4 2016

Cc: ananta@chromium.org
+ananta, can you take a look at this bug?

You recently modified DXVAVideoDecodeAccelerator::DismissStaleBuffers in this CL (https://codereview.chromium.org/1815063002) and I think it might be related to this crash? I didn't have this problem prior to my vacation 3 weeks ago.

Comment 2 by hbos@chromium.org, Apr 4 2016

Cc: hbos@chromium.org
Labels: -Pri-3 M-52 Pri-2
Owner: ananta@chromium.org
Making you the bug owner for now if that's OK.

See also https://codereview.chromium.org/1815063002/diff/120001/content/common/gpu/media/dxva_video_decode_accelerator_win.cc#newcode2648 (line 2648).
Project Member

Comment 3 by bugdroid1@chromium.org, Apr 5 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0f3b2d37a14070c7d17b34053d3b345a844153fd

commit 0f3b2d37a14070c7d17b34053d3b345a844153fd
Author: ananta <ananta@chromium.org>
Date: Tue Apr 05 01:20:23 2016

Ensure that the open gl context is current in the DXVA decoder while processing configuration changes.

This should hopefully fix the DCHECK's which fire for a valid fence when the picture buffers are being torn down.

BUG= 600323 

Review URL: https://codereview.chromium.org/1861483004

Cr-Commit-Position: refs/heads/master@{#385070}

[modify] https://crrev.com/0f3b2d37a14070c7d17b34053d3b345a844153fd/content/common/gpu/media/dxva_video_decode_accelerator_win.cc

Status: Fixed (was: Assigned)
Labels: -M-52 M-51
Adjusting milestone label because the fix landed before the M51 branch point. hbos@, can you resync and verify the fix?

Comment 6 by hbos@chromium.org, Apr 7 2016

Status: Verified (was: Fixed)
I resynced and was unable to reproduce the crash :) good job.

Sign in to add a comment