[gst-devel] Re: [gst-cvs] gstreamer wtay

[Erik Walthinsen]

On Fri, 4 Feb 2000, Wim Taymans wrote:

> Log message:
> Fixed a nasty bug in mp3parse (partial buffer state remained)
That reminded me of something when I looked at the diff (on sourceforge,
which btw is very useful): the ref-counting setup should probably be
changed a little, so the pushing and pulling of pads (which is about to
change as well) does refcounting.  That means that we'll probably adopt
the same convention as Gtk: when you create something, reference it and
then sink it.  This removes the FLOATING flag from the object, which has
potential benefits.  On the other hand, FLOATING really doesn't have much
meaning here for buffers, so maybe doing that would just be more
complication.  Currently there's a single reference on the buffer when you
create it, and no ref/unref occurs until you're done with it, unless you
tee the thing.

> 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 :-( ).
Oooh, ouch.  What I did to test things is use the launch command:

tools/launch 60 disksrc something.m3 \| mp3parse \| mpg123 \| audiosink

The first argument, if any, is the number of seconds to sleep before
exit()ing.  The launch program is not aware of the EOS signal at all, yet.
I've got ideas as to how to handle media seek control, even over networks
and such, that the launcher will be cognizant of in order to keep things
running cleanly.

         Erik Walthinsen <omega at cse.ogi.edu> - Staff Programmer @ OGI
        Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
   Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
        __
       /  \             SEUL: Simple End-User Linux - http://www.seul.org/
      |    | M E G A           Helping Linux become THE choice
      _\  /_                          for the home or office user