Why is my transcoding quality so bad?

[karlshea 8]

Chiming in to say this issue affects me, too. Unbelievably bad transcode (huge pixelation during motion, lots of banding) over the local network to an Apple TV 4K, while the same file was crystal clear without transcode streaming to Kodi.

[Luke 37119]

10 minutes ago, karlshea said:

Chiming in to say this issue affects me, too. Unbelievably bad transcode (huge pixelation during motion, lots of banding) over the local network to an Apple TV 4K, while the same file was crystal clear without transcode streaming to Kodi.

Hi there, we're happy to help. Please see how to report a problem:

Thanks.

[karlshea 8]

Is it worth reporting as a problem? While transcoding it says 'container not supported' as the reason, so I'm guessing my issue is really the same as theirs and I sort of just have to wait for you to decide if/how you'll adjust what ffmpeg is doing?

[Happy2Play 8304]

Without logs all anyone can do is guess they maybe the same issue.

[softworkz 3341]

2 minutes ago, karlshea said:

Is it worth reporting as a problem?

Absolutely! Assumptions about having "the same issue" are incorrect in most cases. In your own issue, all focus will be on your own case. Unlike here..

[cubatilles 3]

Hi,

I'm in the same boat as @drapacioliis. I'm running Emby server on a Synology NAS (x86 Atom based CPU) which can't do hw accelerated encoding, and I mainly use transcoding to be able to watch my videos (anime mainly) correctly on my LAN network (animes are often encoded on x264-10bit, or have SSA styled subtitles, both things are problematic with most AndroidTV devices). Lots of anime require transcoding on my Google Chromecast and on my PhilipsTV (tried Emby client on both), and when that happens, I only want to preserve all possible wuality from the source and reduce buffering to the minimum. I don't care about bitrate in this scenario.

I've setup Transcoding options on server to CRF10 and superfast, so that my weak cpu can transcode at realtime maintaining all possible quality from the source, at the cost of high bitrate. But I end up with same results. Poor transcoded video quality and low bitrate.

It would be great if there was an option to prioritize both quality and speed instead of bitrate-saving.

Maybe it could be a good idea to support other alternative transcoding codecs for this approach. Maybe an older codec like MPEG2 could be more reliable for this approach (MPEG-2 at a higher bitrate could preserve more quality from the source while consuming less cpu resources on the process at the cost of lot of bandwith). I don't even know if there's any opensource mpeg2 codec, but I guess there are other options which could fit on what we want.

Btw, I've just recently downloaded the latest AndroidTV beta client from the Testing Area, and I'm happy to see all the improvements made to the SSA styled subtitles support which is getting better and better. Also lots of animes encoded to x264-10bit are now being directly played without transcoding. Thanks for that, it helps with the issue.

Now if we can have a transcoding option to prioritize quality and efficiency over bandwith, it will be a great.

Thanks for your work.

Greetings.

 

[softworkz 3341]

CRF10 doesn't look like a reasonable value to me.

Better quality requires more  CPU processing and higher bandwidth, which means that you need to use a different H264 preset. 
Older codecs like H.262 are less effective in terms of compression, but that doesn't necessarily mean that they require less computing power (they probably do, but the difference is less than you would expect). 

Further, very few clients support HLS streaming with MPEG2 codec. So to be honest: the situations where it would make any sense to encode to MPEG2 video are so extremely rare that it's not worth  to even consider this. (it would be a huge task anyway, and almost no hw accelerator supports that).

softworkz   

[drapacioli 6]

18 minutes ago, softworkz said:

CRF10 doesn't look like a reasonable value to me.

Better quality requires more  CPU processing and higher bandwidth, which means that you need to use a different H264 preset. 
 

Not necessarily. At any given quality, you can trade bandwidth for processing power and vice versa, to a point. In my case and I suspect cubatilles, we are asking for a way to remove the bandwidth limit of the original file bitrate during transcoding, so we can preserve the original quality level of our already precisely compressed video files (or at least get much closer than it is now). While it is true we could re-encode the videos at a higher quality or less efficient codec, doing so to the point where the quality is preserved during playback may require an excessive amount of storage, which isn't exactly practical or cheap. After all, bandwidth is much easier to manage than adding more spinning disks, particularly for larger libraries like mine. I'd essentially have to buy $1200 worth of drives and a nas expansion unit if I wanted to get around this limitation by re-encoding my library and roughly doubling my file sizes. That's just not practical...

Edited April 5, 2021 by drapacioli

[softworkz 3341]

I'm afraid, but I don't quite understand what you want...

[drapacioli 6]

2 minutes ago, softworkz said:

I'm afraid, but I don't quite understand what you want...

Emby artificially limits the max bitrate during transcoding, overriding any quality presets we're able to set. Frankly, I'd like a way for us to turn that off and let Emby ramp up the bitrate to preserve transcoding quality.

 

We spoke about it at length in December back on page 1.

Edited April 5, 2021 by drapacioli

[softworkz 3341]

9 minutes ago, drapacioli said:

Emby artificially limits the max bitrate during transcoding, overriding any quality presets we're able to set. Frankly, I'd like a way for us to turn that off and let Emby ramp up the bitrate to preserve transcoding quality.

 

We spoke about it at length in December back on page 1.

Sorry, I missed that context, I had just replied to the idea of encoding with MPEG2Video codec.

For the bandwidth limit that Emby is using for transcoding - I'm not familiar with the decision process.

Maybe @Luke can provide some insight.

[Luke 37119]

On 4/5/2021 at 1:17 PM, drapacioli said:

Emby artificially limits the max bitrate during transcoding, overriding any quality presets we're able to set. Frankly, I'd like a way for us to turn that off and let Emby ramp up the bitrate to preserve transcoding quality.

 

We spoke about it at length in December back on page 1.

It limits the transcoding bitrate to the bitrate of the source, although there are some cases where it is allowed to go a little higher.

[drapacioli 6]

1 minute ago, Luke said:

It limits the transcoding bitrate to the bitrate of the source, although there are some cases where it is allowed to go a little higher.

Yes, that's impractical for properly compressed files because a realtime transcoding job will always be less efficient and harder on the cpu the more the source is compressed. But compressing files saves on storage requirements which is necessary for larger libraries to keep costs down. A rock and a hard place, really. That's why I'd like that artificial limit within Emby removed. Bandwidth is much cheaper than storage.

[softworkz 3341]

2 hours ago, drapacioli said:

Yes, that's impractical for properly compressed files because a realtime transcoding job will always be less efficient and harder on the cpu the more the source is compressed. 

I agree to that part and that it can turn out to be a problem.

2 hours ago, drapacioli said:

That's why I'd like that artificial limit within Emby removed.

First, it's not an "artificial" limit. It's being determined by logic in the server.

Also, it's not as easy like a "removal". Encoders ideally need a bandwidth target to be specified for optimal operation and bandwidth is never really unlimited and in most streaming situations it must be controlled in order to provide a smooth streaming experience.

We could probably look into tweaking that logic a bit to allow bitrates somewhat higher than the original files, but a "removal" is not feasible. I could imagine that this "somewhat" factor could go up to maybe the double original bitrate, but we'd also need to think about it a bit more.

[drapacioli 6]

5 minutes ago, softworkz said:

First, it's not an "artificial" limit. It's being determined by logic in the server.

Also, it's not as easy like a "removal". Encoders ideally need a bandwidth target to be specified for optimal operation and bandwidth is never really unlimited and in most streaming situations it must be controlled in order to provide a smooth streaming experience.

I call it an artificial limit because the max bitrate isn't something the user can control, despite quality control setting seeing available. The CRF value in most encoding options is supposed to be used to set a quality standard as an alternative to a strict bit rate. In a regular CLI command or in a tool like handbrake, this means a lower CRF = a better quality encoding at the expense of bitrate. Thus, the encoder doesn't truly need a bandwidth target. If I want to saturate my gigabit connection and set crf to 5, I should be able to do so. Similarly, I could set it to something like 20-25 if I didn't care so much, and I'll get ok quality at a more reasonable bitrate.

 

For "normal" users who haven't a clue what they're doing, a bitrate cap would make sense and I understand why the server logic defaults to that, but the key is if you expose the crf to the user in advanced settings, it needs to work as expected. The fact that the server logic takes this predicable CRF quality standard and "caps" the bandwidth to the original file rate is counterintuitive and deceptive to the user who expects the CRF option to do exactly what it does in other applications.

 

You say you can't "remove" it easily. That may be true, but you can most likely expose it to the user and allow them to override the default amount with a global maximum instead without too much trouble? Unless the source code is a mess, which I guess it well could be.

[softworkz 3341]

19 minutes ago, drapacioli said:

You say you can't "remove" it easily. That may be true, but you can most likely expose it to the user and allow them to override the default amount with a global maximum instead without too much trouble? Unless the source code is a mess, which I guess it well could be.

The source code that you could see in a certain project that had forked off from Emby few years ago - that is what you could call like this, but we have evolved meanwhile and you'll hardly find any line of source code that hasn't changed since then. In fact it's all totally different now.  

I acknowledge that it's not quite right to have both CRF and target bandwidth setting. But the target bandwidth is the part that won't go away, more likely the CRF setting. 
Emby streaming always works in a way that a maximum bandwidth is either determined automatically or set by the user in the app. That's the most crucial part for providing a smooth streaming experience. 

When you say that you don't need to care about bandwidth at all, then you are part of a small minority. 
As I already said: this can be improved, but not in the way you are thinking.

[drapacioli 6]

Well I will say this - a field where you can select a percentage of the original bandwidth to apply during transcoding is also a possibility. If you do it though, please don't cap it. Please let us power users pick what we want and reap the benefits (or suffer the consequences) as we see fit.

 

In the meantime, I'm still using this manual workaround you posted a while back, every single time I watch something with subtitles....