video playback freezes when scrolled offscreen then back with unified media pipeline on android |
||||||||||||
Issue descriptionenable unified media pipeline. load some page that has a video that can be scrolled off-screen. i tried to make a jsfiddle example, but i couldn't get it to fail. i was using N7 + mp4. didn't try elsewhere. anyway, start the video then scroll it off-screen. wait a few seconds then scroll back. the video might be frozen. audio plays, time bar progresses. when playback finishes, it does not show the UI nor the overlay play button if video playback was frozen. one can tap to show the ui, and can start playback normally again. sometimes, one sees queued frames after restart. here's what i've found so far: avda wasn't being reset or destroyed. while on-screen and playing normally, ReusePictureBuffer is being called. all frames are being drawn (no codec buffers come back with the PictureBuffer). when off-screen, the draw is skipped and the picture buffers come back and are released by the strategy. however, after ~20 frames off-screen, Reuse quits getting called. during the first 20 frames, codec buffers were showing up more than once, so it's not like we aren't returning them to the codec.
,
Apr 7 2016
Make sure we get a buganizer bug for this one. this is unexpected.
,
Apr 8 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/62cf4f1fab4e0cc2560983465d3fd15fde537f00 commit 62cf4f1fab4e0cc2560983465d3fd15fde537f00 Author: liberato <liberato@chromium.org> Date: Fri Apr 08 16:05:39 2016 Enable adaptive playback for spitzer, use conservative size. Android MediaCodec allocates memory for adaptive playback (dynamic resolution change) based on hints provided to the codec during construction about the maximum expected decoded frame dimensions. That can signficantly increate the memory usage / reduce the number of concurrent codec instances that chrome can use. On some devices (Samsung S3), adaptive playback also entirely breaks decoding. Decoded frames can be tiled / black and white / generally quite incorrect. Spitzer had previously turned off dynamic resolution support to fix both of these. However, it turns out that enabling adaptive support is necessary: - returning unused decoded buffers to MediaCodec without rendering can incorrectly stop MediaCodec from decoding more frames without adaptive playback enabled. - some videos on some devices (N7) play very slowly otherwise. This CL requests adaptive playback when AVDA creates the MediaCodec instance. It also plumbs the inital coded size to AVDA, and send it to MediaCodecBridge. MediaCodecBridge now uses this size, rather than 1920x1080, as the max adaptive size hint to save memory. For devices like the S3, MediaCodecBridge ignores the request for adaptive playback, and keeps it off. Providing the size to MediaCodec will also allow it to choose an appropriate input buffer size. Previously, it used the requested size of 320x240 when estimating the size of an encoded frame. BUG=599908, 596211 , 601066 Review URL: https://codereview.chromium.org/1869103002 Cr-Commit-Position: refs/heads/master@{#386091} [modify] https://crrev.com/62cf4f1fab4e0cc2560983465d3fd15fde537f00/content/common/gpu/media/android_video_decode_accelerator.cc [modify] https://crrev.com/62cf4f1fab4e0cc2560983465d3fd15fde537f00/content/common/gpu/media/android_video_decode_accelerator.h [modify] https://crrev.com/62cf4f1fab4e0cc2560983465d3fd15fde537f00/media/base/android/java/src/org/chromium/media/MediaCodecBridge.java [modify] https://crrev.com/62cf4f1fab4e0cc2560983465d3fd15fde537f00/media/base/android/java/src/org/chromium/media/MediaCodecUtil.java [modify] https://crrev.com/62cf4f1fab4e0cc2560983465d3fd15fde537f00/media/filters/gpu_video_decoder.cc [modify] https://crrev.com/62cf4f1fab4e0cc2560983465d3fd15fde537f00/media/gpu/ipc/common/media_param_traits_macros.h [modify] https://crrev.com/62cf4f1fab4e0cc2560983465d3fd15fde537f00/media/video/video_decode_accelerator.h
,
Apr 14 2016
I'm seeing this same issue on the moto x but after your change landed :( I haven't investigated in detail yet.
,
Apr 22 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/afa23676f6212a865eeda6c180849e323c020c06 commit afa23676f6212a865eeda6c180849e323c020c06 Author: dalecurtis <dalecurtis@chromium.org> Date: Fri Apr 22 04:58:26 2016 Store AVDACodecImage list in shared state, cleanup callers. Going through the texture manager every time we want to look up an AVDACodecImage is a bit onerous, instead track these within the shared state and clear them when images are destructed. This allows a couple simplificiations and cleanups and paves the way for higher frequency calls. BUG= 601066 TEST=manual playback tests. Review URL: https://codereview.chromium.org/1910063005 Cr-Commit-Position: refs/heads/master@{#389034} [modify] https://crrev.com/afa23676f6212a865eeda6c180849e323c020c06/content/common/gpu/media/android_copying_backing_strategy.cc [modify] https://crrev.com/afa23676f6212a865eeda6c180849e323c020c06/content/common/gpu/media/android_copying_backing_strategy.h [modify] https://crrev.com/afa23676f6212a865eeda6c180849e323c020c06/content/common/gpu/media/android_deferred_rendering_backing_strategy.cc [modify] https://crrev.com/afa23676f6212a865eeda6c180849e323c020c06/content/common/gpu/media/android_deferred_rendering_backing_strategy.h [modify] https://crrev.com/afa23676f6212a865eeda6c180849e323c020c06/content/common/gpu/media/android_video_decode_accelerator.cc [modify] https://crrev.com/afa23676f6212a865eeda6c180849e323c020c06/content/common/gpu/media/android_video_decode_accelerator.h [modify] https://crrev.com/afa23676f6212a865eeda6c180849e323c020c06/content/common/gpu/media/avda_codec_image.cc [modify] https://crrev.com/afa23676f6212a865eeda6c180849e323c020c06/content/common/gpu/media/avda_codec_image.h [modify] https://crrev.com/afa23676f6212a865eeda6c180849e323c020c06/content/common/gpu/media/avda_shared_state.cc [modify] https://crrev.com/afa23676f6212a865eeda6c180849e323c020c06/content/common/gpu/media/avda_shared_state.h
,
Apr 22 2016
Stealing from frank :)
,
Apr 22 2016
,
Apr 22 2016
,
Apr 22 2016
,
Apr 22 2016
,
Apr 23 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1ee5b842e11f679b21a38f156fb7d4688ff8665a commit 1ee5b842e11f679b21a38f156fb7d4688ff8665a Author: dalecurtis <dalecurtis@chromium.org> Date: Sat Apr 23 03:02:05 2016 ReleaseOutputBuffer to surface back and front buffers where possible. Takes the original patch from liberato@ and extends it to release the earliest frame to the back buffer as well as releasing to the front buffer when there is only a single outstanding frame for display. This proves enough to solve the slow n7v2 issue as well as keep decoding up to speed when scrolling the video off the page on an motox, see http://crbug.com/603768 for some more details on the off screen issue. This patch unifies all calls from the deferred strategy for releasing output buffers into a single AVDACodecImage::ReleaseOutputBuffer() call with a couple modes to support all the cases we use: - skip render: ReleaseOutputBuffer(, false); - release only: ReleaseOutputBuffer(, true); FrameListener.Wait(); - release+update: same as "release only" but also UpdateTexImage(). BUG= 601066 TEST=manual testing on n7v2 and moto x. Review URL: https://codereview.chromium.org/1892013002 Cr-Commit-Position: refs/heads/master@{#389350} [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/android_copying_backing_strategy.cc [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/android_copying_backing_strategy.h [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/android_deferred_rendering_backing_strategy.cc [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/android_deferred_rendering_backing_strategy.h [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/android_video_decode_accelerator.cc [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/android_video_decode_accelerator.h [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/avda_codec_image.cc [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/avda_codec_image.h
,
Apr 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1ee5b842e11f679b21a38f156fb7d4688ff8665a commit 1ee5b842e11f679b21a38f156fb7d4688ff8665a Author: dalecurtis <dalecurtis@chromium.org> Date: Sat Apr 23 03:02:05 2016 ReleaseOutputBuffer to surface back and front buffers where possible. Takes the original patch from liberato@ and extends it to release the earliest frame to the back buffer as well as releasing to the front buffer when there is only a single outstanding frame for display. This proves enough to solve the slow n7v2 issue as well as keep decoding up to speed when scrolling the video off the page on an motox, see http://crbug.com/603768 for some more details on the off screen issue. This patch unifies all calls from the deferred strategy for releasing output buffers into a single AVDACodecImage::ReleaseOutputBuffer() call with a couple modes to support all the cases we use: - skip render: ReleaseOutputBuffer(, false); - release only: ReleaseOutputBuffer(, true); FrameListener.Wait(); - release+update: same as "release only" but also UpdateTexImage(). BUG= 601066 TEST=manual testing on n7v2 and moto x. Review URL: https://codereview.chromium.org/1892013002 Cr-Commit-Position: refs/heads/master@{#389350} [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/android_copying_backing_strategy.cc [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/android_copying_backing_strategy.h [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/android_deferred_rendering_backing_strategy.cc [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/android_deferred_rendering_backing_strategy.h [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/android_video_decode_accelerator.cc [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/android_video_decode_accelerator.h [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/avda_codec_image.cc [modify] https://crrev.com/1ee5b842e11f679b21a38f156fb7d4688ff8665a/content/common/gpu/media/avda_codec_image.h
,
Apr 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/675f8b4aacfec7f7fb1d33f430996672c4dc3eec commit 675f8b4aacfec7f7fb1d33f430996672c4dc3eec Author: dalecurtis <dalecurtis@chromium.org> Date: Mon Apr 25 21:29:54 2016 Fix underflow and av/sync issues in low delay and stall presence. When in low delay mode we were previously transitioning to HAVE_ENOUGH if any frame was available; this may include frames which are bad. I.e. frames that are too far in the past to be effective. Instead we need to enter the underflow state in these cases and wait for effective frames to enter the queue. In low delay this should just add a frame or two of latency while we catchup since the frames should be readily available in most cases. In the stalled case, i.e. VideoFrameStream::CanReadWithoutStalling() is false, this will attempt to purge frames as fast as possible such that the decoder can catch up. This is done by taking advantage of a new VideoRendererAlgorithm::Reset() call which allows the frame queue to be purged while maintaining some of the next frame estimates. In all cases this patch also adds the ability to try and avoid ever reaching the paused underflow state by removing expired frames as they are enqueued if the decoder is not keeping. BUG=599908, 601066 TEST=new unittest, manual testing w/ AVDA adaptivePlayback=false. Review URL: https://codereview.chromium.org/1863373002 Cr-Commit-Position: refs/heads/master@{#389564} [modify] https://crrev.com/675f8b4aacfec7f7fb1d33f430996672c4dc3eec/media/renderers/video_renderer_impl.cc [modify] https://crrev.com/675f8b4aacfec7f7fb1d33f430996672c4dc3eec/media/renderers/video_renderer_impl.h [modify] https://crrev.com/675f8b4aacfec7f7fb1d33f430996672c4dc3eec/media/renderers/video_renderer_impl_unittest.cc
,
Apr 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/427a97695071d8b7662dd668cb844477dfb707bf commit 427a97695071d8b7662dd668cb844477dfb707bf Author: dalecurtis <dalecurtis@chromium.org> Date: Tue Apr 26 02:30:53 2016 Avoid unnecessary post task during frame delivery. With the three changes in this CL, primarily the first, we can now play 720p60 and 1080p60 content on the Moto X and N7v2 devices when combined with the underflow fixes from http://crrev.com/1863373002. There are three places we were able to avoid unnecessary thread hops, ordered in terms of impact: - VD::|output_cb| does not need to PostTask since it's already delivered many calls after provided. This change had the most impact, which suggests that the media thread was blocked with other tasks while the frame is delivered. All VideoDecoders are updated. - Don't trampoline GVD::ReleaseMailbox unless necessary, this also runs on the media thread when frames are dropped before being sent to the compositor. This allows underflow to catch up more quickly. - Don't trampoline for NotifyPictureRead() in AVDA and notify before attempting to release to backbuffer and setting codec indices. This speeds up frame metadata delivery to the renderer. In total this reduces the total time from NotifyPictureReady() to FrameReady() from ~[2.5ms, 9.8ms] to around ~[0.7ms,1.5ms]. BUG= 601066 TEST=720p60 and 1080p60 playback are smooth on MotoX and N7v2. Review URL: https://codereview.chromium.org/1921803002 Cr-Commit-Position: refs/heads/master@{#389671} [modify] https://crrev.com/427a97695071d8b7662dd668cb844477dfb707bf/content/common/gpu/media/android_video_decode_accelerator.cc [modify] https://crrev.com/427a97695071d8b7662dd668cb844477dfb707bf/content/common/gpu/media/gpu_video_decode_accelerator.cc [modify] https://crrev.com/427a97695071d8b7662dd668cb844477dfb707bf/media/base/video_decoder.h [modify] https://crrev.com/427a97695071d8b7662dd668cb844477dfb707bf/media/filters/ffmpeg_video_decoder.cc [modify] https://crrev.com/427a97695071d8b7662dd668cb844477dfb707bf/media/filters/gpu_video_decoder.cc [modify] https://crrev.com/427a97695071d8b7662dd668cb844477dfb707bf/media/filters/vpx_video_decoder.cc
,
Apr 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c7aeeb2d491234bfaf07e1ef4e314da09a1f57d3 commit c7aeeb2d491234bfaf07e1ef4e314da09a1f57d3 Author: dalecurtis <dalecurtis@chromium.org> Date: Tue Apr 26 22:52:43 2016 Ignore sink start attempts when no frames are present. Buffering state changes may be in flight at the time of the sink start attempt by RendererImpl. Some of these may have removed all the frames in the queue. Ignore sink start in this case. BUG= 601066 , 606733 TEST=new unittest Review URL: https://codereview.chromium.org/1924513003 Cr-Commit-Position: refs/heads/master@{#389933} [modify] https://crrev.com/c7aeeb2d491234bfaf07e1ef4e314da09a1f57d3/media/base/null_video_sink.cc [modify] https://crrev.com/c7aeeb2d491234bfaf07e1ef4e314da09a1f57d3/media/base/null_video_sink_unittest.cc [modify] https://crrev.com/c7aeeb2d491234bfaf07e1ef4e314da09a1f57d3/media/renderers/video_renderer_impl.cc [modify] https://crrev.com/c7aeeb2d491234bfaf07e1ef4e314da09a1f57d3/media/renderers/video_renderer_impl_unittest.cc
,
Apr 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a71021d6d8102712a613f19afd8ad7eb36ab2563 commit a71021d6d8102712a613f19afd8ad7eb36ab2563 Author: Dale Curtis <dalecurtis@chromium.org> Date: Thu Apr 28 18:10:45 2016 Ignore sink start attempts when no frames are present. Buffering state changes may be in flight at the time of the sink start attempt by RendererImpl. Some of these may have removed all the frames in the queue. Ignore sink start in this case. BUG= 601066 , 606733 TEST=new unittest Review URL: https://codereview.chromium.org/1924513003 Cr-Commit-Position: refs/heads/master@{#389933} (cherry picked from commit c7aeeb2d491234bfaf07e1ef4e314da09a1f57d3) Review URL: https://codereview.chromium.org/1928083002 . Cr-Commit-Position: refs/branch-heads/2717@{#6} Cr-Branched-From: 82735e00e98486689f2d6bca470b0ad18d05a985-refs/heads/master@{#389638} [modify] https://crrev.com/a71021d6d8102712a613f19afd8ad7eb36ab2563/media/base/null_video_sink.cc [modify] https://crrev.com/a71021d6d8102712a613f19afd8ad7eb36ab2563/media/base/null_video_sink_unittest.cc [modify] https://crrev.com/a71021d6d8102712a613f19afd8ad7eb36ab2563/media/renderers/video_renderer_impl.cc [modify] https://crrev.com/a71021d6d8102712a613f19afd8ad7eb36ab2563/media/renderers/video_renderer_impl_unittest.cc
,
May 2 2016
Merge-Request-51 for: http://crrev.com/387213 http://crrev.com/389034 http://crrev.com/389350 http://crrev.com/389671 http://crrev.com/389564 http://crrev.com/389933 Which are necessary to prevent offscreen videos from freezing forever as well as correctly underflow for playbacks which are low delay / stalled type.
,
May 2 2016
Your change meets the bar and is auto-approved for M51 (branch: 2704)
,
May 3 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bd880d6525642734483bfcdc42f9cd2fdc25f862 commit bd880d6525642734483bfcdc42f9cd2fdc25f862 Author: dalecurtis <dalecurtis@chromium.org> Date: Tue May 03 22:12:09 2016 Queue more input buffers and process more output if possible. We only attempt to queue a single input even though we might be able to queue more than one. There may also be more input to queue after dequeing an output. BUG= 601066 TEST=multiple inputs queued sometimes. Review-Url: https://codereview.chromium.org/1942883004 Cr-Commit-Position: refs/heads/master@{#391374} [modify] https://crrev.com/bd880d6525642734483bfcdc42f9cd2fdc25f862/media/gpu/android_video_decode_accelerator.cc
,
May 4 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/501f6225e00045e88ba56d7fe9deed6850c2906c commit 501f6225e00045e88ba56d7fe9deed6850c2906c Author: dalecurtis <dalecurtis@chromium.org> Date: Wed May 04 02:43:31 2016 Avoid waiting on the SurfaceTexture until we need to. We can let the SurfaceTexture operations complete in the background for back buffer rendering instead of waiting during frame delivery; this frees up the GPU thread for other tasks. Also reduces the wait time to be more inline with the UMA stats; some devices like the MotoX don't reliably deliver this event when the MediaCodec is underflowing. I've also seen the N7v2 drop this event every now and then. BUG= 601066 TEST=no playback regressions, less waiting. Review-Url: https://codereview.chromium.org/1924973004 Cr-Commit-Position: refs/heads/master@{#391426} [modify] https://crrev.com/501f6225e00045e88ba56d7fe9deed6850c2906c/media/gpu/avda_codec_image.cc [modify] https://crrev.com/501f6225e00045e88ba56d7fe9deed6850c2906c/media/gpu/avda_shared_state.cc [modify] https://crrev.com/501f6225e00045e88ba56d7fe9deed6850c2906c/media/gpu/avda_shared_state.h
,
May 5 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8a12536eefe4a11a23d33676fb73c71885159e02 commit 8a12536eefe4a11a23d33676fb73c71885159e02 Author: dalecurtis <dalecurtis@chromium.org> Date: Thu May 05 19:45:31 2016 Increase cases where back/front buffering early rendering occur. When dropped frames occur that are opporunties to render to the front buffer when more than one frame is available. Likewise if a later frame is chosen for front buffer rendering, frames earlier than it can be ignored when considering if the back buffer is open. There are also cases where the renderer has dropped the most recent frame and is preparing to display the frame, this releases slightly ahead of schedule assuming normal operation. In less than ideal circumstances the wrong frame may be released. BUG= 601066 TEST=none Review-Url: https://codereview.chromium.org/1939943002 Cr-Commit-Position: refs/heads/master@{#391876} [modify] https://crrev.com/8a12536eefe4a11a23d33676fb73c71885159e02/media/gpu/android_deferred_rendering_backing_strategy.cc [modify] https://crrev.com/8a12536eefe4a11a23d33676fb73c71885159e02/media/gpu/avda_codec_image.cc [modify] https://crrev.com/8a12536eefe4a11a23d33676fb73c71885159e02/media/gpu/avda_codec_image.h
,
May 6 2016
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 10 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2 commit b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2 Author: Dale Curtis <dalecurtis@chromium.org> Date: Tue May 10 04:12:38 2016 Merge to M51: Various fixes to prevent playback hang on MotoX. e886ba2 Avoid waiting on the SurfaceTexture until we need to. cecc8a4 Increase cases where back/front buffering early rendering occur. 9b07026 Queue more input buffers and process more output if possible. 9771835 Avoid unnecessary post task during frame delivery. fb00bd3 ReleaseOutputBuffer to surface back and front buffers where possible. 6c5e1df Delay actual flush and release in AVDA 4ddcd18 Store AVDACodecImage list in shared state, cleanup callers. BUG= 598963 , 601066 TBR=liberato, timav (cherry picked from commit 5cda4bb2b9d1a7b7821f87df58337928361ce2c3) Review URL: https://codereview.chromium.org/1963773003 . Cr-Commit-Position: refs/branch-heads/2704@{#462} Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251} [modify] https://crrev.com/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2/content/common/gpu/media/android_copying_backing_strategy.cc [modify] https://crrev.com/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2/content/common/gpu/media/android_copying_backing_strategy.h [modify] https://crrev.com/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2/content/common/gpu/media/android_deferred_rendering_backing_strategy.cc [modify] https://crrev.com/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2/content/common/gpu/media/android_deferred_rendering_backing_strategy.h [modify] https://crrev.com/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2/content/common/gpu/media/android_video_decode_accelerator.cc [modify] https://crrev.com/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2/content/common/gpu/media/android_video_decode_accelerator.h [modify] https://crrev.com/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2/content/common/gpu/media/avda_codec_image.cc [modify] https://crrev.com/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2/content/common/gpu/media/avda_codec_image.h [modify] https://crrev.com/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2/content/common/gpu/media/avda_shared_state.cc [modify] https://crrev.com/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2/content/common/gpu/media/avda_shared_state.h [modify] https://crrev.com/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2/content/common/gpu/media/gpu_video_decode_accelerator.cc [modify] https://crrev.com/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2/media/base/video_decoder.h [modify] https://crrev.com/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2/media/filters/ffmpeg_video_decoder.cc [modify] https://crrev.com/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2/media/filters/gpu_video_decoder.cc [modify] https://crrev.com/b6b2141b0683cad4d1f7ccfcaa6350c31437cdf2/media/filters/vpx_video_decoder.cc
,
May 10 2016
Merged everything except for the low-delay/stall underflow code since that causes problems which are more noticeable to users until we have a better fix for high-res content on the MotoX.
,
May 10 2016
Going to close this bug now and we'll use a new one for av/sync.
,
May 10 2016
|
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by liber...@chromium.org
, Apr 7 2016Owner: liber...@chromium.org
Status: Started (was: Available)