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:
some jack fixes, alsa touchups, and add rtp by default to the build
if there are any problems building rtp, we're moving it back to experimental ;)
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:
Finally we're on to a proper jack setup, with a specialized bin and elements
that can only go in a jack bin. I had to fix the parser first to do this, but
to run it, the syntax is like so:
gst-launch jackbin.( filesrc ! mad ! jacksink )
But of course it's not fully functional yet. Sigh.
Original commit message from CVS:
* add notify back to filesrc, it's needed for MVC applications
* remove notify printouts from gst-launch
* cleanup in gst-plugins configure.ac
* some jack updates
* remove SELF_ITERATING flag in favor of SEF_SCHEDULABLE (not a clear name,
but it's what we have for the moment)
* improve parsing of request pad names, no more sscanf
* fixes to the fastscheduler Makefile.am
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:
* s/gst_element_install_std_props/gst_element_class_install_std_props/ -- it just makes more sense that way
* added jack element, doesn't quite work right yet but i didn't want to lose the work -- it does build, register,
and attempt to run though
* imposed some restrictions on the naming of request pads to better allow for reverse parsing
* added '%s' to reverse parsing
* added new bin flag to indicate that it is self-iterating, and some lame code in gst-launch to test it out
* fixen on launch-gui
* added pkg-config stuff for the editor's libs
This reverts commit 9e1d419d07.
Reverting this since it adds unreviewed and bad API to v4l2src
(property of type enum, with seemingly random and unsorted values).
Improve parsing of the samplerate.
Parse the framelen so that we can calculate timestamps.
When interpollate the incomming timestamp on outgoing buffers when there are
multiple subframes.
fixes#625825
It was an arbitrary limit from the start, meant as a basic sanity check,
so may just as well increase it a little. Would be good to provide
progress reporting while completing the block in any case..
https://bugzilla.gnome.org/show_bug.cgi?id=637060
output devices should use get/set output, and in either case we should
not print a warning message if the ioctl fails but the device does not
claim to support the tuner interface
If xoverlay is available, v4l2sink should create a window for the overlay to
display in.
The window automatically tries to make itself as large as possible.
This works well on a small screen, but perhaps should first attempt to use
the size of the video that is played (no scaling).
Special case check for sub-buffers: In certain cases, places like
GstBaseTransform, which might check that the buffer is writable before copying
metadata, timestamp, and such, will find that the buffer has more than one
reference to it. In these cases, they will create a sub-buffer with an offset=0
and length equal to the original buffer size.
This could happen in two scenarios: (1) a tee in the pipeline, and (2) because
the refcnt is incremented in gst_mini_object_free() before the finalize function
is called, and decremented after it returns.. but returning this buffer to the
buffer pool in the finalize function, could wake up a thread blocked in
_buffer_alloc() which could run and get a buffer w/ refcnt==2 before the thread
originally unref'ing the buffer returns from finalize function and decrements
the refcnt back to 1!
This is related to issue #545501
The size of the buffer would be zero'd out in gst_v4l2_buffer_finalize()
after the buffer is qbuf'd or pushed onto the queue of available buffers..
leaving a race condition where the thread waiting for the buffer could awake
and set back a valid size before the finalizing thread zeros out the length.
This would result that the newly allocated buffer has length of zero.
