Problem with etnaviv and gstreamer 1.0
Lukasz Majewski
lukma at denx.de
Tue Dec 5 16:34:06 UTC 2017
Hi Luis,
> Replies in between.
>
> Regards,
> Luís Mendes
>
> On Tue, Dec 5, 2017 at 2:33 PM, Lukasz Majewski <lukma at denx.de> wrote:
> > Hi Luís,
> >
> > Thanks for your reply.
> >
> >> Hi Lukasz,
> >>
> >> I'm not part of the mesa/etnaviv development team, but I've tried
> >> somethings with gstreamer, maybe I can provide some useful
> >> information...
> >>
> >> Can you try xvimagesink instead of glimagesink?
> >
> > It would be hard since I do support Weston/Wayland - not X11.
>
> Ok.
>
> >
> >>
> >> Etnaviv provides the driver for the 3D GPU, but I believe the
> >> video is normally output out through the 2D unit, the GC320 in
> >> i.MX6 via xf86-armada drm driver.
> >>
> >> I think the best approach for decoding and outputting video is to
> >> implement the VAAPI and/or VDPAU support in mesa, right on
> >> etnaviv
> >
> > I've read that etnaviv has some issues with YUV->RGB conversion and
> > with some shaders (as they are required by Gstreamer) [1], [2].
> >
> >> making the CODA VPU unit available to all the applications that are
> >> already VAAPI and VDPAU aware, like vlc, kodi and others. That way
> >> standard desktop applications can be used without much changes or
> >> one can develop for both platforms with less effort. I am currently
> >> starting such project to bridge the gap with a prototype driver
> >> that could be integrated in etanviv and mesa. Mesa already
> >> implements VAAPI and VDPAU, I believe one just needs to implement
> >> an internal mesa API named VL.
> >
> > Please correct me if I'm wrong - is the above proposal is for only
> > playing movies?
>
> The above proposal is mainly for playing videos, that is,
> decoding/encoding video sources, could be a stream from a camera,
> through a kind of "standard" API that is also used for desktop
> applications, but also provides an image output path to the screen.
> Kodi seems to use this to output the video but also to overlay text
> and icons.
>
> >
> > Now, I do have a problem to get very basic test working
> > (black rectangle is shown):
> > gst-launch-1.0 -v gltestsrc pattern=smpte ! glimagesink
>
> The above is working on my setup under Xorg. Under weston also works,
> but image is distorted. What kernel/mesa version are you using?
Kernel is v4.14, mesa 17.0.6. Now I will test with 17.1.7.
GST 1.12.2
>
> >
> >>
> >> Meanwhile, maybe you can try the following which also makes use of
> >> the CODA VPU unit with gstreamer:
> >>
> >> wget
> >> http://linode.boundarydevices.com/videos/trailer_1080p_h264_mp3.avi
> >>
> >> gst-launch-1.0 filesrc
> >> location=/home/ubuntu/trailer_1080p_h264_mp3.avi ! \ avidemux !
> >> h264parse ! v4l2video1dec capture-io-mode=dmabuf ! \ xvimagesink
> >> device=1 sync=0
> >
> > Ok (despite the xvimagesink part).
> >
> >>
> >> The above works both on my i.MX6Q and on my i.MX6QP under X, I
> >> haven't tried with wayland, but should work just the same.
> >>
> >> I based this test on the following post by Fabio Estevam:
> >> https://imxdev.gitlab.io/tutorial/Decoding_video_with_a_mainline_kernel_on_i.MX6/
> >
> > I've followed this tutorial - I'm not able to get the movie
> > displayed:
>
> That's odd, again it should work. It works on my i.MX6Q and i.MX6QP
> as long as I haven't any graphical display running. Have you installed
> the CODA VPU firmware in /lib/firmware/vpu?
I've enabled CODA in kernel with adding /lib/firmware/vpu for it.
It seems like it is properly configured.
>
> >
> > The following line gives some output to file.
> >
> > export XDG_RUNTIME_DIR=/run/user/0;gst-launch-1.0 filesrc
> > location=trailer_1080p_h264_mp3.avi ! avidemux ! h264parse !
> > v4l2video1dec capture-io-mode=dmabuf ! filesink location=/tmp/out
> > sync=false
> >
> > And with the below one:
> >
> > gst-launch-1.0 filesrc location=trailer_1080p_h264_mp3.avi !
> > avidemux ! h264parse ! v4l2video1dec capture-io-mode=dmabuf !
> > video/x-raw,format=YUY2 ! glimagesink
>
> I get no such error. Although the video is not playable in this mode,
> it keeps repeating the first bunch of frames in a loop until the video
> duration elapses in a distorted reddish colored window.
> You are probably using an old mesa version. Despite what you say
> regarding the color space unexpected conversion, if I'm not mistaken
> R8G8_UNORM support was only implemented relatively recently, so you
> are likely using an old mesa version.
As noted above - 17.0.6 / 17.1.7
So the R8G8_UNORM is now supported in the newest mesa?
> I would recommend you to test
> with mesa-17.3.0 or the release candidate 6 that is already available,
> Etnaviv improved a lot lately and now supports openGL 2.1, maybe you
> should try mesa-17.3.0.
Ok. I will try mesa-17.3.0
>
> >
> > Error is:
> > ---------
> > etna_rs_gen_clear_surface:77: etna_rs_gen_clear_surface: Unhandled
> > clear fmt PIPE_FORMAT_R8G8_UNORM
> >
> > I'm just wondering -> x-raw,format=YUY2 explicitly asks for YUY2
> > format (which shall be supported by etnaviv).... why then in the
> > middle there is PIPE_FORMAT_R8G8_UNORM ?
> >
> >
> > And with this one:
> > gst-launch-1.0 filesrc location=trailer_1080p_h264_mp3.avi !
> > avidemux ! h264parse ! v4l2video1dec capture-io-mode=dmabuf !
> > videoconvert ! fbdevsink sync=false
> >
> > No errors are present, but also I do not see any output.
>
> I also see no image under Wayland (using Ubuntu 17.10 desktop, or
> Weston on i.MX6QP), but it works (slowly) when I don't have any
> graphical environment running.
Ok. I will test it with weston disabled.
Thanks for tip.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20171205/6c643096/attachment-0001.sig>
More information about the gstreamer-devel
mailing list