GNOME Bugzilla – Bug 795770
vaapih264dec: hangs when decoding a defect stream
Last modified: 2018-11-03 15:54:14 UTC
If a defective stream is decoded by gstreamer with vaapi, the pipeline hangs and can't be stopped anymore with setting the pipeline state to GST_STATE_NULL. This call will block forever. A pcap stream to reproduce this can be found here: https://barcozone-my.sharepoint.com/:u:/g/personal/thomas_scheuermann_barco_com/EQ8TkhCtzEpFoc3RkFzcpBoBZTxhPF1xERHu6XwFhMwBpQ?e=NhTqE0 The pcap file can be played with sudo tcpreplay-edit -l 0 -i <network interface> --pnat=172.23.0.26:<local address>,172.20.51.163:<remote address> --enet-dmac=<remote mac> gstlock2.pcap The pipeline can be started the following way: gst-launch-1.0 udpsrc uri="udp://0.0.0.0:34338" ! application/x-rtp,encoding-name=H264 ! rtph264depay ! h264parse ! vaapih264dec ! vaapisink The pipeline doesn't hang if avdec_h264 is used. Regards, Thomas
Thanks for reporting this. I have troubles replaying the pcap file. Could you upload a log file GST_DEBUG=vaapi*:5 ??
Created attachment 371773 [details] Error log with GST_DEBUG=vaapi*:5 This is the log file with stderr and stdout for GST_DEBUG=vaapi*:5.
I don't see any strange in the logs. What happens if you add vaapispostproc after the decoder or use vaapidecodebin (which is a bin of decoder + queue + postproc)???
At the end of the log there is the line 0:00:10.761486320 17388 0x55587b219c00 DEBUG vaapi gstvaapidecoder_h264.c:1859:parse_slice: parse slice After this line nothing happened anymore. Then I pressed CTRL-C After this it is tried to stop the pipeline, but this will then hang also.
Which trouble do you have replaying the pcap file?
(In reply to Thomas Scheuermann from comment #5) > Which trouble do you have replaying the pcap file? Sorry for the delay. My main question is how to play it. Do I need a second computer to replay it? I tried in a single computer I and didn't receive any data.
Yes, I use two computers. On one I do the replay and the decoding on the other. I think it only works with two computers.
Could you reproduce it with two computers?
Thanks for the ping. Yes. I can reproduce the issue. As matter of fact I could dump a h264 raw file with the stream[1] and the issue is still reproducible. Even ffmpeg complains about the POC "co located POCs unavailable" If I understand correctly, the stream has a large GOP with a lot of B frames, depending on a non-existing I frame, thus the DPB grows and exhaust the available VA surfaces. 1. https://www.ceyusa.com/media/bug795770.h264 (I can remove it if you wish).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/94.