1231842 - Capturing CanvasStream with MediaRecorder creates broken VP8 webm

Status: RESOLVED DUPLICATE of bug 969290

(Core :: Audio/Video: Recording, defect, P1)

Description

[The 8472]

Attachment: broken.webm

Drawing images to a canvas and capturing it with a MediaRecorder creates the following webm which breaks after first playback. I.e. it can't be looped and even attempting to manually seek to the beginning fails.

Video was created on linux, Firefox 45.0a1 20151210030212 

Playback breaks on both windows and linux.

Comment 1

[The 8472]

Attachment: fixed.webm

Applying |mkvmerge broken.webm -o fixed.webm| makes it play properly, which points to incorrect metadata.

Comment 2

[Andreas Pehrson [:pehrsons]]

Metadata for duration and such goes in the beginning of the file. This doesn't work for MediaRecorder as it has an api that provides slices of the recorded file while it is recording, since in case of a long recording we don't want to wait until it has finished before passing along the first blob.

I.e., the duration is not known when the metadata is written, and we typically don't have access to those headers when the duration becomes known later.

Comment 3

[The 8472]

Diffing the mkvinfo output shows that the fixed version contains cues at the end, could MediaRecorder append those? 

And maybe the duration field should be completely omitted since the MKV spec says a) it's optional b) it as no default value c) its range of valid values is > 0
Thus so a duration 0 is non-conformant.

Also, when the recorder only emits a single blob instead of smaller chunks it could make an effort to fix up the header.

Comment 4

[The 8472]

Another option would be to start a new segment for each blob, duration, segment length and cues would be known for that segment at the point where the blob is made available.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

This is also covered under another bug I think; it may thus be a dup.  I'm unsure if starting a new segment for each slice is a viable option and that it wouldn't cause problems when something tries to assemble the slices and play them as a whole.  (Rillian?)

Also we'll need to look at the duration value (even if the spec says it's optional, that doesn't mean that it is in practice).

The un-sliced version "should" play, but there's a bug there too with seek and repeat.

We likely want to improve this soon, and at least document any restrictions in place and file bugs to relax them.