Created attachment 17855 [details] [review]
flacdec patch

if (!GST_PAD_IS_USABLE) gst_element_error(); or so?

We could do this for every plugin, and I don't really want to check
for this in every plugin. Any unconnected pad means a broken pipeline
anyway, the application should check for that.

I mean, what's the use of an unconnected pad in this case? The
pipeline still won't do a thing. So?...

GST_PAD_IS_USABLE() is only useful for multi-pad elements such as
avidemux, mpegdemux etc.

this was discussed a long time ago, check mad and vorbisfile.

The point is that not connecting the src pad allows you to do very
fast querying of media properties, without actually decoding to the
raw format.

So, yes, this is a very useful feature that we want to keep, makes a
lot of sense, and no, it isn't a gst_element_error at all, in fact all
other plugins need to be fixed in similar ways.

I missed the whole discussion then... Use fakesink.

no, you really did miss the discussion :)

It's already decided that it should work with the decoder not
connected,  this patch is a matter of implementing that for flacdec,
just as it has been implemented for mad and vorbisfile.

It's pretty simple; fakesink would still be decoding the input stream
to raw audio, while an unconnected decoder doesn't decode (or tries to
avoid it as much as possible).

So, no, no fakesink.

I don't like this... Ohwell, if you want to do this work, go ahead.

I rest my point that it's just plain ugly.

huh ? what the hell is ugly about it ? it's incredibly clean instead
of ugly.  You don't connect the decoder's src pad if you have no
intent of using the decoded data, period.

How else are you supposed to query 1000+ songs for properties quickly ?

I think you're just having a problem with this because you haven't
thought about the problem and the reason at hand.

The ugly thing is that we have to do a if (GST_PAD_IS_USABLE(pad)) in
100+ of plugins if we want to do this completely. That's insane,
nothing less. If we intend to support these kind of features, then
make a proper solution for this in the core so that we don't have to
bloat each single plugin with the same code.

That's mho. ;).

No, if we want to support it cleanly, we will implement the _USABLE 
check in gst_pad_push.

It is a thing of defining if pads may be left unconnected and which 
ones. I personally think it is ok to have unconnected source pads 
(the example being demuxers when you only want audio - like Marlin 
opening an AVI) and unconnected sink pads (example being an adder 
where some pads are lying around) - though someone needs to define 
what gst_pad_pull does in that case.


However it is _NOT_ ok (and I have a very strong opinion here) to 
rely on a decoder mutating to a metadata-getter when you don't 
connect the source pad(s). Plugins do _one_ clearly defined job and 
do that one only.
If you want a FLAC metadata extraction plugin, write one. That should 
be reasonably easy and would offer the great benefit of having the 
possibility of implementing a subclass that does metadata editing.

btw: both mad and vorbisfile decode the data but discard it when they 
are unconnected if I'm not mistaken.

I'm closing this, since the current behavior seems acceptable, and
it's too late to change for 0.8.  If it's really a problem, it will
come up again.

The current behavior is "drop buffers pushed to unlinked pads".  Note
that there is a small problem with this -- unlinked pads are not
negotiated.