Roku Streaming Stick Proper Capabilities

[roberto188 33]

Did the Roku app get updated to show 60fps support on the streaming stick? My 60 fps content seems to still be transcoding to 30 fps.

[Luke 38342]

Can you link us to your older topic about this so that we can merge them? It will help keep all of the discussion together and allow us to refresh our memory on all of the information related to this. Thanks.

[speechles 1965]

@@roberto188 is there an ffmpeg log of any sorts?

 

if the video was transcoded for some reason, when direct streaming the 60fps depends entirely on the codec when used on the roku. Is it 60fps mpeg2-ts with ac3? is this a recorded tv stream?

 

With the blue neon app It will only decimate the framerate to 30fps from 60fps if it is mpeg2-ts to h264 conversion done and streamed with HLS. The mpeg2-ts to h264 conversion is rough on my cpu and usually not able to keep 60fps at all. Especially at the 720p HD most of these are broadcast in.

 

If it were h264 @ 60fps and everything else fit into the profile as supported by roku, this would direct stream without changes. It is when transcoding the video that I chose to change the framerate to 30fps. This is probably why the official app is changing to 30fps. Its using most of the profile changes I made in blue neon.

 

So It must be mpeg2-ts -> h264 happening. Do the ffmpeg logs show your cpu was fast enough to perform this conversion in real time for 60fps? If so @@ebr can probably work some magic to detect when or when not to allow transcoding to happen at 60fps. I felt the cpu squeeze wasn't worth the juice you got as the end result. It was too much buffering. Your PC may differ which is why I wanted to see ffmpeg logs.

 

NOTE: There are some rokuTV models with support for 60fps in mpeg2. This is because it is required by law for the TV manufacturer to include it with the tuner for OTA digitial broadcasts. American TV requires this, other regions may have laws requiring it too...The app should already detect this support. The blue neon app does and when found it will add the mpeg2 profile as direct play/streamable. 

Edited August 6, 2018 by speechles

[roberto188 33]

https://emby.media/community/index.php?/topic/56657-roku-app-reporting-wrong-capabilities/ Here is the link to the previous thread.
Yes, it's a mpeg2 - h264 convert. But why should that matter? EBR already confirmed that previously they were just pulling capabilities from the info embedded in the Roku and if it's not 4k capable it's not flagged as being able to handle 60fps, which means any 720, 1080p 60fps content will be transcoded to 30 with the Roku app. I currently use the blue neon app to manually set it to 60 fps. At this point I don't particularly care about the Roku TV, there are so many models out there it might be hard to code in the capabilities for all of them, but the Streaming Stick is standard.

 

I currently use my $85 Quadro K2000 and i5 2500 to transcode and stream 5 1080i stations to 720p 60fps simultaneously. The Graphics card sits at 70% and my CPU fluctuates between 90-100%, but all 5 streams keep going smoothly. Quite an accomplishment for old hardware. Only achievable with manually selectable 60fps and 720p resolution (which is why I still use blue neon). I was checking in on the 60fps issue with the standard Roku app, as the guide and all other things look very nice, but the 30fps limit on my Streaming Stick for Live TV still kills it.

Edited August 6, 2018 by roberto188

[speechles 1965]

https://emby.media/community/index.php?/topic/56657-roku-app-reporting-wrong-capabilities/ Here is the link to the previous thread.

Yes, it's a mpeg2 - h264 convert. But why should that matter? EBR already confirmed that previously they were just pulling capabilities from the info embedded in the Roku and if it's not 4k capable it's not flagged as being able to handle 60fps, which means any 720, 1080p 60fps content will be transcoded to 30 with the Roku app. I currently use the blue neon app to manually set it to 60 fps. At this point I don't particularly care about the Roku TV, there are so many models out there it might be hard to code in the capabilities for all of them, but the Streaming Stick is standard.

 

I currently use my $85 Quadro K2000 and i5 2500 to transcode and stream 5 1080i stations to 720p 60fps simultaneously. The Graphics card sits at 70% and my CPU fluctuates between 90-100%, but all 5 streams keep going smoothly. Quite an accomplishment for old hardware. Only achievable with manually selectable 60fps and 720p resolution (which is why I still use blue neon). I was checking in on the 60fps issue with the standard Roku app, as the guide and all other things look very nice, but the 30fps limit on my Streaming Stick for Live TV still kills it.

 

They aren't just pulling information from the roku via roDeviceInfo. There isn't enough information there concerning other factors to make that judgement. It doesn't tell you exactly the capabilities of the TV. It says it supports mpeg2. There isn't a reliable method to detect on the device that your PC is fast enough to encode mpeg2 into h264. The server could do some stress tests and then let the app know its possible. The reason it wasn't is because when the app was created in 2012ish era and then adapted into later versions mpeg2->h264 at 60fps converted on-the-fly was a wild mans dream. INSANE! NOT POSSIBLE! Now in 2018, sure its a reality that can easily be done, thats why I said @@ebr has to work some magic to detect support for it to know the PC the server is running on can support the transcode.

 

device = CreateObject("roDeviceInfo")
rokuTV = device.GetDisplayProperties()
isRokuTV = rokuTV.internal
if isRokuTV then support mpeg2
if server.support60fpstranscode then support 60 fps during transcode

 

Now this can tell its a rokuTV in the app, sure, and tell mpeg2 is supported on that device as direct play/stream. But in the instance of roku streaming stick you must convert to h264. In this case, the app has to talk to the server to know is the server fast enough to do all this or should it, in the interest of users to avoid buffering, limit it to 30fps. Thats the problem I see here. The setting in blue neon lets you tell it yes, your server can do it with a setting in the app. I don't think they want to add extra options users can enable that might break performance. You need to wait for @@ebr to become active in this thread.

 

@@Luke what are your thoughts on this?

Edited August 6, 2018 by speechles

[Waldonnis 148]

Are there Roku models that don't support h.264 1080p (or less) 60Hz progressive input?  I'm sure some of their SoCs are more capable of smoother playback than others, but I thought their currently-supported lineup was all consistent in supporting that type of input.  Even their own media support page lists h.264 @60fps as being supported with no noted exceptions.

[speechles 1965]

Are there Roku models that don't support h.264 1080p (or less) 60Hz progressive input?  I'm sure some of their SoCs are more capable of smoother playback than others, but I thought their currently-supported lineup was all consistent in supporting that type of input.  Even their own media support page lists h.264 @60fps as being supported with no noted exceptions.

 

Not really, mentioning that as the reason. 1080p60 is only on the newer roku devices. The roku3 cannot do 1080p60 without losing video sync, and audio drifts far into the future as the video struggles to never catch up.

 

What I meant is the reason his stick is transcode the mpeg2video into h264 is because only rokuTV supports mpeg2video. The reason its decimate this to 30fps is because at the time, in 2012, PC's were struggling to keep up at 60fps and do this in real time to deliver to the roku over HLS. A decision was made, just to transcode everything to 30fps until such time that maybe it shouldn't be. Maybe that time is now. But how can you tell users with underpowered PC's that shouldn't be transcoding to 60fps any material at that framerate, and instead doing it to 30fps so their CPU can keep up without showing them buffering screens?

 

Thats the quandry...

[Waldonnis 148]

Not really, mentioning that as the reason. 1080p60 is only on the newer roku devices. The roku3 cannot do 1080p60 without losing video sync, and audio drifts far into the future as the video struggles to never catch up.

 

What I meant is the reason his stick is transcode the mpeg2video into h264 is because only rokuTV supports mpeg2video. The reason its decimate this to 30fps is because at the time, in 2012, PC's were struggling to keep up at 60fps and do this in real time to deliver to the roku over HLS. A decision was made, just to transcode everything to 30fps until such time that maybe it shouldn't be. Maybe that time is now. But how can you tell users with underpowered PC's that shouldn't be transcoding to 60fps any material at that framerate, and instead doing it to 30fps so their CPU can keep up without showing them buffering screens?

 

Thats the quandry...

 

I can understand rationale about server capability, but disagree with it.  Whether or not the server can do it shouldn't artificially limit the client's ability to request it.  We see all kinds of "this operation is just too slow on your hardware" reports on the forums all the time, but nobody says to limit all of the clients to half native framerate because someone's server chokes on it in those cases.  I'd hate to see what our clients' capabilities would be like if we based them on a RPi server's transcode performance 

 

Now if certain models of Roku can't do it (as you pointed out), then a case can be made...but it shouldn't limit all models to 30Hz progressive input if there are some that are capable of native 60Hz progressive playback.  Of course, the trick is how to identify which models can do it in a way that hopefully doesn't involve hard-coding exceptions by model (which we both know is painful to support and should be avoided if possible).  If a generalisation can be made that any 4k-supporting Roku can also play back 60Hz progressive input reliably, then that may be an easier "demarcation point" as HEVC support can be checked in a generic manner (just using 4k as an example, but any feature common only to 60Hz-supporting models that can be checked for via API would work).

Edited August 7, 2018 by Waldonnis

[speechles 1965]

Now if certain models of Roku can't do it (as you pointed out), then a case can be made...but it shouldn't limit all models to 30Hz progressive input if there are some that are capable of native 60Hz progressive playback.  Of course, the trick is how to identify which models can do it in a way that hopefully doesn't involve hard-coding exceptions by model (which we both know is painful to support and should be avoided if possible).  If a generalisation can be made that any 4k-supporting Roku can also play back 60Hz progressive input reliably, then that may be an easier "demarcation point" as HEVC support can be checked in a generic manner (just using 4k as an example, but any feature common only to 60Hz-supporting models that can be checked for via API would work).

 

Any dual-core roku device will have issues with 1080p60 and seriously struggle. Even high bitrate 720p60 may throw it for a loop. The quad core roku devices (notably mstar devices) also support 4k. So using that as a method to detect is likely fine. If 4k is supported use 60fps for transcoding, if not assume 30fps when transcoding. That is likely a decision where just one or two devices will still be capable but fail the 4k check. At that time those 1 or 2 devices once known (if there even are 1 or 2, there may be zero) that support 60fps (but do not support 4k) can be added in by model number. Sounds good to me.

 

EDIT: and in 2012 that restriction was done to limit complaints. Emby was still MB3. Complaints kill a product when it constantly buffers. So the choice had to be done to save face. Today I can see the issue, but back then what other choice was there to make. The right choice was made then to limit damage that could occur when transcoding on the roku and people get constant buffering issues. It wasn't done to punish people, that decision.. LOL.. It was done to prevent 1 star reviews and a flood of complaints on the forums back then...

Edited August 7, 2018 by speechles

[Waldonnis 148]

Any dual-core roku device will have issues with 1080p60 and seriously struggle. Even high bitrate 720p60 may throw it for a loop. The quad core roku devices (notably mstar devices) also support 4k. So using that as a method to detect is likely fine. If 4k is supported use 60fps for transcoding, if not assume 30fps when transcoding. That is likely a decision where just one or two devices will still be capable but fail the 4k check. At that time those 1 or 2 devices once known (if there even are 1 or 2, there may be zero) that support 60fps (but do not support 4k) can be added in by model number. Sounds good to me.

 

Agreed.  Doing per-model workarounds just sucks on all levels, so anything to minimise that need would probably be the best way to handle that.  I'd be curious to see which models had issues with 720p60, though, if only to see if there was some kind of "universally supported" resolution/framerate threshold across the entire model lineup (more for intellectual curiosity).  If the issues only seem to crop up at 1080p or above on older models, then it may even be safe to enable 60Hz support for 720p or less across the board, then base higher resolutions' 60Hz capabilities on the 4k condition.  This is more theoretical in my mind since I don't know how well that would adapt to the capability reporting to the server (or if it could even be that granular).

[speechles 1965]

Agreed.  Doing per-model workarounds just sucks on all levels, so anything to minimise that need would probably be the best way to handle that.  I'd be curious to see which models had issues with 720p60, though, if only to see if there was some kind of "universally supported" resolution/framerate threshold across the entire model lineup (more for intellectual curiosity).  If the issues only seem to crop up at 1080p or above on older models, then it may even be safe to enable 60Hz support for 720p or less across the board, then base higher resolutions' 60Hz capabilities on the 4k condition.  This is more theoretical in my mind since I don't know how well that would adapt to the capability reporting to the server (or if it could even be that granular).

 

The issues are the high bitrate big bunny and jellyfish videos. I'm sure you know those.

 

https://github.com/speechles/BN-ONE/blob/patch-1/source/capabilities.brs

 

This is pretty much the capabilities section of the app that is open source. You can make your changes here, and I know ebr could then add them into the official app. Brightscript is brightscript, and the capabilities must be written in it. That would at least give you an idea what is possible and how I worked around things. Gives you an inside peek at my head too, how I thought things through reading through it.

[Waldonnis 148]

The issues are the high bitrate big bunny and jellyfish videos. I'm sure you know those.

 

https://github.com/speechles/BN-ONE/blob/patch-1/source/capabilities.brs

 

This is pretty much the capabilities section of the app that is open source. You can make your changes here, and I know ebr could then add them into the official app. Brightscript is brightscript, and the capabilities must be written in it. That would at least give you an idea what is possible and how I worked around things. Gives you an inside peek at my head too, how I thought things through reading through it.

 

Yeah, but high bitrate files are high bitrate files no matter the resolution or framerate.  A 80Mbit 1080p/60 file is the same bitrate as a 80Mbit 1080p/30 file...there are just more bits per frame in the latter.  Either of them may cause a Roku to hitch a bit, but mostly because that's a lot of data to process at any framerate.

 

Really, bitrate isn't likely the problem in most common cases like recorded sports programming...it's decoding/demuxing performance and bus bandwidth combined with video output capabilities.  I'm inclined to believe that the decoders and memory/buffers are the weak link here and their hardware in some models just can't move decoded frame data fast enough to support the increased refresh rate (basically, can it fill its output buffer at 60Hz at all, or is it just too slow above a certain resolution threshold).

 

If the same Roku model can play a 1080p/30 file at the same bitrate, then it should be able to handle 720p/60 unless their memory/decoders are just too slow to move full frames around that fast to begin with...or there are some limitations on the output hardware side.  It's nearly the same bandwidth required for both, with the only difference being how rapidly frames need to be actually decoded, rendered, and sent through the HDMI connector/circuitry.