Original commit message from CVS:
Speedup in mpg123 parsing. speedup in mp1videoparse. rearanged the
MPEG player got rid of some memcpy. bit handling changes.
MMX code for the IDCT and motion compensation in mpeg_play.
Almost as fast as the commercial mpeg player mtv, but with a much
better video quality :-)
Original commit message from CVS:
The first functional video sink... Removed all of the video stuff
from the MPEG video decoder. Fixed a bug in smoothwave.
The MPEG video decoder still does the YUV->RGB conversion.
Original commit message from CVS:
Made queue default bigger.
fixed parsing errors in mp3parse mpeg1parse mp1videoparse: more than 2
zeros and a 1 is also a sync.
fixed MPEG1 video SKIP_PICTURE which caused a segfault. AlienSong now
plays as it should do. Skips are currently ignored and give some error
on the console, need to clean this up.
Original commit message from CVS:
Fixed the queue length (fixed length 5 for now).
fixed mpeg1 video rate control.
AlienSong segfaults sometimes. My other movies don't....
Original commit message from CVS:
Rearranged and updated mp1parse. Indentation is sane again (what editor
are you using, Wim?), and it now uses threads. Playback is clean (at
least, audio and video are running smoothly. Video is still a little
choppy on my test stream (first 1MB from disk two of Mulan VCD), and it's
still wildly out of sync, but it's looking VERY COOL.
Original commit message from CVS:
Changed the way state is dealt with when a child is added to the bin. The
note states that the COMPLETE state should probably reflect nothing more
than whether or not there is a child in the bin, not whether or not all
children are COMPLETE. I need to write out a few scenarios for complex
pipeline manipulations to figure out how all the states should interact.
The idea is to maintain the ability to dynamically recofigure the
pipeline.
Original commit message from CVS:
The first functional video MPEG1 decoder. The decoder still opens a window
to show the video. This is not optimised at all. Some glitches and
crashes due to bugs in mp1videoparse.c. I need to queue incomplete
slices in mp1videoparse before sending them to the decoder.
use test/mp1parse on your favorite video to test. No audio/video sync,
no QoS at all.
Original commit message from CVS:
Added compiler optimistaion flags to mpg123. reverted to old WRITE_SAMPLE
which was much faster.
Added mpeg_play, the MPEG1 video player. It does not work yet.
Original commit message from CVS:
Fixed the mpeg 1 parser. It can now be used to playback the audio stream
of an MPEG1 movie (check out test/mp1parse.c).
Original commit message from CVS:
Fixed a nasty bug in mp3parse (partial buffer state remained)
Added eos check for the test programs to stop them from allocating all
of your memory (had to use alt-sysreq-k a few times :-( ).
MPEG layer 1 plays fine now with mp3play.
Original commit message from CVS:
Compile a test program to ensure that we have working atomic resource
counting.
A few small changes (include headers, fix a cast) to stop compiler
warnings.
Original commit message from CVS:
Fixed lowercase PLUGINS_USE_SRCDIR which made running test apps fail.
Added GHTTP_LIBS to the libraries.
commented out mm_support() call, wich is not working yet and causes errors.
Original commit message from CVS:
Try to compile a little mmx program, set the default value of HAVE_LIBMMX.
some typos fixed. Changed include path for volume.c. RTjpeg uses mmx.h
Original commit message from CVS:
Re- set up the gtk-doc system. I'd managed to mutilate it a while back,
but now it's fixed. I'll put a copy of the HTML output somewhere on the
website tonight.
In order to actually generate the docs, you'll have to install all the
DocBook tools, as well as gtk-doc from GNOME cvs. (see
http://developer.gnome.org/arch/doc/tools.html)
Notes (I'll codify these some day):
- Don't believe the Gnome page, always edit the SOURCES when documenting a
given function, never the tmpl file.
- I'll be re-arranging things a lot, but gtk-doc is smart enough to merge
any changes to the tmpl file. However, gtk-doc's merge and CVS's diff are
two entirely separate animals. We should probably have a virtual mutex on
the entire docs/gst/ directory, over and above what CVS does.
- I'm going to try to end up with a book set (docbook terms), where
docs/gst/ is only one book. There'd be another called docs/manual/, and
another docs/plugins/, etc. If you have any comments as to how these
should be done, gstreamer-devel is the place.
Original commit message from CVS:
Tidy up of configure script.
Make libghttp detection work at all.
Make library configuration specifiable on configure commandline.
Make detection of atomic resource stuff cope with 2.0 linux kernels.
Fix typo (HAVE_ATOMIC_T for HAVE_ATOMIC_H).
Remove generated ltmain.sh file from mp3decode.
Original commit message from CVS:
More incremental updates. I can now successfully produce an rpm simply by
typing `./autogen.sh;make rpm`. This is good ;-)
Original commit message from CVS:
A bunch more changes to clean up build/`make dist` issues, as well as a
spec file, -config file, .m4, etc. Next step is to build an RPM of this
mess.
Original commit message from CVS:
OK, I think I've got all the .cvsignore stuff taken care of, though we'll
want to fine-tune things as we go, of course. Most of them are the same,
with some exceptions for directories that produce executables (those are
listed by name after the standard ones and a newline for separation).
Original commit message from CVS:
- added usage info
- uses first arg as registry filename
- any additional args are plugins to search for (no change but argv base)
- cleaned up output with a spare \n
Original commit message from CVS:
RTjpeg plugin with several elements. It's currently a skeleton, doing no
work at all. Need to have a video display element, some kind of
simulation source (read from .ppm, a la what I do at work to solve the
exact same problem), raw video types, metadata structs, etc.
The RTjpeg.[ch] code is taken from a just-downloaded copy from Justin's
site, with some fixes (#include <asm/types.h> to get __u64,etc). Once the
aforementioned infrastructure is in place, the elements can actually be
set up to do the encode/decode, and we'll have our first functioning video
codec in place. ;-)
Original commit message from CVS:
Changed Makefiles to:
detect xaudio (check header xaudio/decoder.h)
detect mmx.h
detect CSS (check if css.c is in plugins/dvdsrc), need something better.
some LDFLAGS had *.la dependencies which failed for libtool
The build is now 100% on my system.
