I had to resort to the help of TagLibs library. And since the documentation available how to build this library to make it interact with Qt are very confusing and outdated, I proceeded to make available the library that I managed, with great difficulty, to compile by my hand:
thank you for the tip, I will try this in another project since I currently have a lot of problems getting qmediaplayer or qcamera working on the RaspberryPi. I wrote my code on amd64 on which everything worked fine but on the actual device (RPi) a LOT of problems came in (qt-gstreamer-v4l2-bcm2835-v4l2,MMAL, w.t.h.) but thats worth another thread.
I'm not sure what happened with the code, but now it's finally giving me an error signal. The error and error string are QMediaPlayer::FormatError "Failed to load media"
The media I'm attempting to load uses the file ending ".mp4". I finally thought of opening the media in Quicktime and, lo and behold, it won't open the file. It appears I'm dealing with a "Not a real operating system" error.
EDIT: It appears that what happened was that I was trying to open a 0 byte file. Opening an .mp4 file with actual content still causes the MediaPlayer to get stuck in the LoadingMedia status.
hi and welcome
Maybe you can try with "Media Player Example" to see if it will load and play file. ?
Its available directly in creator under the examples tab. just type video in search.
It might be it dont like the format.
I just created an empty project to test some stuff. The following code
QAudioDeviceInfo info = QAudioDeviceInfo::defaultInputDevice();
// Empty string as output
qDebug() << "Default input device" << info.deviceName();
// 0 as output
qDebug() << QAudioDeviceInfo::availableDevices(QAudio::AudioInput).size();
// 0 as output
qDebug() << QAudioDeviceInfo::availableDevices(QAudio::AudioOutput).size();
prints an empty string as input device, 0 available devices on WinRT. 'multimedia' is added as Qt module.
What could be wrong? A missing plugin (dll not deployed automatically)? Or is WinRT not supported (yet)?
When a signal is emitted that is connected to a slot through a queued connection, the actual invocation is deferred - an event is put into the event queue that belongs to the thread the receiver object lives in for later processing. This is why when you have a multithreaded application the slot is executed in the thread where the receiver lives in, and not in the thread where the actual signal was emitted.
Here in the documentation is a more complete discussion.