<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 1 mai 2019 05 h 51, Wolfgang Grandegger <<a href="mailto:wg@grandegger.com">wg@grandegger.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
Am 01.05.19 um 02:12 schrieb Nicolas Dufresne:<br>
> <br>
> <br>
> Le mar. 30 avr. 2019 16 h 25, Wolfgang Grandegger <<a href="mailto:wg@grandegger.com" target="_blank" rel="noreferrer">wg@grandegger.com</a><br>
> <mailto:<a href="mailto:wg@grandegger.com" target="_blank" rel="noreferrer">wg@grandegger.com</a>>> a écrit :<br>
> <br>
>     Hello,<br>
> <br>
>     I have a wired problem with the following pipeline:<br>
> <br>
>       $ gst-launch-1.0 udpsrc port=5678 buffer-size=180000000 \<br>
>           ! image/jpeg,format=Y42B,width=1920,height=1080,framerate=50/1 \<br>
>           ! jpegparse disable-passthrough=true<br>
>           ! vaapijpegdec \<br>
> <br>
> <br>
> I'm not fully certain, but I believe you might need to add vaapipostproc<br>
> here for this use case. VA element don't produce normal memory, the<br>
> postproc can fix that <br>
<br>
"vaapipostproc" without arguments does *not* help. But I just found out,<br>
that<br>
<br>
  "vaapipostproc format=i420 "<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Ok, in theory, a caps filter after with format=I420 should have the same effect. We aim at deprecating that property.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
here does *cure* the problem! Should it not also work with 422H?<br>
<br>
It there an easy way to find out what format an element uses?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Anyway, as mentioned below, it works fine with the "yuvj420" camera<br>
stream and also with "clockoverlay". Therefore I think "memory" should<br>
be ok in the first place... but maybe I have missed something?<br>
<br>
> <br>
>           ! gdkpixbufoverlay location=logo.png \<br>
>           ! vaapisink<br>
> <br>
>     It works fine with the following camera stream:<br>
> <br>
>       Video: mjpeg (jpeg / 0x6765706A), yuvj420p(pc,<br>
>     bt470bg/unknown/unknown, progressive), 1920x1080<br>
> <br>
>     but the element "gdkpixbufoverlay" breaks it with the stream:<br>
> <br>
>       Video: mjpeg (jpeg / 0x6765706A), yuvj422p(pc,<br>
>     bt470bg/unknown/unknown, progressive), 1920x1080<br>
> <br>
>     It's 420 vs 422? Then I get the error message:<br>
> <br>
>       WARN        vaapisink<br>
>     gstvaapisink.c:1483:gst_vaapisink_show_frame_unlocked:<vaapisink0><br>
>     could not get surface<br>
<br>
What could cause that warning?<br>
<br>
>       WARN        basesrc gstbasesrc.c:3055:gst_base_src_loop:<udpsrc0><br>
>     error: Internal data stream error.<br>
>       WARN        basesrc gstbasesrc.c:3055:gst_base_src_loop:<udpsrc0><br>
>     error: streaming stopped, reason error (-5)<br>
>       WARN        queue<br>
>     gstqueue.c:988:gst_queue_handle_sink_event:<queue0> error: Internal<br>
>     data stream error.<br>
>       WARN        queue<br>
>     gstqueue.c:988:gst_queue_handle_sink_event:<queue0> error: streaming<br>
>     stopped, reason error (-5)<br>
>       ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:<br>
>     Internal data stream error.<br>
>       Additional debug info:<br>
>       gstbasesrc.c(3055): gst_base_src_loop ():<br>
>     /GstPipeline:pipeline0/GstUDPSrc:udpsrc0:<br>
>       streaming stopped, reason error (-5)<br>
> <br>
>     In the log with GST_DEBUG=5 I find in that case:<br>
> <br>
>       DEBUG         vaapi<br>
>     gstvaapiimage.c:293:gst_vaapi_image_new_with_image: VA image<br>
>     0x0a000000, format 422H, size 1920x1080<br>
>       ...<br>
>       DEBUG         vaapidisplay gstvaapidisplay.c:205:append_formats:<br>
>     unsupported format 422H<br>
<br>
That tells me, that 422H is not supported. Is it a hardware or software<br>
limitation? Does it depend on the X86 graphics hardware?<br>
<br>
> <br>
>     In the good case, I do not find the last line but<br>
> <br>
>       DEBUG         vaapi<br>
>     gstvaapiimage.c:293:gst_vaapi_image_new_with_image: VA image<br>
>     0x0a000000, format IMC3, size 1920x1080<br>
> <br>
>     Not sure it it's related, though. It's working fine for both streams<br>
>     *without*<br>
>     "gdkpixbufoverlay" or *with* "clockoverlay".<br>
> <br>
>     Any idea what could go wrong? Anything else I could debug?<br>
> <br>
>     TIA,<br>
> <br>
>     Wolfgang<br>
<br>
Thanks,<br>
<br>
Wolfgang<br>
</blockquote></div></div></div>