GNOME Bugzilla – Bug 752558
0.6.0 vaapipostproc regression: segfault
Last modified: 2015-09-10 15:35:11 UTC
Created attachment 307655 [details] backtrace Hi, I was testing gstreamer-vaapi 0.6.0 and I've found a regression: the very same command worked in 0.5.10. Command (http://www.intel.co.uk/content/dam/www/public/us/en/documents/white-papers/video-encode-atom-e38xx-emgd-gstreamer-paper.pdf page 8): $ gst-launch-1.0 -e v4l2src device=/dev/video0 num-buffers=1800 ! video/x-raw,format=I420,width=640,height=480 ! vaapipostproc ! queue ! vaapiencode_h264 ! qtmux ! filesink location=test2.mp4 Info: $ rpm -qa | grep 'vaapi\|libva' | sortgstreamer1-vaapi-0.6.0-1.fc22.x86_64 gstreamer1-vaapi-debuginfo-0.6.0-1.fc22.x86_64 libva-1.5.1-1.fc22.x86_64 libva-intel-driver-1.5.1-1.fc22.x86_64 libva-utils-1.5.1-1.fc22.x86_64 $ uname -r 4.2.0-0.rc2.git0.1.fc23.x86_64 $ cat /etc/fedora-release Fedora release 22 (Twenty Two)
Created attachment 307657 [details] git bisect run scrpt I wrote a little test in order to run git bisect automatically between 0.6.0 and 0.5.10 in order to detect the bad commit. 9799875df41c263a2614cae37cb7405a032928db "vaapidecode: delayed src caps negotiation " seems the bad one. https://github.com/01org/gstreamer-vaapi/commit/9799875df41c263a2614cae37cb7405a032928db I run ./configure the same way gstreamer1-vaapi Fedora package is configured, in order to use make install. $ git bisect visualize commit 9799875df41c263a2614cae37cb7405a032928db Author: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com> Date: Thu Feb 26 12:24:55 2015 +0200 vaapidecode: delayed src caps negotiation Currently the src caps are set immediately after the sink caps are set, but in that moment the pipeline might not fully constructed and the video sink has not negotiated its supported caps and features. As a consequence, in many cases of playback, the least optimized caps feature is forced. This is partially the responsible of bug #744039. Also, vaapidecode doesn't attend the reconfigure events from downstream, which is a problem too, since the video sink can be changed with different caps features. This patch delays the src caps, setting them until the first frame arrives to the decoder, assuming until that very moment the whole pipeline is already negotiated. Particularly, it checks if the src pad needs to be reconfigured, as a consequence of a reconfiguration event from downstream. A key part of this patch is the new GstVaapiCapsFeature GST_VAAPI_CAPS_FEATURE_NOT_NEGOTIATED, which is returned when the src pad doesn't have a peer yet. Also, for a better report of the caps allowed through the src pad and its peer, this patch uses gst_pad_get_allowed_caps() instead of gst_pad_peer_query_caps() when looking for the preferred feature. v3: move the input_state unref to close(), since videodecoder resets at some events such as navigation. v4: a) the state_changed() callback replaces the input_state if the media changed, so this case is also handled. b) since the parameter ref_state in gst_vaapidecode_update_src_caps() is always the input_state, the parameter were removed. c) there were a lot of repeated code handling the input_state, so I refactored it with the function gst_vaapi_decode_input_state_replace(). https://bugzilla.gnome.org/show_bug.cgi?id=744618 Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com> Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com> $ git bisect log # bad: [daf5ea0be124febd808a7c5b51a74a873aaacf72] 0.6.0 # good: [a14ed0a78eba92ecf55789e631964f1663300d60] 0.5.10 git bisect start '0.6.0' '0.5.10' # skip: [b3eccdb72be42469ad0d4fc45ffb6a8f7b3ebf25] decoder: hevc: cosmetics. git bisect skip b3eccdb72be42469ad0d4fc45ffb6a8f7b3ebf25 # bad: [b1bbc087c1d00a30910673a61b2872cd629c9663] encoder: avoid GstVaapiCodedBuffer redefinition git bisect bad b1bbc087c1d00a30910673a61b2872cd629c9663 # good: [8c93c842ef8a19e2b3c296d9e33c31c07afd6ab0] plugins: add support for BGRA textures. git bisect good 8c93c842ef8a19e2b3c296d9e33c31c07afd6ab0 # bad: [ccccbf4b09c952306a154d343bf3b00722d43da7] gitmodules: Use https:// url instead of git:// for submodules. git bisect bad ccccbf4b09c952306a154d343bf3b00722d43da7 # bad: [5425a05bd4638ed068d4f6e1a6f5e1d162a01288] vaapidecode: re-indent (gst-indent) gstvaapidecode.c git bisect bad 5425a05bd4638ed068d4f6e1a6f5e1d162a01288 # bad: [e4f8d14979c4cdf18e5af5594ee02d59f3b3250b] vaapidecode: upload meta only if feature and allocation git bisect bad e4f8d14979c4cdf18e5af5594ee02d59f3b3250b # good: [3f28da7f5a224178d104992fe902212015dfb2e4] encoder: h264: add support for more than 2 views git bisect good 3f28da7f5a224178d104992fe902212015dfb2e4 # bad: [9799875df41c263a2614cae37cb7405a032928db] vaapidecode: delayed src caps negotiation git bisect bad 9799875df41c263a2614cae37cb7405a032928db # first bad commit: [9799875df41c263a2614cae37cb7405a032928db] vaapidecode: delayed src caps negotiation
What's the error? are you using gstreamer 1.4? Which chipset is used? I just tried with gstreamer 1.5 (current master) with haswell and that pipeline woks fine.
aha! a segfault... do you have a backtrace?
Does it work if you remove the queue between vaapispostroc and vaapiencode_h264?
reply to Víctor Manuel Jáquez Leal from comment #2) > What's the error? are you using gstreamer 1.4? Which chipset is used? Segfault. $ rpm -q gstreamer1 gstreamer1-1.4.5-1.fc22.x86_64 $ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09) $ cat /proc/cpuinfo | grep -m1 '^model name' model name : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz > I just tried with gstreamer 1.5 (current master) with haswell and that > pipeline woks fine. I upgraded gstreamer and it still segfaults. $ rpm -q gstreamer1 gstreamer1-1.5.2-1.fc23.x86_64 (In reply to Víctor Manuel Jáquez Leal from comment #3) > aha! a segfault... do you have a backtrace? It's attached to this bug: https://bugzilla.gnome.org/attachment.cgi?id=307655 (In reply to Víctor Manuel Jáquez Leal from comment #4) > Does it work if you remove the queue between vaapispostroc and > vaapiencode_h264? Yes, it works.
(In reply to Víctor Manuel Jáquez Leal from comment #4) > Does it work if you remove the queue between vaapispostroc and > vaapiencode_h264? Sorry, it doesn't. I said yes because I removed vaapispostroc instead of queue.
Strange! Issue is not reproducible for me !! Tested with 1.4.3 and 1.5(git master) on my HSW machine...
(In reply to sreerenj from comment #7) > Strange! Issue is not reproducible for me !! > Tested with 1.4.3 and 1.5(git master) on my HSW machine... I have just tested with gstreamer 1.4.5 / HSW and works. Reading the backtrace, it looks like a very pathological situation: vaapipostproc's src pad queries itself recursively until all the memory is consumed. I can't imagine which circumstances can lead to the vaapostproc's src pad could query itself, just a bug in gst_pad_get_allowed_caps() in your setup.
Is there something I can do in order to help you?
(In reply to Francesco Frassinelli from comment #9) > Is there something I can do in order to help you? mmmhh... can you upload a debug log?? Something like gst-launch-1.0 -e v4l2src device=/dev/video0 num-buffers=1800 ! video/x-raw,format=I420,width=640,height=480 ! vaapipostproc ! queue ! vaapiencode_h264 ! qtmux ! filesink location=test2.mp4 --gst-debug="vaapipostproc:5,*:3"
Created attachment 307828 [details] Debug log (no colors, no timestamps) (In reply to Víctor Manuel Jáquez Leal from comment #10) > gst-launch-1.0 -e v4l2src device=/dev/video0 num-buffers=1800 ! > video/x-raw,format=I420,width=640,height=480 ! vaapipostproc ! queue ! > vaapiencode_h264 ! qtmux ! filesink location=test2.mp4 > --gst-debug="vaapipostproc:5,*:3" No output from vaapipostproc. I tried to generate a debug log with this command: $ gst-launch-1.0 -e v4l2src device=/dev/video0 num-buffers=1800 ! video/x-raw,format=I420,width=640,height=480 ! vaapipostproc ! queue ! vaapiencode_h264 ! qtmux ! filesink location=test2.mp4 --gst-debug="*:5" --gst-debug-no-color |& cut -b31- | xz -ec -T 4 > vaapipostproc-debug.log.xz The uncompressed file is abot ~380 MB, while the compressed one is less than 500 KB. You can use xzcat vaapipostproc-debug.log.xz | less or similar in order to read it.
It seems that gst_pad_get_allowed_caps() leads to loops in the case of basetransform elements. But I still don't understand why. I see the loop in the log but not the reason of if. It is strange that it is not happening to Sree neither to me. Can you try with autovideosrc??
Created attachment 307844 [details] [review] plugins: don't use gst_pad_get_allowed_caps() gst_pad_get_allowed_caps() query the pad and the peer pad. In the case decoders, that is OK, but in the case of the postproc might lead loops, since the gst_base_transform_query_caps() forwards the query upstream and forth. Instead of gst_pad_get_allowed_caps() we only query the peer with gst_pad_peer_query_caps() using the pad's template as filter. Signed-off-by: Víctor Manuel Jáquez Leal <victorx.jaquez@intel.com>
Francesco, can you try also with the posted patch? I'm not sure if it is really needed, though...
Created attachment 307848 [details] Debug log, using autovideosrc (no colors, no timestamps) (In reply to Víctor Manuel Jáquez Leal from comment #12) > Can you try with autovideosrc?? $ gst-launch-1.0 -e autovideosrc ! video/x-raw,format=I420,width=640,height=480 ! vaapipostproc ! queue ! vaapiencode_h264 ! qtmux ! filesink location=test2.mp4 --gst-debug="*:5" --gst-debug-no-color |& cut -b31- | xz -ec -T 4 > vaapipostproc-debug.log.xz No segfault, exit code is 0. (In reply to Víctor Manuel Jáquez Leal from comment #14) > Francesco, can you try also with the posted patch? > > I'm not sure if it is really needed, though... Patch applied to 0.6.0 and I got no segfault :) Tested with v4l2src and ximagesrc, everything seem to work correctly!
(In reply to Francesco Frassinelli from comment #15) > Created attachment 307848 [details] > Debug log, using autovideosrc (no colors, no timestamps) > > (In reply to Víctor Manuel Jáquez Leal from comment #12) > > Can you try with autovideosrc?? > > $ gst-launch-1.0 -e autovideosrc ! > video/x-raw,format=I420,width=640,height=480 ! vaapipostproc ! queue ! > vaapiencode_h264 ! qtmux ! filesink location=test2.mp4 --gst-debug="*:5" > --gst-debug-no-color |& cut -b31- | xz -ec -T 4 > vaapipostproc-debug.log.xz > > No segfault, exit code is 0. Weird. Perhaps it is a bug in your camera's software stack. Dunno. > > (In reply to Víctor Manuel Jáquez Leal from comment #14) > > Francesco, can you try also with the posted patch? > > > > I'm not sure if it is really needed, though... > > Patch applied to 0.6.0 and I got no segfault :) Tested with v4l2src and > ximagesrc, everything seem to work correctly! With ximagesrc didn't work either?
(In reply to Víctor Manuel Jáquez Leal from comment #16) > (In reply to Francesco Frassinelli from comment #15) > > (In reply to Víctor Manuel Jáquez Leal from comment #14) > > > Francesco, can you try also with the posted patch? > > > > > > I'm not sure if it is really needed, though... > > > > Patch applied to 0.6.0 and I got no segfault :) Tested with v4l2src and > > ximagesrc, everything seem to work correctly! > > With ximagesrc didn't work either? I tested ximagesrc changing the pipeline a little bit, and it work even without the patch. Do you think that this bug should be reassigned to v4l2src or something else?
(In reply to Francesco Frassinelli from comment #17) > > Do you think that this bug should be reassigned to v4l2src or something else? Actually, I am not sure.
Attachment 307844 [details] pushed as c76fe74 - plugins: don't use gst_pad_get_allowed_caps()