GNOME Bugzilla – Bug 761194
gstreamer-vaapi resolution mismatch issue (regression?)
Last modified: 2016-04-29 08:47:01 UTC
I'm seeing a weird issue with gstreamer-vaapi, and some people on the gstreamer-devel mailing suggested that I file a bug. I have some benchmark pipelines that I have been running for quite a while on Ubuntu 15.04 (Gstreamer 1.4ish) with no issues. One pipeline uses vaapidecode/vaapiencode_h264 to do a transcode on the original "Big Buck Bunny" movie (the first release, 1080p, 24fps version). On 15.04 and Gstreamer 1.4, this pipeline worked fine: gst-launch-1.0 filesrc location=/ramdisk/bbb_original_1080p_24fps.mov ! qtdemux ! vaapidecode ! vaapiencode_h264 ! video/x-h264,profile=main ! h264parse ! qtmux ! filesink location=/ramdisk/somefile.mov However, on a newly loaded 15.10 install (same hardware), I get an error, the main message being: ERROR: from element /GstPipeline:pipeline0/GstQTDemux:qtdemux0: GStreamer encountered a general stream error. Looking through the output of gst-launch -v, I see that the resolution changes from 1920x1080 to 1920x1088 at some point in the negotiation. Thinking this is weird, I run avprobe on the file, and notice this: width=1920 height=1080 coded_width=1920 coded_height=1088 Thinking that there is some weird resolution mismatch here, I add a vaapipostproc width=1920 height=1080 element to the pipeline to force scaling, and it runs fine. If no one has the time to look at this right away, pointers or suggestions on what might be wrong would be greatly appreciated. Thanks in advance, Bill Katsak FULL OUTPUT OF gst-launch -v BELOW ------------------------------------------------------------------------- libva info: VA-API version 0.38.1 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_38 libva info: va_openDriver() returns 0 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Got context from element 'vaapidecode0': gst.vaapi.Display=context, display=(GstVaapiDisplay)NULL; /GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:src: caps = "video/x-h264\,\ stream-format\=\(string\)avc\,\ alignment\=\(string\)au\,\ level\=\(string\)4.1\,\ profile\=\(string\)main\,\ codec_data\=\(buffer\)014d4029ffe10016274d4029a9180f0044fcb8035010101b6c2b5ef7c04001000428de09c8\,\ max-input-size\=\(int\)511608\,\ width\=\(int\)1920\,\ height\=\(int\)1080\,\ framerate\=\(fraction\)625/26\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ parsed\=\(boolean\)true" /GstPipeline:pipeline0/GstVaapiDecode:vaapidecode0.GstPad:sink: caps = "video/x-h264\,\ stream-format\=\(string\)avc\,\ alignment\=\(string\)au\,\ level\=\(string\)4.1\,\ profile\=\(string\)main\,\ codec_data\=\(buffer\)014d4029ffe10016274d4029a9180f0044fcb8035010101b6c2b5ef7c04001000428de09c8\,\ max-input-size\=\(int\)511608\,\ width\=\(int\)1920\,\ height\=\(int\)1080\,\ framerate\=\(fraction\)625/26\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ parsed\=\(boolean\)true" /GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:sink: caps = "video/x-h264\,\ stream-format\=\(string\)avc\,\ alignment\=\(string\)au\,\ level\=\(string\)4.1\,\ profile\=\(string\)main\,\ codec_data\=\(buffer\)014d4029ffe10016274d4029a9180f0044fcb8035010101b6c2b5ef7c04001000428de09c8\,\ max-input-size\=\(int\)511608\,\ width\=\(int\)1920\,\ height\=\(int\)1080\,\ framerate\=\(fraction\)625/26\,\ pixel-aspect-ratio\=\(fraction\)1/1" Redistribute latency... /GstPipeline:pipeline0/GstVaapiDecode:vaapidecode0.GstPad:src: caps = "video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)1920\,\ height\=\(int\)1080\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ chroma-site\=\(string\)mpeg2\,\ colorimetry\=\(string\)bt709\,\ framerate\=\(fraction\)625/26" /GstPipeline:pipeline0/GstVaapiEncodeH264:vaapiencodeh264-0.GstPad:sink: caps = "video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)1920\,\ height\=\(int\)1080\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ chroma-site\=\(string\)mpeg2\,\ colorimetry\=\(string\)bt709\,\ framerate\=\(fraction\)625/26" Redistribute latency... /GstPipeline:pipeline0/GstVaapiDecode:vaapidecode0.GstPad:src: caps = "video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)1920\,\ height\=\(int\)1088\,\ interlace-mode\=\(string\)progressive\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ chroma-site\=\(string\)mpeg2\,\ colorimetry\=\(string\)bt709\,\ framerate\=\(fraction\)625/26" ERROR: from element /GstPipeline:pipeline0/GstQTDemux:qtdemux0: GStreamer encountered a general stream error. Additional debug info: qtdemux.c(5306): gst_qtdemux_loop (): /GstPipeline:pipeline0/GstQTDemux:qtdemux0: streaming stopped, reason not-negotiated ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... /GstPipeline:pipeline0/GstVaapiEncodeH264:vaapiencodeh264-0.GstPad:sink: caps = "NULL" /GstPipeline:pipeline0/GstVaapiDecode:vaapidecode0.GstPad:src: caps = "NULL" /GstPipeline:pipeline0/GstVaapiDecode:vaapidecode0.GstPad:sink: caps = "NULL" /GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:src: caps = "NULL" /GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:sink: caps = "NULL" /GstPipeline:pipeline0/GstQTDemux:qtdemux0.GstPad:video_0: caps = "NULL" Freeing pipeline ..
There's a caps negotiation failure here between vaapidecode and vaapiencode_h264. It appears that vaapidecode decides it wants to renegotiate from 1920x1080 to 1920x1088 after decoding the first surface and vaapiencode_h264 does not accommodate it. I'll look more into this on Monday.
Sree's fix for Bug 753914 (vaapidecode: Always report cropped resolution in src caps) fixes this case by not trying to renegotiate with un-cropped width and height.
Are you thinking those patches should solve the issue? They should already be in the latest release, no? The issue is still occurring with 1.7.91.
Sorry no I was referring to the patches that Sree has in his staging tree that are not yet in master. Specifically: 389ed9e Fix decide_allocation handling 558243a vaapidecode :Avoid repeated assigning of decoded surface resolution c233f7d vaapidecode: Fix typo mistake in previous commit 6e64d9d vaapidecode: Derive and save the decoded surface format 5712409 Make vaapidecode to advertise the cropped values in srcpad, but negotiate pool only if needed 80e08c2 vaapidecode: Delay the output format setting until we have a decoded surface
Oh ok, thanks. Do you have a pointer to his tree? I can pull it in and test it in my environment, if that is helpful.
Yep, Sree's tree is here: https://cgit.freedesktop.org/~sree/gstreamer-vaapi/ it looks like his most up to date patches are on the 'staging' branch. I'm not sure he has all of the bugs shaken out of his patches yet, but it was fixing the pipeline in this bug for me.
His tree (master) does indeed work, with everything else being the same. My vainfo, just FYI: libva info: VA-API version 0.39.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/local/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_39 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.39 (libva 1.7.0) vainfo: Driver version: Intel i965 driver for Intel(R) Broadwell - 1.7.0
These patches are still WIP, will push only after the 1.8 release since it may affect all playback pipelines :)
Anyway good to know, those patches fixing the reported issue, Thanks! There are few other related bugs too. Plan is to investigate/test/close all these bugs after 1.8 release.
The current git master has all the patches in. Please have a test and close if issue resolved, thanks !
Closing, feel free to reopen if issue persists.
Sorry to ping on this topic, wanted to ask when these patches are expected to hit a release? This issue still persists in 1.8.1...is it expected to? I can't easily see if all of these patches made it in yet...Thanks!
(In reply to William Katsak from comment #12) > Sorry to ping on this topic, wanted to ask when these patches are expected > to hit a release? This issue still persists in 1.8.1...is it expected to? I > can't easily see if all of these patches made it in yet...Thanks! The patches are in master, they were not rebased into 1.8 branch because they are big and risky. So they will be released in the 1.9.x series, which are unstable, and finally in 1.10.