ffmpeg fails if options --thumbnail and --mkv combined with "audio_only" quality

[15532th]

DEBUG: Executing command: ffmpeg -hide_banner -nostdin -loglevel fatal -stats -i 'video_title.f140.ts' -c copy -attach 'video_title.jpg' -metadata:s:t filename=cover_land.jpg -metadata:s:t mimetype=image/jpeg 'video_title.m4a'

execute returned code 1. Something must have gone wrong with ffmpeg.
The .ts files will not be deleted in case the final file is broken.

It seems -attach argument doesn't work with m4a. Running ffmpeg alone gives

[ipod @ 0x55d17e6f98a0] Could not find tag for codec none in stream #1, codec not currently supported in container
Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  File video_title.jpg -> Stream #0:1

It's not really a big deal, but it looks like a good chance to replace --mkv option with something more generic.

[Kethsar]

I technically already have this fixed in the golang rewrite, but I guess I can ask since you posted this. Is there any particular reason you'd want to force an audio-only download into an mkv container? The current logic in the rewrite is to turn the mkv flag off if audio-only is enabled. I can instead change it to allow audio-only in mkv as well, though it just seems semi-pointless to me.

[15532th]

I can think about some cases where one would want audio-only in video container, like uploading file to some sites that accept mp4 and not m4a, but these should be rare enough to leave it to user to run ffmpeg again against output file. My concern is that someone might want to add another option for, say, webm, and it will require bunch of cross-checks to make sure all options combinations work together. It might be easier to support just one option to specify desired output file format, even if it would only accept a fixed subset of containers.

As for possible reasons one might want to use webm, its lack of 264 support provides easy way distinguish vp9-encoded files by extension without checking file contents, and specifying --vp9 will produce file which might be either vp9 or av1 encoded.

[Kethsar]

webm does not support AAC audio last I checked, and youtube livestreams only have AAC audio, so that's a no go. As for sites accepting MP4 but not M4A, that's just poor coding, though I can't say I'm surprised they might exist. The container is the same, the extension is the only difference and is merely meant to denote the data it contains is audio only.

I'll change it to allow audio only mkv.

[Kethsar]

Fixed in bd3e153