Qt Multimedia

@Bonnie This... is... great! Thank you very much. I came up with following commands: pactl load-module module-null-sink sink_name=my_sink_mix sink_properties=device.description=my_sink_mix pactl load-module module-loopback latency_msec=60 adjust_time=6 source=alsa_output.pci-0000_00_1b.0.analog-stereo.monitor sink=my_sink_mix pactl load-module module-remap-source master=my_sink_mix.monitor source_name=vmic source_properties=device.description=virtual_mic So, all I have to do is to write something with QProcess with these commands. And then use "vmic" as QAudioInput and "my_sink_mix" as QAudioOutput and voila! I can hear the audiostream and save it to disc simultaneously. Again: Thank you very much!

Hi, Your analysis looks correct. The default QAudioOutput constructor does indeed use the default output but in this case, it's the QAudioDevice constructor that is called. You should check the bug report system to see if there's already something about and if not, please open a new ticket.

@ChrisW67 It's an HLS encrypted stream, and those 16 bytes are the encryption key

Regarding your notes: it may be independent of all those things but it may be dependent on the compiler toolchain used, the Qt version in use, and the Windows version for both recording and playback. The Windows component that generated the audio stream provided something odd that Windows Media Player cannot understand. ffmpeg produces valid AAC Low Complexity the Windows Media Player does understand. It's unclear what the original stream is. If the original stream was AAC Main Profile then ffprobe would have reported "Audio: aac (Main) (mp4a / 0x6134706D)...". High Efficiency AAC would be reported as "Audio: aac (HE-AAC) (mp4a / 0x6134706D)" (and less likely to be playable). Does the audio play correctly if extracted from the container? ffmpeg.exe -i original_video.mp4 -c: copy -vn original_video_audio.m4a

They yanked perfectly good functionality out of Qt5, as far as I can tell. Concerning. M$ has a virtual monopoly on OS's, but much like two of the most enduring programming languages out there, win32, C++ and FORTRAN virtually never obsolete a given statement or call. These are also some of the most popular languages/APIs out there. I was looking to pick up the "peak meter" from an audio output, but nevermind. Not the first shortcoming of Qt I've had to code around. I figured out a way to do it with GetPeakValue() and adding the OLE lib to the .pro file. The advantage of doing it this way is the hw usu. does the calculation for you; and you don't have to scan your whole block of audio data. I also prefer linking to a windows distribution of CURL instead of QNetWorkManager; as I found it more reliable. That was in Qt5, however.

Guys my bad, i had connected pause to function that set position in the beginning:D Thanks for helping me out. Iam sorry for bothering.

Yes. I tried showing the window from the start, same thing happens. I switched to using QWindow instead of QWidget, and no difference in behaviour.

@csab6597 That's a sad news, then I think you need to dig into Qt's internal code to find out. From a quick search for the string StalledMedia in the source codes of QtMultimedia, I guess not all the mediaplayer controls of the backends in the plugins would trigger this state, every backend handles it in its own way. [image: 956c0d9b-31fa-4759-9cc3-500014346ea9.png] As for atEnd(), it does get called by some backends for example ffmpeg or gstreamer: // qtmultimedia/src/plugins/multimedia/ffmpeg/playbackengine/qffmpegmediadataholder.cpp static int readQIODevice(void *opaque, uint8_t *buf, int buf_size) { auto *dev = static_cast<QIODevice *>(opaque); if (dev->atEnd()) return AVERROR_EOF; return dev->read(reinterpret_cast<char *>(buf), buf_size); } // qtmultimedia/src/plugins/multimedia/gstreamer/common/qgstappsrc.cpp void QGstAppSrc::pushData() { ...... qCDebug(qLcAppSrc) << "pushData" << (m_stream ? m_stream : nullptr) << m_buffer.size(); if ((m_stream && m_stream->atEnd())) { eosOrIdle(); qCDebug(qLcAppSrc) << "end pushData" << (m_stream ? m_stream : nullptr) << m_buffer.size(); return; } ...... } So I think it does need to be reimplemented but maybe it is not enough. Well since I have no experience in this kind of case that's all what I can find now.

I am using Qt 6.8 on Windows 11 with Visual Studio 2022

@lisco It is not reliable to use qt_gst_element_query_duration. If your media file is short(for example a beep sound file), you will not be able to get duration. Try to use gst_discoverer_new.

@Riptide Hi, Did you manage to solve this issue? I am still looking for better solutions. One solution I would like to explore now has recently been suggested here: https://community.nxp.com/t5/i-MX-Graphics-Knowledge-Base/QT6-Qml-embedded-video-play-for-weston-with-Gstreamer/ta-p/1825985

@zedmatrix said in QMediaPlayer connect signal from its started ffmpeg backend: But none of the signals from QMediaPlayer::error or ::mediaStatus or ::metadataAvailable are empty. I don't understand this sentence. QMediaPlayer::error and mediaStatus aren't signals. You can find the related signals here. What do you mean by "are empty"? What is an empty signal? I think this is from the ffmpeg started by the player function but haven't found a way to connect to it? What's "this"? Maybe you wanna rephrase your question into something easier to understand.

@keksi-venksi said in How to detect Stream is not playing QMediaplayer: Meanwhile Im also facing the same issue , I use m_mediaplyar.play() but nothing played in the screen So you are saying you get "DirectShowPlayerService::doSetUrlSource: Unresolved error code 80004005" if i try to do a "setmedia" on my mediaplayer to change url and get a good one just like the OP, right?

Hi, That's surprising indeed. Did you already check the bug report system ?

@JoeCFD Thank you, it does seem to be a Qt issue with Gnome. I had issues with QVideoWidget, QWidget::createWindowContainer and QColorDialog::getColor corrupting the rendering of my application. Out of desperation I switched everything to KDE and it works as expected. The raspberrypi was my fault and fixed it by explicitly specifying the backend

It works in release mode, but not in debug mode. The latest version is the same

Were you able to find a solution to this? Currently stuck on this. I see my soundcard when doing aplay -l and arecord -l. I am also able to play audio with gst-launch-1.0 playbin. Alsamixer shows me an entire array of controls. However, Qt doesn't seem to recognize this.