[gstreamer-bugs] [Bug 627476] New profile library and encoding plugin

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=627476
  GStreamer | gst-plugins-base | git

--- Comment #14 from Arun Raghavan <arun at accosted.net> 2010-10-04 19:30:42 UTC ---
We're going to be using encodebin in gupnp-dlna to help with MediaServers that
want to provide trancoding support (i.e., Rygel). Just as quick background,
the DLNA specification provides a set of "profiles" that roughly correspond to
a set of constraints on codec, profile, level, bitrate, resolution, etc. that
a given device can play, or a given file conforms to.

The idea is to have Rygel offer streams transcoded to match certain (probably
arbitrary) profiles. Our internal representation of these DLNA profiles is a
superset of GstEncodingProfiles. encodebin makes things a lot simpler for us
(the current implementation being to implement one transcoder pipeline for
each profile). API-wise, gupnp-dlna offers an API that, given a DLNA profile,
returns a GstEncodingProfile that can be used to encode a stream to that
profile. Rygel will feed this GstEncodingProfile to encodebin and we get
automagic transcoding.

Now there are some things that we need to consider:

* Format vs. raw restrictions: GstStreamEncodingProfiles have separate format
  caps (e.g. audio/mpeg, mpegversion=4) and raw caps (e.g. audio/x-raw-int,
  rate=44100, ...). As things happen just putting everything in format caps
  will (or at least should) work. I don't really want to have gupnp-dlna rely
  on this incidental behaviour though. We /could/ add some filtering code in
  gupnp-dlna to split out some standard raw caps fields, but this could be a
  problem that affects other clients, so a generic solution would be better.

* Presets and properties: This is really a larger problem, but since we also
  need to be able to control the profile and bitrate of the encoded stream, we
  need to use the GstPreset API. The main problem here is that since we don't
  know a-priori what encoder will be used for a given codec, and what
  properties that encoder will expose, we need to work around this by adding
  some sort of configuration to provide this information (something like a map
  of codec caps -> (element name, list of properties to populate,
  bitrate_is_in_bps, ...). While some of this could go away in the future with
  the addition of a GstEncoder baseclass or interface as suggested in bug
  #626550, we still need to handle these problems in gupnp-dlna till a leaner
  way to do this appears.

* Persistence: Since the constraints on a DLNA profile might be updated, we
  don't want to make our encoding profile consistent. I don't know if there
  are any other types of applications that could make use of a non-persistent
  registry, but having one would make things cleaner in a sense. gupnp-dlna
  would register a bunch of encoding profiles keyed by the DLNA profile name,
  and the app would just use that. This isn't a huge deal for us, so if there
  aren't any other apps that work like this, we're fine with having our own
  API to get encoding profiles.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.