If the imported file is a socket path, we mark the media as "live". We
continuously poll for the socket path (in case e.g. it disappears / reappears).
As soon as the source socket patch exists, we connect a shmsrc ! gdpdepay
pipeline (instead of a normal uridecodebin element for file-based media) and we
set the pipeline state to PLAYING (playAction button is not needed at the moment
for live sources, but we can change behaviour to only start the pipeline if
play is selected, like with normal file-based media)
In case of a GST_MESSAGE_ERROR, the polling function keeps looking for the
socket path until it exists again. The existing shmsrc pipeline is re-used
once the live source is transmitting again.
Tested with live source gst-launch-1.0:
gst-launch-1.0 uridecodebin uri=file:////opt/Videos/test.avi ! queue !
videoconvert ! video/x-raw, format="RGBA" ! gdppay ! shmsink
socket-path=/tmp/sock shm-size=100000000
The live source was interrupted and restarted again, and the shmsrc in mapmap is
able to pick up the reappearing media stream.
Signed-off-by: Vasilis Liaskovitis <vliaskov@gmail.com>
Doing the buffer pull in the gstreamer "new-buffer" callback decreases the work
needed to be done by the videoPull() thread. This seems to give lower average
timestamps between successive draw/updatecanvas() calls, so perhaps better
framerates can be achieved.
In order to decouple videoPull from pulling the buffer, an async queue is
introduced between the gstreamer "new-sample" callback and the qt videoPull
function. On the release path, gst_sample_unref is decoupled from the qt side by
putting the already used frame in an output async queue. The bffers in the queue
are unreferenced in the gst "new-sample" callback.
Tats