Original commit message from CVS:
bugfixing: always use the right GType when using g_object_get/set; do not free strings from g_object_get, they're not yours (see docs/design/part-standards.txt)
Original commit message from CVS:
initial checkin for the deep_notify signal which replaces INFO events in the long run.
PLEASE do not use gst_element_[info,message,error] anymore. Use g_object_notify instead.
Thank you.
Original commit message from CVS:
this fix makes sure that we actually request a pad from the template with
an unused name
this isn't optimal but gets the job done
should we move this code fragment to it's own helper function to use
everywhere stuff is requested according to a template ?
Original commit message from CVS:
- use autoplugging instead of predefined way on sometimes pads
- exchange plugtype with factories in the spider
- revamp the spider, now messier than before...
- bugfixing
- style corrections
Original commit message from CVS:
Revert aclocal invocation to do cat m4/*.m4 > acinclude.m4 beforehand,
rather than adding m4/ to aclocal search path. Shouldn't cause errors when
macros are already present on system, because macros in acinclude.m4 are
used in preference.
Original commit message from CVS:
Added a first stab at a better clocking system.
It still needs more infrastructure for async notification and custom clock
implementors.
This thing can still deadlock the pipeline.
Original commit message from CVS:
some compile fixes, api changes, and i added the ability to create new chunks on the
stack, which can extend the main thread's stack up to 8M under linuxthreads. thanks
to billh for the {set,get}rlimit tip.
on the other hand, there's a nasty bug in cothreads when they are run without gthreads
that i'm still tracking down. that's the last bug though, at this point.
the commit is to syn the repository with my working copy before moving cothreads to a
separate module.
Original commit message from CVS:
Change soversion back to 0:0:0 and add use of -release flag for libtool.
This means that any program linking against libgst will automatically have
the specific release of libgst encoded into it. This enforces the fact
that (for the moment), the API/ABI is changing rapidly enough that you
can't link against 0.3.2 originally and have it still work with 0.3.3. It
might be possible, but highly unlikely.
When we get closer to a stable API/ABI, in the 0.5.0 timeframe most likely,
we will start using soversions as recommended in the libtool docs. Then
we have to pay more attention to forward and backwards compatiblity, or
rather, we have to *start* paying attention <g>
