Jump to content

Why the server/transcoder doesn't detect the hardware capabilities of a given device?


Richard Branches
 Share

Recommended Posts

Richard Branches

We are limiting it to published specs in auto.  You are free to move it up if your find it works well in your environment.

 

Published specs? where can I find that?

Link to comment
Share on other sites

Published specs? where can I find that?

 

Exactly :).

 

When we can't find specifics, we default to the somewhat industry standard of about 20Mb/s.

Link to comment
Share on other sites

Richard Branches

Exactly :).

 

When we can't find specifics, we default to the somewhat industry standard of about 20Mb/s.

 

Understood. thank you.

Link to comment
Share on other sites

Richard Branches

One more question: What about playback correction? why that option is not on the mobile version?

Link to comment
Share on other sites

It's more automatic. if we detect a failure with direct play, it will automatically switch to transcoding.

Link to comment
Share on other sites

Richard Branches

It's more automatic. if we detect a failure with direct play, it will automatically switch to transcoding.

 

Ohhh!! that should be on the mobile app as well, maybe that helps to fix the bitrate issues with my phone, who knows  :D 

Link to comment
Share on other sites

That’s the thing here... if Emby wants to be top notch for the end user it should work everywhere on every type of devices full automatically, instead of relying on the user to adapt the quality through a list of bitrates. I challenge you to find an Emby user that is not forced to specify the bitrate somewhere on a specific device or on a connexion that the bandwith is reduced during the playback because of other people using it at the time... seems that Plex finds the proper way to do that, and as a end user it’s super exciting, no matter the place, the connexion, if my device is a 10 years old android system, it will play correctly! Pretty sure you guys have the competency and the knowledge to do that! I’m with you! Gogogo!

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

Richard Branches

That’s the thing here... if Emby wants to be top notch for the end user it should work everywhere on every type of devices full automatically, instead of relying on the user to adapt the quality through a list of bitrates. I challenge you to find an Emby user that is not forced to specify the bitrate somewhere on a specific device or on a connexion that the bandwith is reduced during the playback because of other people using it at the time... seems that Plex finds the proper way to do that, and as a end user it’s super exciting, no matter the place, the connexion, if my device is a 10 years old android system, it will play correctly! Pretty sure you guys have the competency and the knowledge to do that! I’m with you! Gogogo!

 

 

Sent from my iPhone using Tapatalk

 

Yeah, it works but it seems to be still in beta because on my sh**** phone it provides a good video resolution without stutter but after several minutes it skips directly to the original resolution/bitrate of the video and the fun ends there  :D  :D  :D 

Edited by delacosta78
Link to comment
Share on other sites

That’s the thing here... if Emby wants to be top notch for the end user it should work everywhere on every type of devices full automatically, instead of relying on the user to adapt the quality through a list of bitrates. I challenge you to find an Emby user that is not forced to specify the bitrate somewhere on a specific device or on a connexion that the bandwith is reduced during the playback because of other people using it at the time... seems that Plex finds the proper way to do that, and as a end user it’s super exciting, no matter the place, the connexion, if my device is a 10 years old android system, it will play correctly! Pretty sure you guys have the competency and the knowledge to do that! I’m with you! Gogogo!

 

 

Sent from my iPhone using Tapatalk

 

If you ask a general question you'll get a general answer. If you're having a specific problem then please report it by providing the information requested in how to report a media playback issue. thanks.

  • Like 1
Link to comment
Share on other sites

That’s the thing here... if Emby wants to be top notch for the end user it should work everywhere on every type of devices full automatically, instead of relying on the user to adapt the quality through a list of bitrates. I challenge you to find an Emby user that is not forced to specify the bitrate somewhere on a specific device or on a connexion that the bandwith is reduced during the playback because of other people using it at the time... seems that Plex finds the proper way to do that, and as a end user it’s super exciting, no matter the place, the connexion, if my device is a 10 years old android system, it will play correctly! Pretty sure you guys have the competency and the knowledge to do that! I’m with you! Gogogo!

 

 

Sent from my iPhone using Tapatalk

What Plex does with ABR (adjustable bit rate) is keep track of the size of the buffer. If it can't keep the buffer filled then the client tells the server to drop down to the next usable resolution/bitrate and keep transcoding using that.  It remembers on the client side the last known good bandwidth and will start with that.

 

The downside to doing this is that everything has to be run through the transcoder/ffmpeg so you loose out on direct play.  For normal playing it works OK but if you need to FF/RW/Jump to different parts of the video is less desirable due to the delay caused by ffmpeg.

 

Something like this could probably be built into Emby as well.

Link to comment
Share on other sites

Richard Branches

What Plex does with ABR (adjustable bit rate) is keep track of the size of the buffer. If it can't keep the buffer filled then the client tells the server to drop down to the next usable resolution/bitrate and keep transcoding using that.  It remembers on the client side the last known good bandwidth and will start with that.

 

The downside to doing this is that everything has to be run through the transcoder/ffmpeg so you loose out on direct play.  For normal playing it works OK but if you need to FF/RW/Jump to different parts of the video is less desirable due to the delay caused by ffmpeg.

 

Something like this could probably be built into Emby as well.

 

It seems to rely only on network connection and nothing more, looks like hardware detection still doesn't exist as of yet, that's why Youtube and Netflix depend on screen resolution to deliver a consistent playback and Emby should follow...

  • Like 1
Link to comment
Share on other sites

  • 1 year later...
Richard Branches

Hello @@Luke I know this is an old and forgotten topic but I'm having problems while trying to watch videos on the Samsung Galaxy J1 with 1GB of RAM, for example, when I hit play on a video like the one with the below media info, the app usually crashes or sometimes it plays the video but the app becomes unresponsive, however, if I reduce the quality to 480p -1 Mbps, the video plays smooth:

 

Video

Title: 1080p H264
Codec: H264
AVC: Yes
Profile: High
Level:40
Resolution: 1920x1040
Aspect ratio: 1.85:1
Anamorphic: No
Interlaced: No
Framerate: 23.976
Bitrate: 4,532 kbps
Bit depth: 8 bit
Pixel format: yuv420p
Ref frames: 1
NAL: 4
 
Audio
Title: Japanese Dolby Digital 5.1 (Default)
Language: Japanese
Codec: AC3
Layout: 5.1
Channels: 6 ch
Bitrate: 640 kbps
Sample rate: 48,000 Hz
Default: Yes
 
Subtitle
Title: Spanish (SRT)
Language: Spanish
Codec: SRT
Default: No
Forced: No
External: Yes
Container: mkv
 
Please, let me know if you need any logs.
Link to comment
Share on other sites

Richard Branches

So you're saying the device doesn't' support that video?

 

That's what it seems because the app crashes 10 times out of 9 for example.

Link to comment
Share on other sites

Richard Branches

Wish the app detected the amount of RAM and resolution of the screen and transcodes the video automatically, but I guess that's not in your future plans.

Link to comment
Share on other sites

Richard Branches

Here is a recording when the app crashes but the recording app I used didn't catch it:

 

https://drive.google.com/open?id=1PI4zDE1-ABMrTRtiPuUg0Hc_IMcNDFgk

 

And here is a recording when the app plays the video after I change the quality, it never crashes and the interface never becomes unresponsive:

 

https://drive.google.com/open?id=1mob5RRbI8N__S77vev5sTkZeUA3nyZfj

Edited by Richard Branches
Link to comment
Share on other sites

Wish the app detected the amount of RAM and resolution of the screen and transcodes the video automatically, but I guess that's not in your future plans.

 

Yes capabilities should be detected and transcoding utilized when appropriate.

  • Like 1
Link to comment
Share on other sites

Richard Branches

Besides "Auto", the app also crashes when I select 480p - 1Mbps with this movie:

 

Container: mkv

 
Video:
 
Title: 1080p H264
Codec: H264
AVC: Yes
Profile: High
Level: 50
Resolution: 1920x1080
Aspect ratio: 16:9
Anamorphic: No
Interlaced: No
Framerate: 23.976
Bitrate: 2,825 kbps
Color primaries: bt709
Color space: bt709
Color transfer: bt709
Bit depth: 8 bit
Pixel format: yuv420p
Ref frames: 1
NAL: 4
 
Audio:
 
Title: English AAC 5.1 (Default)
Language: English
Codec: AAC
Profile: LC
Layout: 5.1
Channels: 6 ch
Bitrate: 320 kbps
Sample rate: 48,000 Hz
Default: Yes
 
Subtitle:
 
Title: Spanish (Default SUBRIP)
Language: Spanish
Codec: SUBRIP
Default: Yes
Forced: No
External: No
Link to comment
Share on other sites

Richard Branches

I was able to test the app with an LG K8 with 1.5 GB of RAM, although the app didn't crash with the above videos, playback wasn't that smooth with Auto, by reducing the quality to 720p - 1 Mbps I got a better performance. Looks like Emby app goes better on phones with 2 GB of RAM or more. Hope you guys improve the app in this regard.

Edited by Richard Branches
Link to comment
Share on other sites

  • 4 weeks later...
Richard Branches

 

Container: mkv

 
Video:
 
Title: 1080p H264
Codec: H264
AVC: Yes
Profile: High
Level: 50
Resolution: 1920x1080
Aspect ratio: 16:9
Anamorphic: No
Interlaced: No
Framerate: 23.976
Bitrate: 2,825 kbps
Color primaries: bt709
Color space: bt709
Color transfer: bt709
Bit depth: 8 bit
Pixel format: yuv420p
Ref frames: 1
NAL: 4
 
Audio:
 
Title: English AAC 5.1 (Default)
Language: English
Codec: AAC
Profile: LC
Layout: 5.1
Channels: 6 ch
Bitrate: 320 kbps
Sample rate: 48,000 Hz
Default: Yes
 
Subtitle:
 
Title: Spanish (Default SUBRIP)
Language: Spanish
Codec: SUBRIP
Default: Yes
Forced: No
External: No

 

 

Today I met Emby's open source fork "Jellyfin" and I was amazed that "Auto" actually knows if a video could be played directly or transcoded in my 1GB RAM smartphone, so I tested the above video and turns out it had to be transcoded with the reason of transcoding saying "Video Level Not Supported", another video I tested said "Container Bitrate Exceeds Limit", that video above played smooth while on Emby, the app crashes as soon as the video starts playing. Why Emby's "Auto" lack this?.
 
Please, take a look at the attached logs.

ffmpeg-transcode-1108639e-c7c7-4ea3-b952-e044ee90fac5.txt

ffmpeg-transcode-4c379561-4792-479a-abd8-db7b4dd8617d.txt

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
 Share

×
×
  • Create New...