I have a scenario in which I am processing an mp4 file in batch mode using VideoCapture via gstreamer. In this case appsink requires the sync=false property so that the execution is at fastest speed without delays.
The problem is that the appsink is configured by cap_gstreamer.cpp as drop with buffer 1. Using the property CV_CAP_GSTREAMER_QUEUE_LENGTH to modify the buffering makes the pipeline crash probably because it is not
Example (OSX with OpenCV 3.2.0) with the following input
Performance motivato: the same FULL HD video playbacks in 100-200 us using gstreamer and in 3-4ms using the hardware decoding provided by OSX VideoToolbox and made accessible by gstreamer via vtdec_hw.
I have a scenario in which I am processing an mp4 file in batch mode using VideoCapture via gstreamer. In this case appsink requires the sync=false property so that the execution is at fastest speed without delays.
The problem is that the appsink is configured by cap_gstreamer.cpp as drop with buffer 1. Using the property CV_CAP_GSTREAMER_QUEUE_LENGTH to modify the buffering makes the pipeline crash probably because it is not
Example (OSX with OpenCV 3.2.0) with the following input
filesrc location=x.mp4 ! qtdemux ! h264parse ! vtdec_hw ! videoconvert ! appsink sync=false
Performance motivato: the same FULL HD video playbacks in 100-200 us using gstreamer and in 3-4ms using the hardware decoding provided by OSX VideoToolbox and made accessible by gstreamer via vtdec_hw.
The specific error is with qtdemux.