VideoImpl now creates the backend pipeline (queue->videoconvert->...->appsink)
Separate subclasses build a different frontend of the pipeline depending on the
type of video stream (uri, webcam , shared memory) that attaches to the backend
pipeline.
- VideoUridecodeBin: front-end for video file / uri
- VideoV4l2SrcBin: front-end for webcam (at the moment only works with
/dev/video*files, tested only on Ubuntu 14.04)
- VideoShmSrcBin: front-end for Shared memory / socket (used to work, currently
has problems)
Code is still hacky, needs work.
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 %)
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>
