Jump to content

Roku 3 transcoding when it shouldn't be


tirdg

Recommended Posts

So I've searched google and the forums and haven't really come up with anything for my issue other than the fact that others seem to being having it in some form or another. As the title suggests, I have a Roku 3 and it seems to be transcoding content when it shouldn't be doing so.

 

Rundown of system components:

Roku 3 Model 4200X - Software Version: 7.5.0 build 4099-04

I've tried the regular Emby app (v2.25) and Emby Blue Neon Night (v4.01)

Linux box running MB Server 3.1.2.0

 

I've attached a log file which shows my issue. I have (to the best of my knowledge) ensured that my files are in a suitable format for direct play but for whatever reason, transcoding persists. My current server is not suited to transcoding on the fly which is why this is important to me.

 

Now, it's my understanding that the Roku 3 should be able to play H264 video and AAC audio in an MKV container directly. I have confirmed as much by inserting a flash drive containing such files directly into the Roku and watching them without incident. I am just at a loss at this point as to why the Roku will play these files from a flash drive but will not play the same files in the context of the Emby system.

 

I've tried both the regular emby app and BNN versions. On the BNN version, forcing DirectPlay fails. Forcing DirectStream works but buffers at times (is this indicating a LAN speed issue?). When DirectStream is forced the server dashboard indicates that the file is being direct played. I'm not sure if that terminology is meant to be interchangeable like this but it is confusing and doesn't make it easier for me to reach any definitive conclusions. I've increased the bitrate to 30Mb/s on the MB client settings. The Roku is connected to a 1080p capable LG TV with onboard stereo speakers. Audio settings on the Roku app are set to "auto detect" and is accurately detecting that the TV is a stereo system.

 

I'm not completely sure what all I'm looking at in the log file. I'm reasonably familiar with ffmpeg usage but emby is naturally using far more parameters than I would ever use and I haven't set down to decipher the complete command as of yet. I see the usage of the word "scale" with some math/variables and the numbers 1080 and 1920 being thrown around. It concerns me that the server may be upscaling the video from 720 to 1080 which I believe would be more efficiently handled by the TV or Roku. If this is indeed what is going on, can this behavior be turned off?

 

Do the log files contain any of the "decision making" done by the server? By that, I mean, the server is deciding - based on a number of factors - to transcode and stream or to hand over a resource location to the client and let it play it handle it over the network. Are the relevant factors used in that decision making process logged anywhere? Are they in this log file and can someone tell me what they are? Can they be added to the log file by increasing verbosity in the logging system?

 

My goal is to choose a file and have it direct play without being forced. I'm willing and able to do super complicated things the average user may not want to do in an effort to fix my system and help uncover issues which may be affecting others. Let me know if I can provide additional information.

Log.txt

Link to comment
Share on other sites

Happy2Play

What is your bitrate set to in the app options?  You would need to adjust it to above 19Mb as that is the bitrate of the file you are trying to play.

-maxrate 1088670
Link to comment
Share on other sites

 

What is your bitrate set to in the app options?  You would need to adjust it to above 19Mb as that is the bitrate of the file you are trying to play.

-maxrate 1088670

The app is set to 30 Mb/s. Also, where are you getting 19Mb? Is -maxrate not designated in bits per second? Meaning it would be 1.088 Mb/s? 

Edited by tirdg
Link to comment
Share on other sites

The app is set to 30 Mb/s. Also, where are you getting 19Mb? Is -maxrate not designated in bits per second? Meaning it would be 1.088 Mb/s? 

 

That is what the app requested - thus the transcoding.

Link to comment
Share on other sites

That is what the app requested - thus the transcoding.

Can you explain a little more in depth. I don't think I'm understanding. My disconnect is coming from two different place.

 

1.) The fact that the "maxrate" parameter is set to "1088670". I don't understand how that equates to 19Mb/s. If maxrate is defined in bits per second, then 1,088,670 is 1 million, eighty-eight thousand, six hundred, seventy bits per second. Where is the 19 coming from?

2.) The app is set to a higher threshold than 19Mb/s so why would it transcode anything?

 

Can you give me any advise to achieve my goal of direct playing these files?

Link to comment
Share on other sites

Sorry, I was just looking at Happy's post.  Looking now at your log I can see that the requested rate in the app was just under 20Mb/s.  The device may be limited to this amount.  However, the bitrate of the item is only 1Mb/s so that isn't why it is transcoding.

 

This is:

"RefFrames":16,

Anything over 12 is going to cause a transcode.

Link to comment
Share on other sites

The blue neon app has a refframe maximum. Raise that to 16. Raise the max framerate to 61. These preferences only have an effect on "auto-detection". If you want the best auto-detection you have to train it for your device using the settings in app.

 

But.. none of this matters when you "force directstream". Using this disregards any detection and just has the roku play the item. If the roku refuses to play it directly the app will fall back to "force transcoding". If you "force directstream" and get no sound, only silence, this is because your setup doesnt support the audio codec. You must transcode to get a surround sound codec to play on a stereo setup.

 

If "force directstream" is causing repeated buffering this indicates a network problem. The roku is likely wireless and running into interference causing dropped/lost packets. You may need to position the roku in a better spot for the wifi signal. If the roku is wired/ethernet and you still see buffering when "force directstream" is used this means a deeper issue. The network may not have enough throughput at 100mbit if several users are watching high bandwidth streams. The best solution to this issue is invest in gigabit router/switches.

 

Using "force directstream" is fine to leave enabled always. You can also change the "reset play mehod" to NO. This will stop the app from changing your play method choice to "use auto-detection" after every video plays.

 

"Force directplay" requires the roku to understand network paths. Roku does not allow network paths in their firmware..yet. When they do, the app is ready to take advantage of it. Until then, "force directplay" will give a dialog error. Using "force directstream" uses an http path instead of a network path to access the original unmodifed file. This is why the server shows this as direct playng. So to ease the confusion, think of directstream being the roku equivalent of direct playing.

Edited by speechles
  • Like 2
Link to comment
Share on other sites

Thanks, speechles. This was a very well explained answer to my question and some good education on how direct play and direct stream work. You are right that I am interested in using the app's own detection to cause direct stream/play to take place. I would prefer to not have to force it so I will be implementing these changes this evening in hopes it will correct the issue. I will also measure my network speed between the server and the wireless connection my Roku uses to see how much data I can reasonably expect to move.

 

Will using the auto detection play method utilize direct stream? That is, is there an order in which the system will attempt to play the content eg. DirectPlay > DirectStream > Transcode? Or will it immediately transcode to a known supported format for the Roku and then stream it once it realizes direct play is failing? It sounds like a weird question but for whatever reason the regular Emby app (not blue neon) always transcodes the AAC stereo audio file into MP3. I have no idea why this is being done as ACC stereo should be passed directly to my LG TV via HDMI (I believe so anyway).

 

I'm surprised to only be hearing that the Roku doesn't support network paths now. Is this in the documentation anywhere? This would have been very helpful to know and would have eliminated a lot of frustration trying to get it to work. Has Roku indicated when this might be added? What devices do support network paths and therefore direct play currently?

 

Do you know what kind of CPU overhead is expected for direct streaming? If the server passes the client an http path, it means the server must be actively serving that content. Since it's called "DirectStream" does that mean it serves it completely unaltered? No ffmpeg event? That's certainly what I'm noticing. When direct streaming content, there is no ffmpeg log generated. 

Edited by tirdg
Link to comment
Share on other sites

Thanks, speechles. This was a very well explained answer to my question and some good education on how direct play and direct stream work. You are right that I am interested in using the app's own detection to cause direct stream/play to take place. I would prefer to not have to force it so I will be implementing these changes this evening in hopes it will correct the issue. I will also measure my network speed between the server and the wireless connection my Roku uses to see how much data I can reasonably expect to move.

 

Will using the auto detection play method utilize direct stream? That is, is there an order in which the system will attempt to play the content eg. DirectPlay > DirectStream > Transcode? Or will it immediately transcode to a known supported format for the Roku and then stream it once it realizes direct play is failing? It sounds like a weird question but for whatever reason the regular Emby app (not blue neon) always transcodes the AAC stereo audio file into MP3. I have no idea why this is being done as ACC stereo should be passed directly to my LG TV via HDMI (I believe so anyway).

 

Auto-detection is just that. The roku has 3 ways to play: direct, remux or transcode. The auto-detection aims to play as much directly as possible. After that remux is far preferable to a full transcode. At the end of the spectrum lies transcoding.

 

Direct simply has emby act as an http server to serve the unmodified file. This impacts the cpu barely, if any. Remux means the container was opened, and the streams inside were used. Remux either means the container was changed, and the streams inside were all copied. Or what it usually means is one of the streams in the container wasnt able to be directly streamed and was transcoded, the rest were copied. 9x out of 10 this means audio only is being transcoded. This is light on the cpu. A remux of the video stream is cpu heavy. That means the audio stream can direct play, but not the video stream. Then there is the full transcode. The container may be acceptable, but the video and audio streams aren't compatible. This burdens the cpu the most since both streams are converted on-the-fly.

 

 

 

I'm surprised to only be hearing that the Roku doesn't support network paths now. Is this in the documentation anywhere? This would have been very helpful to know and would have eliminated a lot of frustration trying to get it to work. Has Roku indicated when this might be added? What devices do support network paths and therefore direct play currently?

 

Roku has never supported local network access. It would make local access to everything trivial and open up the roku as a perceived "pirate" box. Because of this there is "middleware" required to facilitate the roku's ability to play files over a local home network. For all intents and purposes, emby is that middleware we are using to accomplish this. Then an emby app needs to run on the roku to talk to emby and do what the roku can't do on it's own. The only devices with network access run in native device code. One example of this is Kodi. A device running Kodi doesn't necessarily need any middleware to play over a network.

 

 

 

Do you know what kind of CPU overhead is expected for direct streaming? If the server passes the client an http path, it means the server must be actively serving that content. Since it's called "DirectStream" does that mean it serves it completely unaltered? No ffmpeg event? That's certainly what I'm noticing. When direct streaming content, there is no ffmpeg log generated.

 

Directstreaming needs barely any cpu. An old celeron 300A (circa 1998) running at 300mhz can do it just fine. You are correct, since the roku app must use emby(middleware) it is emby serving the roku any content. This content is served unmodified in its original form(container/streams unchanged). Emby is simply linking to the file using its embedded http-server api. The only time ffmpeg is required is when the roku has to open the container and make use of the streams inside. It sounds like you understand how most of this works just needed confirmation.

 

If you have any questions as to what each setting in the blue neon app does I can also answer those. Most of them should be self-explanatory, but you only get so much text to describe them. There is a huge possibility of users not fully understanding what each does. If you happen to be one of these users do not feel afraid to ask what they do.

 

Keep in mind too, that "force transcoding" means that it isn't playing directly. The app still gives the server a capabilities profile when you "force transcoding" so that streams can be copied. What it isn't doing when "force transcoding" is giving any direct play capabilities in the profile. This is to force transcoding and the app lets the server decide whether to remux or transcode. So you will still see remux logs on the server when "force transcoding". Hopefully this clarifies it a bit. :)

Edited by speechles
Link to comment
Share on other sites

A quick question about the log file. At the top there is a long URL with a bunch of variables encoded into it. DeviceId, MediaSourceId, VideoCodec, AudioCodec, etc... This is where VideoBitrate=19808000, AudioBitrate=192000, MaxRefFrames=12, etc.. show up. Below that is a large JSON-type data structure called Protocol which defines among other things a key called MediaStreams which is itself a series of key/value pairs. In the MediaStreams structure, are substructures relating to video and audio. In the video structure there is a key called "BitRate" and it's value is 1088670.

 

What are these structures? Why does it seem like bitrates are being defined twice with different values? Just trying to get into the meat of this. Any reference material you might have on reading the log files would help me quite a bit. Thanks.

Link to comment
Share on other sites

You can see these in the blue neon app. Navigate to an items detail screen. Use the "show overview/info" button. Now on the next screen, choose the media information button. If there is no overview you are taken directly to the media information screen. On this screen you can see the individual bitrates for each stream and how the stream is composed. These are the media bitrates that must be met to directly play.

 

The maximum video bitrate defines what will or will not directly play. Any video streams under this bitrate will attempt to directly play. Any over this must be transcoded to fit under the maximum bitrate. This is why there are two bitrates. The app works directly with the server to decide how auto-detection will work.

 

You can also use the in-app debug logs with the blue neon app. Enable debug in preferences, and look for the debug logs button on the options row. There are lots of tools built into the blue neon app to make it easy for users to provide self help for themselves. You can also use the "device info" button and see all the juicy information usually only shown to developers. This will help you learn more about your device, the same things the app knows.

 

 

Sent from my Nexus 7 using Tapatalk

Edited by speechles
  • Like 1
Link to comment
Share on other sites

OK. So I think I'm seeing what is going on here. The url in the beginning of the log file seems to be logging the current client app settings. So the VideoBitrate=19808000 and AudioBitrate=192000 are just an allocation of the 20 Mb/s I had defined in the client across the video and audio streams. (This must have been when I was messing with settings because I leave it at the maximum of 30.)

 

The "Protocol" dictionary which follows defines the actual file properties (container, stream properties, etc..). Here the actual video bitrate is shown to be 1088670 but the audio bitrate isn't defined - only the sample rate is shown as 48000. 

 

So if I'm understanding this correctly, the video bitrate of my file is just a bit over 1Mb/s which is no where near the maximum and leaves plenty of room for say 192kb/s worth of audio for stereo AAC. Does the app define what bit rate at which the audio should be streamed (192k in this case) and the server streams it at this rate or will it stream whatever the rate happens to be based on the sample rate and bit depth but just cap it at 192k?

 

I would also like to confirm or dispel what Happy2Play said above so as to reduce my own confusion and to help anyone reading this in future. He said, "What is your bitrate set to in the app options?  You would need to adjust it to above 19Mb as that is the bitrate of the file you are trying to play.", which I believe would be incorrect as those definitions at the top are derived from the maximum settings you define in the app. Am I correct in thinking the bit rate of this file is somewhere north of 1Mb/s but no where close to 19Mb/s or even 2Mb/s? Or will the server, in an unbelievable display of inefficiency, up-sample everything to stream at the defined maximum of each requesting app?

 

I'm about to try some of this and I'll report back my findings. Thanks for all your help thus far.

Link to comment
Share on other sites

OK. So I think I'm seeing what is going on here. The url in the beginning of the log file seems to be logging the current client app settings. So the VideoBitrate=19808000 and AudioBitrate=192000 are just an allocation of the 20 Mb/s I had defined in the client across the video and audio streams. (This must have been when I was messing with settings because I leave it at the maximum of 30.)

 

You got it! That's the ticket. The audio bitrate is sliced off the top, which is misleading since the preference says maximum video bitrate.. But you get the idea, some stuff is fudged a bit. Its not rocket science so exactness isn't required.

 

 

The "Protocol" dictionary which follows defines the actual file properties (container, stream properties, etc..). Here the actual video bitrate is shown to be 1088670 but the audio bitrate isn't defined - only the sample rate is shown as 48000.

 

Sometimes the audio stream won't have a bitrate known ahead of time. It depends on how long it was ffprobing the file and other variables. Just know sometimes the audio stream bitrate is n/a and not always a value. The server in this case can still transcode the file and there is no check in the roku app to report what a maximum bitrate for audio would be even if we could tell the server. So its acceptable that sometimes the audio bitrate is a big ? (question mark).

 

 

 

 

So if I'm understanding this correctly, the video bitrate of my file is just a bit over 1Mb/s which is no where near the maximum and leaves plenty of room for say 192kb/s worth of audio for stereo AAC. Does the app define what bit rate at which the audio should be streamed (192k in this case) and the server streams it at this rate or will it stream whatever the rate happens to be based on the sample rate and bit depth but just cap it at 192k?

 

The maximum only affects direct play. If your content is above said limit, it will be reduced below it. If the stream is already below said maximum it can direct play. But the next check for refframes might make it transcode. Or the check after that for frame rate.. Or.. etc.. There are many reasons why a video stream may not be copied/remuxed. The roku auto-detection in the blue neon app is personally tested by me against a library of containers/codecs I use as samples to test against.

 

There are over 100 types of files I test the auto-detection against and I can safely say it passes the test all 100 and chooses correctly. Every time it transcodes a file I then force directstream and sure enough the roku refuses it and app falls back to force transcoding. So you might say the app w/fallback is even smarter than the user. So its okay to trust that the best decisions are made. With hevc/vp9 codecs there is still work to do. These might attempt to direct play things it should be transcoding. I need more samples for these codecs to run tests. But in the meantime the apps self fallback will successfully play the file anyways. It just wont know how to play it at first, fail, and then force transcode and work.

 

 

 

I would also like to confirm or dispel what Happy2Play said above so as to reduce my own confusion and to help anyone reading this in future. He said, "What is your bitrate set to in the app options?  You would need to adjust it to above 19Mb as that is the bitrate of the file you are trying to play.", which I believe would be incorrect as those definitions at the top are derived from the maximum settings you define in the app. Am I correct in thinking the bit rate of this file is somewhere north of 1Mb/s but no where close to 19Mb/s or even 2Mb/s? Or will the server, in an unbelievable display of inefficiency, up-sample everything to stream at the defined maximum of each requesting app?

 

The bitrate is divide by 1000 (bits to kbits) and again by 1000 (kbits to mbits) to get Mbps. That means 1088670 becomes 1.088670 Mbps. So you are correct. Happy2Play is mistaken. We are all human and make mistakes and if anyone says they don't that person must be a robot. They might be the terminator in that case, and their next question could be "Where is Sarah Connor?" or similar. In that case, run, find John Connor (inside Sarah as a fetus) and save humanity. But I dont think thats the case here. It was just a human thing to do.

 

The server is using the maximum bitrate to figure out, "can this stream direct play or not?". If the streams bitrate is below this threshold the server isnt up-converting to a higher bitrate or upscaling it to a higher resolution. If the stream bitrate is below the maximum bitrate threshold and passes all the other direct play tests the stream will direct play at the bitrate it is. The server will not modify this bitrate, except to keep it under the maximum.

 

 

 

I'm about to try some of this and I'll report back my findings. Thanks for all your help thus far.

 

Let us know. Another set of eyes is always a good test. You will find out the auto-detection is pretty damn accurate. :)

Edited by speechles
Link to comment
Share on other sites

Excellent! It's working like a champ. I guess it was getting caught on the ref frames because I increased that to the max and viola! Direct streaming with no force required. Now to add these settings to my other Roku and I'll be in business.

 

Thanks for all your help. You're doing an excellent job. 

Link to comment
Share on other sites

@@tirdg

 

We have a winner!! nice..

 

Thats what I wanted to hear. This is why the blue neon app has so many options. In this world there is not a perfect one-size fits all solution. To make it possible for users to self diagnose their own issues and change settings is important. This makes less work for me, and quicker solutions for users of the app. You can solve most problems in the auto-detection by using the preferences to "train" the app how best to handle your media and setup. The initial training of the blue neon app has a steep learning curve so glad you stayed with me through all that.

 

You may also want to raise the max framerate up to 61 until you have an issue. The roku supports up to 60fps in every codec except vp9. As the roku is natively up-convert everything to 60fps (50fps UK) to display videoframes this makes sense. You will have an issue with 1080p60 on a roku3 or earlier. These older devices have only a dual core processor and it lags behind rendering. The audio will desync from the video stream  and drift forward while the video lags behind. You will have to lower the max framerate to 30fps for these. But everything else will play fine at 60fps direct playing without issues in my tests. This is the reason 30fps is the default. There is one edge case 1080p60 where it causes an issue. As long as you know about this edge case you are fine using 61fps. Some 60fps is actually 60.005 or 60.010 weird ratios, using 61 as the max framerate allows these to also direct play. In case anyone wondered why 61?? That's why. ;)

Link to comment
Share on other sites

TomTiddler

One question for Speechles - where is the "force directplay" and force directstream" options. I can't seem to find them anywhere?

Link to comment
Share on other sites

One question for Speechles - where is the "force directplay" and force directstream" options. I can't seem to find them anywhere?

4ced7e53ecb2f80e4d7b691912a8209f.jpg

 

On an items detail screen choose the "more ..." option

 

b2b66e00429e231d7e889c17c69c97ab.jpg

 

Voila. :)

Edited by speechles
Link to comment
Share on other sites

TomTiddler

So this is a "per item" option only?

 

Ah, just checked on my Roku, and I don't have those "force ..." options at all. Am I out of date on the blue neon app? It says it's version 4.0 Build 1.

Edited by TomTiddler
Link to comment
Share on other sites

There is both a full version, and a simple version. The simple version lacks any methods to force.

 

https://my.roku.com/account/add?channel=EmbyBlueNeon

 

That above is the full version. All the bells, whistles, and handlebar streamers available. Have fun. :)

 

 

The "force" options are on a per videoplayer session start. If you use continuous play all items will try to use your play method on first try. The app will fallback if the roku gives a playback failure and will immediately try again using "force transcoding", even if you used "force directstream".

 

If you want no fallback (not advised!), change the preference for fallback retries to 0. This will spawn videoplayer dialog errors, rather than try to change your play method and silently trying again. Also change "reset play method" to NO. This will stop your play method from reverting to auto after every videoplayer session.

 

To use continuous play press the PLAY button on your remote when you are on a row of items. Rather than go to the detail screen like using OK does, you get a continuous play dialog. From this dialog you have more choices for playback depending on if the item is an episode, movie, video.

Edited by speechles
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...