Jump to content

Feature to Force DirectPlay Only Without Any Detection and Disable All Transcoding


gordan
Go to solution Solved by gordan,

Recommended Posts

gordan

Hi,

 

I am looking to move from Plex to Emby specifically because the above feature is missing in Plex. The detection appears to be notoriously buggy in both Emby and Plex, and my intended server target is low power ARM machines, so any and all transcoding is completely out of the question. Plex already doesn't implement transcoding at all in their ARM binaries, but capability detection is still implemented, frequently resulting in mis-detection and a message that media cannot be transcoded (despite the fact that the same media worked fine before and a recent auto-detection "enhancement" broke it.

 

I am happy to contribute time and effort to implement the above feature (to disable any attempt at capability auto-detection and DirectPlay everything, and if the receiving device chokes on it, so be it), but since I have never looked at Emby code before, some guidance from more seasoned Emby developers would be welcome (starting with which files and functions I am likely to need to modify to add the feature).

 

TIA

  • Like 26
Link to comment
Share on other sites

An option like this will most likely just lead to a lot of problems because the average user wouldn't know the ramifications of choosing it (items simply may not play).

 

The number one goal when someone hits "Play" in an app is that the content actually plays.  A very high secondary goal is that it plays in the most efficient way possible but we have to have it playing as the top priority or people will just think it doesn't work.

 

Our automatic detection has gotten better and better and will continue to so the best effort to apply here is towards that.

Link to comment
Share on other sites

Hi, welcome. If you think there's an issue with our detection somewhere, can you report that? If you do it that way, everybody wins :)

Link to comment
Share on other sites

gordan

@ebr:

I didn't say make the option on by default. The ramification of the option not being available is that:

1) Auto-detection inevitably gets it wrong

2) It makes emby 100% unusable on a machine that doesn't have tons of CPU to burn for transcoding.

 

I am currently running Plex on a machine with a single core ARMv5, without a FPU. DirectPlay uses next to no CPU resources, and all works fine.

I am just trying Emby on a quad core i7 with the same media files, with the same target device for playback (Firefox with gstreamer plugin, H.264/AAC/MP4 media file), and emby spawns ffmpeg that burns through 400% of CPU while the playback is running. This would be completely unworkable on a small, embedded machine, and throwing more hardware at the problem to work around software bugs is beyond ludicrous as far as workarounds go.

 

So, Plex' capability detection is less broken, and it still annoyed me enough to be looking for a different solution even though I managed to get Plex to work the way I want it to _most_ of the time. I am particularly interested in Emby because the source seems to be fully open so I can fix various broken annoyances, no matter how well intentioned they may be.

 

The number one goal of everything "just working" when somebody hits play is all well and good, but I notice, for example, QNAP NAS boxes are supposedly supported. Well, the above mentioned ARM machine is in fact a QNAP TS-421. What exactly do you suppose that machine will do when it decides to transcode even a low definition video? It certainly isn't going to "just work". So as far as I am concerned, it already "doesn't work". I'm just offering to invest my own time in making it work. A pre-emptive response of denying the problem even exists isn't particularly helpful.

 

@@Luke

Auto-detection is all well and good, but my experience is that it is at best an annoyance to work around, and at worst a show stopper that completely breaks function. I have gone through the effort of ensuring my entire video collection is in H.264/AAC/MP4 format, of appropriate level and version to ensure it will DirectPlay on all targets I can possibly envisage consuming it on (various Android devices, Firefox/gstreamer, Chrome, Chromecast), and any kind of further transcoding is a complete show-stopper. My Plex experience went through the floor when they implemented auto-detection. For the sake of an "Always Force DirectPlay" tickbox that defaults to off, the entire problem can be avoided at the very least for people who do know what they are doing (and the rest can fall back on the current behaviour of being at the mercy of auto-detection and thus be no worse off).

 

But since you suggested reporting - where do I report bugs in the capability auto-detection and other components?

  • Like 3
Link to comment
Share on other sites

Even if it isn't on by default, a user will find it and turn it on (because, hey, of course I want everything to direct play) and then half his media won't play and he'll think its broken.

 

So, as I mentioned (and Luke did more eloquently), the best course of action here is to improve our automatic detection as much as possible and you can help do that both by reporting what, exactly, doesn't work properly and, if you wish, actually improving the code.

 

The place to make the reports would be in the server forum.  Thanks.

Link to comment
Share on other sites

gordan

@ebr:

So let me make sure I am getting this right: It is better for things to be outright broken with auto-detection and not work (server grinding to a halt because it can't handle transcoding due to lack of CPU power), than it is to have an option to disable auto-detection that would make it work without fail at least for people who are meticulous about their media collection formatting. Is that the basic gist of it?

 

As for reporting the bug to the server forum, where do I find the relevant logs for auto-detection and decisions being made to transcode, and if not on by default, how do I enable them?

 

@Luke:

All of my media is already encoded in a way that it will DirectPlay on all of my media consumption devices, so provided that auto-detection isn't broken (and it seems to be), I am not sure how the above changes would in fact help with my use case.

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

This seems to underestimate emby users and treat them as uneducated. The option to choose directplay/directstream/transcode should be part of the client. It should be directly accessible on the same screen the play button is on. It should be clearly labeled "play method". Under this should display the play method which for most people will just say "auto detect". Clicking this should let you change the play method. Everytime the client starts up it should reset the play method back to auto detect. This way does indeed work. Emby users are smarter than you think in this area. They are quite aware and can migrate away from emby if their whims arent met. Allowing a user to choose the play method (even incorrectly) should be allowed. This issue wont go away. Others will bring up this idea, again and again. It is such a simple request to fulfill. One of the main reasons people use the embyblueneon for roku app is because it allows this feature.

 

Sent from my Nexus 7 using Tapatalk

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

The vast majority of users are uneducated about these issues.  They don't have to worry about it with Netflix or Amazon prime.  They have no idea what "transcoding" is - heck that isn't even a word - we made it up :).

 

If we can get specific examples where the detection does not work properly, we can address them.  The more we address, the better it will be.

Link to comment
Share on other sites

gordan

then we should look at some examples

 

 

Absolutely, see my question above regarding how to get the Emby site auto-detection logging data.

 

 

This seems to underestimate emby users and treat them as uneducated. The option to choose directplay/directstream/transcode should be part of the client. It should be directly accessible on the same screen the play button is on. It should be clearly labeled "play method". Under this should display the play method which for most people will just say "auto detect". Clicking this should let you change the play method. Everytime the client starts up it should reset the play method back to auto detect. This way does indeed work. Emby users are smarter than you think in this area. They are quite aware and can migrate away from emby if their whims arent met. Allowing a user to choose the play method (even incorrectly) should be allowed. This issue wont go away. Others will bring up this idea, again and again. It is such an easy request to fulfill.

 

I agree 99%, with the exception that I think there should also be a server side option to make the server never, ever try to transcode and always DirectPlay. The reason for that is that you don't get to use a button like what you describe on a device like the Chromecast. It would be a welcome addition to applicable clients for sure, but I would rather set it on the server side and never have to touch it again.

 

As for migrating away, I very much want to migrate from Plex because this option doesn't exist, and being partially closed source with very questionable documentation on how to rebuild the open parts from git (which don't work without the closed bits), I don't have the option of fixing it myself. With Emby that option should theoretically exist, hence why I was asking for specific info on what part of the code I should be focusing on as far as plumbing in such an option is concerned. I was asking for guidance, not crying for somebody to do my homework for me, nor was I even looking approval/blessing.

  • Like 1
Link to comment
Share on other sites

An item that has been added to the library, but has not has been ffprobe'd yet. These items show with no images yet, no metadata, just a filename since it isnt completely read in yet. These will choose transcode because of this. But since it was added, and I know its directstream-able I can force directstream on it. Now when I play, regardless of mediainfo being missing on it, the item directstreams. Once the scan has read in the item and ffprobe'd it the auto-detection can be used again. This is my use case and why the option is mission critical to have.

 

Sent from my Nexus 7 using Tapatalk

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

gordan

The vast majority of users are uneducated about these issues.  They don't have to worry about it with Netflix or Amazon prime.  They have no idea what "transcoding" is - heck that isn't even a word - we made it up :).

 

If we can get specific examples where the detection does not work properly, we can address them.  The more we address, the better it will be.

 

Youtube doesn't have those problems either, nor does google real-time transcode everything to the target device. It's all stored in H.264/AAC/MP4 (and webm, but let's ignore that for now) and DirectPlay-ed to the client. Netflix and Amazon Prime don't real-time transcode, either - ever. If anything you are making my point for me here, in that by the examples given, the correct solution is to remove real-time transcoding and have offline transcoding that will either cache the universaly consumable data (which H.264/AAC/MP4 is), or outright replace the source media when the transcoding is completed.

Link to comment
Share on other sites

There is an option on the server to disable transcoding for users which is why I never mentioned that. It is already implemented server side.

b5c6f0f3c4aab848253f0d7c15bc3a42.jpg

Manage server >> Users >> click the user to edit

 

Sent from my Nexus 7 using Tapatalk

  • Like 1
Link to comment
Share on other sites

gordan

There is an option on the server to disable transcoding for users which is why I never mentioned that. It is already implemented server side.

b5c6f0f3c4aab848253f0d7c15bc3a42.jpg

Manage server >> Users >> click the user to edit

 

Sent from my Nexus 7 using Tapatalk

 

These options seem to be set by default, and I have all three of those ticked. And I still have ffmpeg eating all of my CPU time (literally) when trying to play the media back. So either this is a bug (the setting is being ignored) or something else is broken.

Link to comment
Share on other sites

shorty1483

These options seem to be set by default, and I have all three of those ticked. And I still have ffmpeg eating all of my CPU time (literally) when trying to play the media back. So either this is a bug (the setting is being ignored) or something else is broken.

 

Don't you need to disable the transcoding checkboxes in your case and see if the mentioned files play though? Additionally, could you upload a 10 sec snippet (perhaps credits) and MediaInfo of one of the affected files?

Edited by shorty1483
Link to comment
Share on other sites

Don't you need to disable the transcoding checkboxes in your case and see if the mentioned files play though? Additionally, could you upload a 10 sec snippet (perhaps credits) and MediaInfo of one of the affected files?

 

Correct, he would want to un-check those to keep it from transcoding.  That won't do exactly what he wants as it isn't going to try to direct-stream it instead.  But it will keep playback requests from hammering the server with ffmpeg instances.

Link to comment
Share on other sites

gordan

If you tell me where to find the logs showing what the emby server thinks the client supports, I can provide that along with the media info on the files in question.

In this case, specifically, for FF+gstreamer emby thinks it needs to supply a vpx/vorbos/webm, even though the client can definitely handle the actual source format DirectPlay-ed (h.264/aac/mp4) - verified because the same media file DirectPlays fine via Plex to a different tab in the same browser.

 

So, is there a log I can pull that contains what emby gets back from the client as supported formats, or am I going to have to tcpdump it out?

 

And you are right, disallowing transcoding doesn't make it DirectPlay because Emby doesn't think the client can handle it, so it is not the feature I am talking about here - the feature I am talking about is to send the raw data stream blind and let the client choke on it if it cannot handle it.

Link to comment
Share on other sites

You need to clear your logs completely out. Then try to play a movie that should directly play/stream. Afterwards, the server log and the transcode log for that session. The server log will show the app capabilities passed to it. The transcode log will show how the server chose to handle it. Both please. Thanks. :)

 

Disallow transcoding on the server isnt really required, and at best is only half of the equation. The other half is alter the client to always believe it can directplay and directstream and fake the metadata for the item it gets that controls this. Then it all falls into place.

 

Sent from my Nexus 7 using Tapatalk

Edited by speechles
Link to comment
Share on other sites

Ok there is a specific reason for that but that is actually a special case. On linux firefox always reports that it supports h264, but it depends on gstreamer for this, and even without gstreamer installed it still reports that it supports it. So that's something that would cause a playback failure. I will look at improving that detection. Do you have any other examples?

Link to comment
Share on other sites

gordan

Ok there is a specific reason for that but that is actually a special case. On linux firefox always reports that it supports h264, but it depends on gstreamer for this, and even without gstreamer installed it still reports that it supports it. So that's something that would cause a playback failure. I will look at improving that detection. Do you have any other examples?

 

Since all of my media is H.264/AAC/MP4 format, I cannot provide any other examples.

However, FF DOES support H.264 even without gstreamer. The reason gstreamer is needed is because FF reports it only supports AAC bit rates up to 192k. With gstreamer, that limitation goes away.

 

This is actually a very good example of why auto-detection should, IMO, be disablable. In this particular case, from what you are describing, auto-detection gets overridden because FF was assumed to be lying. That findamentally breaks the auto-detect everything paradigm, IMHO. And if the paradigm is going to be auto-detect, plus exceptions for where something might be lying, I am not sure why it is such a big deal to have an option that says "assume _everything_ is lying, DirectPlay everything, JFDI".

  • Like 1
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...