The work I have done this summer boils down to three things:
- A new GStreamer plugin called "gsttranscodebin", which takes a single profile argument and transcodes it's sink pad to conform to the profile and outputs it on it's source pad. This is available at https://github.com/kmeisthax/gst-transcode.
- Patches to Rygel to use gsttranscodebin to encode things. They are available here: https://github.com/kmeisthax/rygel/tree/gsoc2011-gsttranscodebin. It's the "gsoc2011-gsttranscodebin" branch.
- Patches to Rygel to use GUPnP-DLNA to retrieve encoding profiles, obsoleting the current fixed-transcoder classes. They are available here: https://github.com/kmeisthax/rygel/tree/gsoc2011-gupnpdlna-integration. It's the "gsoc2011-gupnpdlna-integration" branch.
I split the Rygel work into two pieces - one involving GUPnP-DLNA and one involving GstTranscodeBin. Since I inevitably need to get GstTranscodeBin into Gstreamer eventually, I need to get in touch with some of the Gstreamer maintainers, including Edward Hervey (creator of decodebin2/encodebin, recommended to me by Zeeshan) - I want to know what they think of the element and if it can be added to Gstreamer eventually.
Asfor the GUPnP-DLNA work, it's mostly done, but there's kind of an issue - now that we have many more encoding profiles you'll also need many more encoder plugins installed, since we don't yet check if we can actually encode a particular profile. I believe the original fixed-transcoders had the same issue, but I've kind of exacerbated the problem. Additionally, MP3 encoding using the GUPnP-DLNA profile breaks the existing transcoding logic as well as GstTranscodeBin (since it's based on the existing transcoding logic). I'm not yet sure if this is an issue with the profiles I get from GUPnP, or how the transcode logic works. I'm going to post this to the appropriate mailing lists later in the week, hopefully when I have that last issue worked out.
