Closed
Bug 675045
Opened 13 years ago
Closed 13 years ago
crash seeking in webm file [@ nsBuiltinDecoderReader::DecodeToTarget ]
Categories
(Core :: Audio/Video, defect)
Core
Audio/Video
Tracking
()
RESOLVED
FIXED
mozilla8
People
(Reporter: Dolske, Assigned: cpearce)
References
Details
Attachments
(1 file)
2.08 KB,
patch
|
kinetik
:
review+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•13 years ago
|
||
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).
Assignee | ||
Comment 2•13 years ago
|
||
This is a regression from bug 670055 which is on the ff8 release train.
OS: Mac OS X → All
Hardware: x86 → All
Target Milestone: --- → mozilla8
Comment 3•13 years ago
|
||
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.
Assignee | ||
Comment 4•13 years ago
|
||
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. [1] http://www.webmproject.org/code/specs/container/
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → chris
Status: NEW → ASSIGNED
Assignee | ||
Comment 5•13 years ago
|
||
Attachment #549700 -
Flags: review?(kinetik)
Updated•13 years ago
|
Attachment #549700 -
Flags: review?(kinetik) → review+
Assignee | ||
Comment 6•13 years ago
|
||
http://hg.mozilla.org/integration/mozilla-inbound/rev/e9c2f5390408
Whiteboard: [inbound]
Comment 7•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/e9c2f5390408
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•13 years ago
|
Whiteboard: [inbound]
You need to log in
before you can comment on or make changes to this bug.
Description
•