Sorry for late answer. Yes everything seemed fine. No error report at least.
But I'm guessing that this might not actually be linked with this topic anymore. So I'll just look into this issue on my own from there.
This is the way i fixed it.
Step 1: use 'apt-cache search -n gstreamer' to get the list all of the gstreamer and libgstream lib
Step 2: for each of lib in the list. Use 'apt-get install name-of-the-gstreamer-lib' to install it. After install almost the lib in the list my example run. ( i don't know which is the exactly lib i need to install. I just install all of them until my example run)
Step 3: rebuild your example and run.
I suspect @speeter will have long disappeared, as that post was a year ago :)
Just a thought: have a look at (the first part of) https://raspberrypi.stackexchange.com/a/61086, which claims it's a generic Linux problem rather than just a RPi one. It's not quite the same messages, but worth investigating?
@tamolo You used qmake from home/Qt5.7 to build QtMultimedia, right? In this case make install should copy it to home/Qt5.7. If it did not then you still can copy the stuff manually. Actually, if you call "make install" you see what it is installing where.
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.
"big buffer" is quite relative and that "big" depends on needs.
In my case I'm using audio data to pitch recognition and depending on pitch range to recognize, I'm using 512, 1024 or 2048 samples buffer, so it is apparently 11, 23 and 45ms (more less). Those power-of-two buffer sizes are required by FFT routines.
But my app is flexible enough, and when underlaying OS is not capable to keep that buffer size it will portion any audio data size as needed for pitch detection algorithm.
(on Android Qt Audio is used and with low level device a delay between data ready call could sometimes be about 100ms)
However smaller buffer gives faster app response (displaying pitch in score).
And no any glitches was notices even if buffer is set to 64 frames (2ms)
And if we take simpler example, which could be passing input mike data to an output device - more quicker we send incoming data to the out - less delay will be in speakers - it means less buffer - faster response.
Got another problem though I have managed to cross compile Qt5 with gstreamer1.0 support it is unable to play HD videos on pi.
I checked using GST_DEBUG=3 and it seems like it still uses gstreamer0.10.
So Do anyone have got HD video playing on pi and can suggest me to get it playing??