GNOME Bugzilla – Bug 796585
Stuttering when trying to decode stream encoded with omx
Last modified: 2018-11-03 13:02:16 UTC
I am trying to decode a h264 stream encoded by omxh264enc using omxh264dec. It seems that every time I get a key frame there is a visible stutter in the decoded video. The interesting part is if I try to encode using x264enc or decode using avdec_h264, the stream looks fine. I am attaching videos of the same recording using omx and x264, as well as a demo video with the visible stutter. In the recorded video, I have used the force key frame event to ensure that A keyframe is produced every second.
the platform we are using is: AMD Radeon R7 Graphics (CARRIZO, DRM 3.25.0, 4.17.0-qtec-standard, LLVM 6.0.1) Mesa 18.1.1
the same video encoded with omx and x264: http://ge.tt/4CuOlAq2
the video showing the stutter: http://ge.tt/4UBHlAq2
You should maybe share the encoding parameters you have chosen (properties and caps filter that follow the encoder). Defaults paremeters are very different, specially that with gst-omx it is OMX stack dependant. I also don't think there is anyone actively working on gst-omx running on AMD Radeon accelerators. On another note, have you tried with other containers then AVI ?
https://bugs.freedesktop.org/show_bug.cgi?id=106919
Container wise I have tested with a couple of others (mpegts, ogg..) and also streaming out the h264 with rtp and playing it on another device with the same physical hardware/software and I get the same results. caps after omxh264enc: video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, profile=(string)baseline, level=(string)5.1, width=(int)1980, height=(int)1080, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)60/1, interlace-mode=(string)progressive, colorimetry=(string)bt709, chroma-site=(string)mpeg2, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono the parameters I am leaving at default. Will monitoring them give me any feedback on wht the hardware sets? Also thanks Julien for linking out ticket on the Mesa bugzilla :)
Not a solution for this problem, but we managed to get vaapi installed on the platform and after some experimentation we managed to get a functional stream using vaapi elements.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-omx/issues/24.