GNOME Bugzilla – Bug 679521
Make Totem an UPnP/DLNA renderer
Last modified: 2018-05-24 10:41:42 UTC
Attached is my patch for turning Totem into an UPnP renderer, originating in my blog post http://jensge.org/2012/07/rygel-split-up/. This is of course not a complete implementation with regard to totem and - as noted before - has some problems: - It's too low-level in Totem (directly attaching to the playbin) - It's always on - It has network interfaces hard-coded Some of these issues are due to the proof-of-concept nature of the code, some are a bit harder to solve: An UPnP renderer implementation that wishes to be compatible with real DLNA servers needs to have some kind of access to the HTTP headers the playbin sends out to the server. Likewise it has to have some kind of means to report other capabilities of the source to the playbin, e.g. whether or not it's possible to do HTTP range request.
Created attachment 218187 [details] [review] backend: Use librygel-renderer for UPnP
Could you explain what would be difficult/impossible to do if you were to make this into a Totem plugin? I played with the AirPlay plugin this afternoon as an exercise (we'd want solutions to fit both technologies), and the main one was the playlist handling (needing to have an item in the playlist to open/play something). I believe that we can fix that.
The only issue I currently see is to either inhibit seeking or to force souphttpsrc to use DLNA's time-seeking headers, apart from the playlist thing. I've yet to convert this into a proper plug-in to get a complete impression of what's missing.
(In reply to comment #3) > The only issue I currently see is to either inhibit seeking or to force > souphttpsrc to use DLNA's time-seeking headers, apart from the playlist thing. Could souphttpsrc detect that it needs to use DLNA time-seeking headers? And if it can't detect it, could this be a boolean property on souphttpsrc anyway, something we could expose to the UPnP renderer plugin for example. > I've yet to convert this into a proper plug-in to get a complete impression of > what's missing.
Comment on attachment 218187 [details] [review] backend: Use librygel-renderer for UPnP Marking the patch as rejected, as that's not the implementation we want.
(In reply to comment #4) > Could souphttpsrc detect that it needs to use DLNA time-seeking headers? And if > it can't detect it, could this be a boolean property on souphttpsrc anyway, > something we could expose to the UPnP renderer plugin for example. It could but it would need to do (a) HEAD request(s) and gain quite a lot of knowledge about all those flags or link to gupnp-av and basically duplicating the work that the UPnP part of the renderer has to do anyway.
I'll wait until you've had a chance to give a better try at making a plugin. Feel free to add the necessary signals or accessors to the backend video widget, and we'll see whether we can trim them a bit more anyway :)
I'm sorry, I was kind of swamped, I'll look into providing a better way to do this soon.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/totem/issues/58.