Just like the first two times, I’m assembling my Watkins Glen 2017 track footage with ffmpeg.

However, I encountered a small issue I didn’t last year, plus I decided to change things up a bit with codecs, and audio selection.

ffmpeg requires protocol whitelist now

I’m using pretty much the same concatenation command as last year (filenames are a bit different):

$ for f in Front-*MOV; do echo file "$f"; done | ffmpeg -f concat -i - -c copy Front.MOV

The error I got from ffmpeg looked like:

[file @ 0x55d7ded86680] Protocol not on whitelist 'crypto'!
[concat @ 0x55d7ded7cc80] Impossible to open 'Front-AMBA0009.MOV'
file:: Invalid argument

I used my google-fu and found a helpful blog that pointed me at the cause. This is actually a pretty decent security feature, and should prevent ffmpeg from reaching out to the world without your knowledge. However, it appears the default behaviour (at least from rpmfusion) differs from the man page:

protocol_whitelist list (input)
    Set a ","-separated list of allowed protocols. "ALL" matches all
    protocols. Protocols prefixed by "-" are disabled.  All protocols
    are allowed by default but protocols used by an another protocol
    (nested protocols) are restricted to a per protocol subset.

Unless file was disallowed becayse it was used via pipe. Anyway, solution was simple enough: Whitelist ‘file’, and ‘pipe’ (we’re piping in the file list).

$ for f in Front-*MOV; do echo file "$f"; done | ffmpeg -protocol_whitelist file,pipe -f concat -i - -c copy Front.MOV

Helpful options to make youtube processing faster

Uploading to youtube is always a lengthy process, as youtube needs to reprocess the video. They have documented the ideal format characteristics. And I found a blog post describing the ideal youtube paramters in ffmpeg terms, so I didn’t have to read the man page again. Yay.

The concatenated videos (above) are just using the ‘copy’ codecs, so I’ll leave them as-is. Only when combining the front & rear video will I apply the new settings:

$ time ffmpeg -i Front.trim.MOV -filter:v "movie=Rear.trim.MOV, scale=480:-1 [inner]; [in][inner] overlay=1370:740 [out]" -codec:v libx264 -crf 21 -bf 2 -flags +cgop -pix_fmt yuv420p -codec:a aac -strict -2 -b:a 384k -r:a 48000 -movflags faststart Combined-FrontAudio.mp4

Also, you might want to do this on a powerful computer. My laptop heat throttled and was converting at 8fps. Copied the video to my server, and got 45fps. (I also had a load average of 22!!!). Your mileage will vary depending on your CPU:

Note that hardware encoding is not an option here due to the video overlay filter.

Audio from rear camera seems better

While comparing the Front & Rear audio clips, it appeared that the audio from the rear camera might be a bit better. It picked up our talking a little bit less, and picked up the (rear/mid) engine noise a little bit better. Also, the front camera had an intermittant click/hiss/whine in some videos. I haven’t figured that out yet.

I wanted to do a side-by-side comparison of front & rear audio, so I needed both output files. Additionally, since the bulk of the conversion time was video, and that isnt’ changing, I can just swap out the audio on the video from above.

We’ll use -map to grab the first input video (0:v), and the second input audio (1:a):

$ time ffmpeg -i Combined-FrontAudio.mp4 -i Rear.trim.MOV -map 0:v -map 1:a -codec:v copy -codec:a aac -strict -2 -b:a 384k -r:a 48000 -movflags faststart Combined-RearAudio.mp4

Note that I re-applied the youtube audio codec wizardry.

Watch the video

You can watch the three videos of the Watkins Glen 2017 trip on youtube