Re: [Rhythmbox-devel] DACP (iTunes remote) support added

>> Actually, I forgot I found a better solution ;) libdmapsharing uses
>> gdk-pixbuf if present, while getting only a filename from Rhythmbox,
>> it loads the image, resize and convert to PNG (take a look
>> at dacp_share_ctrl_int in dacp-share.c). I think it's still a better
>> solution then including it directly in the API, because it's easier
>> to port to other platforms and still keep the dependencies low.

> What about when the cover art isn't held as a simple image file
> on disc? I'm thinking of embedded covers in the ID3 tags of an
> mp3 file or similar.
> However, if the cover art is an image file on disc (JPG, PNG,
> etc) then RB can just give the filename to libdmapsharing and
> it will shrink it (if needed) and turn it into PNG (if needed).
> I've tried this by making rb_dacp_player_now_playing_artwork
> return different hard coded filenames, and it works :)
> I haven't quite managed to get the the entry metadata
> but this should be enough to support the DCAP request
> /ctrl-int/1/nowplayingartwork.

Please review the previous conversation between Alexandre and I.  You may
find most of it at:

Search for pixbuf throughout the bug entry.

We decided on the compromise that gdk-pixbuf would be an optional
dependency for libdmapsharing. Everything needs to work without
gdk-pixbuf, with the exception of things like scaling and converting
images (everything can work without gdk-pixbuf, as long as additional
constraints are placed on how the images are stored, i.e., small and in
PNG). This is similar to how libdmapsharing uses GStreamer. Everything
works without it, except transcoding. As long as media is stored in a
format supported by the clients, nothing is lost. I would like things
to continue in this manner for the reasons noted previously.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]