Original commit message from CVS:
compatibility fix for new GST_DEBUG stuff.
Includes fixes for missing includes for config.h and unistd.h
I only ensured for plugins I can build that they work, so if some of them are still broken, you gotta fix them yourselves unfortunately.
Original commit message from CVS:
Plugins cleanup:
* stereo2mono, mono2stereo, int2float, float2int: replaced by audioconvert.
* stereosplit replaced by oneton.
* vumeter replaced by level (and was broken anyway).
* avifile replaced by ffmpeg.
* mjpegtools duplicates functionality of jpeg. jpeg now works with jpeg-mmx,
too, which makes mjpegtools unneeded.
* allow for jpegmmx instead of jpeg.
* openquicktime replaced by qtdemux and ffmpeg. Broken anyway.
* XMMS is broken and will never be fixed.
* vga is broken and will not be fixed anywhere soon.
* videosink has never worked. If it works, add it back to replace xvideosink.
Original commit message from CVS:
Some final fixes for the v4lsrc elements.
* remove software sync thread (use GST_ELEMENT_THREAD_SUGGESTED instead)
* make all src elements threadsafe
* fix num_buffer argument setting in v4l2src (VIDIOC_S_PARM)
* re-add bufsize (RO) for v4lmjpegsrc
* fix the A/V sync calculation in all elements (spvf=GST_SECOND/fps, not GST_SECOND*fps)
* probably some more crap....
With all this, it actually works quite well. The TODO files describes the
next steps in order to make a full-featured video recorder based on these
elements and GStreamer (bottom). Making a simple recorder should be fairly
easy now, btw.
Original commit message from CVS:
This implements filtered-caps negotiation for all the v4l*src elements, and removes the accompanying properties since they're no longer needed
Original commit message from CVS:
another batch of connect->link fixes
please let me know about issues
and please refrain of making them yourself, so that I don't spend double
the time resolving conflicts
Original commit message from CVS:
v4l plugins:
* add open/close signals
v4l2 plugins:
* add open/close signals
* move source format enumeration from v4l2element to v4l2src
* adapt to the final v4l2 API in kernel 2.5 (patches for 2.4 on http://bytesex.org/patches)
* small tweaks
Original commit message from CVS:
This patch fixes some issues caused by design issues in video4linux, adds
some nicety to video4linux2 plugins and does some more evil stuff:
* video4linux doesn't tell us which formats are supported by a card, so
the only way to know this is by simply trying it out. This patch adds that.
* v4lmjpegsink didnt have a bufferpool yet - is integrated now.
* all copy() bufferpool functions have been removed since they're not needed.
* v4lmjpegsink doesnt have a free() function, because hen playing the frames,
all this is already handled. When the frame is not played, nothing has to
be done. In total, the function is not needed.
* adds a get_caps() function to v4l2src
* some minor crap
Original commit message from CVS:
this adds video4linux2 source and element plugins. The division in v4l2* plugins is the same as for v4l1 - i.e. an element, a src and a sink, but there won't be separate encoding plugins (like v4lmjpegsrc) - all functionality is (thanks to video4linux2) integrated in one plugin: v4l2src. v4l2sink is still to be done, that'll come later.
Original commit message from CVS:
Added *BSD (and Darwin) ioctl cdaudio playing. Couple bugfixes. 'end-track','current-track' and 'cddb-discid' properties and 'track-change' signal for the element.
Original commit message from CVS:
* a hack to work around intltool's brokenness
* a current check for mpeg2dec
* details->klass reorganizations
* an element browser that uses details->klass
* separated cdxa parse out from the avi directory
Original commit message from CVS:
* some s/KHz/Hz/ fixes in osssrc
* added dxr3 plugin from rehan khwaja <rehankhwaja@yahoo.com>, with some
consistency-with-the-rest-of-gst adjustments
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.