Invader115 10 Posted October 23, 2019 Share Posted October 23, 2019 So, one of the main devices I use to access Emby is my Android tablet, an oldie-but-goodie Samsung Galaxy Tab S. It's a model that I believe dates back to 2014, sporting a gorgeous OLED display, more than enough processing power, and some very outdated firmware. More recent OLED-equipped tablets cost a small fortune, so I've been keeping this one going as long as I can. It's only really used as an Emby access point, so I didn't think I'd ever have trouble with it. Obviously I was wrong, or I wouldn't be asking for help... Video formats have evolved since 2014, and a number of media items on my server use the newfangled HEVC (and on occasion VP9) codec. That's bad news for my tablet, because it doesn't have hardware decoding support for either. Despite the tablet's processor being fast enough for snappy general usage, it's almost completely unable to software decode these media files at a reasonable rate. In almost all scenes, what reaches the tablet's screen is like a bizarre modern art piece, with almost nothing from the original video recognizable. It's like it gives up and sends barely-processed frames to the screen, with the audio track playing normally all the while. That's all to be expected from a five-year-old tablet, though. What I'd like to do is "ban" or "blacklist" HEVC and VP9-encoded files for this tablet, forcing any item encoded this way to be transcoded when played from the tablet. Is this at all possible? I've looked through my server and client settings for anything like this, but I've come up empty. Am I missing something obvious? I should add that I've forced transcoding on these items by dropping the video bitrate, and that does indeed produce watchable video. That's not a viable solution, though, because the vast majority of my library can easily be direct-played at fairly high bitrates. I would like to avoid messing up picture quality for the whole library for the benefit of a handful of items. Link to comment Share on other sites More sharing options...
chef 3745 Posted October 23, 2019 Share Posted October 23, 2019 (edited) There use to be device profiles under the transcoding menu in Emby which might have, at the time, made it possible to handle this sort of thing. I'm not seeing those options any longer in the lastest builds of the server. What is interesting is that your device is reporting to the server that it can handle these codec, so the server is serving them up that way. Each time a device connects to the server it sends SupportedCommands through the API. Edited October 23, 2019 by chef Link to comment Share on other sites More sharing options...
Luke 37056 Posted October 23, 2019 Share Posted October 23, 2019 Hi, it should be detecting that your device doesn't support it and then having the server transcode it. Are you saying it is direct playing? What version of android does this run? Link to comment Share on other sites More sharing options...
Invader115 10 Posted October 24, 2019 Author Share Posted October 24, 2019 (edited) Yes, the tablet direct-plays these items when it shouldn't. Its Android version is 6.0.1 A minor detail, but I discovered the garbled software-decoded frames I was talking about only happen when I'm using an external Android player (VLC); using the native player, playback is just extremely choppy. Edited October 24, 2019 by Invader115 Link to comment Share on other sites More sharing options...
chef 3745 Posted October 24, 2019 Share Posted October 24, 2019 (edited) So it sound like VLC is sending that info back to the server saying that it can support the codec at a specific rate, but actually the tablet doesn't like it. Have you tried all possible bitrate options in the default emby player to try and get smooth playback? Some times it's as simple as changing the 1080p rate down to 5mb/s. I always start low on the bitrate and then gradually test higher ones until I find the limit where playback get choppy for my device. Once I have the highest it'll play it'll be set there Everytime Edited October 24, 2019 by chef Link to comment Share on other sites More sharing options...
Happy2Play 8281 Posted October 24, 2019 Share Posted October 24, 2019 @@chef This issue will be HEVC/H265, as it usually already has a lower bitrate then H264. Yes, the tablet direct-plays these items when it shouldn't. Its Android version is 6.0.1 A minor detail, but I discovered the garbled software-decoded frames I was talking about only happen when I'm using an external Android player (VLC); using the native player, playback is just extremely choppy. Can you post a server log and ffmpeg log if one is created when you play a item with this issue. 1 Link to comment Share on other sites More sharing options...
Invader115 10 Posted October 24, 2019 Author Share Posted October 24, 2019 (edited) Alright, I ran a video and saved the log. Its bitrate is well within what I can reliably play, but all the choppiness is still there, so this should be a good representation of the overall problem. No FFMPEG log was created. Edited October 26, 2019 by Invader115 Link to comment Share on other sites More sharing options...
chef 3745 Posted October 24, 2019 Share Posted October 24, 2019 (edited) @@Happy2Play, the remoteClientBitrate limit is 10000000 The max bitrate limit is 6000001 Would it make sense to see the ffmpeg logs? The only other thing I can see, but am unsure what it is, is a socket exception just before you stopped playing the media file. But that could be the stream stopping... maybe. Edited October 24, 2019 by chef Link to comment Share on other sites More sharing options...
Invader115 10 Posted October 24, 2019 Author Share Posted October 24, 2019 (edited) I think I stopped the stream by closing the app, which may have upset the server a bit and could explain the socket exception. Also, the bitrate limit I've set in the app is "1080p 6 Mbps". I've successfully used it all the way up to 15 Mbps for some larger files, but I've lowered it for testing this problem. Why the log reports such a massive value is beyond me. EDIT: Previously I wrote here that I was confused whether HEVC and VP9 were really both affected by this problem, but I've since found a testable HEVC file and used it to confirm the codec's got all the problems VP9 has on my tablet. The file I played in the log files you saw was encoded in VP9. Edited October 24, 2019 by Invader115 Link to comment Share on other sites More sharing options...
Invader115 10 Posted October 25, 2019 Author Share Posted October 25, 2019 Sorry to double-post, but is there any more information I can provide, or any pointers you can give me to get around my problem? Link to comment Share on other sites More sharing options...
chef 3745 Posted October 25, 2019 Share Posted October 25, 2019 (edited) Do you have hardware accerated encoding turned on in the Emby server transcoding tab?? If you do, turn it off. Also I found this for VLC online: Preferences -> Input/Codecs -> Disable hw decoding If you are a Windows user, Preferences -> Video -> Change from direct3d11 to direct3d9 Do those options exist on your tablet?? Also, this is mentioned online: Although VLC has claimed its native support for HEVC/H.265 codec, however, it is well know that the H.265/HEVC playback is very processor extensive, even if your computer has meet the minimum standard to playback HEVC/H.265 video, you may still suffer video playback choppy or corruption issues. Although you can enable GPU accelerated decoding in VLC, however, this feature only works with H.264 streams but not for H.265/HEVC streams. Emby should be transcoding these file to h264. I really think the problem is with using VLC as an external player. Edited October 25, 2019 by chef Link to comment Share on other sites More sharing options...
Invader115 10 Posted October 25, 2019 Author Share Posted October 25, 2019 (edited) Alright, I disabled hardware decoding in VLC for Android and I've disabled hardware acceleration in the Emby server. These settings changed the symptoms but the overall problem's still there: the frames look normal now in VLC, but it's still super choppy even at a bitrate I know the tablet can handle (it's always got a strong connection to my 802.11AC wi-fi because it's only really used in one room). Taking your advice further, I disabled external players in the Emby Android client and used the native player. Under these circumstances the playback is still unwatchably choppy. Neither player has the "bizarre modern art" video corruption anymore, but there's still a major problem with these codecs. EDIT: I could begrudgingly switch to using the native player for everything and drop the bitrate every time something runs poorly, but VLC's got some very nice features the native player lacks and I'd much rather handle this more elegantly. Edited October 25, 2019 by Invader115 1 Link to comment Share on other sites More sharing options...
chef 3745 Posted October 25, 2019 Share Posted October 25, 2019 (edited) Okay so it would seem that the hardware accelerations where cause the "bizzar modern art" frames in the stream. I have seen other people mentioning this type of behaviour in the forms here. You probably don't have to switch back to the Emby player, now that the acceleration is turned off. What kind of gpu are you using on your server? If you are using integrated graphics keep the acceleration off, if you have an aftermarket GPU, you could be okay with turning in the hardware settings. As for VLC on the tablet I have been reading some threads online that might help get the stream smooth. Edited October 25, 2019 by chef Link to comment Share on other sites More sharing options...
chef 3745 Posted October 25, 2019 Share Posted October 25, 2019 (edited) Okay, clear the VLC cache on your tablet. It would be under app settings. Apparently... And this is what some said online... Reboot the device after you have disabled hardware acceleration and cleared the app cache. Then try to play the media again. What I hope will happen is that the device will change the 'Capabilities'response to the server, and therefore not attempt to direct play HVEC/h265 file anymore. Instead transcode them to h264. Edited October 25, 2019 by chef 1 Link to comment Share on other sites More sharing options...
Invader115 10 Posted October 25, 2019 Author Share Posted October 25, 2019 I tried all that and the problem stayed the same, but something else happened while I was trying it: I put on a 5 Mbps H264 media item, direct-played, and it had the same choppiness. My brain is melted. So, what's actually the problem here? Who knows! That one discovery seems to blow my theories out of the water. At least the problem being totally different than I thought explains why the suggested solutions weren't working... Seriously, thanks a ton for your assistance. I'll check back if I have more questions, but for now I don't see as there's much anyone can do to help me. Link to comment Share on other sites More sharing options...
Invader115 10 Posted November 10, 2019 Author Share Posted November 10, 2019 The problem I made this thread for is gone. I noticed a couple days ago, but I was letting time pass to make sure it's really fixed. I don't know if there was an update I didn't notice, or if something on my end changed, but all is good now. Thanks for your help either way! 1 Link to comment Share on other sites More sharing options...
Luke 37056 Posted November 10, 2019 Share Posted November 10, 2019 Thanks for the feedback. Link to comment Share on other sites More sharing options...
Invader115 10 Posted February 10, 2020 Author Share Posted February 10, 2020 Mega necropost, but also the final post: my problem never went away. Somehow, I stopped running into it for a while. My best guess: it was a coincidence, I ran into a large amount of new content that was never affected, and when I tested old content again, I misremembered things and wound up testing old content that was also never affected. Regardless, this issue was always there and I saw it return soon enough. I became so sick of it that I bought a new tablet. An upgrade was long overdue. I've had my new tablet for over a month and it has never seen any problems like the video "corruption" described in the OP, possibly confirming the general hypothesis that it was a format compatibility issue. My new tablet, a Samsung Galaxy Tab S5e, is far more recent and doesn't have issues with modern video formats. I should have updated this post months ago but I considered tech support a lost cause (no offense intended) and decided to start saving my pennies instead. I'm posting this now just so it's on the record that this weird problem never solved itself. Link to comment Share on other sites More sharing options...
Luke 37056 Posted February 10, 2020 Share Posted February 10, 2020 Hi, thanks for the feedback. Why do you think tech support is a lost cause? Have you seen how response we are here on this community? Link to comment Share on other sites More sharing options...
Invader115 10 Posted February 10, 2020 Author Share Posted February 10, 2020 (edited) The problem with tech support wasn't responsiveness, it was just that after several replies and a back-and-forth I was no closer to solving the issue. It wasn't a comment about Emby support in general, just this one instance with my one unusual problem. Even then it wasn't the quality of support provided. It seemed like there wasn't a solution for the problem at all; the best support possible probably couldn't have helped. Edited February 10, 2020 by Invader115 Link to comment Share on other sites More sharing options...
Luke 37056 Posted February 13, 2020 Share Posted February 13, 2020 Thanks for the feedback! Yes i agree that more admin control to reduce resource consumption would be helpful. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now