[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 #15 from Edward Hervey <bilboed at gmail.com> 2010-11-05 15:58:23 UTC ---
(In reply to comment #14)
> 
> 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.

  Only putting the restrictions in the format caps relies on the encoders being
able to properly convey that information upstream via get_caps and check it can
use them with set_caps. So yes... it should work, but I've seen encoders that
don't handle that. You're also relying on the encoders forwarding *all*
restriction fields (and not just the obvious width/height/framerate, but also
pixel-aspect-ratio for ex).
  To sum up : if you trust the encoders you can ignore the restriction field,
if not, you'll need to split up.

> 
> * 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.

  I tried to came up with the least intrusive way of describing encoded stream
properties and encoder settings (we want this API to be usable without
requiring as much knowledge/pain that it's barely more useful than doing
everything yourself from scratch). Yes, GstEncoder base classes would
definitely be a good way towards solving this issue.

  The least-intrusive way I found means having presets for various encoders (if
needed) where you set the various settings, save those presets, and then
specify them in the profile.
  This means writing presets, sure. But it would be a good way to have a more
extensive collection of presets for various encoders/muxers.

  The other thing that could be improved in elements, is to have more format
caps. Ex : for having a h263 profile 0 level 45 stream, have the encoders be
able to configure themselves properly if downstream caps are :
video/x-h263,profile=0,level=45. Then the only thing remaining to set would be
the tweaking of 'how' the stream is encoded.

> 
> * 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.

  I still need to finish the profile registry, but (de)serialization of
encoding profiles is already working in my profileregistry branch. This allows
you to handle your own collection of profiles without exposing them
system-wide.

  That being said... you could install them system-wide with a proper encoding
category, like "UPNP-DLNA". Maybe some other apps would benefit from having
those 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.