ffmpegelectronwebm

Generating timestamps in webm transport stream with ffmpeg


I am recording screen capture of my Electron app to a file, as suggested here: Save captured video to file in Electron

It works great, but the file is a “transport stream”. I can play it in Chrome browser, but can’t adjust the time slider.

The suggestion was to use ffmpeg to post-process the file. The simplest, straight-forward command I found is:

ffmpeg -fflags +genpts -i in.webm out.webm

I thought that this simply generates timestamps. However, the out.webm file is 15 times smaller than in.webm! I don’t see any change in the quality. The downside is - the processing takes about the same time as the duration of the video.

Two questions:

  1. Is there any way I can speedup this “timestamping” process?
  2. Can I record a video that is already 15 times smaller in size?

I specify maxFrameRate: 30 when calling webkitGetUserMedia().

Here is the output of that ffmpeg command:

vlad$ ffmpeg -fflags +genpts -i in.webm out.webm
ffmpeg version 4.3.2 Copyright (c) 2000-2021 the FFmpeg developers
  built with Apple clang version 12.0.0 (clang-1200.0.32.29)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/4.3.2 --enable-shared --enable-pthreads --enable-version3 --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librtmp --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox
  libavutil      56. 51.100 / 56. 51.100
  libavcodec     58. 91.100 / 58. 91.100
  libavformat    58. 45.100 / 58. 45.100
  libavdevice    58. 10.100 / 58. 10.100
  libavfilter     7. 85.100 /  7. 85.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  7.100 /  5.  7.100
  libswresample   3.  7.100 /  3.  7.100
  libpostproc    55.  7.100 / 55.  7.100
Input #0, matroska,webm, from 'in.webm':
  Metadata:
    encoder         : Chrome
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv), 2560x1416, SAR 1:1 DAR 320:177, 1k tbr, 1k tbn, 1k tbc (default)
    Metadata:
      alpha_mode      : 1
Stream mapping:
  Stream #0:0 -> #0:0 (vp9 (native) -> vp9 (libvpx-vp9))
Press [q] to stop, [?] for help
[libvpx-vp9 @ 0x7f85f2012600] v1.9.0
[libvpx-vp9 @ 0x7f85f2012600] Neither bitrate nor constrained quality specified, using default CRF of 32
Output #0, webm, to 'out.webm':
  Metadata:
    encoder         : Lavf58.45.100
    Stream #0:0(eng): Video: vp9 (libvpx-vp9), yuv420p, 2560x1416 [SAR 1:1 DAR 320:177], q=-1--1, 1k fps, 1k tbn, 1k tbc (default)
    Metadata:
      alpha_mode      : 1
      encoder         : Lavc58.91.100 libvpx-vp9
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
frame=  209 fps=5.8 q=0.0 Lsize=     881kB time=00:00:17.81 bitrate= 405.0kbits/s speed=0.494x    
video:879kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.231567%

And here is the information on both files from ffprobe:

vlad$ ffprobe in.webm
ffprobe version 4.3.2 Copyright (c) 2007-2021 the FFmpeg developers
  built with Apple clang version 12.0.0 (clang-1200.0.32.29)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/4.3.2 --enable-shared --enable-pthreads --enable-version3 --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librtmp --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox
  libavutil      56. 51.100 / 56. 51.100
  libavcodec     58. 91.100 / 58. 91.100
  libavformat    58. 45.100 / 58. 45.100
  libavdevice    58. 10.100 / 58. 10.100
  libavfilter     7. 85.100 /  7. 85.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  7.100 /  5.  7.100
  libswresample   3.  7.100 /  3.  7.100
  libpostproc    55.  7.100 / 55.  7.100
Input #0, matroska,webm, from 'in.webm':
  Metadata:
    encoder         : Chrome
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv), 2560x1416, SAR 1:1 DAR 320:177, 1k tbr, 1k tbn, 1k tbc (default)
    Metadata:
      alpha_mode      : 1

and

vlad$ ffprobe out.webm
ffprobe version 4.3.2 Copyright (c) 2007-2021 the FFmpeg developers
  built with Apple clang version 12.0.0 (clang-1200.0.32.29)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/4.3.2 --enable-shared --enable-pthreads --enable-version3 --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librtmp --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox
  libavutil      56. 51.100 / 56. 51.100
  libavcodec     58. 91.100 / 58. 91.100
  libavformat    58. 45.100 / 58. 45.100
  libavdevice    58. 10.100 / 58. 10.100
  libavfilter     7. 85.100 /  7. 85.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  7.100 /  5.  7.100
  libswresample   3.  7.100 /  3.  7.100
  libpostproc    55.  7.100 / 55.  7.100
Input #0, matroska,webm, from 'out.webm':
  Metadata:
    ENCODER         : Lavf58.45.100
  Duration: 00:00:17.82, start: 0.000000, bitrate: 405 kb/s
    Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv), 2560x1416, SAR 1:1 DAR 320:177, 1k tbr, 1k tbn, 1k tbc (default)
    Metadata:
      ALPHA_MODE      : 1
      ENCODER         : Lavc58.91.100 libvpx-vp9
      DURATION        : 00:00:17.815000000

Solution

  • I am fairly sure your FFmpeg processing isn't exactly what you think it is -- with your command line, particularly with absence of certain explicit switches, FFmpeg will transcode your video and audio at its own discretion, which is why your output file is much smaller -- the data have been re-compressed, with potentially loss of quality.

    If you just want to generate the index necessary for the kind of seeking most players do, and avoid the undesired transcoding, the following command line will suffice:

    ffmpeg -i <input-file> -codec copy <output-file>
    

    On a minor note, do take into account that without an additional explicit switch to instruct it otherwise, FFmpeg infers the output container format from the output file name extension. I assume both your input and output are WebM, so there isn't any issue in your case. But even if they weren't, re-muxing media into another format of container doesn't have to result in quality loss.

    As you can surmise from the command line above, just running FFmpeg without any explicit switch pertaining to "generation of frame time index", causes it to build the index anyway. It will do so with or without transcoding taking place.

    P.S. There are some players, like [the now abandoned] MPC-HC, which are able to seek at least some transport streams. I expect it to be able to seek your kind of WebM media. I don't know the exact details on how it actually does the seeking, but if I would guess I'd say it simply does a linear search from some appropriate location in the media (or the very beginning) for a frame matching the time of seek. Much like looking for a row in a database table which doesn't have an index to help with the search predicate.