Jump to content

bitrate auto vs manual vs available bandwidth, crash if adjusted


lifespeed

Recommended Posts

lifespeed

Android mobile could have near-unlimited bandwidth on wifi to the LAN, or could be trying to suck through a cellular straw.  It would be great if it could automatically choose the appropriate bandwidth.  I tried the "Auto" setting in the client, but it seems unable to reduce the bandwidth as appropriate on the cellular network.  If I check the bandwidth under quality menu it shows the max - 1080p 60Mbps.

 

I am left with trying to manually adjust bandwidth to suit my situation, inconvenient for me, and out of the grasp of my non-tech users.  When I try and adjust BW on the fly during a video the android client crashes.

Link to comment
Share on other sites

Hi, Auto works just fine. The issue might be that you clicked an option in the video player menu, and then that became your new saved value. Try going back into the app's playback settings and making sure the playback max streaming bitrate is on Auto. Thanks !

Link to comment
Share on other sites

lifespeed

Hi, Auto works just fine. The issue might be that you clicked an option in the video player menu, and then that became your new saved value. Try going back into the app's playback settings and making sure the playback max streaming bitrate is on Auto. Thanks !

 

It doesn't work for Live TV.  It is not transcoding for the Android mobile client even though the connection is lower bandwidth than LAN.  If I switch to a pre-recorded media file it transcodes and adapts to the mobile connection bandwidth as you said.

Edited by lifespeed
Link to comment
Share on other sites

lifespeed

Sounds like there are a lot of improvements to look forward to in the next release.  Thanks.

Link to comment
Share on other sites

shorty1483

Hi, Auto works just fine. The issue might be that you clicked an option in the video player menu, and then that became your new saved value. Try going back into the app's playback settings and making sure the playback max streaming bitrate is on Auto. Thanks !

 

I have to disagree on this Luke. There is a reason I reapeat my request to have a separate option for cellular connection, e.g. on VPN connected devices again and again (https://emby.media/community/index.php?/topic/34318-android-mobile-2652/page-3&do=findComment&comment=334389 and https://emby.media/community/index.php?/topic/31207-max-streaming-rate-per-user/page-2&do=findComment&comment=408757 )

 

My personal experience: Everytime I set the playback setting to Auto, no matter if connected over 3G, 4G  the player starts playing and then stutters with high bitrate movies all the time. The log shows that the file is transcoded to 21Mbit stream which is very heavy for streaming to a mobile device imo due to so many factors like performance slumps on mobile nets. For a mobile a set up bw between the server and the mobile could be far to large just a few seconds after the bw test between the app and server finished. E.g. in Germany, the network coverage in terms of quality is far away from the US like everything in tec :D, so we have very often bw gaps.

 

Imo, there needs to be a setting specially for limiting cellular client connections (based e.g. on IP) to a admin desired value if that's possible. The US server admin sets it to 10 Mbit, I would set it to 2 Mbit. No user complaints about not proper working connections over cellular anymore in case user has network at all :D

Edited by shorty1483
Link to comment
Share on other sites

  • 2 months later...
lifespeed

It looks like this issue is back.  As far as I can tell, it is not adjusting bitrate for the limited bandwidth of my 4G Android phone.  It appears not to automatically reduce the bandwidth for Live TV.  It may be transcoding library MKV files, but the client is not properly displaying the transcoded bitrate, instead showing the max for the given resolution, ie; 1080p 60Mb

 

I'm not sure if this is related to the Android client or the server side, but it has happened recently.  Both the server and the Android client have recently been updated, so I don't really know which caused it.

 

At about 4:04PM I played a library 26.5Mbps MKV file (The Aviator), the Android client appeared to not be limiting the bandwidth ("auto - 1080p 60Mb" shown by the client), however it did not stutter.  Maybe just really good 4G, or it was really transcoding?  The ffmpeg-transcode log seems to indicate it was transcoding the library MKV file.

 

Then at about 4:14PM I played channel 5.1 OTA TV at 1080i, typically around 16Mbps.  The android phone client indicated "auto - direct play".  It froze badly and generally behaved as if the bandwidth was inadequate.  There was no ffmpeg-transcode log with a 4:14PM timestamp from transcoding OTA TV.

 

Unfortunately it looks like this problem has returned.

ffmpeg-transcode-06019a33-3ad6-4b6c-87a0-0d0466e9a4be.txt

server-63627638400.txt

Edited by lifespeed
Link to comment
Share on other sites

It looks like this issue is back.  As far as I can tell, it is not adjusting bitrate for the limited bandwidth of my 4G Android phone.  It appears not to automatically reduce the bandwidth for Live TV.  It may be transcoding library MKV files, but the client is not properly displaying the transcoded bitrate, instead showing the max for the given resolution, ie; 1080p 60Mb

 

I'm not sure if this is related to the Android client or the server side, but it has happened recently.  Both the server and the Android client have recently been updated, so I don't really know which caused it.

 

At about 4:04PM I played a library 26.5Mbps MKV file (The Aviator), the Android client appeared to not be limiting the bandwidth ("auto - 1080p 60Mb" shown by the client), however it did not stutter.  Maybe just really good 4G, or it was really transcoding?  The ffmpeg-transcode log seems to indicate it was transcoding the library MKV file.

 

Then at about 4:14PM I played channel 5.1 OTA TV at 1080i, typically around 16Mbps.  The android phone client indicated "auto - direct play".  It froze badly and generally behaved as if the bandwidth was inadequate.  There was no ffmpeg-transcode log with a 4:14PM timestamp from transcoding OTA TV.

 

Unfortunately it looks like this problem has returned.

 

Nothing has returned. The probe of the live stream did not produce a bitrate so the server estimated, and perhaps the estimate was lower than actual. If you have specialized bandwidth requirements then you may want to just set an in-app bitrate.

Link to comment
Share on other sites

lifespeed

Nothing has returned. The probe of the live stream did not produce a bitrate so the server estimated, and perhaps the estimate was lower than actual. If you have specialized bandwidth requirements then you may want to just set an in-app bitrate.

There are a couple things that have changed from recent versions:

 

1) The Android client no longer displays the bitrate for transcoded streams (from the media library) over the internet, although they are indeed being transcoded and working well.  Instead it just displays the maximum possible bitrate for the resolution of the video.  So this is not badly broken, but it was nice to have the ability to understand picture quality vs available bandwidth automatically selected by the server for internet streaming.  Automatic streaming bandwidth adjustment is a great feature of Emby for non-technical users.

 

2) Live TV no longer appears to be transcoded for streaming over the internet.  This used to work.  The logs provided show no transcoding taking place.  The HDHR4-US tuners have always provided the bitrate of the stream (attached).

 

One of the really nice features of Emby is the ability to stream video over the internet, transcoded as needed for limitations different bandwidth limitations.  I don't think my situation is any different from any other user of Emby internet streaming.  I have a 25Mbps upstream connection and a high-powered CPU.  This feature has been working well.  I am just trying to convey that Live TV transcoding appears to have broken recently and ask that you look into it and let me know if there is anything I can provide via logs or testing.

 

One other comment about my particular configuration:  I have set the maximum streaming BW to 18Mbps due to my relatively fast upstream connection.  My understanding was this was a maximum, and lower bandwith would be selected based on BW all the way to the client on the internet at large.  In the past I had this set to 5Mbps, but I routinely saw Emby choose 1 - 4Mbps based on BW available to the client.

 

Thank you,

post-44858-0-63176300-1492190517_thumb.png

Link to comment
Share on other sites

lifespeed

For #1 - this has always been the case.

Perhaps my understanding of client behavior with regard to displaying the bitrate was incorrect.  At least library media, typically in MKV format, are being transcoded.

 

I do believe an issue with failing to transcode Live TV, which could easily be 15 to 19Mbps for a 1080i program, still exists for both Emby Theater and Emby Android phone.  Perhaps this is a server side issue.  I am sure this used to work.

Link to comment
Share on other sites

The issue is that the probe of the live stream is not coming up with a bitrate which is forcing us to estimate it with a dummy value.

Link to comment
Share on other sites

lifespeed

The issue is that the probe of the live stream is not coming up with a bitrate which is forcing us to estimate it with a dummy value.

Is this FFPROBE.EXE?  I am using 4/11/2017 version from ffmpeg.org.  I have used other versions and had the same problem, however.

 

I guess I am wondering if there is something on the Emby server end that has changed to cause this problem.  I know the SD tuner firmware hasn't changed, and that Live TV transcoding worked with an earlier version of Emby server.  I guess I should install the older server version and post a log showing successful Live TV transcoding.

Link to comment
Share on other sites

I am not sure why the probe is not determining a bitrate but since we know the resolution we should be able to use that to produce an estimate that isn't too far off.

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...