> On 28 May 2021, at 10:27, Samuel Gaist <samuel.ga...@idiap.ch> wrote: > > >> On 28 May 2021, at 10:09, Lars Knoll <lars.kn...@qt.io> wrote: >> >>> On 28 May 2021, at 09:15, Alberto Mardegan <ma...@users.sourceforge.net> >>> wrote: >>> >>> Hi Lars, >>> >>> On 26/05/21 15:09, Lars Knoll wrote: >>>> The hope is that we can change that for Qt 6. To make this possible, we >>>> have changed not only parts of the public API, but completely redone its >>>> internal architecture, especially how multimedia connects to the platform >>>> specific backends. Apart from cleaning up the backend API and greatly >>>> simplifying it, I also chose to make it private and remove the plugin >>>> architecture around it. The backend is now selected at compile time, and >>>> we’re now only supporting one backend per platform. >>> >>> can you please clarify what this would mean for projects (like Ubuntu >>> Touch) which are using their own QtMultimedia plugins? >>> Supporting one plugin per platform seems reasonable, but making the >>> plugin API private and selecting the plugin at compile time probably >>> means that all multimedia backends must be made part of QtMultimedia git >>> repository, right? >> >> For the moment that is correct. The reason is that it greatly simplifies >> maintenance of the module, something we’ve been struggling with for the >> whole lifetime of Qt 5. >> >> Having a public API for the backend was one of the main problems that made >> it extremely difficult to work and maintain the module. And plugins for the >> backend didn’t make much sense once the backend API is private. >> >> A public backend API with a BC promise is simply not an option IMO, as it >> will make it significantly harder to implement new functionality for Qt MM >> in the future. >>> >>> Or is it so that the backend is selected at compile time, but it can >>> still be dynamically loaded from a separate plugin binary? >> >> No, selection is done at compile time right now. >>> >>> This has the potential to make things harder to develop, especially for >>> smaller projects like ours. I'm especially thinking of: >> >> Before we go into the topics below, can we take a step back, please? I’d >> first like to know *why* you were developing and maintaining your own >> multimedia backend. >> >> Cheers, >> Lars >> > > There might also be a need to define exactly what "multimedia backend" means > here. > > I have implemented several custom QCamera backends for hardware that were not > accessible through the system multimedia API. > > For example network cameras, AJA capture cards, BlackMagic capture cards, etc. > > Would that still be possible with the Qt 6 implementation ?
How have you implemented those? If you implemented a gstreamer element for those cameras, and gst-device-monitor lists them correctly, we’ll simply pick them up. Cheers, Lars _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
