New issue
Advanced search Search tips

Issue 843438 link

Starred by 3 users

Issue metadata

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



Sign in to add a comment

CodecWrapper needs to handle EOS after flush

Project Member Reported by xhw...@chromium.org, May 16 2018

Issue description

It seems some MediaCodecs cannot handle an EOS buffer as the first buffer. So in CodecWrapperImpl, we have a DCHECK on this [1]:

    // Some MediaCodecs consider it an error to get an EOS as the first buffer
    // ( http://crbug.com/672268 ).
    DCHECK_NE(state_, State::kFlushed);

However, it's actually possible that after config change, which triggers the flush logic, the first buffer read from the demuxer is an EOS buffer. In that case we'll actually hit this DCHECK.

For the record, this has been discussed in
https://chromium-review.googlesource.com/c/chromium/src/+/1056490/5/media/gpu/android/codec_wrapper.cc#223

[1] https://cs.chromium.org/chromium/src/media/gpu/android/codec_wrapper.cc?rcl=de67106ba27287f1b29a8094aabe4d275ca3beb6&l=221
 
notes to self:

either (a) return a new "EOS elided" error message and make the client understand this, or (b) record a count of elided EOSes and return fake eos buffers from DequeueOutput.  note that for (b), we know that we're starting with no buffers queued since that (i think) clears the flushed state.

Sign in to add a comment