Created attachment 164659 [details] [review]
patch

If they have a replacement, shouldn't we just disable them entirely ?

No, I don't think we should disable them. We ship multiple mp3 decoders and file readers and whatnot. It's nice to be able to use other not-as-good elements to verify behavior or do tests (or to use them to work around muxers that are broken ;)).

No, it's not nice. It's misleading, people who try to use them are frustrated if stuff doesn't work or doesn't work as well as expected. It gives GStreamer a bad name, and it gives ffmpeg a bad name (even if it may just be our glue that's broken), and gstreamer-devel gets flooded with cries for help, and then people are just told "don't use these elements".

If the elements are there, there's an expectation that someone cares about them at least a little bit, which is simply not the case. I don't see the point in providing elements that we are not going to support. And if the main muxers are broken in some way, they need to get fixed anyway.

We can still make these muxers available for testing purposes by bypassing the blacklisting when some environment variable is set or something.

So +1 for these patches, and +1 for blacklisting the muxers entirely (but that doesn't have to be decided now, and it's not what the patches are about).

Just an idea I just had, sorry for being off-topic:
It might be useful to somehow print a warning (GST_WARNING() or GST_ERROR() maybe?) when someone instantiates an element with GST_RANK_NONE, kinda like tainted kernel modules. That'd allow us to still ship such elements but make it obvious to everyone that they are borked.
And I'd really like if we would continue shipping more than one version of everything, even if we'd just support one.

Btw: +1 for those patches.

(In reply to comment #5)
> Just an idea I just had, sorry for being off-topic:
> It might be useful to somehow print a warning (GST_WARNING() or GST_ERROR()
> maybe?) when someone instantiates an element with GST_RANK_NONE

You mean, like audioconvert? ;)


I'd like to see this patches committed too and maybe we can really disable all ffmpeg muxer for next release until someone fixes them.

If I were to continue hacking along these lines, I think I would add an element status enum, one of "experimental", "under development", "broken", "abandoned", "deprecated", "good", etc., covering the axes of "someone cares", "being developed", "known to be buggy".  Probably a 0.11 thing.

Another thing that I think would help outside developers is fixing the output of gst-inspect to have less useless crap (by default), and focus on things like description, rank, caps, etc.  I might take this on after the release, especially if someone wants trade ideas about it.

Committed the patches.

So we're 100% clear, there's a *very* good chance that the bad behaviour of these muxers is due to our glue code (regardless of bugs that might be present in libavformat). I haven't had time to follow all the minute changes in AVFormat behaviour over the past few months. That's why I'm against giving them a NONE rank.