Re: Rygel and DMP support

[Milan Plzik <milan plzik streamunlimited com>]

On 10/07/2013 11:24 AM, Jens Georg wrote:
> On Mi, 2013-10-02 at 10:13 +0200, Milan Plzik wrote:
> > Good day,
> >
> >     company I work for considers to use Rygel/gupnp/... as a UPnP stack
> > in one of its products.  After some basic analysis and testing, we found
> > out some limitations we would like to discuss:
> >
> >      1) RygelMediaPlayer and playlist/multi-track support
> >
> >
> >      RygelMediaPlayer's interface does not provide API (nor any other
> >      public clas does) making playlist handling possible (e.g.
> >      next/previous commands, and also reporting of both current media and
> >      track).
> Correct. The current implementation wasn't really done with DMPs in
> mind.
>
> >      Since Rygel handles playlist logic internally in
> >      RygelPlayerController, it can lead to cases where next/prev controls
> >      don't work (if media playback was initiated via rygel, local UI does
> >      not know about media and vice versa).
> >
> >      Without breaking ABI, this might be solvable by making
> >      RygelPlayerController public and enabling user to re-implement it,
> >      but it would be good to discuss this a bit more to have merge-able fix.
> We can break ABI, we might even have to for the next stable, there's
> some DLNA testcase fixes for the renderer that can't be done in a nice
> way without breaking ABI. I already prepared a branch for that. But
> making the controller public might make sense anyway.

  The question is, what is better. Current RygelMediaPlayer is readily 
usable by simple players like gst playbin, offloading almost any of 
necessary logic to rygel code; I guess currently finds a lot of uses. It 
might be useful to have RygelPlayerInterface (or any better name, this 
might plug into RygelMediaDevice), which would work as a thin layer 
between upnp stack and some client plugged into rygel.

  RygelPlayerController would need to be rewritten to implement 
RygelPlayerInterface, and to provide a way to plug RygelMediaPlayer into 
it (providing simplified interface for simple players).

> >      2) Error reporting
> >
> >      Rygel's API is not designed to allow error reporting (error codes)
> >      from player to UPnP control point in first place; e.g. there is no
> >      way to report an error client when invoking play() while no media is
> >      set. Rygel's code currently does not handle these cases and there is
> >      no hint about whose responsibility is to return error code. If it is
> >      solely rygel's responsibility, we will gladly supply patches which
> >      fix this behavior, otherwise the API might need significant changes.
> Hm, correct. The initial idea was that it would be Rygel's
> responsibility.

  In some cases (and maybe in more, when considering DMP), error 
reporting might be necessary. Currently, only presence of the resource 
on network (rygel is does not do any checking by itself) comes to my 
mind. This is problematic probably only within context of Play() and 
SetAVTransportUri(), maybe Seek(). Maybe some other parts of 
RygelMediaPlayer implementations may be also dependant on external 
state, though.

> > Currently, these two issues are main blockers for us and we are
> > interested in fixing them as soon as possible.If you have any
> > suggestions/comments to any of these issues, we would like to merge our
> > fixes to the upstream.
> Appreciated :)