Media on Bastien Traverse

Parallel ffmpeg stream manipulation

Fri, 29 Oct 2021 00:00:00 +0200

This post will illustrate how we can apply different operations (audio transcoding, subtitles selection, video, chapters and fonts passthrough) on multistream MKVs with ffmpeg, while optimizing for multicore systems.

More precisely, here is what we are trying to achieve:

transcode the Japanese audio track from a entire anime season, from a superfluously lossless Flac to the more efficient Opus format¹
shed the useless (to me) English audio track (also in Flac, and 5.1…), as well as the unneeded “Signs-only” subtitle tracks
pass-through the video track
retain all attachments (fonts, chapters…)
preserve file modification times
replace the original files with the new ones
do all this as fast and efficiently as possible 😎

When starting, I knew how to accomplish this in two steps using two different tools:

Identify and remove the unwanted streams with mkvmerge^(source):

mkvmerge -i *.mkv
File '01.mkv': container: Matroska
Track ID 0: video (HEVC/H.265/MPEG-H)
Track ID 1: audio (Flac)
Track ID 2: audio (Flac)
Track ID 3: subtitles (SubStationAlpha)
Track ID 4: subtitles (SubStationAlpha)
Track ID 5: subtitles (HDMV PGS)
Track ID 6: subtitles (HDMV PGS)
Attachment ID 1: type 'application/vnd.ms-opentype', size 30712 bytes, file name 'font.ttf'
(...)

for f in *.mkv; do mkvmerge -o "remuxed/$f" --audio-tracks '!eng' --subtitle-tracks '!4,6' "$f"; done

Note

Here I was able to use !eng because the audio track was labeled as such, but we could achieve the same with numerical index (just as we are doing for subs).

Use ffmpeg to transcode the remaining audio track to Opus, using a generous 192 kbps (96k per audio channel) bitrate and then do the cleanup:
```
for f in remuxed/*.mkv; do ffmpeg -i "$f" -map 0 -c copy -c:a libopus -b:a 192k "tmp_$f"; touch -r "$f" "tmp_$f"; mv "tmp_$f" "$f"; done
```
Where -map 0 ports over all input streams, -c copy keeps them intact, and -c:a libopus -b:a 192k modulates this by transcoding all audio streams (in our case, the one we kept) to 192k Opus. Finally, touch -r updates our file modtime to reflect the original one, and mv overwrite the source with the modified file (warning: make sure to always test on a copy first, otherwise data loss will incur!).

From there it was rather easy to merge it all in one fell for loop:

for f in *.mkv; do \
    mkvmerge -o "tmp_$f" --audio-tracks '!eng' --subtitle-tracks '!4,6' "$f"; \
    ffmpeg -i "tmp_$f" -map 0 -c copy -c:a libopus -b:a 192k "tmp2_$f"; \
    touch -r "$f" "tmp2_$f"; \
    mv "tmp2_$f" "$f"; \
    rm "tmp_$f"; \
done

However, now the next step was to get rid of the superfluous mkvmerge and do it all with the Ever Almighty Multimedia Swiss-Army Knife®, ffmpeg. For that I had to dig quite a bit, but here is the result:

for f in *.mkv; do ffmpeg -i "$f" -map 0 -map -0:a:1 -map -0:s:1 -map -0:s:3 -c copy -c:a libopus -b:a 192k "tmp_$f"; touch -r "$f" "tmp_$f"; mv "tmp_$f" "$f"; done

As before we first select all streams via -map 0, then make use of negative mapping (notice the minus sign at the front of the subsequent -map values) to get rid of the unwanted tracks (second audio track, second and fourth sub tracks… Beware, this time we are using ffmpeg’s indexes/IDs which are relative to the category and 0-indexed). Then it is as before, we copy all remaining streams without changing them (-c copy) except audio ones which are transcoded to Opus.

Now this is all well and dandy, but this command runs sequentially, iterating over each file while queuing up the others, disregarding our multicore CPU architecture and thus slowing down the process. How can we run all this concurrently, dispatching a job to each CPU thread?

GNU Parallel² to the rescue!

parallel ffmpeg -i {} -map 0 -map -0:a:1 -map -0:s:1 -map -0:s:3 -c copy -c:a libopus -b:a 192k tmp_{}';' touch -r {} tmp_{}';' mv tmp_{} {} ::: *.mkv

Note

Of course, overall time will also depend on your storage read/write speeds…

Et voilà, that’s how you efficiently and stylishly reduce a bloated 10.9GB series to a lean and mean 4.8GB one. Great success! 👍👏🤗

See Why you should never use FLAC (for that use case that is) ↩︎
See this Unix SE answer for why Parallel is superior to Xargs in this matter. ↩︎

Anime recommendation: Showa Genroku Rakugo Shinju

Thu, 22 Apr 2021 00:00:00 +0200

MyAnimeList.net - AnimeNewsNetwork - IMDB - Wikipedia

This anime is an absolute masterpiece. The quality of the drawings, the ambiance, the story… They are all so delicate, so refined. It is one of those works which upgrades your perception of a whole genre.

Promotional video (in Japanese):

The trailer certainly does not capture the depth of the ambiance this anime will suck you into. It has quite litterally entranced me. Watching it made me feel more human. It made me laugh, it made me cry. It softened my heart.

Update 2022-10-08: I’ve just finished re-watching the anime, this time mustering the courage to go all the way through the last two final episodes; and if, like me – and apparently quite a few others – you are incredibly disturbed by the insinuation made about Konatsu’s first child’s father, I warmly suggest reading this excellent review which offers a credible rebuttal.

In any case and despite this one unexpected late speck, my opinion and all the reviews seem to concord: this anime really is a masterpiece 😊🙏

ffmpeg set sub as default

Fri, 01 May 2015 00:00:00 +0200

Copy of my answer to the question “Is there an option in ffmpeg to specify a subtitle track that should be shown by default?” on superuser:

No, there isn’t an option in ffmpeg to specify a subtitle track that should be shown by default.
(ffmpeg version 2.6.1 built with gcc 4.9.2 (GCC) 20150304 (prerelease) as default on Arch, see end of answer for compile flags)

Resources highlighting the lack of command line options for setting default/forced subtitles stream in ffmpeg include the following:

this Oct. 2012 mailing list thread (which delves in the matroska format and explains that ffmpeg doesn’t write in the required fields)

this Jan. 2013 thread (shows the lack of interest of ffmpeg devs for this)

this Jan. 2014 thread (asks about flipping the default flag in Matroska container, to no avail)

this very recent forum post (MP4, zeranoe ffmeg forums)

Finally, this question on StackOverflow asks the same as you but for mkv, and highlights the fact that ffmpeg is the culprit since mkvpropedit (part of mkvtoolnix) can do it.

However, there is a potential workaround
This March 2013 ffmpeg bug report (still open) deals with mkv and default flag for subtitles and explains something that we can use to circumvent this limitation in some scenarios:

The Matroska specification - http://matroska.org/technical/specs/index.html (search for FlagDefault) - specifies that the value for the default flag is “default” if nothing is specified, the demuxer therefore marks all subtitle tracks as “default”.

So ffmpeg may write the default flag on our subtitles stream in some cases; I tried it with different input video files and got mixed results:
with the Big Buck Bunny AVI Mpeg4 and a random .srt file, the remuxed mkv subtitles stream did have the default flag:
  $ ffmpeg -i big_buck_bunny_480p_surround-fix.avi -i subtitle.srt -c copy test.mkv
  $ ffmpeg -i test.mkv
  Input #0, matroska,webm, from 'test.mkv':
    Metadata:
      ENCODER         : Lavf56.25.101
    Duration: 00:28:31.40, start: 0.000000, bitrate: 1028 kb/s
      Stream #0:0: Video: mpeg4 (Simple Profile), yuv420p, 854x480 [SAR 1:1 DAR 427:240], 24 fps, 24 tbr, 1k tbn, 24 tbc (default)
      Stream #0:1: Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s (default)
      Stream #0:2: Subtitle: subrip (default)
however I couldn’t reproduce this with a sample mp4-contained H264 sample neither with a personal mp4, so I guess mp4 --> mkv doesn’t work. But what if…?
  $ ffmpeg -i sample.mp4 -c copy sample.avi
  $ ffmpeg -i sample.avi -i subtitle.srt -c copy sample.mkv
  $ ffmpeg -i sample.mkv
  ...
Input #0, matroska,webm, from 'sample.mkv':
  Metadata:
	ENCODER         : Lavf56.25.101
  Duration: 00:28:31.40, start: 0.000000, bitrate: 2 kb/s
	Stream #0:0: Video: h264 (Constrained Baseline), yuv420p(tv, bt709), 560x320, SAR 1:1 DAR 7:4, 60 fps, 60 tbr, 1k tbn, 60 tbc (default)
	Stream #0:1: Audio: aac (LC), 48000 Hz, mono, fltp (default)
	Stream #0:2: Subtitle: subrip (default)
VICTORY! Doing mp4 --> avi and then avi + srt --> mkv gets the subtitles stream on by default and VLC displays them correctly.

Sure that’s very roundabout and I’d rather not think of the information loss in the process, but at least it works.

Summary

ffmpeg is definitely not adapted right now for setting streams as default or forced,

mkv is probably better than mp4 as an origin container, since it has a known tool doing the job fine (mkvpropedit from mkvtoolnix).

ffmpeg version details:
ffmpeg version 2.6.1 built with gcc 4.9.2 (GCC) 20150304 (prerelease) configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-avisynth --enable-avresample --enable-fontconfig --enable-gnutls --enable-gpl --enable-libass --enable-libbluray --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxvid --enable-runtime-cpudetect --enable-shared --enable-swresample --enable-vdpau --enable-version3 --enable-x11grab