Insufficent transcoding definition/bitrate choices

General Discussions
, ,
1

Hello,

The 4k “light” content become more and more popular. It offers a good compromise between storage space and quality on 4k screens (better than 1080p up-scaling).

Here is an example for a 4k “light” file medatada with a 3840x1608 definition and a h265 4Mbit/s bitrate :

Input #0, matroska,webm, from ‘filemkv’:
Duration: 02:13:37.42, start: 0.000000, bitrate: 3688 kb/s
Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x1608, SAR 1:1 DAR 160:67, 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)
Stream #0:1(fre): Audio: eac3, 48000 Hz, 5.1(side), fltp, 256 kb/s (default) (forced)
Stream #0:2(eng): Audio: eac3, 48000 Hz, 5.1(side), fltp, 768 kb/s

Because of 2k or SDR only screens, subtitles or codec incompatibilities, and network bandwidth limitation, on-the-fly transcoding may be required.
My last PMS handle 4k hardware transcoding to h264 with HDR tone mapping perfectly . :clap:
The “Automatically convert” sometimes doesn’t fit and manual transcoding is a precious workaround.

Unfortunately when 4k “light” media transcoding is required, some Plex players (e.g Samsung TV, LG TV) may offers a limited transcoding profiles. Like if profiles where filtered on lower bandwidth & definition.

The previous file on an recent 4K LG (and Samsung) TV shows:
tv

So, we got something like 4K High h265 HDR10 3.7Mbps → 720p Fast H264 3 Mbps → 4K screen upscalling.
Such transcoding chain produce ugly videos while a trancoding to 1080p Fast H264 8Mbps looks much better. Probably because limting the downscaling and h264 require about the twice bitstream than h265 to equivalent quality.

The web UI (and PMP) offers more choices and let us fix the h265->h264 bitrate adjustment by ourselves.

web

While the problem is not limited to 4k stream, but to h265 stream with low bitrate, my eyes are less bloodshot with transcoded 1080p “light” content.

I didn’t find in the TV XML profiles how to prevent TV from filtering the codec list for transcoding, like in the web UI.
How can we achieve that?

Regards,

2

Do you have a formal specification which can be referenced?

3

Unfortunately no, I didn’t find a formal specification of “4KLight”.

From a quick analysis of about 500 4KLight NFO files, they are all H265 encoded files with bitrate from 2661 to 9990 Mbit/s with a mean at 5379 Mbit/s ; file sizes from 1.31 to 10.6 GiB, with a mean at 4.44 GiB.

4

@ChuckPa Despites no formal definition of 4Klight, the root cause is H265 to H264 transcoding algorithm for several clients.
Do you know if the selection is done on the client or on the server? If the xml profiles could allow override this limitation?

A elegant solution would be to instruct PMS to known that H265 videos could be downgraded to H264 with a double bitrate.

The reference about the quality equivalence is from the Wikipedia HEVC article.

In comparison to AVC, HEVC offers from 25% to 50% better data compression at the same level of video quality…

5

@ChuckPa friendly ping before the topic to be closed automatically :slight_smile:

6

Let me first share – H.264 → H.265 (HEVC) compression, in practice, does not live up to the hype. Compressing H.264 → H.265, in practice, gives at best 25% in all cases I’ve tried. 50% was achieved only under very specific conditions and those conditions did not include the high-CGI content often found in today’s fims.

Categoric doubling the bitrate is not a solution.

Example:

  1. I have 80 Mbps HEVC content I rip from disc.
  2. I cannot share at 96 Mbps (80*1.2) rate. My limit is 42
  3. Regardless of the player’s capabilities, it will get transcoded down to the limit I set for remote streaming — 20 Mbps, bt709, H264.
  4. Hardware transcoding and hardware tonemapping have proven to do an excellent job in mapping BT2020 to BT709 in all videos I’ve watched.
  5. Whenever tone mapping, you are going to lose one axis, It’s unavoidable due to how the algorithm works. Finding that balance has always been subjective and problematic.
7

There is surely some exaggeration from the HEVC designers on the 50%.

Even if I hope that one day the default selection algorithm will be improved, today the problem is that we can’t choose manually what we want (like in the web interface). So finding the balance manually cannot be done subjectively.

The example you provided is based on HEVC at high bitrates. If I can update the example with 4K light situation it would be :

  1. I have a 3.7 Mbps HEVC content
  2. There is no share limitation
  3. There is no remote streaming limitation
  4. Content is hardware transcoded to 3 Mbps 720p. Keeping the same bitrate with a 1080p would be better choice than this. It’s better to compress than upscale.
  5. TV player upscale it to 4k.
8

Knowing what the team is now working on,

I can pretty much guarantee that they will defer to upstream FFMPEG supporting first for the first part.

For the second part (the finer granularity of bit rates),

Would you be willing to propose a list of candidate rates knowing there are users streaming from 2 Mbps (indirect) to full gigabit upload rates? (keep wifi bitrates in consideration while planning A/B/G/N/AC/AX)

9

The bit rates proposed by the Web UI or the PMP are enough, I don’t think the first to do is do add more.

Here is the list :

The issue is this very list is not available on Samsung tv or LG tv (event with option “Disable bitrate limiting”).
As this transcoding profiles are already available on the web UI, I guess there is no requirement from FFMPEG upstream to remove the limitation from the device application or server device profile, no?

10

What do you think about using the existing list?