[gstreamer-bugs] [Bug 617314] pbutils: Add codec-specific utility functions
bugzilla at gnome.org
Fri May 7 05:08:27 PDT 2010
GStreamer | gst-plugins-base | unspecified
--- Comment #10 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2010-05-07 12:08:23 UTC ---
> I think in the long run, we want a support lib for every format that is handled
> by more than one plugin
I am not sure we want separate mini libs for every major format, but let's
stick to the short run for this bug.
> For a codec, I'd do something like GstH264Format *gst_h264_format_new_from_data
> (GstBuffer *codec_data) and GstBuffer *gst_h264_format_to_data (GstH264Format
> *format) in addition to the caps functions.
> Then elements can use the format struct to seamlessly transform between data
> and caps and modify the format using getters and setters.
I'm not sure this is needed here, since we usually don't need to keep any of
this stuff around. Also, it's basically a parse-stuff-into-helper-structures
approach, which we tend not to do (and where we have done it in the past, we
want to change it in 0.11), and we didn't chose it on purpose for e.g. the
stuff in libgstvideo.
> The current functions to me don't look like a very good public API. They seem
> to be just a bunch of utility functions dumped into some file - I think this
> can be done better with a bit of thought.
I don't think this is bad API at all. Some more concrete suggestions /
criticisms would be nice.
> You want to have caps code that's as trivial as
> (and that code does more than ffmpegcolorspace).
As far as I can tell, there's not much overlap between your cairo stuff and the
codec stuff here. You need to handle fixation, negotiation, expansion, etc. We
need to parse and evaluate stuff here according to certain rules (e.g. to
determine the level). Completely different use cases.
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
More information about the Gstreamer-bugs