Pixelated/Blurry/Discolored Playback on Roku when Transcoding

[Xalactic 6]

Saw the 4.8.10 update with the hardware transcoding fix note and thought it might address this, but I'm still having the same issue. This is happening on pretty much any transcoded movie I watch, but I'll mention again that it's really only during dark scenes.

I really hope this gets addressed at some point. Some of these bug reports do seem to grow stale... Please let me know if I can provide additional information or test anything.

[Luke 42078]

Hi, we are looking into this. Thanks.

[Xalactic 6]

This is still an issue... Running 4.9.1.7 beta at the moment.

[Xalactic 6]

Is this just being ignored, or what? Still very much a noticeable issue during darker scenes. Don't want to come across as rude but this is getting frustrating.

[Luke 42078]

@Xalacticapologies for the delay. Since you've updated to 4.9, can you please provide a log example from that? Thanks !

[Xalactic 6]

On 9/7/2025 at 1:13 AM, Luke said:

@Xalacticapologies for the delay. Since you've updated to 4.9, can you please provide a log example from that? Thanks !

https://www.dropbox.com/scl/fo/fqh921rtwz0gfkfdqdeaw/AN5BOATUAQ8GeZ4YLUGO0og?rlkey=01h72ol5i0njpihv1rjj22fqr&st=w98y0e52&dl=0

Running 4.9.1.27

[Xalactic 6]

@LukeDoes that give you what you need? Any ETA or detail on when this will be fixed?

[Luke 42078]

Hi, we are working on it. Thanks.

[Xalactic 6]

Checking in again. On the latest beta after seeing the Intel driver and subtitle related fixes. Still having this issue. Any specific details or ETA at all? It's been over a year since this was reported.

[Xalactic 6]

This is ridiculous. Is this just going to be ignored and not fixed? It's been over a year and I've provided logs twice. This is a consistent playback issue with paid software. I guess I'm somehow the only one having this issue but it feels like I'm getting the runaround here.

[Luke 42078]

HI, apologies for the delay. We are looking into this.

[Luke 42078]

Have you tried setting your hardware transcoding on the server to vaapi rather than qsv?

[Xalactic 6]

59 minutes ago, Luke said:

Have you tried setting your hardware transcoding on the server to vaapi rather than qsv?

 

On 9/3/2024 at 4:26 PM, Xalactic said:

Yes, same exact issue with only VAAPI enabled.

I have tried it since then as well.

[Luke 42078]

On 11/11/2025 at 5:00 PM, Xalactic said:

 

I have tried it since then as well.

Can we please see a log example of that? Thanks.

[Xalactic 6]

On 11/17/2025 at 5:19 PM, Luke said:

Can we please see a log example of that? Thanks.

Here. The issue is still very much apparent. https://www.dropbox.com/scl/fo/d6h5vz4vltzf880lb7l8d/AMpcss4lNeNIzn40M_R3iM4?rlkey=eg8z1o8u93oxv0q2imdurbg4y&st=efy5swyx&dl=0

[Luke 42078]

OK we are looking into it. Thanks.

[Xalactic 6]

On 11/30/2025 at 4:55 PM, Luke said:

OK we are looking into it. Thanks.

Still an issue. I don't know if I'm somehow the only one experiencing this or what but it's incredibly frustrating to keep hearing that it's being looked into and nothing else. It's been over a year and I've provided logs across multiple versions. Please fix it or just say that it's not going to be fixed because this is ridiculous.

[Gilgamesh_48 1240]

3 minutes ago, Xalactic said:

Still an issue. I don't know if I'm somehow the only one experiencing this or what but it's incredibly frustrating to keep hearing that it's being looked into and nothing else. It's been over a year and I've provided logs across multiple versions. Please fix it or just say that it's not going to be fixed because this is ridiculous.

FWIW: I use a fairly under powered server and I have never seen the issue you describe. If I were troubleshooting your set up I would look at things like:
Are you using your server for other duties? That is usually a bad idea.
Is your server wireless? That is always a bad idea.
Is there wireless interference affecting your client(s)? That can cause all sorts of unusual problems as communication between client and server is very important.

Are the involved files very large or have high bit rates or high frame rates?

The fact that nobody else is seeing this issue pretty much says that it is something local to your setup. 
The one thing I can think of is that your server is simply under powered for the task(s) you are using it for but that is up to you unless it has lots of other duties. If it does then that needs to be reduced a lot or the "other" duties need to be switched to a different computer.

[Xalactic 6]

3 minutes ago, Gilgamesh_48 said:

FWIW: I use a fairly under powered server and I have never seen the issue you describe. If I were troubleshooting your set up I would look at things like:
Are you using your server for other duties? That is usually a bad idea.
Is your server wireless? That is always a bad idea.
Is there wireless interference affecting your client(s)? That can cause all sorts of unusual problems as communication between client and server is very important.

Are the involved files very large or have high bit rates or high frame rates?

The fact that nobody else is seeing this issue pretty much says that it is something local to your setup. 
The one thing I can think of is that your server is simply under powered for the task(s) you are using it for but that is up to you unless it has lots of other duties. If it does then that needs to be reduced a lot or the "other" duties need to be switched to a different computer.

I am using the server for other applications but it has resources to spare. Everything in this scenario is hardwired. I've seen this issue across DVD, Bluray, and UHD rips. Again, only on Roku clients. I'm open to this being a localized issue but I don't know how that would be the case.

 

[speechles 2055]

57 minutes ago, Xalactic said:

I am using the server for other applications but it has resources to spare. Everything in this scenario is hardwired. I've seen this issue across DVD, Bluray, and UHD rips. Again, only on Roku clients. I'm open to this being a localized issue but I don't know how that would be the case.

 

•  
• 21:55:25.995 Stream #0:0 (h264_qsv) -> hwdownload:default (graph 0)
• 21:55:25.996 Stream #0:3 (pgssub) -> scale:default (graph 0)
• 21:55:25.996 hwupload:default (graph 0) -> Stream #0:0 (h264_qsv)
• 21:55:25.996 Stream #0:1 -> #0:1 (dts (dca) -> ac3 (native))

 

If you disable burning in the pgssub and instead used external srt that would make the video stream able to be copied and direct played. Since it isn't copying the video stream this means it will use HLS. The audio stream is DTS is not supported in HLS. But if you weren't using those graphical pgssub, either no subtitles or external srt, it would've been direct playing and it could've then direct played the DTS audio too. The entire container would've been used with no HLS used at all.

 

You notice it in your example when the entire scene changes. The initial keyframe looks blocky/muddy. Cannot be easily fixed without a huge initial delay in transcoding. The method Emby is using for HLS has a much faster start time. Then it sorts itself out. This isn't unique to the Roku. Rather the Roku makes it noticeable this is happening. Any device that cannot burn in pgssub subtitles and needs to burn them into the video would cause the same thing. The video would get transcoded and the DTS audio would need to be converted since DTS isn't supported with HLS.

 

Edited January 26 by speechles

[Xalactic 6]

11 hours ago, speechles said:

•  
• 21:55:25.995 Stream #0:0 (h264_qsv) -> hwdownload:default (graph 0)
• 21:55:25.996 Stream #0:3 (pgssub) -> scale:default (graph 0)
• 21:55:25.996 hwupload:default (graph 0) -> Stream #0:0 (h264_qsv)
• 21:55:25.996 Stream #0:1 -> #0:1 (dts (dca) -> ac3 (native))

 

If you disable burning in the pgssub and instead used external srt that would make the video stream able to be copied and direct played. Since it isn't copying the video stream this means it will use HLS. The audio stream is DTS is not supported in HLS. But if you weren't using those graphical pgssub, either no subtitles or external srt, it would've been direct playing and it could've then direct played the DTS audio too. The entire container would've been used with no HLS used at all.

 

You notice it in your example when the entire scene changes. The initial keyframe looks blocky/muddy. Cannot be easily fixed without a huge initial delay in transcoding. The method Emby is using for HLS has a much faster start time. Then it sorts itself out. This isn't unique to the Roku. Rather the Roku makes it noticeable this is happening. Any device that cannot burn in pgssub subtitles and needs to burn them into the video would cause the same thing. The video would get transcoded and the DTS audio would need to be converted since DTS isn't supported with HLS.

 

Sure, using SRT does indeed get around the issue. Manually lowering the bitrate while using PGSSUB also gets around the issue as found previously. I'd like to not have to set the bitrate when using PGSSUB. I try to use SRT for most things but sometimes the automatically downloaded set is out of sync and I'm not near my computer to go find a different version when the movie starts. Sometimes SRTs don't get downloaded automatically and I have to do it manually. Sometimes the PGSSUB formatting is just nicer than SRT on Roku.

Based on all the previous log requests and "looking into it" responses, it sounded like there was some acknowledgement of this being a bug. Is the official answer now just "Don't use PGSSUB"? I'll have to go strip them out of every file and/or set up some automation to rename the downloaded SRT files as default since there's no option to name them as such automatically.

[Xalactic 6]

This is the level of support I'd expect for free software but buying a license specifically to use hardware transcoding and getting the runaround for a year is insane. Don't even ask for logs and say you're "looking into it" if the final answer is just going to tell me not to use PGSSUB. I give up but this has been really frustrating.

[RanmaCanada 495]

13 minutes ago, Xalactic said:

This is the level of support I'd expect for free software but buying a license specifically to use hardware transcoding and getting the runaround for a year is insane. Don't even ask for logs and say you're "looking into it" if the final answer is just going to tell me not to use PGSSUB. I give up but this has been really frustrating.

You appear to be the only person who is experiencing this, which means it is limited to your hardware/software. You were also asked for ffpmeg logs back in 2024, which you did not provide. Luke also asked you for logs constantly, which you did provide. No one else has apparently reported your issues, so this "level of support" is to be expected as the dev team absolutely can not duplicate your problem. PGSSUBS are image based and Roku does not support them. From a user standpoint, if you demand to play pgssubs and your current hardware can't play them back properly, I would just replace the hardware with something that can and stop complaining, or stop using pgssubs altogether.

As a server admin myself, I ended up buying Android devices for several family members to shut them up for other playback reasons. Those that refused, got booted.

Edited 2 hours ago by RanmaCanada

[Xalactic 6]

36 minutes ago, RanmaCanada said:

You appear to be the only person who is experiencing this, which means it is limited to your hardware/software. You were also asked for ffpmeg logs back in 2024, which you did not provide. Luke also asked you for logs constantly, which you did provide. No one else has apparently reported your issues, so this "level of support" is to be expected as the dev team absolutely can not duplicate your problem. PGSSUBS are image based and Roku does not support them. From a user standpoint, if you demand to play pgssubs and your current hardware can't play them back properly, I would just replace the hardware with something that can and stop complaining, or stop using pgssubs altogether.

As a server admin myself, I ended up buying Android devices for several family members to shut them up for other playback reasons. Those that refused, got booted.

I provided logs every time when asked, i don't know what you're talking about there. There hasn't been a response stating that the issue can't be replicated, just that they're unsure what's causing it. Burning in the PGSSUBS on Roku is a feature that Emby offers and the whole point of this thread has been that it isn't working properly for me. I'm aware that I can buy other hardware or stop using PGSSUB but I actually wanted to see if the issue could be resolved. I'm glad that we consider bug reports to be "complaining"... If they can't figure out the problem, fine I guess. The frustrating part has been the process of request logs, I provide them, crickets for months until I bump the post, rinse and repeat.