GNOME Bugzilla – Bug 733168
omxaudiosink: Does not set ports to non-flushing after prepare
Last modified: 2014-07-23 08:09:08 UTC
Created attachment 280663 [details] GST_DEBUG=omx*:6 I updated my GStreamer versions on device to 1.3.90 and gst-omx 08385fe94425cb935f22dfa8cb399ac5589cbab0. Previous working version I had was 2c3797acfe3dc645ad2d4d09b15de7b1bc544cca. Now the glimagesink only renders the first few frames of my test video here, the decoder seems to drop everything else. I'm attaching a log file as requested by Sebastian. The test file I use is http://trac.webkit.org/browser/trunk/LayoutTests/media/content/test.mp4 downloaded to the sdcard and played with gst-play or gst-launch playbin uri=...
After bisecting the first bad revision is http://cgit.freedesktop.org/gstreamer/gst-omx/commit/?id=190adce12595f9596f3666fb4e7d25fb363ed289
The problem here seems to be the audio sink, it believes it is flushing all the time. Can you please retry without audio to see if that fixes it?
And because of that it seems like the video decoder is dropping all frames as they are "too late".
I won't be able to test anything until next Monday, unfortunately :(
This should fix at least the audiosink problem. Please test if it also fixes everything else for you. commit c4deb7c07ca797ab6af779d5bbd87a20433fd7e8 Author: Sebastian Dröge <sebastian@centricular.com> Date: Sun Jul 20 17:46:30 2014 +0200 omxaudiosink: Set port to not flushing in prepare() and keep it at flushing in unprepare() https://bugzilla.gnome.org/show_bug.cgi?id=733168
Does not seem to make any noise, but it work fine here: gst-launch-1.0 playbin uri=file:///home/nicolas/test.mp4 video-sink=glimagesink audio-sink=omxhdmiaudiosink (Note, it's unclear to me what will be next version, last one was 1.0.0)
Sorry, my bad, this is missing a decoder for that audio track.
Ok, now for real, it works for me. Note that the CPU is nearly saturated when doing so. I don't currently have perf to figure-out why. It is very likely that for someone else it will drop.
Ok, my CPU usage was that avec_h264 was used, as both decoder had same rank. I've bumped the omx rank in the config, imho we should probably do that no ?
Yes, we should, and we do now :) See bug #732161