Unable to remote stream because of audio issues

Hmm okay, what versions exactly?

There have been some other transcoder changes very recently, and there's a new build from yesterday which may fix any issues in the previous test build.

Also which encoder are you using?

The beta version that had the macroblocking was 2019.03.20.1953. The version I reverted to was 2019.03.12.0544. This was using the hardware encoder h264_vaapi. Maybe I'll give a newer beta a try ...

Thanks for all your effort.

1 Like

Thanks that's helpful. The bad build had a change to how often keyframes are generated, and could explain the macroblocking.

Things should be better in 2019.03.23.0112 but let me know if they are not. I would be curious if it affects software transcoding too or specific to vaapi

The macroblocking is improved with Saturday's build versus Wednesday's, but it is still present a bit. It's nowhere near as bad as it was previously (the streams are now watchable), but it is still not as smooth as it was with the previous release build.

I checked with both hardware and software encoding, and the macroblocking was present in both. I haven't compared the ffmpeg options between builds to see what has changed, but there is something there. (Also, it's not specific to the encoder being used.)

Once again, thanks for all of the work and effort.

A post was merged into an existing topic: Wrong audio language (English forced)

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.)

1 Like

Yea, previously keyframes were every 0.2s for 60fps (or 0.4s for 30fps), and now we are forcing keyframes every second using a different option.

Do you mind if I ask what your new options are? I was about to test my wrapper with:

# systemctl stop channels-dvr
$ cd /usr/lib/channels-dvr/latest
$ mv ffmpeg ffmpeg-channels
$ cat > ffmpeg << EOF
#!/bin/sh
/usr/bin/channels-dvr/latest/ffmpeg-channels $(echo "$@" | sed -e 's/-g:v 0 //' -e 's/gt(floor(t),floor(prev_t))/gte(t,n_force*1)/')
EOF
# systemctl start channels-dvr

You've got it, but it's s/force/forced/

Thanks. I'll give it a try after my evening recordings finish tonight.

There must be something different about the way the external apps are exec'ed from Go, as wrapping the ffmpeg command seems to fail. (It works in manual testing, but when Channels calls ffmpeg, something else is going on.)

A brief look at the command line options used in the new 2019.03.25.1619 looked like it was using the same options as the previous beta (and therefore still exhibited macroblocking).

For the time being I guess I'll have to plan when I want to watch a program with a bad audio channel and manually switch it over to a beta. Otherwise, the other members from my household won't be happy with the quality loss just to enable me to watch my programs.

I guess you can grab the latest ffmpeg but run it in the last stable release. That will give you the audio fix but keep the old keyframe options.

Unfortunately I'm about to leave on an international trip for a couple weeks so I won't get a chance to investigate this further until I'm back.

I'm not sure I understand. The ffmpeg binary is modified with the audio fix? I thought you were doing something with ffprobe before starting transcoding.

How have you modified the ffmpeg binary?

I could have used ffprobe too, but I opted for a (hacky) ffmpeg patch. Here's a copy: https://gist.github.com/tmm1/b582a40269af75f1f7db61845e29ff58

Ah, that makes sense. I was thinking some detection was happening before the ffmpeg call. However, since ffmpeg is patched and my problem seems to be with the different options it's being called with, putting the newer ffmpeg into an older DVR build makes sense. Thanks for this!

1 Like

If I update to the latest beta and have issues, how do I get back to the latest stable build 2019.03.12.0544?

Long story shortened.

I was spending time testing the beta versions and wanted to try the latest but am about to give up and let others try.
Channels DVR on my Synology NAS appears to only keep the last three versions.
I no longer have the last stable version 2019.03.12.0544.
What I have is;
2019.03.15.1810
2019.03.23.0112
2019.03.24.2249.

You would need to do a reinstall and restore

I'm pushing out a new build which removes -g 0 for now, so things stay stable while I'm away on vacation.

I'm changing this to keep last six as well.

Thanks and enjoy your well deserved vacation.
Don't stream too much from your DVR while in Bali (or wherever vacation is), we want you well rested when you get back :grinning: