Green Pixelation?

[Luke 42077]

On 12/20/2020 at 6:17 PM, roxerroneous said:

Hey Luke, I’m experiencing the same (or similar) issue.  It sounds like the HEVC issue that was suggested earlier.  Have there been any updates on the issue?  I can supply logs if it helps but it sounds like you’ve isolate the problem.

Hi, yes please, that would be helpful. Thanks.

[sooty234 266]

The app should be changed to decode audio, like the Android TV app is being changed.

ALL apps should do this. Using the server to transcode audio is ridiculous.

[speechles 2055]

12 hours ago, sooty234 said:

The app should be changed to decode audio, like the Android TV app is being changed.

ALL apps should do this. Using the server to transcode audio is ridiculous.

 

Interesting. If only that were possible. The Roku offers a single method at this point. There is no way do this on the Roku using either SDKA or RSGA.

https://developer.roku.com/docs/references/scenegraph/media-playback-nodes/video.md
( The Roku uses completely unique components unlike any other platform which speeds up some development and slows us down in other areas )

Using RSGA (shown in the link above) there is no way to decode any streams or encode any streams. You get a minor look at inside what the streams are. But beyond that this is all in Roku control. We are sandboxed. There is no way to interact outside of the interfaces RSGA (XML/Brightscript). You cannot break out of the sandbox you are in that is a violation and you risk your developer credentials and being banned from Roku forever.

We are doing the best we can on Roku. Believe me. There is a little more we can do as far as Live TV and in that respect. But for the rest we are already doing the best we can. Please understand. Merry Christmas and Happy New Year!

 

Side-Note: It is possible to do this on the Roku using the NDKA framework (which Netflix and Youtube use) but access to that costs at minimum $100,000 USD. Yes, you read that right. The more users of your application the higher that fee goes. This is why not many participate in that arena. Big boys with deep pockets only.

Edited December 25, 2020 by speechles

[vdatanet 1617]

Another solution to avoid this bug if you can't decode DTS on the device, is to use fMP4 fragmentation instead of MPEGTS, It has been discussed in other threads and it has been concluded that it is not easy to implement. But we need a solution, it is not always possible to decode DTS on the client.

[roxerroneous 3]

20 hours ago, Luke said:

Hi, yes please, that would be helpful. Thanks.

Hey Luke, I just send it at 6:44 pm.  The local user is Brad and I was playing Infinity War.  Trying to play the 4K version with TrueHD 7.1 audio. If I switch to 5.1 it plays fine which is why it sounds like the HVEC issue.  

[sooty234 266]

4 hours ago, speechles said:

 

Interesting. If only that were possible. The Roku offers a single method at this point. There is no way do this on the Roku using either SDKA or RSGA.

https://developer.roku.com/docs/references/scenegraph/media-playback-nodes/video.md
( The Roku uses completely unique components unlike any other platform which speeds up some development and slows us down in other areas )

Using RSGA (shown in the link above) there is no way to decode any streams or encode any streams. You get a minor look at inside what the streams are. But beyond that this is all in Roku control. We are sandboxed. There is no way to interact outside of the interfaces RSGA (XML/Brightscript). You cannot break out of the sandbox you are in that is a violation and you risk your developer credentials and being banned from Roku forever.

We are doing the best we can on Roku. Believe me. There is a little more we can do as far as Live TV and in that respect. But for the rest we are already doing the best we can. Please understand. Merry Christmas and Happy New Year!

 

Side-Note: It is possible to do this on the Roku using the NDKA framework (which Netflix and Youtube use) but access to that costs at minimum $100,000 USD. Yes, you read that right. The more users of your application the higher that fee goes. This is why not many participate in that arena. Big boys with deep pockets only.

Ah, I see. That's a pity. Well, Roku just jumped to the top of the list of tech I will never buy.

Oh, I forgot. Crapple has that title.

Edited December 26, 2020 by sooty234

[ebr 16169]

16 hours ago, roxerroneous said:

Hey Luke, I just send it at 6:44 pm.  The local user is Brad and I was playing Infinity War.  Trying to play the 4K version with TrueHD 7.1 audio. If I switch to 5.1 it plays fine which is why it sounds like the HVEC issue.  

Hi.  Please post the server and ffmpeg logs from that session.  Thanks.

[roxerroneous 3]

52 minutes ago, ebr said:

Hi.  Please post the server and ffmpeg logs from that session.  Thanks.

Hey ebr, sere are all of the logs from around that time.

ffmpeg-remux-aec77b32-e0df-44e4-9aef-3b9f8a937f7c_1.txt ffmpeg-remux-234c510b-6801-4d15-9c1a-e62cac975f8b_1.txt ffmpeg-remux-0f1e489a-4c6b-4363-a83c-38da837d848d_1.txt

[vdatanet 1617]

1 minute ago, roxerroneous said:

Hey ebr, sere are all of the logs from around that time.

ffmpeg-remux-aec77b32-e0df-44e4-9aef-3b9f8a937f7c_1.txt 23.49 kB · 0 downloads ffmpeg-remux-234c510b-6801-4d15-9c1a-e62cac975f8b_1.txt 29.25 kB · 0 downloads ffmpeg-remux-0f1e489a-4c6b-4363-a83c-38da837d848d_1.txt 26.4 kB · 0 downloads

an old known bug:

18:41:26.907 Stream mapping:
18:41:26.907   Stream #0:0 -> #0:0 (copy)
18:41:26.907   Stream #0:1 -> #0:1 (truehd (native) -> ac3 (native))

 

[ebr 16169]

Yep it is the stream copy.  Playback Correction should fix it.

[sooty234 266]

4 hours ago, ebr said:

Yep it is the stream copy.  Playback Correction should fix it.

How so? By forcing a transcode? It looks like it's HDR... So that will make it worse.

[sooty234 266]

You guys realize that your system is pretty broken, right? I mean... it simply doesn't work... You aren't addressing HDR issues, at all!