We now create an audio pipeline with a volume gstreamer element. The "volume"
property of the element has a range of 0.0 - 1.0 and is 0.0 by default (i.e.
effectively muted input). The property can be seen and changed in the paint
property browser (in %)
GST_MESSAGE_ASYNC_DONE is received when elements finish changing state. If we
initiate an updateRate here, we keep generating seek events in a loop forever,
pausing and re-starting the pipeline without reason.
Buffer releasing should happen independently of videoPull() getting called for
texture updates. We move all processing and buffer unreferencing in
gstNewSampleCallback. This way we don't run out of memory in case of video
pipeline playing without texture/mappings.
Shmsrc seems to work with a gstreamer 1.4 build, but not with distro gstreamer
(segfault due to missing fix https://bugzilla.gnome.org/show_bug.cgi?id=731093)
Reader / writer of live source need to be using same gstreamer build, otherwise
some pipeline problems appear in deserializing and caps detection.
Playback of the first shape mapped with the live source doesn't seem to work (?),
so this bug stiil needs investigation.
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.
The gst_sample pulled from the appsink is already reference counted. We just
need to unref it after copying it, which we do.
If we reference it again, the sample/buffer is not freed - I have seen the app
crashing while consuming most of system memory (can lead OS to out-of-memory
condition) before this commit.
Tats