1219460 - Corrupt webm files when being played in a video tag

Status: RESOLVED DUPLICATE of bug 969290

(Core :: Audio/Video: Playback, defect, P2)

Description

[Peter Bengtsson [:peterbe]]

Attachment: Screenshot 2015-10-28 15.15.30.png

Steps to reproduce:

1. Go to https://air-dev.allizom.org/
2. Sign in (ideally with your LDAP email or your vouched mozillians.org account)
3. Go to https://air-dev.allizom.org/new/record
4. Click the start "Start Camera" button
5. Accept the default share settings (e.g. camera and microphone)
6. Press "Start recording" and make a video that is at least 5-10 seconds.

Expected result:
* A page that with the (centered) headline that says "Happy?" with two buttons ("Upload Recording", "Restart Recording")
* A big video player that you can play your recording. ...over and over. 

Actual result:
* In the video tag element is says "Video can't be played because the file is corrupt."
See attached screenshot

Note: If you make a 1-2 second recording, it almost always work to play the video (...before uploading it).

Comment 1

[Peter Bengtsson [:peterbe]]

The javascript code that puts the data into the video tag is this:
https://github.com/mozilla/airmozilla/blob/535ee6adae0e46b2b9ddedc437045acb5ecf520d/airmozilla/new/static/new/js/controllers.js#L590

The recording is done with RecordRTC.js [0] and this code used to work some weeks or months ago. 

[0] https://github.com/muaz-khan/WebRTC-Experiment/tree/master/RecordRTC

Comment 2

[Peter Bengtsson [:peterbe]]

As you an see here, the webm recording [0] could be uploaded to Vid.ly and transcoded and now perfectly viewable [1]

[0] https://air-mozilla-uploads-dev.s3.amazonaws.com/2015/10/28/20151028222307-b64b6de6aa964.webm
[1] https://air-dev.allizom.org/demonstrating-1219460/

Comment 3

[Ralph Giles (:rillian)]

I can reproduce, will see what's wrong with the stream.

In general we need to provide better error reports (write media format errors to js console instead of stderr) so it's more obvious what's wrong here.

Comment 4

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

This should be fixed in nightly. Can you still reproduce the issue?

Comment 5

[Peter Bengtsson [:peterbe]]

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #4)
> This should be fixed in nightly. Can you still reproduce the issue?

I don't have Nightly but I followed the steps in the bug description and this time I did NOT get a "Video can't be played because the file is corrupt." error. 

https://air-dev.allizom.org/12-seconds-of-nothing/ 

However, the video is played sped up. The original .webm file was just fine https://air-mozilla-uploads-dev.s3.amazonaws.com/2016/04/12/20160412095316-2b00273220b14.webm
I guess I need to look into why it plays at a different speed.

Comment 6

[Peter Bengtsson [:peterbe]]

So, if it's working now in DevEdition. Does that mean we can close this bug?

Comment 7

[Peter Bengtsson [:peterbe]]

(In reply to Peter Bengtsson [:peterbe] from comment #6)
> So, if it's working now in DevEdition. Does that mean we can close this bug?

No. I suspect there's something weird going on and its either our fault or Vid.ly's fault. 

Again, see 
https://air-dev.allizom.org/12-seconds-of-nothing/ 

* Play it and note that it's played in 1.5-2x speed (or something).
* Click the Download tab and notice that if you play the WebM or the Mpeg4 files, they play at extra speed too. 
* Check out the original https://air-mozilla-uploads-dev.s3.amazonaws.com/2016/04/12/20160412095316-2b00273220b14.webm and note that it's NOT playing fast. 
* wget that file and inspect it with ffmpeg. Notice that there's no Duration https://gist.github.com/peterbe/a7eba4b5c086a52d4a628532bfa5224c#file-gistfile2-txt-L17
* Try converting the file to MPEG4 with `ffmpeg -i 20160412095316-2b00273220b14.webm foo.mpg` and that file doesn't even play in my Quicktime Player.

Comment 8

[Peter Bengtsson [:peterbe]]

Note: On the "Download" tab, the links there are the output of what which Vid.ly create from the original .webm file that was uploaded to S3. 

Note2: I'm still only on DevEdition.

Comment 9

[Peter Bengtsson [:peterbe]]

So thought I'd try with Nightly (48.0a1) and that crashed the browser. 
https://crash-stats.mozilla.com/report/index/eec4b20b-eeca-4748-93e1-0ba782160412

Comment 10

[Ralph Giles (:rillian)]

I took a brief look at the framerate thing, which I can reproduce. The original and vid.ly version of the file have the same number of frames, and ffprobe reports both as 30 fps. The input uses the 'FrameRate' element, which is deprecated in WebM, and mkvalidate complains about keyframe marking or positioning in the input file, so maybe that confused the transcoder.

The vid.ly version also plays with the wrong aspect ratio in gstreamer.

Comment 11

[Peter Bengtsson [:peterbe]]

(In reply to Ralph Giles (:rillian) from comment #10)
> I took a brief look at the framerate thing, which I can reproduce. The
> original and vid.ly version of the file have the same number of frames, and
> ffprobe reports both as 30 fps. The input uses the 'FrameRate' element,
> which is deprecated in WebM, and mkvalidate complains about keyframe marking
> or positioning in the input file, so maybe that confused the transcoder.
> 
> The vid.ly version also plays with the wrong aspect ratio in gstreamer.

I'm not very good at this stuff, but files on Vid.ly are basically their repackaging of the original .webm files we upload to S3. 

If you want access to one of those S3 URLs for a video of your own recording, ping me on irc (@peterbe) to provide you the link. 

My thinking is that, if the recorded .webm file is so odd that it doesn't have a duration and that I can't convert it locally with *my* ffmpeg then there's something wrong with the source.

Comment 12

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Maire - this looks like it might be a recording issue. Do you want to take it on?

Comment 13

[Maire Reavy [:mreavy]]

This looks like a dup of bug 969290