Add new consecutiveDroppedFrames callback
This is similar to the droppedFrames callback, but represents the number of consecutive frames that we dropped before rendering a frame or seeking or stopping the renderer.
While we already have a maxConsecutiveDroppedFrame available in the DecoderCounters, this doesn't provide enough visibility into the actual statistics of dropped frames.
If we get 200 dropped frames and a maxConsecutive of 20, we don't know if we dropped 20 frames in a row once and then dropped a single frame 180 times or if we dropped 20 frames 10 times.
We could add some code on our OnDroppedFrames callback to estimate if two calls are for consecutive frames, but that seems very fragile.
There is an open issue currently on how often to notify, and my preference would be to add a new minConsecutiveDroppedFramesToNotify similar to the maxDroppedFramesToNotify but that would only notify if more than X consecutive frames were dropped.
Hi @microkatz @tonihei @icbaker , is this ready to be pushed upstream? I see Gilles has addressed most comments
@khouzam
Apologies for the delay!
I was holding off from additional comments and edits as we instituted a new Builder pattern into MediaCodecVideoRenderer rather than adding new constructors for all these new variables/thresholds etc. This PR then got lost in the weeds after that was completed here, https://github.com/androidx/media/commit/decfb9b0a9da075eba4629f470fe116a026f61e7.
There are a few requests for the PR. First, would you be able to rebase to the tip of main and transition to a Builder parameter for your consecutiveDroppedFrames threshold?
Secondly, in discussions with the team, it was thought better if we could still have a single listener event for dropped frames rather than two. The idea would be to add an additional parameter to onDroppedFrames for maxConsecutive. Currently, onDroppedFrames may be invoked when the dropped frames threshold is reached. This would be changed so that the invocation would occur where you are currently checking for consecutive frame drops notification. At onStopped, onDisabled, and after a successful frame render.
Would this suggestion still work to provide you the granularity of analytics you need?
Please reach out if you have additional questions.
Thanks for the feedback @microkatz, a single listener would also work, as long as we make sure to invoke it appropriately. We'll update the pull request with a rebase and the changes.