Bug 106919

Summary: Stuttering when trying to decode stream encoded with omx
Product: Mesa Reporter: Ricardo Ribalda <ricardo.ribalda>
Component: Drivers/Gallium/radeonsiAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact: Default DRI bug account <dri-devel>
Severity: normal    
Priority: medium CC: boyuan.zhang, ckoenig.leichtzumerken, gurkirpal204, julien.isorce, leoxsliu, ricardo.ribalda, sunpeng.li
Version: 18.0   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: Original file encoded with omx (one keyframe per second)
Sluttering (how do I see the video with omx decode)

Description Ricardo Ribalda 2018-06-14 14:30:31 UTC
We have the following configuration:

With this configuration:
Mesa 18.1.1 AMD Radeon R7 Graphics (CARRIZO, DRM 3.25.0, 4.17.0, LLVM 6.0.1)

When we decode with OMX a video that was previously encoded with OMX, the video seems to roll back a second once in a while (Please take a look to the videos, it is hard to explain what is happening).

We are accessing libmesa-omx with libomx-bellagio 0.9.3 and gstreamer 1.12.4
Comment 1 Ricardo Ribalda 2018-06-14 14:31:43 UTC
Created attachment 140154 [details]
Original file encoded with omx (one keyframe per second)
Comment 2 Ricardo Ribalda 2018-06-14 14:33:28 UTC
Created attachment 140156 [details]
Sluttering (how do I see the video with omx decode)
Comment 3 Julien Isorce 2018-06-14 18:32:04 UTC
Is it a regression ? Was it working for you before on the same or other config ?
Comment 4 Ricardo Ribalda 2018-06-14 18:36:40 UTC
I do not know. It is the first time that I use this configuration: omx for encoding and decoding.

The only thing that I know for sure is that the effect gets worse and worse if I increase the frequency of key frames.
Comment 5 Julien Isorce 2018-06-14 19:18:24 UTC
Can you try gstreamer-vaapi ? to compare with another hw decoder. And with sw decoders in gstreamer it works ? And other players ?
I am trying to determine if the issue is only in the omx decoder.
Comment 6 Ricardo Ribalda 2018-06-14 19:26:05 UTC
I tried this combinations with gstreamer:

sw encoding + sw decoding (libva): works

sw encoding + omx decoding: works

omx encoding + sw decoding (libva): works

omx encoding + omx decoding : fails


I havent tried vaapi yet. I can try to give it a try tomorrow and report results
Comment 7 Ricardo Ribalda 2018-06-14 19:27:17 UTC
BTW: Are you aware of anyway that I can validate that a video is properly encoded, besides playing it?

Thanks!
Comment 8 Ricardo Ribalda 2018-06-15 10:08:37 UTC
We are trying with vappi and we cannot reproduce the bug. This is the pipeline that we are using:

gst-launch-1.0 videotestsrc ! video/x-raw,width=800,height=600,framerate=60/1 ! timeoverlay  ! videoconvert ! vaapih264enc ! video/x-h264,profile=main ! h264parse ! vaapih264dec ! vaapisink sync=0 --gst-debug=*:3


To sumarise

ENC -> DEC : Result

sw    -> sw    : OK
sw    -> omx   : OK
sw    -> vappi : OK
omx   -> sw    : OK
omx   -> omx   : FAIL
omx   -> vappi : OK
vappi -> sw    : OK
vappi -> omx   : OK
vaapi -> vappi : OK
Comment 9 GitLab Migration User 2019-09-25 18:08:54 UTC
-- 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/mesa/mesa/issues/1315.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.