1061402 - After seeking in a WebM MSE video the decode fails with an invalid frame buffer error from libvpx

Status: RESOLVED WORKSFORME

(Core :: Audio/Video: Playback, defect)

Description

[cajbir (:cajbir)]

After seeking in a WebM MSE video the decode fails with an invalid frame buffer error from libvpx in WebMReader::DecodeVideoFrame. A workaround for this was put in place in bug 1061400. This bug is to fix the underlying issue.

Comment 2

[Matthew Gregan [:kinetik]]

Not sure how I managed that, but I posted bug 1062101's comment here and this bug's comment there.  Made it private to avoid confusion.  Intended comment:

I stuck a MOZ_ASSERT(false) into WebMReader::DecodeVideoFrame where we return false on a decode error to try to catch this.  I've only hit it once so far, and I'm not sure what to make of it:

- Playing at ~29.8s
- Seek to 104s
- Waits for data/new decoders, seeks correctly in audio and video frame
- Next RequestVideoData switches back to original reader (due to bug mentioned below)
- Decode frame 29.84
  ...
- Decode frame 29.92
- Hit assert while attempting to decode frame 29.60
  Examining the file in question, the frame has a size of 186 bytes in the WebM file
  The parsed frame in the nestegg_packet has a valid looking data pointer and the correct length

So we're not obviously trying to parse random data after losing sync in the file.  It could be memory corruption (will Valgrind a build to check soon), or something else I'm missing.

Note that this was in a build with a seeking bug I introduced where we'd switch to the correct reader, seek, then immediately switch back to the pre-seek-position reader and continue decoding.  That's broken, but it shouldn't cause this issue directly.  I don't seem to hit the assert in builds without this bug.

Comment 3

[Matthew Gregan [:kinetik]]

(In reply to Matthew Gregan [:kinetik] from comment #2)

> - Hit assert while attempting to decode frame 29.60

I mean 29.96.

That frame is at offset 459187 in the file, 30.00 is at 459380, and 30.040 is at 459621.

Also, the underlying SourceBufferResource has mOffset of 459624, mEnded is true,  mInputBuffer.mLogicalLength of 1025900 and mInputBuffer.mOffset of 0.  So libnestegg appears to have read 29.96, 30.00, and the first 3 bytes (which will be the block ID and the size) of 30.040.  So it seems like the expected data is present and we're not hitting a bug in SBR.

Comment 4

[cajbir (:cajbir)]

I have not hit this using the patch list described in bug 1061400 comment 4. It's either become a lot more intermittent or gone away. The particular fix that did it for me was dealing with the discontinguous flag in seeking samples.