I just crashed twice with the following video. Current OS X Nightly. http://people.mozilla.org/~mratcliffe/StyleInspector.webm 1) load video 2) scroll down to scrubber (it's taller than my window size, dunno if that matters) 3) grab scrubber and start moving to the right bp-7fcc5252-f05a-4940-827f-d1e982110728 bp-e9648ee8-eca0-413c-a45a-c046a2110728
Oh, pretty sure this must be a regression since sometime after 6/29, since I know I repeatedly viewed that video while reviewing bug 582596 (where it's linked).
This is a regression from bug 670055 which is on the ff8 release train.
I get: ###!!! ASSERTION: Target must at or be after data start.: 'targetSample >= startSample', file /home/derf/src/mozilla/mozilla-central/content/media/nsBuiltinDecoderReader.cpp, line 344 If true, that means samplesToPrune will be negative, which causes the memcpy below to fail.
This file is badly muxed, it's not a valid WebM file. Justin, do you know what tool was used to produce it? The file is duration 4:17, but it has only 18 Vorbis packets scattered throughout the file, mostly occurring near the middle. I'm guessing those packets contain compressed silence to cover the duration of the VP8 stream. This file violates the WebM container guidelines , which say: "Audio blocks that contain the video key frame's timecode should be in the same cluster as the video key frame block." Because of that, the audio blocks required to play the media at the seek target lie before the video data, which is why the next audio packet we read is so far after the target, and we end up with an integer overflow. We should just bail out of DecodeToTarget in this condition, we'll end up playing silence to play across the gap.  http://www.webmproject.org/code/specs/container/
Created attachment 549700 [details] [diff] [review] Patch
Justin, can you please verify if this bug is fixed?