GNOME Bugzilla – Bug 701170
Low fps when playing 1080p video on Raspberry Pi Model B
Last modified: 2018-05-06 12:33:33 UTC
I'm trying to play the 1080p movie (http://samplemedia.linaro.org/H264/big_buck_bunny_1080p_H264_AAC_25fps_7200K.MP4) using the following pipeline: filesrc location=… ! \ qtdemux ! \ queue max-size-bytes=10000000 ! \ h264parse ! \ omxh264dec ! \ queue max-size-buffers=4 ! \ eglglessink unfortunately many frames are dropped. If I run this pipeline with --gst-debugging-level=2, there is a bunch of messages like: omxvideodec gstomxvideodec.c:1489:gst_omx_video_dec_loop:<omxh264dec-omxh264dec0> Frame is too late, dropping (deadline 0:00:00.029042840) In the other hand omxplayer (https://github.com/huceke/omxplayer) plays the same movie smoothly.
Can you add a queue before qtdemux and before omxh264dec and give all four queues names with the name property? Then run the pipeline and look in top, which of the queue threads is taking all the CPU.
For the following pipline: filesrc location=… ! queue name=demux ! qtdemux ! queue max-size-bytes=10000000 name=parse ! h264parse ! queue name=decode ! omxh264dec ! queue max-size-buffers=4 name=sink ! eglglessink CPU usage is: omxh264dec-omxh: 26% filesrc0src: 4% eglglessink-ren: 4% demux:src: 2% parse:src: 2% decode:src: 2% sink:src: 1%
That's a lot less than 100% ;) If you set sync=false on the sink, is playback smooth and faster than realtime?
Overall CPU usage by gst-launch is always < 50% If I set sync to false on sink, playback is smoother but slower than normal speed.
That sounds like for some reason the hardware codec is too slow, but OTOH it works with omxplayer as you said. Might be because omxplayer is directly displaying instead of getting back the memory to the CPU first.
Is it a bug in decoder or in the sink? Or it's very fundamental gstreamer problem?
Neither of those, could you try with latest git master of gst-omx and gst-plugins-bad/eglglessink? There it will not get the decoder memory back to the CPU (requires latest firmware).
Do I need to compile gstreamer, gstreamer-base etc from the sources as well to be able to compule gst-omx/gst-plugins-bad ?
I've compiled gstremaer, gstreamer-plugins-base, gstreamer-plugins-good, gstreamer-plugins-bad (--with-egl-window-system=rpi) and gst-omx (--with-omx-target=rpi) from the master branch sources and it helped!
There are a lot of messages like this: videodecoder gstvideodecoder.c:2736:gst_video_decoder_decode_frame:<omxh264dec-omxh264dec0> decoder frame list getting long: 54 frames,possible internal leaking? Is that normal?
Yes, that warning is faulty, though it should reach a stable size during playback. Is it stable or it keep growing ?
No, tha value is 40-60 all the time.
Yeah, that's normal then. That warning should just be removed.
This bug is back in both 1.0.10 and 1.2.3
*** Bug 725714 has been marked as a duplicate of this bug. ***
Each ~100ms a message like the following is logged: omxvideodec gstomxvideodec.c:1934:gst_omx_video_dec_loop:<omxh264dec-omxh264dec0> Frame is too late, dropping (deadline 0:00:00.011214452)
Does this still happen with git master of everything, and glimagesink? If it does, can you check which threads are using too much CPU, if any?
Pretty sure this is fine with gst-omx-1.2 and gstreamer stack of 1.4.5. As long as you don't want to scale :) git master now supposedly has other problems, like bug 743914, though
We can't use shipped gst-omx-1.2 as a reference. It contains several patches that are not upstream.
(In reply to Nicolas Dufresne (stormer) from comment #19) > We can't use shipped gst-omx-1.2 as a reference. It contains several patches > that are not upstream. What are these patches and why don't they ask us to merge them?
I an referencing upstream gst-omx-1.2 without patches. I use gstreamer core/base/good/bad 1.4.5 without patches and gst-omx-1.2 without patches. I only have patches to -bad configure.ac for using rpi-userland pkg-config files, which I also patch in, that's all. Playing 1080p on a 1080p monitor takes a total of ~10% CPU (less than 3% on each core on rpi2, fluctuating); I don't even have NEON Orc used yet. I am not aware of patches in raspbian on top of gst-omx-1.2, I know of what they call 1.0.0.1 with patches and some of those patches I'm working on updating for bug 722686
(In reply to Sebastian Dröge (slomo) from comment #20) > (In reply to Nicolas Dufresne (stormer) from comment #19) > > We can't use shipped gst-omx-1.2 as a reference. It contains several patches > > that are not upstream. > > What are these patches and why don't they ask us to merge them? They are somewhere in bugzilla of course, it's the resizer component integration (which also do colour conversion). This is being hooked (tunnelled) inside the decoder. This is how they managed to get very decent video playback in Epiphany without GL support. This changes the behaviour in many places, and makes it hard to compare 1.2 against 1.4 (specially if you are assuming a regressions).
Ah, IMHO we should merge those patches if anybody can be bothered to port them to 1.4. Nobody is going to work on a cleaner solution anytime soon and it's improving things a lot.
I can't reproduce this issue with git master, FWIW :) Playback is smooth on my RPi2 for this video file.
Closing as INVALID because we cannot reproduce it. Please feel free to reopen it and provide a test case if this is still an issue.