Last Comment Bug 675045 - crash seeking in webm file [@ nsBuiltinDecoderReader::DecodeToTarget ]
: crash seeking in webm file [@ nsBuiltinDecoderReader::DecodeToTarget ]
Product: Core
Classification: Components
Component: Audio/Video (show other bugs)
: unspecified
: All All
-- normal (vote)
: mozilla8
Assigned To: Chris Pearce (:cpearce)
: Maire Reavy [:mreavy] Please needinfo me
Depends on:
Blocks: 670055
  Show dependency treegraph
Reported: 2011-07-28 14:45 PDT by Justin Dolske [:Dolske]
Modified: 2011-08-11 11:22 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch (2.08 KB, patch)
2011-07-31 16:55 PDT, Chris Pearce (:cpearce)
kinetik: review+
Details | Diff | Splinter Review

Description User image Justin Dolske [:Dolske] 2011-07-28 14:45:56 PDT
I just crashed twice with the following video. Current OS X Nightly.

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

Comment 1 User image Justin Dolske [:Dolske] 2011-07-28 14:49:13 PDT
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).
Comment 2 User image Chris Pearce (:cpearce) 2011-07-28 15:06:51 PDT
This is a regression from bug 670055 which is on the ff8 release train.
Comment 3 User image Timothy B. Terriberry (:derf) 2011-07-28 15:14:03 PDT
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.
Comment 4 User image Chris Pearce (:cpearce) 2011-07-31 16:45:38 PDT
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 [1], 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.

Comment 5 User image Chris Pearce (:cpearce) 2011-07-31 16:55:33 PDT
Created attachment 549700 [details] [diff] [review]
Comment 7 User image Marco Bonardo [::mak] 2011-08-01 08:06:10 PDT
Comment 8 User image Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-08-11 11:22:11 PDT
Justin, can you please verify if this bug is fixed?

Note You need to log in before you can comment on or make changes to this bug.