Hi everyone,
I am about to merge some new cool DLNA stuff into gupnp-av that not
only benefits Rygel but also any MediaServer based on gupnp-av, so I
thought I share some information about it before I do:

1. DLNA profile detection:

Every gupnp-av users know that we really miss good DLNA profile
guessing APIs in gupnp-av. Currently we have some very simple guessing
for some profiles and its far from being complete or accurate. The
issue wasn't a simple one to solve as for a proper implementation you
need a lot more info that whats available in DIDL-Lite properties.
While I was wondering how to best solve this issue, Edward Hervey came
along with his GstDiscoverer idea. GstDiscoverer in simple words is a
gstreamer-based metadata harvesting API that is not just much easier
to use (hiding low-level gstreamer details) but does the task much
much faster than if you do the same using playbin/decodebin. The
result of his work is going into a package called gst-convenience[1],
which upon reaching API stability will be merged into
gst-plugins-base.

So we decided to make use of those efforts and we (mostly Arun
Raghavan from Collabora Multimedia) have been working on
implementation of a subclass of GstDiscoverer [2] in gupnp-av,
GUPnPDLNADiscoverer that adds DLNA profile information to all the
information extracted by its parent class. The DLNA profile
information is kept on disk in a set of XML files and hence addition
of new DLNA profiles and editing/removing existing ones is easily
possible without any coding or modification to gupnp-av.

2. Fully automatic transcoding:

Although there is nothing related to transcoding in gupnp-av, Rygel
implements transcoding using gstreamer. Thanks to GStreamer's
decodebin2 element, transcoding is pretty much format agnostic on the
source side (i-e it can transcode from any format that GStreamer can
handle). However, since there was no encodebin so far, we not only
needed custom code for each transcoding target, the encoding/muxing
part (used gst elements) was hardcoded.

The gst-convenience library mentioned above also provides this very
much needed element and I already have ported Rygel's transcoders to
make use of this in a branch[3]. The result was not just much simpler
code but we no longer have the hardcoded the encoding pipeline.
However the transcoding formats are still pretty much static and it
would be really nice to make them dynamic: (advanced) user be able to
specify the DLNA profiles which needs to be offered to the client in
the config file (or command-line option) and rygel be able to
construct the needed pipeline at runtime when a client device requests
the transcoded stream without any prior knowledge about the DLNA
profile in question.

An encodebin needs to be given something called encoding profile to
inform it about the target format. A nice coincidence was that Arun
was already using these encoding profiles to represent the DLNA
profiles in memory so we figured that an API that provides the
encoding profile given the name of the DLNA profile will allow us to
achieve our goal.
-------------

While #1 is pretty much working already and Arun's recent work on
this has mostly been about populating the default DLNA profile
database, the API to fetch encoding profile given the DLNA profile
name is still at its infancy. I want to merge the #1 already in
gupnp-av and get unstable release out already to get things working in
time for GNOME 3.0, which Rygel is now part of and gupnp will soon
become a blessed dependency in. Hopefully the encoding profile APIs
will also be ready for a merge soon.

Now all this sounds really exciting, however we have one issue:
gst-convenience library this all depends on, according to Edward will
not be getting merged into gst-plugins-base for another two months. We
can wait for that to happen but that will be too late to get it tested
(by many people) before GNOME 3.0 and we wouldn't want that to happen.
So as a temporary workaround, Arun and I have decided to move the
gst-convenience (its not really big) into gupnp-av. Arun has promised
to make sure that this internalized copy is up2date every week. Once
gst-convenience is merged into gst-plugins-base, we'll get rid of this
internalized copy.

Thats it folks! Thanks a lot to Arun for all this work he has been
doing for the past some months. He not only implemented these APIs but
also has been fixing things in gst-convenience and different gstreamer
plugins whenever needed.

--
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] http://git.collabora.co.uk/?p=user/edward/gst-convenience.git
[2] http://gitorious.org/~arunsr/gupnp/dlna-profile
[3] http://gitorious.org/rygel/rygel/commits/encodebin
_______________________________________________
___________________________________________________

Posted on the Rygel-list mailing list. Go to http://mail.gnome.org/mailman/listinfo/rygel-list to subscribe.

Hi,

On Fri, 2010-06-11 at 01:39 +0300, Zeeshan Ali (Khattak) wrote:

> Now all this sounds really exciting, however we have one issue:
> gst-convenience library this all depends on, according to Edward will
> not be getting merged into gst-plugins-base for another two months. We
> can wait for that to happen but that will be too late to get it tested
> (by many people) before GNOME 3.0 and we wouldn't want that to happen.
> So as a temporary workaround, Arun and I have decided to move the
> gst-convenience (its not really big) into gupnp-av. Arun has promised
> to make sure that this internalized copy is up2date every week. Once
> gst-convenience is merged into gst-plugins-base, we'll get rid of this
> internalized copy.

Does this mean that gupnp-av will get a dependency on GStreamer? That
would be very unfortunate. Serving media should not depend on a media
decoding/playback framework. We don't even have GStreamer installed on
the device that hosts our media server.

Can't we just add the necessary APIs to gupnp-av that allows to hook in
custom DLNA profile detection?


Greetings,
Sven


_______________________________________________
___________________________________________________

Posted on the Rygel-list mailing list. Go to http://mail.gnome.org/mailman/listinfo/rygel-list to subscribe.

Hi Sven,

----- Original message -----
> Does this mean that gupnp-av will get a dependency on GStreamer?

Yes.

> That
> would be very unfortunate. Serving media should not depend on a media
> decoding/playback framework.

GStreamer is a generic multimedia framework, albeit decoding/playback is the main usecases. Also metadata harvesting (including dlna profile detection) does involve 'decoding' no matter which framework you use.

> We don't even have GStreamer installed on
> the device that hosts our media server.

GStreamer core isn't big at all so you might want to consider installing it now? Perhaps at the same time as you upgrade gupnp-av?

> Can't we just add the necessary APIs to gupnp-av that allows to hook in
> custom DLNA profile detection?

We certainly could & any ideas in that regard are welcome. Having said that, keep in mind that we won't have time to implement your ideas anytime soon (lots of things to do & many deadlines coming) & gstreamer dependency isn't an issue for us.

--
Regards Zeeshan Ali (Khattak)
Sent from Nokia N900

> & gstreamer dependency isn't an issue for us.
>

I understand that gupnp/rygel have much corporate sponsorship and that
the primary goal is to make your company happy and a product that
works well for them. However, I have noticed you also have a desire
to be open, develop with a community and create a product that works
for the community at large and I share that goal and feel strongly
about it.

It would seem that in making this decision you have only considered
the 'us' and not the implication for your non-corporate users. If we
want gupnp/gupnpav to be used many application
creators/developers/companies/applications then we should be wise
about their needs and consider that adding new dependencies will make
peoples lives harder sometimes.

Could the feature not simply be #ifdef'd?
_______________________________________________
___________________________________________________

Posted on the Rygel-list mailing list. Go to http://mail.gnome.org/mailman/listinfo/rygel-list to subscribe.

Hi,

>> & gstreamer dependency isn't an issue for us.
>>
>
> I understand that gupnp/rygel have much corporate sponsorship and that
> the primary goal is to make your company happy and a product that
> works well for them.  However, I have noticed you also have a desire
> to be open, develop with a community and create a product that works
> for the community at large and I share that goal and feel strongly
> about it.
>
> It would seem that in making this decision you have only considered
> the 'us' and not the implication for your non-corporate users.

Rygel is also part of GNOME now and I have taken care of that target
even though it has nothing to do with "corporate" interest. GStreamer
is *the* multimedia framework and depending on it for all multimedia
needs just makes sense.

Instead of dwelling in arguments, please feel free to provide
patches that makes gstreamer an optional dep but do provide at least
one non-gstreamer implementation for the same APIs.

--
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
_______________________________________________
___________________________________________________

Posted on the Rygel-list mailing list. Go to http://mail.gnome.org/mailman/listinfo/rygel-list to subscribe.

On Mon, 2010-06-14 at 08:55 -0400, Zachary Goldberg wrote:

> Could the feature not simply be #ifdef'd?

If it is not too integrated, I could try to come up with a patch that
makes it conditional. But from my experience with code that is compiled
conditionally, this might become a nightmare to maintain.


Sven



_______________________________________________
___________________________________________________

Posted on the Rygel-list mailing list. Go to http://mail.gnome.org/mailman/listinfo/rygel-list to subscribe.

On Mon, 2010-06-14 at 13:48 +0300, Zeeshan Ali wrote:
> Hi Sven,
>
> ----- Original message -----
> > Does this mean that gupnp-av will get a dependency on GStreamer?
>
> > We don't even have GStreamer installed on
> > the device that hosts our media server.
>
> GStreamer core isn't big at all so you might want to consider
> installing it now? Perhaps at the same time as you upgrade gupnp-av?

If it was just a dependency, that would be a minor problem. But I am
afraid that this means that GStreamer is going to need access to all the
media files for the media-server to work. This would be difficult and it
has the potential to cause a significant performance degrade, which
would be unacceptable for us. We can't afford to actually access the
media file each time that meta-data about the file is being requested by
a control-point.

> > Can't we just add the necessary APIs to gupnp-av that allows to hook
> > in custom DLNA profile detection?
>
> We certainly could & any ideas in that regard are welcome. Having said
> that, keep in mind that we won't have time to implement your ideas
> anytime soon (lots of things to do & many deadlines coming) &
> gstreamer dependency isn't an issue for us.

Well, if you could send your patches for review, that would make it
easier for me to suggest changes.


Sven


_______________________________________________
___________________________________________________

Posted on the Rygel-list mailing list. Go to http://mail.gnome.org/mailman/listinfo/rygel-list to subscribe.

Hi,

> On Mon, 2010-06-14 at 13:48 +0300, Zeeshan Ali wrote:
>> Hi Sven,
>>
>> ----- Original message -----
>> > Does this mean that gupnp-av will get a dependency on GStreamer?
>>
>> > We don't even have GStreamer installed on
>> > the device that hosts our media server.
>>
>> GStreamer core isn't big at all so you might want to consider
>> installing it now? Perhaps at the same time as you upgrade gupnp-av?
>
> If it was just a dependency, that would be a minor problem. But I am
> afraid that this means that GStreamer is going to need access to all the
> media files for the media-server to work. This would be difficult and it
> has the potential to cause a significant performance degrade, which
> would be unacceptable for us. We can't afford to actually access the
> media file each time that meta-data about the file is being requested by
> a control-point.

1. You'll have this issue no matter which multimedia framework you use
or even you don't use any.

2. That is why almost every MediaServer implementation caches the
metadata in a DB and this is what Rygel's media-export backend does.

>> > Can't we just add the necessary APIs to gupnp-av that allows to hook
>> > in custom DLNA profile detection?
>>
>> We certainly could & any ideas in that regard are welcome. Having said
>> that, keep in mind that we won't have time to implement your ideas
>> anytime soon (lots of things to do & many deadlines coming) &
>> gstreamer dependency isn't an issue for us.
>
> Well, if you could send your patches for review, that would make it
> easier for me to suggest changes.

I already pointed to the gitorious gupnp-av repo/branch where Arun
is keeping his changes currently in my first email and these patches
will be in gupnp-av git master soon enough.

--
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
_______________________________________________
___________________________________________________

Posted on the Rygel-list mailing list. Go to http://mail.gnome.org/mailman/listinfo/rygel-list to subscribe.

> So the question here is where to draw the line for gupnp-av. Currently
> it is a helper library for writing and parsing DIDL-Lite fragments. That
> makes it useful for many applications and as such ensures that many
> applications will provide proper DIDL-Lite and that many applications
> can share the parser code.
>

I would like to propose, following this line of thought, that the current gupnpav become gupnp-didl and the new mediaserver specifics become gupnpav. I think this is a reasonable solution

> On Mon, 2010-06-14 at 16:04 +0300, Zeeshan Ali (Khattak) wrote:
>
>>    Instead of dwelling in arguments, please feel free to provide
>> patches that makes gstreamer an optional dep but do provide at least
>> one non-gstreamer implementation for the same APIs.
>
> Wait, this is not something that can be solved by patches. This is a
> design decision in the first place, not an implementation detail that
> can be fixed later.
>
> So the question here is where to draw the line for gupnp-av. Currently
> it is a helper library for writing and parsing DIDL-Lite fragments. That
> makes it useful for many applications and as such ensures that many
> applications will provide proper DIDL-Lite and that many applications
> can share the parser code.
>
> Now you are pulling functionality into gupnp-av that does IMO belong
> into the actual media-server implementation.

The fact of the matter is that the main functionality is DLNA
profile detection and that was in gupnp-av for quite some time now and
it was you[1] who asked for a more complete/better implementation of
it.

What really is getting added is a full-fledge metadata extractor
(most of which is implemented outside gupnp-av though) so what we
could do is to not add that part to gupnp-av but Rygel. gupnp-av will
then only provide APIs to get the DLNA profile given a
GstEncodingProfile and viceversa. However, this will not change
anything wrt to dependencies.

--
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] http://bugzilla.openedhand.com/show_bug.cgi?id=1564
_______________________________________________
___________________________________________________

Posted on the Rygel-list mailing list. Go to http://mail.gnome.org/mailman/listinfo/rygel-list to subscribe.