Issue metadata
Sign in to add a comment
|
VideoFrameController::OnBeginFrame is called for invisible layers. |
||||||||||||||||||||||
Issue descriptionPreviously these callbacks were not delivered when a layer becomes invisible; i.e. scrolled off the page. This triggers video frame resource uploads and holds onto the VideoFrame object without drawing, which can starve hardware video decoders which have limited output buffers. I.e. on a Moto X w/ the spitzer pipeline enabled this will cause the last draw frame to freeze forever ( issue 601066 ). To reproduce just take a ToT build on any platform (I used Linux and Android) to: http://storage.googleapis.com/dalecurtis/tag.html?src=buck2.mp4 And scroll the video frame off the page, if you have logging enabled you'll notice that VideoFrameProviderClientImpl::OnBeginFrame() is still being called regularly, but the frames are never drawn -- causing them to be counted as dropped frames to the client. Aside from being inefficient by uploading resources, this will muck of accounting of dropped frames by the client.
,
Apr 15 2016
Actually, the dropped frame counts may not be an issue, DidDrawFrame() is actually being called, so the frame is considered for drawing and thus isn't counted as a dropped frame.
,
Apr 15 2016
,
Apr 15 2016
Preliminary investigation on M-51 linux: 1. VideoFrameProviderClientImpl::OnBeginFrame gets called. 2. once every two frames the VideoFrameProvider tells us that it needs to put a new video frame and calls SetNeedsRedraw 3. the scheduler tries to draw, LTHI::CalculateRenderPasses reports an empty rect, but draw result = success and LTHI::DidDrawAllLayers gets called which calls VideoFrameProviderClient::DidDrawFrame which in turn tells the provider that the frame was drawn. 4. the scheduler keeps asking for begin frames because the video frame provider client impl is active.
,
Apr 15 2016
Have a workaround for our android issue https://codereview.chromium.org/1892013002, so I guess the only real issue is that we're uploading frames that we're never going to use which will probably have power impacts for invisible videos. FWIW, not having background rendering would greatly simplify our code if that issue can be solved while keeping this/similar behavior. Though long ago I think we decided that we prefer a 250ms cycle in cases like this to even further reduce power consumption.
,
Apr 17 2016
This usually happens with the flash itself (.swf files)
,
Apr 21 2016
dale, can you assign to a proper owner?
,
Apr 22 2016
Over to sunnyps@ to make the call on what the expected behavior here is nowadays.
,
Apr 22 2016
I don't know if the behavior was ever different from what it is now. We can't tell at the beginning of the frame if the video layer is going to be visible or not. But we do tell the VideoLayerImpl to draw (at the end of the frame) if it's visible. dalecurtis@ what do you think should happen wrt OnBeginFrame?
,
Apr 22 2016
Hmm, I think you're right. Sorry, I'm conflating background tabs vs off screen elements. It's only when a tab is backgrounded that we stop receiving begin frame callbacks. I just verified this locally. I think we'll need to land the patch I mentioned above to workaround the frame never being drawn in our zero-copy path. This particular issue is WontFix then. We already have issue 601066 for the moto x issue. Sorry for the noise! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dalecur...@chromium.org
, Apr 15 2016