When one repeatedly launches gstreamer using h264 vpudec and then terminating it with killall it leads to situation where pipeline stops working. From log below it looks like that it doesn't properly free decoder and they run out. I couldn't replicate this behaviour by using gst-launch -e and properly termination it with ctrl-c sending EOS.
gst-launch-1.0: ../../source/h264high/h264hwd_asic.c:1009: H264RunAsic: Assertio
n `0' failed.
test: line 10: 5842 Aborted (core dumped) gst-launch-1.0 -e -v
$START vpudec ! textoverlay text="blabla" ! $SINK
[ 505.839740] audit: type=1701 audit(1520332016.986:12): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=5284 comm="rtpjitterbuffer" exe="/usr/bin/gst-launch-1.0" sig=6
[ 510.376891] hantrodec: DEC[0] still enabled -> reset
[ 510.417429] hantrodec: DEC[0] still enabled -> reset
[ 510.435842] hantrodec: DEC[0] still enabled -> reset
As side note how one builds h264 encoder? It could lead to easier example of videotestsrc ! encode h264 ! vpudec ! glimagesink
test scripts are
test:
gst-launch-1.0 ...(rtsp h264 stream from camera) ! vpudec ! glimagesink
runtest:
for ì in `seq 1 100`; do
sh test &
sleep 3
killall gst-launch-1.0
done
Ping,
I mostly want to know status, if somebody is looking into this or not?
Or if bugs should be reported in different system?
why would you stop the gstreamer again and again? it seems killall command doesn't release the memory, I don't know if we can use other option, could you tell me what's your demands of your case?
Mainly this should be at least documented.
As QA issue it means that one must put gstreamer parts into separate process to minimize risk of crash.
This means that one couldn't with not very important application like displaying weather that uses lot of third party code and gstreamer relaunch it when it crashes. It would cause more important applications failure after weather one crashes enough times.