So I checked the ffmpeg
command arguments used between 2019.03.12.0544 (latest stable), 2019.03.20.1953 (first fix for corrupted audio streams) and 2019.03.23.0112 (latest beta) to see if I could pinpoint the differences. Here are my conclusions (which aren't scientific in the least):
The macroblocking seems to be introduced when changing the default GOP (option -g 0
). Default is 12
, but modifying it seems to introduce the macroblocking. The change between to two betas looks to be primarily about changing the key-frames (in addition to timestamp changes, but I don't think that's relevant for this part). The heavily macroblocked first beta introduced the GOP changes while keeping the key-frame expression from latest stable; while the latest beta seems to modify the key-frame expression, which improves the macroblocking.
My next experiment will be to see if I can change the ffmpeg
command that the DVR is calling to use the default GOP and key-frames from the stable build, while using the other modifications from the beta tests. Perhaps something like:
#!/bin/sh
#ffmpeg
OPTS=$(sed 's/-g 0//' "$@")
./ffmpeg-channels $OPTS
Essentially it's just a shell wrapper to make changes to the command options that Channels passes to ffmpeg, and then pass those changes on to the bundled version of ffmpeg. I'll give that new test a run later tonight. (I have to plan these tests out because I don't want to interfere with the recording of scheduled shows as I haven't set up a test server to experiment with.)