gdkpixbufoverlay breaks vaapi pipeline

[Nicolas Dufresne]

Le mer. 1 mai 2019 05 h 51, Wolfgang Grandegger <wg at grandegger.com> a
écrit :

> Hello,
>
> Am 01.05.19 um 02:12 schrieb Nicolas Dufresne:
> >
> >
> > Le mar. 30 avr. 2019 16 h 25, Wolfgang Grandegger <wg at grandegger.com
> > <mailto:wg at grandegger.com>> a écrit :
> >
> >     Hello,
> >
> >     I have a wired problem with the following pipeline:
> >
> >       $ gst-launch-1.0 udpsrc port=5678 buffer-size=180000000 \
> >           ! image/jpeg,format=Y42B,width=1920,height=1080,framerate=50/1
> \
> >           ! jpegparse disable-passthrough=true
> >           ! vaapijpegdec \
> >
> >
> > I'm not fully certain, but I believe you might need to add vaapipostproc
> > here for this use case. VA element don't produce normal memory, the
> > postproc can fix that
>
> "vaapipostproc" without arguments does *not* help. But I just found out,
> that
>
>   "vaapipostproc format=i420 "
>

Ok, in theory, a caps filter after with format=I420 should have the same
effect. We aim at deprecating that property.

I suspect that the main side effect is that it's no longer passthrough. I
think it's worth filing a bug report on gitlab. Something isn't quite right
for this use case.



> here does *cure* the problem! Should it not also work with 422H?
>
> It there an easy way to find out what format an element uses?
>

For gdkpixbufoverlay, it's static, so simply gst-inspect, for VAAPI it's
very dynamic, you have to dig into the caps. In general you should not have
to care, it should always negotiated something that works.


> Anyway, as mentioned below, it works fine with the "yuvj420" camera
> stream and also with "clockoverlay". Therefore I think "memory" should
> be ok in the first place... but maybe I have missed something?
>
> >
> >           ! gdkpixbufoverlay location=logo.png \
> >           ! vaapisink
> >
> >     It works fine with the following camera stream:
> >
> >       Video: mjpeg (jpeg / 0x6765706A), yuvj420p(pc,
> >     bt470bg/unknown/unknown, progressive), 1920x1080
> >
> >     but the element "gdkpixbufoverlay" breaks it with the stream:
> >
> >       Video: mjpeg (jpeg / 0x6765706A), yuvj422p(pc,
> >     bt470bg/unknown/unknown, progressive), 1920x1080
> >
> >     It's 420 vs 422? Then I get the error message:
> >
> >       WARN        vaapisink
> >     gstvaapisink.c:1483:gst_vaapisink_show_frame_unlocked:<vaapisink0>
> >     could not get surface
>
> What could cause that warning?
>
> >       WARN        basesrc gstbasesrc.c:3055:gst_base_src_loop:<udpsrc0>
> >     error: Internal data stream error.
> >       WARN        basesrc gstbasesrc.c:3055:gst_base_src_loop:<udpsrc0>
> >     error: streaming stopped, reason error (-5)
> >       WARN        queue
> >     gstqueue.c:988:gst_queue_handle_sink_event:<queue0> error: Internal
> >     data stream error.
> >       WARN        queue
> >     gstqueue.c:988:gst_queue_handle_sink_event:<queue0> error: streaming
> >     stopped, reason error (-5)
> >       ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:
> >     Internal data stream error.
> >       Additional debug info:
> >       gstbasesrc.c(3055): gst_base_src_loop ():
> >     /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:
> >       streaming stopped, reason error (-5)
> >
> >     In the log with GST_DEBUG=5 I find in that case:
> >
> >       DEBUG         vaapi
> >     gstvaapiimage.c:293:gst_vaapi_image_new_with_image: VA image
> >     0x0a000000, format 422H, size 1920x1080
> >       ...
> >       DEBUG         vaapidisplay gstvaapidisplay.c:205:append_formats:
> >     unsupported format 422H
>
> That tells me, that 422H is not supported. Is it a hardware or software
> limitation? Does it depend on the X86 graphics hardware?
>
> >
> >     In the good case, I do not find the last line but
> >
> >       DEBUG         vaapi
> >     gstvaapiimage.c:293:gst_vaapi_image_new_with_image: VA image
> >     0x0a000000, format IMC3, size 1920x1080
> >
> >     Not sure it it's related, though. It's working fine for both streams
> >     *without*
> >     "gdkpixbufoverlay" or *with* "clockoverlay".
> >
> >     Any idea what could go wrong? Anything else I could debug?
> >
> >     TIA,
> >
> >     Wolfgang
>
> Thanks,
>
> Wolfgang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190501/ee4779a7/attachment.html>