QMediaPlayer stream data from a self signed https server

[Vagabond]

My question is quite simple: How can I make a QMediaPlayer playback media from a self signed https server?

I am running a Python media server using Flask, which is still under construction. To provide https, I am using a self signed SSL certificate. Thus, I have to prepare my QNetworkQuery objects on the client side, before sending them out via a QNetworkAccessManager. This avoids verification errors:

QSslConfiguration ssl_conf = QSslConfiguration::defaultConfiguration();
ssl_conf.setPeerVerifyMode(QSslSocket::VerifyNone);
QNetworkRequest request;
request.setUrl(url);
request.setSslConfiguration(ssl_conf);

Now, when I am streaming media files, which are served from my Flask server via send_file(storage_path, conditional=True), I am running into an issue. Naively, I tried setting the QMediaContent url based on my ReST API endpoints:

QMediaPlayer* player;
player->setMedia(QMediaContent(QUrl("https://0.0.0.0:5000/api/sounds/<uuid>")));
player->play();

It came as no surprise that my output logged:

Error: "Secure connection setup failed."

That is because the aforementioned request preparation is missing. Then, I noticed QMediaContent also offered a constructor using a QNetworkRequest. So I combined the two snippets above into:

QNetworkRequest req;
QSslConfiguration conf = QSslConfiguration::defaultConfiguration();
conf.setPeerVerifyMode(QSslSocket::VerifyNone);
req.setUrl(QUrl("https://0.0.0.0:5000/api/sounds/<uuid>"));
req.setSslConfiguration(conf);
player_->setMedia(QMediaContent(req));

Unfortunately, the error persisted. I kind of get the feeling that the internal QMediaPlayer features set their own ssl verification levels. At least it seems like I am running out of configuration options. Is there a way to disable ssl verification for the above scenario?

Note: I was able to verify that I could playback media as expected if my server runs plain http.

Edit:

With respect to the error message up above, I have found an issue on a random github project addressing a similar problem. This is what leads me to believe, that my question is in fact related to some internal GStreamer issue, which I can't solve from within Qt. I am beginning to think this should be a Qt bug report rather than a forum question. I find the ignored ssl config on the request (see snippet above) fairly misleading, so I'd at least consider this unexpected behavior.

[SGaist]

Hi,

Is it a typo here or are you using the wrong constructor of QMediaContent in your code in your test with your custom QNetworkRequest ?

[Vagabond]

@SGaist Hi! Yes, good catch. That was a typo. Should be fixed by my last edit.

[Vagabond]

@SGaist do you have any advice towards the issue?

[SGaist]

Did you try to use something like wire shark to check the communication between your application and server ?

[Pablo J. Rogina]

@Vagabond

Could it be possible you connect QNetworkAccesManager::sslErrors() signal to some slot where you can inspect what may be going on, in particular look for QSslError::SelfSignedCertificate which you can ignore...

see snippet in QNetworkReply::ignoreSslErrors() documentation.

[Vagabond]

@Pablo-J-Rogina there is neither a QNetworkReply nor a QNetworkAccessManager involved in the QMediaPlayer related code snippet which produces the issue (see last code snippet). Thus, I am not aware of a way to test either of your suggestions. Note, I do not have troubles sending & receiving regular requests to the dev server using QNetworkAccessManager (see first code snippet). My problems originate only from using QMediaPlayer.

[Vagabond]

@SGaist not sure how that would help. Serving HTTP from my dev server works fine in QMediaPlayer and regular HTTPS requests work too, when using ssl_conf.setPeerVerifyMode(QSslSocket::VerifyNone);. Seems fairly clear to me that the ssl config isn't forwarded to the GStreamer back-end of QMediaPlayer, or something similar.

[Pablo J. Rogina]

@Vagabond maybe you need to work with the QMediaNetworkAccessControl related to your QMediaPlayer?

[Vagabond]

@Pablo-J-Rogina thanks. Just looked into it. As the docs for QNetworkConfiguration state:

QNetworkConfiguration encapsulates a single access point or service network. In most cases a single access point configuration can be mapped to one network interface.

I deduce from that, that any call to QMediaPlayer::setNetworkConfigurations(QList<QNetworkConfiguration>) will not fix my problem. In fact, I gather from the information, that QNetworkConfiguration deals more with hardware-side networking & routing configurations than it does with specifics for transmission protocols.

This notion is strengthened by the fact, that there is no accessible public members for QNetworkConfiguration and the only available constructors are copy and default. Therefore, the only way accessible way to provide valid values to setNetworkConfigurations is by filtering QNetworkConfigurationManager::allConfigurations()). Then again, this method produces a list dependent on the host system, which indicates hardware specific settings.

Still, I got curious while reading the desciption for QNetworkConfiguration::ServiceSpecificPurpose, which states:

The configuration can be used for operator specific services (e.g. receiving MMS messages or content **streaming**).

For experimental purposes I filtered all available configurations of that type, which again didn't change anything for me.

(Also, be sure to check out my latest edit up top, if you care for more info)