addons: deprecate plugin ability to set player. #1427
Conversation
|
Hmm.. this seem strange to me. We allow specifying player in xbmc, why shouldn't a plugin be able? |
|
If a player doesn't exist, have it fall back to default then instead. You may still want to force paplayer instead of dvdplayer for some streams, or gstreamer instead of dvdplayer whenever that shows up in linux builds. |
|
You might force paplayer, doesn't mean the platform supports paplayer. |
|
Like Elupus says, I think this is the wrong approach. Perhaps this needs a little more thought? |
|
I think the plugin shouldn't know anything about the player selection. XBMC should be the one in charge to select the right player. Since we are getting more internal players and supported platforms, plugin writers can't know what the right player is to choose. |
|
Then I assume you want to remove the play using option too? Users likely Imho it would be better to just fall back to default if requested player |
|
IMO "play using" in the GUI is another use case. It only shows the players suitable for a certain file and if there's no dvdplayer it won't show as an option. So users can't really make a completely wrong decision whereas a plugin can do whatever it wants.Joakim Plate notifications@github.com hat geschrieben:Then I assume you want to remove the play using option too? Users likely Imho it would be better to just fall back to default if requested player |
|
Right, so then let plug ins do the same. Also since upnp renderers on the |
|
most of the time addon authors will not spec the player needed, in case they do and its not available on the platform we should gracefully fallback to AUTO |
|
that would fail for pivos as both dvdplayer and amlplayer are present. |
|
What would fail? Auto?! |
|
@elupus the issue is that addon author might specify dvdplayer, because that's where it plays best. but on pivos/rpi, it needs to be routed to the hardware player. We have tons of logic in playercorefactory for deciding the right player to use. It's senseless to leave it up to the addon. |
|
@amet: of course, that's exactly what this commit does. The player it set to auto, platform uses the default player to play it. on desktop, that'd be dvdplayer. on embedded, it'd be the hardware player. I really don't understand the controversy here. All we're doing is ignoring the setting, and using AUTO instead. Desktop users will see zero change. |
|
@theuni what happens if PAPLAYER is chosen by the addon as it performs better? on desktop it will go to DVD player by default and that was not what the addon author wanted. all I am saying is that if these changes are needed for embeded or specific platforms they should apply to those platforms and not on Desktop as well |
|
then there is something wrong with our playercore rules. |
|
I think we can consider this functionality an Xbox remnant where we had both mplayer & dvdplayer on the same platform and some stuff would only work with one of them. Since this is no longer the case on any platform the only thing the remains is either default video or default audio player... |
|
Which and how many use cases are there were it makes sense for a plugin to dictate which player to use? IMO if there is such a case it means that our player selection rules in core and not optimal and could be improved. DVDPlayer should handle anything that contains video and PAPlayer anything that only contains audio and if there are other players available there should be specific rules that prefer those players over DVDPlayer/PAPlayer. IMO letting plugins specify the player will only lead to problems and confusion. @amet: So you want to have different plugins for embedded and non-embedded XBMC installations? Good luck with that. |
|
@Montellese I am not sure how you got that out of what I said :) if addon developer specs PAPlayer and we default it to AUTO with this PR desktop users will use DVDplayer and that is wrong I think. if PAPlayer is needed by the addon and it doesnt exist for the platform then we need to default to AUTO, if DVD player is needed and user is on Pivos, again default to AUTO but if user is on desktop let it be DVDplayer |
|
@amet: But you know on Desktop default would be DVDPlayer/PAPLayer. |
|
Again. Why shouldn't a addon be able to target an upnp renderer on the I se no point in hiding functionality we have in xbmc (and are not going to The addon should just be marked broken until it is just optional on the |
|
An alternative could be specifying multiple players using bitmaks, eg. (DVDPlayer | OMXPlayer | AMPlayer). Obviously this does require us to modify the defines for those. |
|
@elupus: Draw me a strong example why it is that important for plugins to be able to set the player ? |
|
Say you have 4 xbmc systems on your network. Plugin should select which one Mp3 stream works badly in Paplayer plug in ask to play it in dvdplayer. Seeking doesn't work in omxplayer, until solved in xbmc, addon forces |
|
@elupus: here we come to the point you oversee. On RaspberryPI only OMXPlayer is usable. You can't select DVDPlayer or PAPLayer. There might come other platforms where it is the same. |
|
that's really something that should be decided in xbmc, not in the plugin imho. i'm not 100% familiar with how it's done now, but if it's not done already, then the plugin should provide some metadata and let xbmc decide what the best player is instead of trying to figure it out in the plugin. the best player for the file can be different for each platform the same plugin runs on, can be different when something changes in xbmc, etc. why would we want to have logic in plugin when xbmc already contains a selection mechanism? |
|
If player isn't supported it should use default.... So that is imho a mute We should not remove functionality from addon api due to add on devs being Also how should xbmc know if user want to playback in living room or |
|
Plugin should only tell the source to play. XBMC should decide which player to use. |
|
Do you even read what I write? |
|
Right - so there needs to be an API call for getting that list definitly. |
|
I agree that having the list exposed is essential as is validating the
|
|
Hesitant bump. We need some decision on this. Imo upnp devices and other future things should be left out of the argument and hash them out as they come in. @jmarshallnz how would you propose validating? |
|
In the magical future, xbmc.getplayers(media_item) would return a sorted list of allowed players, with preferred on top, and the plugin would select one of the players from that list. Validating, therefore, would simply check that the chosen player was in the allowed list. If it wasn't, it'd be ignored and the default player for that item would be used. We could even comment in the log that this player is suboptimal if it's not the optimal choice. I presume that this validation is already done in XBMC now anyway, otherwise what happens if the player specifies that they want mplayer? The only problem then is with add-ons that specify a player that is available on the platform but known to be worse than another player. The add-on is at fault for choosing a bad player for the particular item, but I see no reason why XBMC should ignore their choice. If the player is so bad on a platform that it should never be used, then don't allow it in the allowed player list. Thus, on playback where a player is specified, I'd:
|
|
The problem is in the past, addons could pick paplayer (for audio), dvdplayer (for video) and mplayer (not a clue what happens). This worked fine on desktop for picking the audio player (paplayer) or the video player (dvdplayer). Note the common theme, audio or video. That's the choice that addons want, not to explicitly pick a player but to vector to the default audio or default video player. They really don't care about which internal video player is used, they only had one choice before and that is what some have hardcoded. Now we have embedded and two new internal players, amlplayer and omxplayer. These new internal players are the only way to play HD video content on embedded as there is just not enough ponies to use software decode and dvdplayer. So rather than complicate things by exposing internal video player names (which is only going to grow), just limit the addon to being able to pick one, either the default audio, or default video and XBMC core will make the choice as to which internal video player is best for that platform. This simplifies the solution and still gives addon their audio/video player choice. |
|
Consider the happy world of only 2 players: paplayer (audio-only) and dvdplayer (either). In this world, the add-on author doesn't have a choice between audio and video player, as there's only one video player anyway. Thus, the only reason that the add-on author has to choose between the players is in the case of audio-only playback. One presumes, then, that they're choosing dvdplayer as it works better for an audio-only item than paplayer does. This assumption should ofcourse be checked with data - I'm sure that a quick grep through the addons repo will identify the add-ons that use this feature and the authors can then be queried. If there is a reason for this to be there, then we really need to leave it there. If there's not, then you can kill it. In the meantime, if platform A really doesn't want anything other than player B available, then that is all it returns in the list of allowed players. The first step either way is validating the choice the add-on makes against the list of allowed players. This provides a mechanism for the platforms that don't want to use dvdplayer or paplayer to cross them off the list. |
|
@jmarshallnz sight unseen, I'll buy you a sixer for any addon you can find in the repo with a legitimate need for specifying any player that it's specifying. Imo you're asssuming a need here when there's no need. As I see it currently, it's an option that's exposed that can only break things. |
|
I wouldn't be surprised if that were the case, though equally, I wouldn't be surprised if there are some audio streams that work nicer in dvdplayer than in paplayer, so the potential for the choice being available is there. Whether it's enough to warrant having it available for abuse, I have no idea. Assuming there's no reason for it being there, then this would be a bugfix, so I don't see the need for a hurry. Perhaps the best way to convince @elupus would be to show there's no existing use case for it by checking the audio add-ons (no need to check video add-ons as there's only one player there in the old world). |
|
Reasonable as always, I'll accept that as a fair criteria and report back. |
|
@theuni: At the risk of re-poking the hornets nest, what was the verdict? |
|
I would like to resurrect this PR
So i would say drop the ability to choose players. |
|
@theuni , @MartijnKaijser , @jmarshallnz Sorry to interpose myself in this conversation, but I have a use case (the XBMC Pandora plugin @ https://github.com/rivy/xbmc-pandora), in which I must specify I assume that .mp4 audio streams must be unusual. But I'm sure some similar issues may arise where the basic info about a file or stream doesn't lead to correct AUTO selection. I see in http://forum.xbmc.org/showthread.php?tid=173887&pid=1516662#pid1516662 that Or, is this use case a bug, or an incorrect usage of the player API? |
…deprecation commentary * xbmc.Player( xbmc.PLAYER_CORE_MPLAYER ) is deprecated [ see URLref: http://forum.xbmc.org/showthread.php?tid=173887&pid=1516662#pid1516662 ] * using the CORE_MPLAYER is currently necessary to play .mp4 files (low/medium quality from Pandora) * PENDING investigation about a bugfix for playing the stream or leaving the current API as is in Gotham [ see URLref: xbmc/xbmc#1427 ]
|
@rivy the inability to detect the correct player for mp4 is no reason to drop this feature. It's a bug that has to be fixed. @elupus - I agree that plugins should be able to specify the target device XBMC should play to, but no longer the internal player. In doubt abstract it and use xbmc.PLAYER_CORE_AUDIO and xbmc.PLAYER_CORE_VIDEO which internally resolves the correct player for the specific media type. |
|
I'm in favour of this PR. On Pi I'd like to choose between dvdplayer and omxplayer, but currently they are hacked to both resolve as omxplayer. If I remove that hack I'm hit by this problem that iPlayer (and other plugins) request dvdplayer, even though the default video player is set to omxplayer. I agree with @da-anda that a plugin should not be allowed to choose a specific internal player. |
|
Why should a addon not be able to specify a player over UPNP? |
|
What popcornmix also make sense. Ie filter based on features instead, but that should not remove the ability to specify player. |
|
@popcornmix |
Looks like unprocessed_rating key is not available anymore ....
…e in the list, fixes xbmc#1427
|
@popcornmix i'm still in favour of getting this in. Any chance of you picking this up? |
ghost
mentioned this pull request
…deprecation commentary * xbmc.Player( xbmc.PLAYER_CORE_MPLAYER ) is deprecated [ see URLref: http://forum.xbmc.org/showthread.php?tid=173887&pid=1516662#pid1516662 ] * using the CORE_MPLAYER is currently necessary to play .mp4 files (low/medium quality from Pandora) * PENDING investigation about a bugfix for playing the stream or leaving the current API as is in Gotham [ see URLref: xbmc/xbmc#1427 ]
Now that we have multiple players in mainline, specifying a player in an addon should be considered a bug, and is deprecated for Frodo.
Instead, we always use the standard player detection logic.
@jimfcarroll please let me know if any other diddling is necessary with the code-generation. it appears as though this is all that's needed.