Roku Beta app - Cant play 4k properly

[vaise 304]

ok - updated to 3.4.0.1.

Server restarted for clean logs

Disabled the three media conversion options for my user.

Using emby roku beta only

Played Paddington 2 - played fine, no green fuzz at start, FF a bit and also played fine.

Played Star Wars - A very big file (media info attached to this thread before) - all green screen, but can hear the sound

 

Logs attached.  No transcode logs at all.  I assume correct as I told it not to allow.

 

Paddington is not recognized as a direct play and transcodes (above logs show that in previous posts).

 

 

embyserver.txt

embyserver-63660959460.txt

embyserver-63660959456.txt

[Luke 37056]

Ok, we'll see what @@ebr thinks. Thanks.

[vaise 304]

And so you have something to compare with.

 

I allowed my user to transcode again.

Played paddington, and got the green at the start then green lines throughout it.

Logs for that attached.

 

At the very least, you should be able to use that to figure out why the roku wants to transcode that file when it can play it direct perfectly.

 

I can then test with other files.

embyserver.txt

ffmpeg-remux-dbdfca92-1bac-40ce-81f0-34f112db4dfa.txt

[ebr 14910]

I am at a loss because we are stream copying the video in the instance where you say it doesn't play properly...

[ebr 14910]

And so you have something to compare with.

 

I allowed my user to transcode again.

Played paddington, and got the green at the start then green lines throughout it.

Logs for that attached.

 

At the very least, you should be able to use that to figure out why the roku wants to transcode that file when it can play it direct perfectly.

 

I can then test with other files.

 

This remuxed because you had a TrueHD audio track selected.

 

What happens if you select the plain DD track instead?

[vaise 304]

Remember that BNN plays this fine so whatever they are doing I would think Emby Roku beta should do the same whent he same file is played without any messing..

[vaise 304]

So, once I figured out how to change the audio source (the little icon at the bottom), then emby roku does play this fine.

 

For kicks, I went to BNN, and made sure it was set on the dolby atmos audio, and it still plays fine there too.

 

Now I know about the audio bit, I can adjust that accordingly but seeing as the roku can play these natively, emby roku should too.

 

I am going back to my TV direct attached HD method for now, as no transcoding etc required.

[Luke 37056]

What could be done to ensure that you would have discovered it the first time around?

[vaise 304]

What could be done to ensure that you would have discovered it the first time around?

 

If you mean the audio track, I have never looked for it as I have never needed to - if something does not play in emby, we try BNN force transcode.

 

I have never changed an audio track to date - I imagine 4K stuff has more options.

 

In this specific 4k playback issue for this thread however, it is an emby Roku beta vs BNN thing, emby cant do it unless you change the audio track, BNN can do it regardless of the audio track.

[Luke 37056]

There's no way bnn can play the truehd track if the Roku does not support it.

[vaise 304]

to clarify, this is AFTER transcoding is back on for my user - so they can transcode it (tried with both audio trancks), Roku Emby cannot play without green fuzz on that audio track.

[ebr 14910]

There's no way bnn can play the truehd track if the Roku does not support it.

 

Yeah, I imagine that app is just disallowing the selection of that track.

[Erik 120]

Could the emby roku app check the available audio formats in the file and if none have been chosen by the user manually. Just play the track that would direct play (if the roku API allows you to see whats actually available) vs just transcoding the default track (usually the TrueHD/etc).

[vaise 304]

Is this what nbn does?

Are you able to detect what roku it is and choose the correct one that the roku device can play?

[ebr 14910]

Could the emby roku app check the available audio formats in the file and if none have been chosen by the user manually. Just play the track that would direct play (if the roku API allows you to see whats actually available) vs just transcoding the default track (usually the TrueHD/etc).

 

In many situations that would get you director's commentary all the time.

 

Since we don't know the content of the audio, we can't make assumptions like that.

[Erik 120]

Ha, fair enough. Didn't think of that one!

[vaise 304]

How does bnn do it?

Theirs plays but emby beta does not.

Do they only select the dd track if it’s there, regardless?

I tried to select both tracks on bnn and it played.

[speechles 1917]

How does bnn do it?

Theirs plays but emby beta does not.

Do they only select the dd track if it’s there, regardless?

I tried to select both tracks on bnn and it played.

 

An interesting question..

 

The answer depends on your play method. 

 

If direct play happens, then you can use the standard roku * button to change things during playback.

 

 

Simply navigate to audio track, and choose the track you wish. The issue might now be, that the item produces no sound. The blue neon app will NOT switch between direct play to transcoding to make an audio track will work for your system. Some unsupported audio tracks with direct play will produce silence. This is just how these things go. If you choose TrueHD in that menu above likely you will hear the sound of silence.

 

If you use the pre-play audio & subtitles menu you can choose your audio track you wish. The app will direct stream when you do this, as it is assuming you are wanting to over ride the default behavior that occurs during direct play and its limitations. If you use the pre-play menu it will either fully transcode or directstream. It will never choose to play directly from the container. This causes problems with some containers mp4 vs mkv and the m3u8 playlist alleviates the issue.

 

I suspect the emby app needs to do the same, and when a user chooses to switch audio tracks, force a container swap remux, and if possible preserve both the video and audio streams.

 

 

This is what blue neon is doing.  It was done this way because different roku models handle these things differently so remux when changing audio streams is always done to keep things from breaking. It barely impacts the CPU any differently to remux the streams into the hls container/m3u8 playlist vs directly playing the container.

Edited May 6, 2018 by speechles

[vaise 304]

Thanks speechless.

Way to complicated for me.

All I can say is this video bnn can play fine just by default playback (trueDD the audio format says), but emby does not.

I can change audio track to dd, and emby then plays, but really emby should do whatever bnn does and just play it somehow without fiddling.

[speechles 1917]

Thanks speechless.

Way to complicated for me.

All I can say is this video bnn can play fine just by default playback (trueDD the audio format says), but emby does not.

I can change audio track to dd, and emby then plays, but really emby should do whatever bnn does and just play it somehow without fiddling.

 

The blue neon app will default to AAC as its transcode codec, not mp3. Although if you want to use mp3, it supports that too.... lol.. You shouldn't unless you only want 2 channel stereo, but its there for those who want that choice.

 

If you change the "force surround" option to YES this will force AC3 whenever transcoding/remuxing is done.

 

If you only change the default audio codec option to AC3 this means you only want dolby if the audio codec isn't supported by the system. In this way, AAC can still direct stream as can MP3. With force surround set to YES as well, this will always result in an ac3 streams when transcoding and the default codec is over-ridden.

 

Might this be the difference? I am not sure what codec emby app defaults to when it finds an unsupported codec like trueHD. it might just turn it into AAC 2 channel. In the blue neon app, you can find the option "AAC Downsample" change this to OFF instead of AUTO and the blue neon app will disregard the roku shows support for AAC 5.1 (because in reality the roku is stripping all but the left and right channels and playing this audio as 2 channel AAC on-the-fly). If you change "AAC Downsample" it will disable the roku from runing your surround sound experience.

 

NOTE: 1 last thing I almost forgot, find the "Enable HD Audio Test" option if you are truly curious. This will adapt the capabilities profile to include support for your 7.1 codecs. It will make the auto-detection understand this, rather than having to "force direct" to achieve the same thing. This is just for your own curiousity. Everyone not curious should leave the option disabled since no roku models presently support it, I created that option in case roku firmwares added support for this, the app would just need that switch flipped to support it.

Edited May 6, 2018 by speechles

[ebr 14910]

Thanks speechless.

Way to complicated for me.

All I can say is this video bnn can play fine just by default playback (trueDD the audio format says), but emby does not.

I can change audio track to dd, and emby then plays, but really emby should do whatever bnn does and just play it somehow without fiddling.

 

The source track may be the TrueHD one but, if you are hearing sound, that's not what it is actually playing.  It is being converted as described above.

[vaise 304]

I get that it can’t play truehd natively, I’m just pointing out that bnn recognised that and converts/plays fine, but roku beta doesn’t recognise that and does a corrupted play (all the green stuff) unless you manually change the audio track. I feel Whatever bnn is doing should be the default therefore.

[ebr 14910]

I get that it can’t play truehd natively, I’m just pointing out that bnn recognised that and converts/plays fine, but roku beta doesn’t recognise that and does a corrupted play (all the green stuff) unless you manually change the audio track. I feel Whatever bnn is doing should be the default therefore.

 

It must be transcoding the video but I'm not sure why that is necessary in this case.

 

Can you please post a new ffmpeg log from when you play it with BNN?

 

Thanks.

[vaise 304]

There are a few of these logs in this post for bnn playing vs emby roku for Paddington.

[speechles 1917]

I see the issue, and it happened due to a server change regarding the use of the "name" attribute in the media source.

 

The "name" attribute used to look like this: HEVC/AC3/1080P

 

The blue neon app needs to know what the codec is, so it can use this knowledge when figuring out which codec can direct stream.

 

Now the "name" attribute looks like this: Filename_of_media_HEVC_AC3_1080P-SomeGroup

 

The blue neon app cannot figure out what the codec is because it is expecting to see two slashes and break up the name into its 3 sections. Since it cannot do this, it will fallback to the h264 encoding. This is what is happening. This is the version of the blue neon app presently on the roku store. The store won't let me update that app any longer. So it exists in the store in this broken condition.

 

If instead, you use the version you sideload in development mode, it will build its requirements from other attributes from the media sources for that item. This version will unfortunately work the same as the official app is doing, and give you that wonderful (not!) green screen. 

 

It has something to do with the video stream:

Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x1608 [sAR 1:1 DAR 160:67], 24 fps, 24 tbr, 1k tbn, 24 tbc (default)

 

I say this because it is transcoding, so it can't be the hdmv_pgs subs causing the issue, as that can only happen if it direct played. When transcoding the server controls which streams make it to the roku, and those pgs subs arent making it.

 

Can you post the media info from this file: Paddington 2 (2017).mkv ?

 

Seeing that would shed some light on what is going on...

 

--------

 

TLDR; The app needs to transcode that hevc stream to h264. How to detect when to transcode hevc and when not to.. indeed.. that is the quandry.. the quagmire.. the issue.. giggity giggity..lol

 

The following media formats are supported on Roku devices that support 4K

• 4K Video – H.265/HEVC (.MKV, .MP4, .MOV); VP9 (.MKV, .WEBM)
• 4K Video – H.264 (Roku Premiere, Premiere+, and Ultra only)

 

The blue neon app is downsampling your 4k to 1080p. see here: Stream #0:0: Video: h264 (libx264), yuv420p, 1920x804 [sAR 1:1 DAR 160:67], q=-1--1, 24 fps, 90k tbn, 24 tbc (default)

 

As a test, enable the option "h264/Mpeg4 in 4k" and see how the blue neon app transcodes that video, it should do it in 4k this time. But your device may not support it. This is why it's a test. As developers there is a limit to the hardware you are able to test yourself because of various factors (expense, ability to locate, logistics, etc) so it is key that other users help refine issues they find on their unique hardware. So thank you @@vaise for making this thread and staying active in it. 

 

NOTE: Could also be a bug in the roku firmware? Maybe we should raise an issue on roku's forum board for this?

 

possibly the rokuTV settings?: https://forums.plex.tv/discussion/314594/roku-ultra-hevc-4k-issue

Edited May 6, 2018 by speechles