1068001 - Seeking does not work in videos recorded with MediaStreamRecorder

Status: UNCONFIRMED

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

Description

[brian]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20140910030204

Steps to reproduce:

1) Record a video using MediaStreamRecorder, as in this example: https://www.webrtc-experiment.com/msr/audio-recorder.html
2) Save the resulting video as a Blob
3) Play the video in the browser and again in VLC


Actual results:

When the video plays back in Firefox and in VLC, it is impossible to seek within the video. Seeking does work in Chrome.

When loading the video in Firefox, after the "durationchange" and "loadedmetadata" methods, the duration is reported as 0. In Chrome, the duration is reported as Infinity.

An audio file recorded without video works fine.


Expected results:

The video file should be saved with a duration, and seeking should function properly.

Comment 1

[brian]

Forgot to mention the browser version. It's the same one I used to report the bug, listed above.

Here's the output of ffprobe run on the recorded file. Note the duration and bitrate.

Input #0, matroska,webm, from 'recorded.webm':
  Metadata:
    encoder         : QTmuxingAppLibWebM-0.0.1
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0(eng): Video: vp8, yuv420p, 640x480, SAR 1:1 DAR 4:3, 30 fps, 30 tbr, 1k tbn, 1k tbc (default)
    Stream #0:1(eng): Audio: vorbis, 44100 Hz, mono, fltp (default)

Comment 2

[brian]

This is still an issue.

But the demo link above is incorrect. Audio recording seems to work fine. It's this one: https://www.webrtc-experiment.com/msr/video-recorder.html

Comment 3

[christianalfoni]

Hi there,

Just wanted to comment on this being a problem on a service I am building. Great that FireFox handles video/audio recording, but it is a pretty huge deal that you are not able to seek the video after the recording. Would be great if this got attention.

Comment 4

[Thijs Triemstra]

Also running into the same issue. ffprobe shows missing duration and bitrate for a file recorded with MediaRecorder:

ffprobe version N-74720-g21bfeec Copyright (c) 2007-2015 the FFmpeg developers
  built with Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
  configuration: --prefix=/usr/local --enable-gpl --enable-nonfree --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --disable-doc
  libavutil      54. 31.100 / 54. 31.100
  libavcodec     56. 59.100 / 56. 59.100
  libavformat    56. 40.101 / 56. 40.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 40.100 /  5. 40.100
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc    53.  3.100 / 53.  3.100
Input #0, matroska,webm, from '/Users/thijstriemstra/Downloads/RecordRTC.webm':
  Metadata:
    encoder         : QTmuxingAppLibWebM-0.0.1
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0(eng): Video: vp8, yuv420p, 640x480, SAR 1:1 DAR 4:3, 30 fps, 30 tbr, 1k tbn, 1k tbc (default)
    Stream #0:1(eng): Audio: vorbis, 44100 Hz, mono, fltp (default)


Using the Whammy library everything seems fine:

ffprobe version N-74720-g21bfeec Copyright (c) 2007-2015 the FFmpeg developers
  built with Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
  configuration: --prefix=/usr/local --enable-gpl --enable-nonfree --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --disable-doc
  libavutil      54. 31.100 / 54. 31.100
  libavcodec     56. 59.100 / 56. 59.100
  libavformat    56. 40.101 / 56. 40.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 40.100 /  5. 40.100
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc    53.  3.100 / 53.  3.100
Input #0, matroska,webm, from '/Users/thijstriemstra/Downloads/capture.webm':
  Metadata:
    encoder         : whammy
  Duration: 00:00:20.34, start: 0.000000, bitrate: 3093 kb/s
    Stream #0:0: Video: vp8, yuv420p, 320x240, SAR 1:1 DAR 4:3, 16.67 fps, 16.67 tbr, 1k tbn, 1k tbc (default)

Comment 5

[Thijs Triemstra]

Same results with https://simpl.info/mediarecorder/

Input #0, matroska,webm, from '/Users/thijstriemstra/Downloads/test.webm':
  Metadata:
    encoder         : QTmuxingAppLibWebM-0.0.1
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0(eng): Video: vp8, yuv420p, 640x480, SAR 1:1 DAR 4:3, 30 fps, 30 tbr, 1k tbn, 1k tbc (default)
    Stream #0:1(eng): Audio: vorbis, 44100 Hz, mono, fltp (default)

Comment 6

[Guang-De Lin]

Bug 657791 to support seeking in webm files with no Cues element.
Bug 969290 to add Cues to webm files generated by MediaRecorder.

Comment 7

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

Mass change P2 -> P3

Comment 8

[John Thomson]

For the record, another team would very much like a fix for this, or even a good work-around. We want to feed videos recorded in Firefox (actually in GeckoFx) into video editing tools, and most tools we've tried won't open or won't successfully edit videos recorded in FF, apparently because of this problem.
It's relatively easy to fix with ffmpeg, but bundling ffmpeg with our product would double its size.

Comment 9

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

The primary issue with creation of seekable files at this stage is that it is largely incompatible with the current MediaRecorder spec (without post processing or similar). There's been some discussion on this on the spec Github[0][1], but there are those who see the changes needed for this as too much of a dilution to the API.

[0]: https://github.com/w3c/mediacapture-record/issues/119
[1]: https://github.com/w3c/mediacapture-record/issues/67#issuecomment-247283783

Comment 10

[John Thomson]

Hmmm, I wasn't really aware that I wanted a 'seekable' file...in fact until I read the articles you quoted I was thinking the title on this bug was somewhat misleading. All I'm asking for is that when I record a video blob with MediaRecorder and save it to a file, it should be a correctly formatted mp4 with valid metadata indicating its length, bitrate, and so forth. I want ffprobe to give valid numbers instead of "Duration: N/A, ..., bitrate: N/A" (see above, Thijs Triemstra's comment). I now gather that the problem is that the required metadata has to be put in the first chunk that goes into the blob (sorry, that's probably the wrong technical term) and that's no longer available to the recorder to fix unless it can seek to earlier chunks which breaks the whole API...
But I also see several references suggesting that some fairly simple Javascript could be written to clean up a blob assembled from MediaRecorder in the same way that ffmpeg can clean up the resulting file. If someone has actually done that, a direct link from this issue would be very helpful; I'm having trouble tracking it down from the links you gave. Of course what has to be done probably depends on the MediaRecorder settings for codec etc, so maybe there isn't a general solution...but it's infuriating that we can so nearly make useful recordings, but not quite...