[gst-devel] Erm, is it legal to parcipate in IRC after the fact?

[Erik Walthinsen]

On Fri, 5 Jan 2001, Paul Flood wrote:

> <richardb> Been lpaying with the editor.  Fun. :)
> <richardb> If a little buggy.  Easy to get segfaults...
> <richardb> But releasable as an alpha version. ;-)
Agreed.  With release notes <g>

> <wtay> made an mp3 player?
> <richardb> Yup.
I'm wanting to something more interesting soon, I did the "draw an mp3 
player in 15sec" back in October '99.

> <richardb> Is asyncdisksrc significantly different from disksrc.
> <wtay> asyndisksrc supports seeking
> <richardb> And why are both provided?  What's the advantage of disksrc?
> <wtay> not sure why we need both of them...
The original idea was to make sure there were elements of both types.  The
direction we seem to be moving with fakesrc/identity/fakesink is to build
them so you set some args and you can construct just about any common type
of element.  I'd favor merging disksrc and asyncdisksrc (and maybe 
renaming to 'filesrc') and making the asyncdisksrc method the default, 
with an arg to make it work like the current disksrc.

> <richardb> Couldn't the disksrc simply wait until the state is set to
>            not playing, or the file runs out, and then reread the arg?
> <richardb> Or skip to the beginning of the new file immediately.
> <wtay> I guess this could be implemented...
> <richardb> Is it generally neccessary to check args with get_arg after
>            setting them, to see if the set arg took?
The current behavior, as you guessed, requires the src to be in NULL state
before it will accept a new filename.  IMO this is the correct behavior,
but we do need some way of consistently verifying thinsg.

> <richardb> So, should set_arg always succeed, or is there a way to
>            check if it did?
> <wtay> we need to decide on a policy about changing the args while in
>            the playing state
> <richardb> Yup. :) <g>
> <wtay> either they succeed or they don't
> <richardb> It certainly needs to be allowed in some cases (eg, set offset)
> <wtay> yup, but not in others, like changing the bitrate of an mp3
>        encoder while encoding
> <richardb> So it needs to be able to return a bool to say if it succeeded...
> ...
> <wtay> no, not unless we write a gst_object_set that can return a value
> <wtay> we might actually do that for API consistency anyway...
I like this idea, since it allows us to maintain the API's consistency
(arguments and signals are the two things we still call down to gtk for,
outside of the elements themselves.

> <richardb> Okay.  The only other way to do it that I can think of is to
>            require people to check that the arg got set with get_arg.
> <richardb> Which is a bit nasty, but would work.
> <wtay> yeah, that seems reasonable
Of course, it is pretty messy.  Another option would be to fire a generic
GstObject signal "arg_set_failed" with the argument name and possibly the
attempted value.  This has the problem of being async to the application,
and requires lots of checking and validation of the value's type, etc.

> <wtay> I'm working on the manual some more.
> <richardb> I saw those changes you'd done.  Will hopefully have time
>            to go and write some of the fwg sometime this weekend.
Cool.  I've got some changes I should send you via email tonight, rather
than check them in.  Sent.

> <wtay> I you have time, do try to read it, I'm just knocking out these
>        chapters. My grammar sucks a bit too.
Every one of us should review all the documentation for correctness,
spelling, and grammer before it's considered done.  Of course, the
author(s) have to consider it reasonably done before it makes sense to
review....

> <richardb> How expensive is a signal if noone catches it?
> <wtay> I think it's done with a list of pointers and so it probably is
>        very non-expensive
It's possible to make signal throwing with zero listeners very fast, but I
have no idea how gtk does it now.  Basically, if the list is null, skip
it.  Do it in a macro to make it inline/fast.  No idea what GObject does.

> <richardb> But the disksrc presumably advances in large chunks...
> <richardb> Or we could have a signal for "arg has changed", but define
>            that this doesn't have to be thrown _every_ time, just
>            "often".
Defining "often" is hard, but I suppose if we have a guideline that
anything that can be fired "too often" should be dealt with lazily, for
some definition of lazy.  Ideally there'd be a way we could set properties
on signals and arguments, so this can be figured out at runtime.  As it
is, you can't attach any data to a signal or argument at all, so we have
no way of describing things.

> <richardb> How would we add autoplugging to the editor?  Have a
>            special button to click to autoplug the things in a pipeline?

> <wtay> autoplugging currently returns a list of elementfactories
>        between two GstCaps structures or two GstPads
> <wtay> I would like it to return a GstElement instead
> <richardb> Only _one_ element?
> <wtay> the GstElement could be a bin with threads and such
> <wtay> to the app programmer it would appear to be one element
Hrm.  Not sure I like this idea too much, since it hides the pipeline from
the app more than may be good.  I guess the question I have (not having
read the autoplugging code, something I wish to do in depth post 0.1.0) is
what happens to state during autoplug.  Does the pipeline actually start
up into PLAYING state, at least partially, as is required in order to pass
data from the src?  That's potentially the most complex case for state
management, so that's something to keep in mind when changing things.  And
I guess that question had nothing to do with the single-element 
question.  Nevermind <g>

> <richardb> What if you could make a special "autoplug" element which
>            you put into your pipeline, and then call a method on which
>            causes it to return a suitable element for connecting.
One thought I had was that autoplug would work like the scaffolding on a
bridge during construction.  Install scaffold, pour concrete, remove
scaffold and re-assemble it on the 'new' end of the bridge.  Repeat.
Something like that could be used for the autoplug element, which
internally would deal with caching buffers sent to typefind and such,
while constantly re-building the contents of its own parent.

> <richardb> THen the autoplug element would be put there explicitly in
> the editor, and would simply remain a magic black box which connects
> the two things.
That would defeat the purpose of several things, such as XML saving,
unless the autoplug 'element' is simply an uber-smart Bin.  That's
definitely an option, instead of the above idea of the autoplug element
wiring up stuff inside it's parent, it *is* the parent being
rewired.  It could even utilize a function we need to write that would
replace any Bin with any other type Bin, in place (so you could replace
the GstAutoplug with a GstBin, or it could replace itself).

> <wtay> I would like to be able to look into the black box though
Exactly <g>

> <wtay> a pipeline has a method to add one src element and multiple
> sink elements
Hrm?  I guess I need to read gstpipeline.c again, checking.  Ah, I
see.  That could be implemented as simply attaching a pad to the above
GstAutoplug and setting the Autoplug to the right state.

That brings up a nasty problem: in order for the GstAutoplug to get to
READY state, it has to build a pipeline.  In order to build a pipeline,
most times you have to put the disksrc in PLAYING.  Grr.  More rethinking
of the state management still needed.

> <wtay> another neat thing would be to right click on a pad and it
>        shows the elements that can connect to that pad
> <richardb> Yes, I was thinking that too.
> <wtay> with a tendency to move to a video/audio sink
> <wtay> right click on an element, shows a menu option to start
>        typefind
That'd be very nice, yes.

> <wtay> we need to cut down the time to create an mp3 player down to
>        seconds :-)
> <richardb> :)
I demo'd it in 15sec, if we can cut that to 5 I'd be very happy <g>

> <wtay> by the time Erik gets his hands on the editor, you'll see a
>        complete audio mixer in the editor :-)
> <richardb> Well, it clearly has the potential...
Working on it... ;-)

> <richardb> Going to bed soon...
> <wtay> me too
> <richardb> Right, time to go.  Byee.
Me too, maybe I'll be up early enough so we can talk for more than a
couple hours.

         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