Solving playback issues

[ftballpack]

If your problem is isolated to Plex, I'd suggest checking your Roku profiles.

I thoroughly tested the issue to see what is happening. The problem exists on the Roku for 8-bit content in x265 format in MKV files specifically; however, because of issues with audio and AAC on the Roku, the problem will also occur using the default Plex profile for this Roku for 8-bit x265 content in an MP4 container that has AAC audio. The Plex server transcodes AAC audio to AC3 on the Roku, because direct-played AAC audio on the Roku plays backs substantially quieter than it should.

When the audio is transcoded from AAC to AC3 by the Plex Server, to work around the AAC audio being excessively quiet, the Roku reads the audio is coming from an MKV, which reintroduces the MKV problem, even though the video/audio file is in an MP4 container.

For MP4 files, modifying the profile to not transcode AAC to AC3 by default causes the audio issue on other Roku devices that can direct play 8-bit content in x265.

tl;dr, working around the MKV issues reintroduces AAC audio issues on all Rokus that are subject to that profile, including devices that properly play x265 8-bit content in an MKV.

The only solution that completely works around this issue is to convert all MKV x265 8-bit content, to MP4 x265, AC3 audio.

FYI, the Shield does not have Hulu 4K support (and only got 5.1 support a few weeks ago) - but Roku does, and has (both), for nearly 2 years now.

That assumes that prioritizing Hulu makes a device, "better" for "internet streaming." If a person could care less about Hulu but wants all of their YouTube content in 4k, whether YouTube has it in 4k or not, then the rival product would be "better."

I'm making the point that saying something is "better" by better supporting one streaming provider over another is entirely subjective. That all being said, it would be nice if products support the formats and containers it warranties on the box that it does.

[StreamerUser]

---

@ftballpack wrote:

That assumes that prioritizing Hulu makes a device, "better" for "internet streaming." If a person could care less about Hulu but wants all of their YouTube content in 4k, whether YouTube has it in 4k or not, then the rival product would be "better."

I'm making the point that saying something is "better" by better supporting one streaming provider over another is entirely subjective. That all being said, it would be nice if products support the formats and containers it warranties on the box that it does.

---

I'll take that as a concession that your original statement "one device has AI upscaling built into it and plays 4k from every streaming provider that has 4k content" is, in fact, false/wrong/incorrect.

Hulu is a major internet streaming service and has 4K content - the Shield doesnt support it.  

YT/YTTV are also major internet streaming services - and the Shields cannot output any HDR (HDR10 or HLG) from either app (it doesnt even have HLG support at all).  

If you want to watch 4K HDR (HDR10 or HLG) content on YT/YTTV, you can do it on Roku, you cant do it on Shield.

It also lacks 5.1 output on Peacock TV - Roku has it. Etc.

Some of this can be fixed/addressed with app updates/provisioning support, some of it cant.

The Shield is an inferior internet streamer relative to Roku, due in part both to hardware design and app support (for both platforms).

The Shield is a superior local streamer relative to Roku, due in part both to hardware design and app support (for both platforms).

Yes, extensive detailed documentation of specific supported standards/formats/protocols for the entire streaming industry is subpar to say the least, even more so when specific support changes with different firmware/OS/app versions/builds.

Yes, "better" is subjective, but specifically relative to actual platform/app capabilities and usage patterns, which is the underlying reality of needing a multiplatform streaming strategy in order to maximize playback quality - you use the platform that has the best app quality/functionality/availability at playback time.

[ftballpack]

In any event, this thread has gone significantly off-topic.

To sum up my last post, I spent days isolating the issue. If Roku would fix the problem with 8-bit x265 in an MKV container. Everything else would fall into place and work perfectly. But they don't so this issue continues.

I have written about all of this in my prior posts, in this thread, isolating the cause of the issues.

[kawasakikr1]

I've just sent back my Ultra 4800, and will now buy something "better" for me.

I have 3 other Roku devices that all play the same files flawlessly, 2 of them do use transcoding for x265 files, but the 3rd - a premiere plus 4630 - plays them back directly without any colour issues.

The experience with the Ultra 4800 probably means I would never buy another Roku device.

[robross0606]

I can fully confirm. I have four Roku Ultra clients on a Plex server connected to a variety of displays. Everything from a 1080P (SDR) projector all the way up to a 4K HDR OLED. All four are exhibiting this issue with any of my HEVC content. Colors are completely crushed and saturated beyond recognition with latest Plex server, latest Roku firmware and latest Plex client. I cannot believe they Roku and/or Plex haven’t fixed this problem in all these months. Clearly it isn’t a hard problem to reproduce or document. This is shameful.

[CJLDAD]

This is such an interesting thread and I'm glad I found it..  

I found out that if I stripped all info from the MKV Header using MKVToolNIX for the following properties it would play with the correct color space..

Colour Matrix Coefficients
Colour Range
Transfer Characteristics
Colour Primaries

They were all set to 1 which should tell it BT.709..  But it was still trying to do BT.2020

Once they were removed from the header, the videos worked just fine..  
They were played off of a USB drive, so can't say that Plex/Emby/etc. is the problem..  

[ftballpack]

I can tell you for a fact that it does not matter if you use Plex/Emby/Jellyfin/or a USB drive. The 4800x Roku is forcing the BT.2020 profile to all content in an HEVC container. I tested this back in April, the same exact video/audio, changing to an MP4 container from MKV, using FFmpeg, plays without issue. The problem entirely lies with how the 4800x Roku handles HEVC content in the MKV container and Roku refusing to even look at the issue.

In April I even made another ticket with Roku and linked example cat video files of the issue that my wife shot and gave me for this specific purpose, meaning the example files can be freely shared.

https://community.roku.com/t5/Channel-Issues-Questions/Severe-color-contrast-distortion-while-Plex-s...

This whole situation is comical. A known issue and the known cause has been reported to Roku several times, including by the Plex Devs yet nothing is ever done about it.

https://forums.plex.tv/t/roku-ultra-2020-aka-4800x-direct-play-colors-distorted-when-playing-back-he...

It's almost like Roku is trying to drive customers away from its products.

[CJLDAD]

Yup, I agree and I can tell you for a fact that if you remove the above contents from the mkv header, it will work as well.. Is that the ultimate resolution, no... But it makes the 4800's play HEVC files without issue... 

[ftballpack]

I know what you mean, I can modify all of my MKV files to create non-standard MKV files to work around this comically broken Roku, which will likely create all sorts of other issues on clients that follow the proper MKV standard.

But even if I did that, I would still have to convert all of my AAC audio to AC3 as Roku has known issues with multichannel AAC audio that Plex works around by transcoding the AAC audio to AC3 for the Roku, remuxing a new file in an MKV container. 

So I would have to modify the audio of all of my multichannel AAC audio files and break the MKV standard to get HEVC to work correctly. Or Roku could fix this issue for everyone by releasing a proper firmware fix.

[CJLDAD]

The weird part of it is, I didn't notice any of this issue till I started using Handbrake to convert..  I wanted better control over my Color Space/Subs..  I had used ffmpeg before and it did not flag the items in the header when it compressed/converted so I didn't notice it..  Hadn't noticed any issues with AAC  but I do my "compressed for streaming" files with AC3 for ultimate compatibility. 

Seems like this should be an easy fix for Roku to implement..  

Bummer for sure...