GNOME Bugzilla – Bug 705531
h264parse does not always properly reset when put to STATE_NULL
Last modified: 2016-02-21 12:24:53 UTC
Hi, I have a dynamic pipeline where I have two bins doing double buffering (see below) [1]. It works if I use fresh bins with all elements factory made. Once I swap them back and try to recycle a bin it does not work anymore. I tried to set the bins into STATE_NULL but it does not really reinitializes them. I first thought it might be the mp4mux, but I made now some better debugging and everything works if I replace the h264parse with a new one between the swaps. Strangely, the pipeline does not crash, it seems as the h264parse is throwing the buffers away. (There seems to be no memory leak either). Unfortunately (for debugging purposes) everything works perfectly if I do not use the uvch264src but if I read a mp4 file from disk [2]. I am working on git HEAD (I just pulled again and tested against it) [1] gst-launch-1.0 -e uvch264src device=/dev/video1 name=src auto-start=true src.vfsrc ! queue name=prevQueue ! video/x-raw,width=320,height=240,framerate=30/1 ! autovideosink name=previewsink src.vidsrc ! queue name=vidQueue ! video/x-h264,width=1920,height=1080,framerate=30/1,profile=constrained-baseline ! tee name=t ! queue ! h264parse ! avdec_h264 ! autovideosink t. ! queue name=srcQueue ! myBin Template of bins I swap around: myBin: queue name=fileQueue1 ! h264parse name=ph264_1 ! mp4mux name=mux_1 ! filesink name=filesink1 location="test.mp4" [2] filebased version: gst-launch-1.0 -e filesrc location="/run/media/peter/home/tmp/webcam/Video 66.mp4" ! qtdemux ! queue ! tee name=t ! queue ! h264parse ! avdec_h264 ! autovideosink t. ! queue ! h264parse ! mp4mux ! filesink location=/run/media/peter/home/tmp/webcam/test.mp4
Created attachment 251109 [details] C file showing this issue
I initially wrote the program in python. I converted it to C now. The problem persists. I uploaded a gist (https://gist.github.com/groakat/6179024) and you can also find it attached. Please read the top of the file to know what user input is required. I apologize that I did not make the effort to embed the preview stream in the gtk window ;). You will have to click the PAUSE button to swap to another file and reproduce the effect. If you want to can uncomment #define TEST_RECYCLE to see it working with fresh bins. You can also play around with the resetBin() function and instead of re-making the entire recBins, just remake some elements. With python I found the h264parse to be the guilty one. I will upload the python version tomorrow. Stay tuned if you prefer to play around with that.
Can't you provide a simpler testcase for this? If h264parse really just forgets to clean up properly when resetting it, it should be possible to write a much simpler testcase. Something that just has "filesrc ! h264parse ! fakesink" and does something with it. Can you try to provide something simpler, also something that compiles without hundreds of warnings? :)
Created attachment 252214 [details] Now with less warnings I tackled the warnings. There is only one left, which I am not able to resolve: parseBug.c:316:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] event = (GstEvent*) gst_video_event_new_upstream_force_key_unit(GST_CLOCK_TIME_NONE, TRUE, data->cnt); gst_video_event_new_upstream_force_key_unit is supposed to return a GstEvent* but it seems to return an int. Anyway, I am think that has no effect since the pipelines does swap anyway. Regarding providing a simpler example. This is as simple as I can think of. Because the bug only happens if the h264parse is reused. And it only happens with the camera. Using the same pipeline with a filesrc loading an mp4 file, does not reproduce the problem.
Well, then I have really no way to reproduce it here unfortunately :( It should be possible to reproduce with a simple "filesrc ! h264parse ! fakesink" pipeline if the input has the same format as what your camera produces, and you re-use the same parser on the input again (set it back to READY, then start it all again). Btw, that remaining warning happens because you don't include <gst/video/video.h>.
Needs a simpler test case, but in any case this might have been fixed in the last few years anyway. Please re-open if it's still an issue with current versions of GStreamer, thanks!