Original commit message from CVS:
A very small change to make eos somewhat work. no inner bins are checked.
When an element fires EOS, the chain with that element is removed from
the scheduler (marked inactive). If all chains are inactive, the bin
fires EOS.
Original commit message from CVS:
Major cleanup of the latest ghostpad changes. Fixed everything that
broke, correctly. Someone will want to go update the API doc templates.
Original commit message from CVS:
ALPHA COTHREADS WORK! Worked around a nasty stack issue that probably
can't be solved anyway. Tomorrow the UDB build will commence, and let the
best guess win!
Original commit message from CVS:
First pass at updating to new ghostpad system. The objects are in place,
I now need to go and get all the Bin end of things worked out. Testing
should be fairly easy, at least for verification.
Everything I've tried so far works with no changes, with is amazing.
That's just cool. Once again we rewrite an entire subsystem, and nothing
else notices anything but the new features ;-)
Original commit message from CVS:
Wrote a little more text, and did more of the work on making the sections.
When this manual has text in all these sections its going to be pretty
impressive...
Original commit message from CVS:
Added mthodes to request an element to create pads: gst_element_request_pad*
This can be used to construct a tee and a muxer/mixer/aggregator element.
Moved the tee element to elements/ because it can now be handled with the
new pad request features.
The padfactory also has some changes: a pad can now be of presence REQUEST,
which means that the pad can be requested from this plugin (doh).
Original commit message from CVS:
Some more fixes for libxml.
Also, some code formatting changes in esdsink, some further fixes to
vumeter, and some work on synaesthesia to make it closer to working
(it doesn't fully work yet, though. :( )
Original commit message from CVS:
Updates to cothreads code, including non-working alpha. Changed things a
bit, including PPC. Not having a PPC machine, I need someone to test
these changes and report back whether they worked or not.
Original commit message from CVS:
Fix permissions problems: the directory will now always be created mode
2755. In addition, the temporary file is given restricted permissions, and
the permissions on the registry file are preserved if one already exists,
or 666 (and modified by the umask) if one doesn't already exist.
Original commit message from CVS:
Fix build problem when don't have db2html, or a directory to put the manual in:
was trying to make a symlink in the non-existant directory, and causing the
build to stop.
Original commit message from CVS:
Adding nasty hack to rules to generate cothreads.{o,lo}, to get dependencies
right. Rules copied from automake, and therefore a bit dependent on automake
keeping doing dependency things the same kind of way, but it should work as
long as automake puts dependencies into .deps/*.P
Original commit message from CVS:
Massive build fixup. Will send message to -devel list later with details
on the changes and what they mean for Makefile.am writers. Check
docs/random/omega/build/TODO for a list of things that I had to make sure
of.
NOTE: this requires a complete rebuild of all plugins, since I also
changed the STATE enum to a bitfield instead of sequential numbers.
Original commit message from CVS:
Added an extra signal_cond to queue to make sure that the waiting thread
is woken up. Can somebody with queue problems verifify that this does
improve the situation a bit. I'm suspecting that something else is going
on, like a pthreads bug or something.
Small updates to the fake elements.
Original commit message from CVS:
Antoher way of dealing with EOS. This proposal does not use the recursion
to propagate the EOS signal. This implies that an element cannot deny an
EOS signal anymore but since the signal is generated when a NULL buffer is
pushed, somebody did something wrong anyway.
Original commit message from CVS:
While typing on eos2 about the EOS handling, I got an idea and started
eos3. eos3 takes a different approach by merging the eos detection and
the scheduling in a quite elegant way. I'm not sure we handle the
scheduling like this though...
