gdkpixbufoverlay breaks vaapi pipeline
Locked
gdkpixbufoverlay breaks vaapi pipeline
 
|
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 \ ! 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 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 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 _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: gdkpixbufoverlay breaks vaapi pipeline
|
|
Le mar. 30 avr. 2019 16 h 25, Wolfgang Grandegger <[hidden email]> a écrit : Hello, 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 ! gdkpixbufoverlay location=logo.png \ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: gdkpixbufoverlay breaks vaapi pipeline
|
|
Hello,
Am 01.05.19 um 02:12 schrieb Nicolas Dufresne: > > > Le mar. 30 avr. 2019 16 h 25, Wolfgang Grandegger <[hidden email] > <mailto:[hidden email]>> 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 " 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? 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 _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: gdkpixbufoverlay breaks vaapi pipeline
|
|
Le mer. 1 mai 2019 05 h 51, Wolfgang Grandegger <[hidden email]> a écrit : Hello, 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.
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.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: gdkpixbufoverlay breaks vaapi pipeline
|
|
Hello,
Am 01.05.19 um 15:44 schrieb Nicolas Dufresne: > > > Le mer. 1 mai 2019 05 h 51, Wolfgang Grandegger <[hidden email] > <mailto:[hidden email]>> a écrit : > > Hello, > > Am 01.05.19 um 02:12 schrieb Nicolas Dufresne: > > > > > > Le mar. 30 avr. 2019 16 h 25, Wolfgang Grandegger > <[hidden email] <mailto:[hidden email]> > > <mailto:[hidden email] <mailto:[hidden email]>>> 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. Done! See: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/158 Thanks, Wolfgang _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |