Recent DTV encoding features

[jasongdove]

You may not want these changes as-is bf3b076

For the stillimage tune, I think it would make more sense to explicitly enable for only those encoders known to support it. The upside of the tune as written is that it optimizes the (brief) loading screen, while the downside is that the stream won't start at all if the encoder doesn't support that specific tune. Also, there is some duplication:

tunarr/server/src/ffmpeg.ts

Lines 424 to 430 in bf3b076

	// this tune apparently makes the video compress better
	// when it is the same image
	// Don't enable this for NVENC...it seems to break with a strange
	// error. Unclear if this affects other HW encoders
	if (!this.opts.videoEncoder.includes('nvenc')) {
	stillImage = true;
	}

tunarr/server/src/ffmpeg.ts

Lines 671 to 673 in bf3b076

	if (stillImage && this.opts.videoEncoder.toLowerCase().includes('nv')) {
	ffmpegArgs.push('-tune', 'stillimage');
	}

For the "mpeg2video fix" which replaced -b:v (target video bitrate) with -crf (constant quality mode) for all encoders except mpeg2video - it's kind of a similar story since many encoders don't support -crf, though at least they seem to ignore it rather than failing altogether. This introduced a massive quality loss for everything except mpeg2video and maybe libx264.

My guess is that DTV testing may be limited to mpeg2video and libx264, in which case these recent changes wouldn't really affect anything, or might actually improve things, but for anyone using hardware encoding they have not been well received.

[chrisbenincasa]

Thanks for pointing this out. I'm still learning the ins and outs of the encoding stuff specifically, so this is very helpful. I think tackling the ffmpeg.ts file will be one of my next efforts; it's quite messy and hard to follow. I will definitely take your advice on withholding the mpeg2video change as well.

[jasongdove]

Cool. I think the difference between -tune stillimage and -crf whatever is that -tune is a valid option for many encoders, but stillimage is often an invalid value:

[h264_nvenc @ 0x5e3f4563f640] [Eval @ 0x7ffe8c97bb00] Undefined constant or missing '(' in 'stillimage'
[h264_nvenc @ 0x5e3f4563f640] Unable to parse option value "stillimage"
[h264_nvenc @ 0x5e3f4563f640] Error setting option tune to value stillimage.

Whereas with -crf the unsupported option is simply ignored.

[out#0/null @ 0x5c1483d5ab80] Codec AVOption crf (Select the quality for constant quality mode) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream.

[chrisbenincasa]

Yeah, before I saw the DTV change I had run into the stillimage issue on my own instance when running with nvenc. I changed this over in fc67cf1. Verified those 3 encoders work as expected with stillimage. Also reverted the crf change in 8acbc7f

[chrisbenincasa]

Hmmm interestingly for the offline player + stillimage I'm seeing that same warning you posted about crf:

@tunarr/server:dev: [out#0/mpegts @ 0x7fab9da05f40] Codec AVOption tune (The metric that the encoder tunes for. Automatically chosen by the encoder by default) has not been used for any stream. The most likely reason is either wrong type
(e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream.

[jasongdove]

That case looks like an encoder that doesn't understand the tune option, thus the warning, vs the invalid tune value which might totally fail. Which encoder are you using?

[jasongdove]

Must be mpeg2video - I guess that one doesn't need the tune.

ffmpeg -hide_banner -h encoder=mpeg2video | grep tune

[chrisbenincasa]

Yep it was mpeg2video, I missed the warning the first time around when testing. I'll remove it from the new allowlist array I just added