[barberio]

With XBMC now expanding (back) to embedded systems, we hit problems where library scans/plugins provide content that the hardware devices can't decode, or can't decode well. Many plugins offer the ability to change which content they show, but there's no standard way of doing this. Some have a setting in their configuration panel, some pop up a dialogue box to ask every time something is played, some just select an arbitrary stream based on hard coded decisions.

It might be a better idea to include in the api somewhere a GetPreferedVideoFormat() function, that returns a list of the formats the hardware can handle. For example, an AppleTV would be set to return "h.264, 720p; *, 567p;" so that the plugin could automatically determine that they should first try to select a HD h.264 stream, then any SD stream. (Human readable example, return a struct would be much better than a string.)

Similar GetPreferedAudioFormat() and GetPreferedSubtitleFormat() might also be useful, but of more limited function. (Or including them in a single PreferedFormat struct.) The only example I can think of right now would be signalling plug-ins that would otherwise attempt to use styled subtitles on iOS 5 AppleTVs.

It might also be useful to eventually allow the user to set these preferences themselves on HTPC versions of XBMC.

[topfs2]

One way of doing this is as uPnP, i.e. an item (video, music etc.) have multiple resources connecte to it. The client chooses the one which fits its best. So they have no real handshake but rather let the server write out all it can provide and the client chooses which, if any, it can handle.

So an addon would submit all possible stream types and the xbmc core would choose the one most promising. This could be further expanded to have xbmc switch stream if network is to slow (i.e. switching quality as done in flash players)

Another option would be to implement a real handshake, not sure if thats worth it?

[barberio]

I don't think that seamless stream switching is even possible, at least not without very ugly hacks and even more overloading of iFile, with the current monolithic dvdplayer. So picking the 'best' option at the start of playback is the only thing really possible without a fundamental rewrite of video playback to something object/stream/message flavoured.

Not saying that a fundamental rewrite of video playback would be a bad thing. I just don't see it happening any time soon.

[topfs2]

Seamless wasn't the point. And anyways, that was just another thing which could be useful for this suggestion. As you said though, picking the best from the start is what is the most useful.