It's useful enough already to be used in other elements for audio aggregation,
let's give people the opportunity to use it and give it some API testing.
https://bugzilla.gnome.org/show_bug.cgi?id=760733
Original commit message from CVS:
* gst-libs/gst/audio/.cvsignore:
Ignore generated file.
* gst-libs/gst/audio/Makefile.am:
Do not install example filter.
Original commit message from CVS:
* gst-libs/gst/audio/Makefile.am:
Add gstaudiofiltertemplate.c and building of gstaudiofilterexample.c
from the template.
* gst-libs/gst/audio/gstaudiofilter.c:
* gst-libs/gst/audio/gstaudiofilter.h:
Add bytes_per_sample and size and n_samples calculation.
* gst-libs/gst/audio/gstaudiofilterexample.c:
Remove, now autogenerated.
* gst-libs/gst/audio/gstaudiofiltertemplate.c:
Moved from gstaudiofilterexample, object name changed, code added
so that it actually works.
* gst-libs/gst/audio/make_filter:
Script to build an audiofilter subclass from the template.
* gst/colorspace/Makefile.am:
* gst/colorspace/yuv2yuv.c:
Remove file, since it's GPL, and we don't use it.
Original commit message from CVS:
* actually recurse into sndfile if we are able
* big ladspa cleanups, mainly to comply with the buffer-frames caps property, but also general
cleanups
- the samplerate prop is gone, if you want to set it explicitly (as in for get-based plugins)
you need to use a filtered connection, just like with buffer-frames
* big float2int and int2float changes for buffer-frames compatibility - I think it's quite a bit
simpler
* make the ossclock general, add it to gstaudio, and use it in sndfile as well
i need to update mimetypes, but that's coming soon. there are some other plugins that don't
support buffer-frames, i guess i need to get around to fixing them as well.
Original commit message from CVS:
Updated autogen.sh/configure.ac and various Makefiles to make the
configure script set up all gcc specific compiler arguments, rather
than hardcoding them in the Makefile.am files
Original commit message from CVS:
* removal of //-style comments
* don't link plugins to core libs -- the versioning is done internally to the plugins with the plugin_info struct,
and symbol resolution is lazy, so we can always know if a plugin can be loaded by the plugin_info data. in theory.
Original commit message from CVS:
s/@GST_PLUGIN_LDFLAGS@/$(GST_PLUGIN_LDFLAGS)/
@-substitued variables variables are defined as make variables automagically,
and this gives the user the freedom to say make GST_PLUGIN_LDFLAGS=-myflag
Original commit message from CVS:
moving and renaming
we put the libs in the source in gst-libs/gst/(dir)
the headers get installed in prefix/include/gst/(dir)
the libs are installed in prefix/lib/gst
with a libgst prefix
the sources should be without the gst prefix
as per irc agreement
please comment if this sounds like a bad idea ;)
