Same issues after testing on another Windows 10 machine. The output file seems to be in sync on a M2 macbook air.

Hi, if you have to straming audio and video files you could use live555 on server side and, client side, only QMediaPlayer using rtsp.

@Prakash08
Sorry, but you're wrong. @Christian-Ehrlicher & I have both tried to point this out to you.

First of all, QMediaPlayer *player = new QMediaPlayer is a pointer to an allocated object on the heap. That means it persists until something deletes it. The fact that QMediaPlayer *player is itself a local variable is neither here nor there, when it goes out of scope that does not destroy the object it points to. That is quite different from QBuffer buffer(&received_data), which is a local stack variable, not a pointer to an object. That does get destroyed at the end of the if.

Secondly, player->setMedia(QMediaContent(), &buffer) means that player is using the stack buffer, so as soon as the if exits buffer is destroyed but the QMediaPlayer is still using it as its buffer. When you go player->play() at the end that only starts playing the video, it does not finish playing it. It carries on playing after the function exits. But it's reading from a buffer which has now been destroyed. Not good! Lucky it does not "crash". Your "Error:failed to seek" error may be from code trying to access it when it is no longer valid.

This is all standard C++ stuff.

@Olivier-Duguay can you update to a more recent version of Qt ? Since 6.5, the default backend has been switched to ffmpeg which may give better results.

@ChrisW67 Thanks for your response! Using Qt::FramelessWindowHint flags can help me in my case.
But for further understanding, in case I want to record other apps then I have to remove its header section (such as the OBS header in above picture), I wonder If I could set this similar flags to CapturableWindow when I get it from capturableWindows(). Or QWindowCapture, QMediaRecorder had the other ways to help me with this?
Please feel free to share, I’m grateful.

@artemious3 said in Creating QIODevice with infinite data:

I'd like to know if you can see some problems with this implementation,

On a cursory inspection...
Let's say your audioData buffer size is 1024 bytes, for example, and the user requests a read of 2048 bytes (because your bytesAvailable says that is available). This line:

currentDataPtr = std::copy(audioData, audioData + remainingBytes, targetData);

will try to copy 2048 bytes out of a 1024 byte buffer.

You should also look at the QIODevice::bytesAvailable() docs regarding what this should return.

Hi and welcome to devnet,

The probe APIs have been removed. See here.

You might be able to do something with the QAudioDecoder class.

On a side note, please use coding tags around your code. That will make it readable.

@eramne Is it working for you now? I've got a problem linking FFmpeg with static Qt, which I've logged at https://bugreports.qt.io/browse/QTBUG-115052 but if it's working for you, feel free to mark this as Solved

@SGaist Yes in case of Qt 6.5.0, but this also happens with Qt 6.3.1, although the error I can read from QMediaPlayer is different:

Qt 6.5.0: QMediaPlayer::ResourceError Qt 6.3.1: QMediaPlayer::FormatError

Edit:
The root cause of this issue was connected to file types and the way my url was constructed. I opted to use the native darwin backend with Qt 6.5 instead of the new ffmpeg, at least until 6.5.1 is out and I can do further testing. Thank you for the valuable input (as always!).

@sethsource same with HLS

So 6.5.1 is out and this should now be fixed, but nope, it starts, debug output shows hls playlist information but the it just ends with "Operation not permitted". Same url works with ffplay just fine. sigh.

@ekkescorner This issue will be fixed in next release.
Qt support said that overwriting Qt 5.15.11 androiddeployqt files with Qt 5.15.10 ones will fix this issue.
I don't like mixing versions, so I'm waiting next release while using Qt 5.15.10 which is good enough for my development.

@nishithaa I have tried to do this for years to make a VR video player using Qt and I'm finally close to achieving it but without gstreamer. I don't know if gstreamer is a requirement to you but I use libvlc 4, based on this example : https://github.com/videolan/vlc/tree/master/doc/libvlc/QtGL .

It compiles and runs well but I don't want to use QOpenGLWidget (I use QWindows with manually-managed QOpenGLContexts) and somehow I can't make it to work in this setup.

@Sam-Aaron said in QtMultimedia - UI Freezes after 6.4.0 update.:

Downgrading to Qt 6.2.4 does appear to have fixed the issue. I've had the GUI running overnight and all morning and no freezing so far.

Unfortunately (for me) this assertion was wrong and I got a freeze with a Qt 6.2.4 build. Apologies for the red herring - my issue is likely unrelated.

I am currently unsure that you can achieve that this way.
If memory serves well, you can create a custom QMediaObject that you can attach to VideoOutput. It could be an alternative.

This is because of virtualbox 3d acceleration support opengl version 2.0
it looks like qt multimedia(6.2) need opengl at least 3.0 version

Below was how to know it.
mesa log enable and log like below

Mesa: glGenTextures 1
Mesa: glBindTexture GL_TEXTURE_2D 2
Mesa: FLUSH_VERTICES in bind_texture_object
Mesa: FLUSH_VERTICES in teximage
Mesa: glTexImage2D GL_TEXTURE_2D 0 GL_R8 960 360 1 0 GL_RED GL_UNSIGNED_BYTE (nil)
Mesa debug output: GL_INVALID_VALUE in glTexImage2D(internalFormat=GL_R8)

GL_R8 variable is available upper than opengl 3.0

That's why we have to see green screen in virtualbox 3d acceleration

@DeepakVishak
SGaist is right. custom GStreamer pipelines have been dropped in Qt 6 Multimedia, however you can achieve the same using qml6glsink.
Have a look at this example:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/tree/1.24/subprojects/gst-plugins-good/tests/examples/qt6/qmlsink?ref_type=heads