GNOME Bugzilla – Bug 731192
vaapipostproc: failed to deinterlace and scale H.264 videos
Last modified: 2015-01-09 11:05:34 UTC
With a 720x480i60 H264 stream deinterlacing and scaling needs two vaapipostproc calls Examples OK with two vaapipostproc calls gst-launch-1.0 …. vaapidecode ! vaapipostproc deinterlace-mode=1 deinterlace-method=4 ! vaapipostproc width=400 height=300 ! vaapisink not OK with only one vaapipostproc call gst-launch-1.0 …. vaapidecode ! vaapipostproc deinterlace-mode=1 deinterlace-method=4 width=400 height=300 ! vaapisink Is it a normal behavior to call vaapipostproc two times?
Hi, (In reply to comment #0) > With a 720x480i60 H264 stream deinterlacing and scaling needs two vaapipostproc > calls > > Examples > OK with two vaapipostproc calls > gst-launch-1.0 …. vaapidecode ! vaapipostproc deinterlace-mode=1 > deinterlace-method=4 ! vaapipostproc width=400 height=300 ! vaapisink > > not OK with only one vaapipostproc call > gst-launch-1.0 …. vaapidecode ! vaapipostproc deinterlace-mode=1 > deinterlace-method=4 width=400 height=300 ! vaapisink > > Is it a normal behavior to call vaapipostproc two times? This is not normal. I think the reason why deinterlacing works on the next attempt is because the first one does update the src pad caps to include the correct interlace-mode attribute. Otherwise, I believe the root issue is that the decoder acts as if we had progressive frames in interlaced streams. i.e. the buffers individually report interlaced contents, but overall, at the caps level, everything happens as if we had progressive only. Anyway, this would explain a situation where you use deinterlace-mode=auto, but you explicitly use deinterlace-mode=interlaced here. So, this might be something else.
Some combinations works also with only one vaapipostproc call. One more info, which maybe can help. This is a working pipe (one vaapipostproc call) gst-launch-1.0 [h264i60-stream] ! vaapidecode ! vaapipostproc deinterlace-mode=auto deinterlace-method=motion-adaptive width=480 height=270 ! vaapisink Only changing the deinterlace-method from motion-adaptive to motion-weave is not working gst-launch-1.0 [h264i60-stream] ! vaapidecode ! vaapipostproc deinterlace-mode=auto deinterlace-method=motion-weave width=480 height=270 ! vaapisink IPv4 based on 0.0.0.0 IPv4 based on 192.168.0.14 libva info: VA-API version 0.35.1 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_35 libva info: va_openDriver() returns 0 WARNING: erroneous pipeline: could not set property "deinterlace-method" in element "vaapipostproc0" to "motion-weave"
(In reply to comment #2) > Some combinations works also with only one vaapipostproc call. > > One more info, which maybe can help. > > This is a working pipe (one vaapipostproc call) > gst-launch-1.0 [h264i60-stream] ! vaapidecode ! vaapipostproc > deinterlace-mode=auto deinterlace-method=motion-adaptive width=480 height=270 > ! vaapisink > > > Only changing the deinterlace-method from motion-adaptive to motion-weave > is not working > gst-launch-1.0 [h264i60-stream] ! vaapidecode ! vaapipostproc > deinterlace-mode=auto deinterlace-method=motion-weave width=480 height=270 ! > vaapisink > IPv4 based on 0.0.0.0 > IPv4 based on 192.168.0.14 > libva info: VA-API version 0.35.1 > libva info: va_getDriverName() returns 0 > libva info: Trying to open /usr/lib/dri/i965_drv_video.so > libva info: Found init function __vaDriverInit_0_35 > libva info: va_openDriver() returns 0 > WARNING: erroneous pipeline: could not set property "deinterlace-method" in > element "vaapipostproc0" to "motion-weave" The correct name is "weave", and this is not implemented because it's totally useless, that's just about displaying what we have in the VA surface. Anyway, if "weave" is not implemented, it should fallback to "bob".
Sorry, my fault. With "weave" instead of "motion-weave" the pipe works. Anyway, the issue I reported at the beginning is still there. Maybe this gives a hint: gst-launch-1.0 [h264i60-stream] ! vaapidecode ! vaapipostproc deinterlace-mode=interlaced deinterlace-method=motion-compensated width=400 height=300 ! vaapisink IPv4 based on 0.0.0.0 IPv4 based on 192.168.0.14 libva info: VA-API version 0.35.1 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_35 libva info: va_openDriver() returns 0 Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Got context from element 'vaapidecode0': gst.vaapi.Display=context, display=(GstVaapiDisplay)NULL; Progress: (open) Opening Stream Progress: (connect) Connecting to rtsp://192.168.0.14:8554/stream Progress: (open) Retrieving server options Progress: (open) Retrieving media info Progress: (request) SETUP stream 0 Progress: (request) SETUP stream 1 Progress: (open) Opened Stream Setting pipeline to PLAYING ... New clock: GstSystemClock Progress: (request) Sending PLAY request Progress: (request) Sending PLAY request Progress: (request) Sent PLAY request (gst-launch-1.0:2629): GStreamer-CRITICAL **: _gst_util_uint64_scale: assertion 'denom != 0' failed gst-launch-1.0: gen75_vpp_vebox.c:71: vpp_surface_convert: Assertion `src_obj_surf->orig_width == dst_obj_surf->orig_width' failed. Aborted
(In reply to comment #4) > Sorry, my fault. > With "weave" instead of "motion-weave" the pipe works. > > Anyway, the issue I reported at the beginning is still there. > Maybe this gives a hint: > > gst-launch-1.0 [h264i60-stream] ! vaapidecode ! vaapipostproc > deinterlace-mode=interlaced deinterlace-method=motion-compensated width=400 > height=300 ! vaapisink > > IPv4 based on 0.0.0.0 > IPv4 based on 192.168.0.14 > libva info: VA-API version 0.35.1 > libva info: va_getDriverName() returns 0 > libva info: Trying to open /usr/lib/dri/i965_drv_video.so > libva info: Found init function __vaDriverInit_0_35 > libva info: va_openDriver() returns 0 > Setting pipeline to PAUSED ... > Pipeline is live and does not need PREROLL ... > Got context from element 'vaapidecode0': gst.vaapi.Display=context, > display=(GstVaapiDisplay)NULL; > Progress: (open) Opening Stream > Progress: (connect) Connecting to rtsp://192.168.0.14:8554/stream > Progress: (open) Retrieving server options > Progress: (open) Retrieving media info > Progress: (request) SETUP stream 0 > Progress: (request) SETUP stream 1 > Progress: (open) Opened Stream > Setting pipeline to PLAYING ... > New clock: GstSystemClock > Progress: (request) Sending PLAY request > Progress: (request) Sending PLAY request > Progress: (request) Sent PLAY request > > (gst-launch-1.0:2629): GStreamer-CRITICAL **: _gst_util_uint64_scale: assertion This one will be dealt in another report. > 'denom != 0' failed > gst-launch-1.0: gen75_vpp_vebox.c:71: vpp_surface_convert: Assertion > `src_obj_surf->orig_width == dst_obj_surf->orig_width' failed. > Aborted Ah, my testing was done on Ivybridge. This assert() originates from the VA driver for Haswell. Maybe a bug in there with the VEBOX block.
Debugged and root cause it was a driver/libva issue. Please help to close it and open a need bug for driver/libva to track.
(In reply to comment #6) > Debugged and root cause it was a driver/libva issue. Please help to close it > and open a need bug for driver/libva to track. Closed, but NOT fixed. See https://bugs.freedesktop.org/show_bug.cgi?id=81199 *** This bug has been marked as a duplicate of bug 81199 ***
Test again and it works now. Issue fixed with libva/intel-driver version 1.5.0 (also with 1.5.0.pre1) Setup info: libva info: VA-API version 0.37.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/va/i965_drv_video.so libva info: Found init function __vaDriverInit_0_37 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.37 (libva 1.5.0) vainfo: Driver version: Intel i965 driver for Intel(R) Haswell Mobile - 1.5.0 gstreamer version 1.4.4 vaapi version 0.5.10.pre1 See also https://bugs.freedesktop.org/show_bug.cgi?id=81199 Thanks for support.