On 27 May 2021, at 15:25, Rodrigo Gonçalves de Oliveira
<rodrigo.gol...@gmail.com> wrote:
Also, this is how I define and change different audio devices ("gst-pipeline:
... audio_sink=\"alsasink device=%1\") on demand.
Are there plans to have an easy way to change the output audio device? Think on
an embedded system, within a media app and multiple audio devices, where the
user want to change the audio output device at any time.
Have a look at QMediaDevices that lets you discover different inputs/outputs.
You can also get notifications when a new output becomes available (eg. because
you connected a headset).
QMediaPlayer and QMediaCaptureSession have an API that let you choose the
output you want based on the available devices you can get from QMediaDevices.
Cheers,
Lars
On Thu, May 27, 2021 at 9:54 AM Samuel Gaist via Development
<development@qt-project.org<mailto:development@qt-project.org>> wrote:
> On 27 May 2021, at 14:35, Lars Knoll
> <lars.kn...@qt.io<mailto:lars.kn...@qt.io>> wrote:
>
>> On 27 May 2021, at 14:25, Eike Hein <h...@kde.org<mailto:h...@kde.org>>
>> wrote:
>>
>> May 27, 2021 8:14 AM, "Lars Knoll"
>> <lars.kn...@qt.io<mailto:lars.kn...@qt.io>> wrote:
>>> The one thing I want to avoid is what we had in Qt 5, where you could force
>>> Qt MM to use a
>>> different/custom gstreamer pipeline based on environment variables. That
>>> part made maintaining the
>>> code base extremely hard. Other than that I’m of course open for patches
>>> and improvements. If some
>>> integration points are needed, we can discuss those separately, but unless
>>> they are trivial, they
>>> will probably need to wait until after 6.2.
>>
>> Hmm - does that mean the `gst-pipeline:` URL scheme for `setMedia`/the
>> `source`
>> prop is getting dropped as well?
>
> That’s correct. It’s has honestly been a huge cludge, and something we didn’t
> have anywhere else. I’d rather see that we fix issues inside Qt MM instead of
> working around them with hacks such as this one.
>>
>> If memory serves right, this was possible accidentally at some point and then
>> was raised to the status of Official Footgun in 5.12+:
>>
>> https://doc.qt.io/qt-5/qmediaplayer.html#setMedia
>
> Footgun is probably the right name for it, and a reason I don’t want to
> continue with it for Qt 6.
>>
>> A potential troublemaker for sure, but also very powerful. With QtGStreamer
>> being deprecated (an old set of Qt bindings to GStreamer API - also something
>> at least one KDE app I'm aware of still carries an internal fork of, sadly),
>> a QtMM w/ custom pipeline support sort of the next best thing.
>
> Lets rather have a look at the use cases that people want to have supported
> and how we can get those working.
>
> Cheers,
> Lars
>
> _______________________________________________
> Development mailing list
> Development@qt-project.org<mailto:Development@qt-project.org>
> https://lists.qt-project.org/listinfo/development
I think one of the main use case I have seen for custom GStreamer pipelines is
to be able to get rtsp or other network streams in Qt applications.
Best regards
Samuel
_______________________________________________
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
https://lists.qt-project.org/listinfo/development
--
Rodrigo Oliveira
Florianópolis, Brazil
rodrigo.gol...@gmail.com<mailto:rodrigo.gol...@gmail.com>
+55 48 91605760
http://br.linkedin.com/in/rodrigogoliveira
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
