New plugin for ONNXRuntime

Sat Jun 11 05:51:03 UTC 2022

To add to what Nicolas said, the "good, bad, ugly" joke has also changed
meaning over time. For instance, "bad" plugins used to mean:

> GStreamer Bad Plug-ins is a set of plug-ins that aren't up to par
compared to the rest. They might be close to being good quality, but
they're missing something - be it a good code review, some documentation, a
set of tests, a real live maintainer, or some actual wide use.

But in reality, most of the code in the -bad module is good quality since
all code merged into any gstreamer module gets code review on GitLab,
basically every plugin has documentation (at least API docs), and since
everything new goes into -bad, all new code in -bad is actively maintained.

The vast majority of the time, code that would be considered "excellent
quality" by almost anyone continues to be in -bad because:

1. The API is unstable because the underlying tech is evolving, or we are
understanding people's use-cases better. In an open-source project with
dozens or hundreds of stakeholders, it takes time to get to an
understanding of how everyone uses things.
2. No one has felt the need to move it over yet even though the code is
ready to be moved, because it requires work that has little benefit and in
fact breaks file-level git history (git blame).

There is plenty of code in -bad that has been used in production for years
at thousands of companies around the world but is still in -bad because no
one has bothered to move it. I have plenty of examples of this: webrtc,
wasapi, wasapi2, nvcodec, mediafoundation, dtls, opus, openh264, srtp,
sctp, wayland, vulkan, inter, mpegtsmux, and more.

On the flip side, there is no mechanism for moving plugins from "good" to
"bad", so there is code that is bitrotting because there isn't a maintainer
for it anymore, or the underlying APIs are deprecated (f.ex., directsound),
or the library that the plugin wraps is dead / outdated / obsolete, or
there were changes elsewhere in gstreamer that weren't incorporated into
this plugin and no one noticed.

On top of all this, some plugins are in the "-base" module, which doesn't
even fit into the "good, bad, ugly" joke. We don't even put libraries in
"good", they go from "bad" to "base". Some libraries go straight into the
core module "gstreamer" such as GstPromise if they count as "core API" that
will be used by all modules.

To summarize:

1. The naming scheme has no relation to the meanings of the words used in
the categories, and the joke anyway meant "bad as in "bad person" not "bad
quality"
2. Directory-level categorization has unwanted side-effects
3. It is difficult to gauge the "code quality" of plugins, for many
reasons, so even labels might not work
4. It was a dumb idea to call our own code "bad", even dumber to keep using
that term when it is not even useful
5. We should probably get rid of this categorization for plugins and
libraries, maybe just a "staging" area, a "deprecated" area, and a "normal"
area
6. This topic is prime bikeshedding material, so don't count on it ever
getting done
7. Deriving "security" implications from this categorization is a futile
exercise, might as well read tea-leaves

Please feel free to refer your security team to this email thread as
supporting evidence. If they have questions, it's best to ask on this same
mailing list or on our IRC / Matrix channel #gstreamer on OFTC. The
gstreamer website has outdated information regarding our security practices
too, since the website usually has outdated information (it needs a
rewrite).

Cheers,
Nirbheek

On Sat, Jun 11, 2022 at 9:30 AM Nicolas Dufresne via gstreamer-devel <
gstreamer-devel at lists.freedesktop.org> wrote:

>
>
> Le ven. 10 juin 2022, 17 h 17, pranav sharma <prsmsft at gmail.com> a écrit :
>
>> Thanks for your response. Someone on this list asked why it matters if
>> the plugin is in bad or good state. It's a matter of perception. Our
>> internal production teams have a very high bar for quality and security. No
>> plugins that are marked as "bad" will be acceptable. If Microsoft is going
>> to checkin a plugin it'll be maintained by our team as it's going to be
>> used by our internal partner teams in production; we just don't have any
>> other option.
>>
>
> Somehow though your team will have to read the documentation to translate
> this good, bad and the ugly joke into what this is really is.
>
> The bad repository is a staging area. We don't commit to a stable API
> there yet. That includes we can remove or change element properties, change
> API if we are making a library. It has nothing to do with code quality,
> code there is getting the same attention as any other code, and a security
> report there will have the same severity. Remember, we do have crucial bit
> of software that seems to stay forever in there, notably our bitstream
> parsers. Without these, you cannot do much video playback in GStreamer. It
> really hard to commit to a final and stable API for such a thing.
>
> No matter how good, great, high standard your team is, you will have to
> land your work there first. Considering the learning curve, I believe in
> order to achieve this high standard you will need reviews, comment feedback
> from experienced GStreamer developers.  Challenging your team design I the
> public space and getting feedback from third is definately the right way to
> do Open Source and grow community around your code. GStreamer maintainers
> are no robots, if you send large chunk of code at us without getting us
> involved, you may endup waiting very long before someone can do the extra
> work, and your team might have moved on when we start raising issues and
> asking for changes to allow merging your code.
>
> Regards,
> Nicolas
>
>
>
>> On Fri, Jun 10, 2022 at 8:19 AM Nicolas Dufresne <nicolas at ndufresne.ca>
>> wrote:
>>
>>> Le vendredi 10 juin 2022 à 11:52 +0100, Tim-Philipp Müller via
>>> gstreamer-devel a
>>> écrit :
>>> > There are some checklist items here
>>> >
>>> >
>>> https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gstreamer/docs/random/moving-plugins
>>> >
>>> > but it's not really a superwell defined process. The technical / code
>>> style
>>> > bits are usually easy, but then there's also a subjective "does it
>>> seem ready
>>> > and in good shape" bit to it, and a question or whether the plugin API
>>> is good
>>> > and will likely stand the test of time. Does the plugin seem actively
>>> > used/maintained? Are multiple GStreamer developers familiar with it
>>> and can
>>> > help maintain it?  Is there a group of external contributors who is
>>> actively
>>> > using and contributing or maintaining it? Are people using it
>>> successfully,
>>> > what issues, warts, problems have they run into that should perhaps be
>>> fixed
>>> > before a move, etc.
>>> >
>>> > On the upside there's probably no issue with licensing/patents here on
>>> the
>>> > plugin side.
>>>
>>>
>>> Adding my two cents, if you are to run this on Windows, you likely want
>>> to add
>>> any missing D3D11/12 support for zero-copy, and the lib for that is only
>>> available in -bad as its API is not yet considered stable. So see that
>>> as a good
>>> thing, it gives you maximum flexibility to get things working very
>>> smoothly.
>>>
>>> Nicolas
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220611/67f87ec7/attachment-0001.htm>