Closed Bug 1245775 Opened 8 years ago Closed 8 years ago

MediaRecorder Fails when recording a ScreenCapturing stream

Categories

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

44 Branch
x86_64
macOS
defect

Tracking

()

RESOLVED DUPLICATE of bug 1213775

People

(Reporter: saulnoz, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.97 Safari/537.36

Steps to reproduce:

using an extension on a web page to enable ScreenCapturing (https://github.com/muaz-khan/WebRTC-Experiment/tree/master/Firefox-Extensions)
Request screen sharing then use a media recorder to record this stream


Actual results:

The generated webm is not well encoded and could not be readed neither in FF or VLC


Expected results:

The generated webm is should be readed in FF or VLC
Component: Untriaged → Webapp Runtime
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64
Component: Webapp Runtime → Audio/Video: Recording
Product: Firefox → Core
The recorded file contains frames with various resolutions.
when the recorded blob is played in FF or vlc, it can't be read.

After a re-encoding of the fil with ffmpeg, the file can be read in FF or vlc.

I guess the VideoTrackEncoder changes resolution to avoid performance issues.

This problem seems to be related with the one described here : http://stackoverflow.com/questions/35209608/mediarecorder-changes-size-without-provocation
After browsing FF source code, I Guess the encoder uses VP8 spatial resampling, even if as mentionned in the webmproject "VP8 supports both temporal and spatial resampling. These are specialist parameters and are not generally recommended".
This isn't spatial resampling.

MediaRecorder will record what's fed in, which may be video where the resolution can change (such as a window capture, or a remote WebRTC video stream, or canvas.captureStream()), or just rotating a smartphone.  However, many video playback tools will fail to play these, though they're valid encodings.  The latest VLC I think  can handle it, though not well.  Older ones crashed.

What to do about it is another question.

mreavy and I talked about this, and we think that the best way forward is to pitch a setting in the spec for "allowResolutionChange", with a default of 'false', and in the meantime lock the resolution on the first one seen.  Note that this means in some cases letterboxing if an aspect ratio changes!
Status: UNCONFIRMED → NEW
Rank: 15
Ever confirmed: true
Priority: -- → P1
Yes but in my case i made a window capture of the entire screen and the resolution of my screen doesn't change during the capture, so maybe the window capture stream should have a fixed resolution during the capture ?
I believe this is a dup of bug 1213775 which just landed on inbound; if you can grab a nightly build and verify that would help a lot

(Note: after that patch merges to mozilla-central (basically the first Nightly the day (pacific time) after it merges to mozilla-central); most likely this means tomorrow's Nightly, but it might be the day after.)
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(saulnoz)
Resolution: --- → DUPLICATE
I tried with the nightly 47.0a1 (2016-03-01), but I still have resolution changes in the webm stream. I'll try in a few days.
Finally the commit https://hg.mozilla.org/mozilla-central/rev/8fd524b61720 of the Bug 1213775 just disabled the spatial resampling;) so maybe I was right, even if we don't care !
Flags: needinfo?(saulnoz)
I think the patch for Bug 1213775 will be in the Nightly of today, so try in a few hours.
Hello, I tried with 47.0a1 (2016-03-03), there is no more problems, no resolution changes !
Great, and the quality of the recorded video is excellent now.

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