crash seeking in webm file [@ nsBuiltinDecoderReader::DecodeToTarget ]

RESOLVED FIXED in mozilla8

Status

()

Core
Audio/Video
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Dolske, Assigned: cpearce)

Tracking

unspecified
mozilla8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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

6 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).
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
Blocks: 670055
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 [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: nobody → chris
Status: NEW → ASSIGNED
Created attachment 549700 [details] [diff] [review]
Patch
Attachment #549700 - Flags: review?(kinetik)
Attachment #549700 - Flags: review?(kinetik) → review+
http://hg.mozilla.org/integration/mozilla-inbound/rev/e9c2f5390408
Whiteboard: [inbound]
http://hg.mozilla.org/mozilla-central/rev/e9c2f5390408
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Justin, can you please verify if this bug is fixed?
You need to log in before you can comment on or make changes to this bug.