Original commit message from CVS:
fix funny build issue by not linking plugin libraries to gstreamer core. this is
because they are plugins, not shared libraries per se, and will only be loaded by
the core itself. this change allows the core elements (schedulers, autopluggers, etc)
to use the core loadable libraries (bytestream, getbits, etc) as well as "ext" libs
like the new cothreads package.
Original commit message from CVS:
I don't think we wanted to change the include dir to gstreamer as well.
If we did, then we need major code cleanups all over so let's hold off for
a second.
Original commit message from CVS:
this is a really evil hack.
I would like for someone to help wingo and me fixing it properly ;)
and for that I could use a little basic education on some of the LD FLAGS
we need all over because trying to fix it properly got me confused.
Original commit message from CVS:
major rewrite of the spider.
Now uses GstSpiderConnection to track current connections and remember the way they're plugged.
Advantages of this approach:
- function prototypes are now much cleaner.
- Allow event propagation (EOS) to elements that are not connected but plugged.
- Allow deconstruction of plugged pipes. (not implemented)
Disadvantage:
- I screwed up naming (always get src and sink the wrong way). It's very inconsistent in the gstspider.[ch] files
- a little more time and memory are needed to manage the structs
Original commit message from CVS:
* removed cothread-specific code from gstinfo.c because the new cothreads has no cothread_self()
* added a new scheduler, untested but it does compile :-)
* cothreads links to the scheduler, not core now
* no installation of cothreads headers
Original commit message from CVS:
This patch (nearly) completes the removal of vertical events from the
core.
What it does:
- removal of the EVENT signal of GstElement (to be replaced by
g_object_notify)
- changing of the ERROR signal to allow recursive notification (like
deep_notify)
- implementing recursive notification with error events.
- removal of some functions in gstbin.c that are not used anymore.
- The function gst_element_info and gst_element_send_event now do
nothing but printing a warning, that these functions are gone. This is
done to allow plugins to catch up.
- Some bugfixes in XML saving are included, they simply were in the
file.
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:
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>
