Jump to content

Transcoding when using the Web App on iPad


fogpuppy

Recommended Posts

fogpuppy

Hi,

 

I'm seeing transcoding when streaming to an iPad with the Web App in Safari or Chrome. The Reason for transcoding: Media bitrate exceeds limit. I see this every time for 1080P and Sometimes I even see this at lower res 480p movie.  This transcoding does not happen to the native iPad app (good) or VLC or Infuse. 

How does Emby know/determine the max bit limit for the a device? is this some sort of configuration setting or ?????

Link to comment
Share on other sites

Happy2Play

Best guess would be the Auto quality setting.  If you set the quality to something beside Auto do you get better results?

Click the gear during playback or click User icon-Playback.

But would need to see server log and ffmpeg log.

https://emby.media/community/index.php?/topic/739-how-to-report-a-problem/

 

Link to comment
Share on other sites

Try going into option in the web app and look at Playback option I think it is. You should be able to set audio and video quality and bitrates I think there.  If not there poke around close to that.

Happy2Play has a quicker trigger finger than me.  LOL

Edited by cayars
Link to comment
Share on other sites

fogpuppy

I’ll try to grab a log tomorrow when I can access the server but there’s a bit more data.  It was reported to me as an iPad but it turns out to be an Phone in reality. So I started testing it myself and  The settings in the web client are set to “Auto” before starting play but when I hit play it changes to “Auto - 720p 15kbps”.  Not sure why it selects this but if I override it and set to specifically to 1080p 10mbs and then it does direct stream.  So ... the question is why Auto is deciding to down convert to 720p 15kbps when the device is more than capable of higher rates at direct stream.  

Link to comment
Share on other sites

Let's go over an example and more detail of a play session.  We can then figure out why it's doing this and if it shouldn't or not.

BTW, you can change the default from AUTO to one of the higher bitrate settings which is probably what you may want to do.  If you know your resolution and bandwidth you can set this.

Link to comment
Share on other sites

fogpuppy

Ok ... how do you want me to proceed. I can get logs and run experiments tomorrow when I have access to the server.  Let me Know you want to know / what experiments to run  

I do kind of need to figure it out because I can’t ask all my users to tweak their settings (I often don’t even know who they are).  The transcoding is loading down the server a bit and it shouldn’t be needed. 

Link to comment
Share on other sites

fogpuppy

Ok I restarted the server to get nice short clean logs.  Attached in the server log, and two transcoding logs and even the hardware detect log.  What I did was:

Start start streaming a 1080p movie to my iPhone in safari using the web app.  The quality setting was set to "Auto".  It decided to transcode down to 720p. 

I then switch the quality setting to 1080p 5Mbps and it stopped transcoding and was able to stream the 1080p content direct with no issues.

I then switch back to auto and it started transcoding again.

Let me know if you need anything else to diagnose.

embyserver.txt ffmpeg-transcode-02d1a85d-bba7-442b-a228-7c6c1c4735e9_1.txt ffmpeg-transcode-474c83dd-e614-487c-8112-ba36f6db2fa2_1.txt hardware_detection-63730324482.txt

Link to comment
Share on other sites

Happy2Play

To me it is the Auto quality setting that is limiting connection, as the returned limits is "&VideoBitrate=1337230&AudioBitrate=162770" about 1.5Mbps.  There are several topic on the Auto quality setting.

So the question comes back to why is the client sending the this max bitrate limit while set to Auto?

http://xxx-xxx.xxxxx:8096/emby/Items/14418/PlaybackInfo?UserId=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&StartTimeTicks=0&IsPlayback=true&AutoOpenLiveStream=true&AudioStreamIndex=1&MediaSourceId=f77f26ba6ec0119fd1af96e2df18d762&MaxStreamingBitrate=1500000. UserAgent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.2 Mobile/15E148 Safari/604.1
2020-07-14 12:05:43.389 Info MediaInfoService: User policy for Guest. EnablePlaybackRemuxing: True EnableVideoPlaybackTranscoding: True EnableAudioPlaybackTranscoding: True
2020-07-14 12:05:43.390 Info MediaInfoService: Bitrate exceeds DirectPlay limit: media bitrate: 2521319, max bitrate: 1500000

The only current workaround is manually setting a higher quality limit via the client.

Link to comment
Share on other sites

Happy2Play
5 minutes ago, fogpuppy said:

When you say "the client" isn't the client Emby Web app?  Or do you mean the browser itself?

Well in your case as the log shows "Safari".  But overall all devices that use Auto have these remote quirks.  There are several topic on the forum.  Best way to describe is Auto is extremely conservative.

Edited by Happy2Play
Link to comment
Share on other sites

Yes try setting the in-app quality setting to a suitable value if you find the Auto value to be too conservative.

Link to comment
Share on other sites

Any chance the "auto" feature could be improved a bit so that it wasn't so conservative?

Link to comment
Share on other sites

fogpuppy

OK first, I understand what to do to work around this for now but  it's pretty ugly to tell all my users to manually change their settings.  It works but it is far from optimal. 

Second, I'm not sure still who you guys are saying is the "culprit" here.  Is it the Ebmy Server/Web app being too conservative?  Or is it Safari reporting something to Emby in error (since we know the phone can stream 1080P no problem).  I'm suspecting the former because I've seen safari stream youtube and other sites quite happily at 1080p.  Also I don't think Safari is going to inject the " &MaxStreamingBitrate=1500000" into the URL which is what seems to trigger this issue. 

Link to comment
Share on other sites

It's not something you have to do every time. You can configure it once using in-app quality settings.

Link to comment
Share on other sites

Happy2Play

At the same time your home connection will likely never have the bandwidth or optimization as YouTube. 

But in the end the client set to auto is defaulting to a set value do to the conditions of the connection at the time of playback.  This does not always mean the connection can not sustain the original bitrate, but for some reason Auto determined to use the default conservative rate.

Link to comment
Share on other sites

fogpuppy

You are right that normally in a 4 or 5 device household it's not a big deal to change the setting manual and it does remember it.  But this Emby server is serving up content to a large population of people who come and go.  I don't really get a chance to tell them what to do in a reliable fashion.  Yes there's a cheat sheet of sorts but we all know no one "reads the manual".   I can limp along like this but it is causing a lot of totally unneeded transcoding to occur.

But I'm not sure why we are are dancing around what exactly is causing this issue?  For the record, can we acknowledge is this some sort of "bug" or "undesirable behavior" in Emby where it just decides to be "conservative" when it doesn't need to?  And If so why?  What's triggering it? And how do we record the details so it gets fixed?  BTW this also happens on a 12.5" iPad Pro where the down-converted video looks pretty bad so it's not just a "little screen" issue. 

I can also confirm that on this same network YouTube, Prime Video, YoutubeTV and many other services stream to both these devices at 1080p in their corresponding Auto settings. And that is pulling content over the (much slower) internet connection.  The Emby server is local and has waaaay more bandwidth to the clients than the internet connection. In addition, I can report the Native iOS Emby app does NOT transcode so ...

Link to comment
Share on other sites

Happy2Play
57 minutes ago, fogpuppy said:

The Emby server is local and has waaaay more bandwidth to the clients than the internet connection.

Are you saying this happens on your LAN?  If so that would mean the server is seeing your clients as Remote.  A dev will have to correct my but I don't believe the Auto setting really applies to LAN connections.  @Luke @ebr

Only other thing I can possibly think of would be possibly IPv6.

Link to comment
Share on other sites

On the LAN auto will use a max value to get as much direct play as possible.

Link to comment
Share on other sites

fogpuppy

Ok so both are connected to the same local wifi ssid on the same lan.   I have a lot of strange issues with local vs remote where sometimes it just won't connect unless I enable remote access even though both were local.  I reported some of this in other threads where it was being passed a local IP6 address but still declaring it remote.  

Is IP6 not officially supported?  I've previously reported a DLNA issue that it was not starting properly because it was using an IP6 address. 

Link to comment
Share on other sites

Is your Emby server connected to WIFI and not on Ethernet?

I don't know if this is a business network but if so it's quite possible to be on a different IP address range as business will often segregate networks and then setup routing between them based on need for security.  If something like this is going on then the Emby Server could/would think these are remote users.

So can you tell us more about the network setup?

Link to comment
Share on other sites

fogpuppy

They are both Emby server and the clients are connected wifi on a the same single unique ssid.  The DHCP is handed by the WiFi access point so they are all on the same subnet.  THe IP address of the server is 192.168.7.128.  the iphone is 192.168.7.186 and the iPad is 192.168.7.189.  The Netmask is 255.255.255.0 on all devices. Similar rules apply for the IP6 address (all local to one subnet, given out by access point, etc).  This network typically does not have any internet connectivity so there's no way they have any other IP range.   

Again, is IP6 an fully supported or is that the issue?  I ask because I have previously reported that some of the devices wouldn't not connect until I allowed remote access we tracked it down to IP6 addresses being used but I never got an explanation of why it was a problem. Even though the IP6 addresses were local.  See the issue here:

 

Link to comment
Share on other sites

Happy2Play

People have reported it works, but in the end if your hardware is creating a segregated IPv6 network I would guess Emby is not seeing this network the same.  I am speculating just like a different network subnet.

@Luke would have to comment more.

Link to comment
Share on other sites

fogpuppy

It is NOT a different subnet ... There's no way because there's only one netowkr here on one DHCP servergiving out one set of addresses ..... The question is if the server have both ip4 and IP6 addresses does it consider both local.  Or ... Is it possible if the server thinks it's ip4 address is it's primary address that it could consider connections via IP6 remote even though it's. It.   If you look at the other post you can see the IP6 addresses are local ...

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