Video Support including Fading

[tobi08151405]

Extension of Basic Video Support

This PR builds upon #333 .

This PR provides:

• Fade of video cues using the "Alpha" plugin
• System sink expanded to also use autovideosink
• Automatic adjustment and linking in the pipeline for audio-/video- and audiovideo-cues

TODO

• Fade of Audio and Video currently happen after eachother not concurrently
• adjust other video parameters (brightness, contrast, etc)
• most of the TODOs from Basic Video support #333

[tobi08151405]

@FrancescoCeruti I could not figure out how to let the fade of audio and video happen simultaneously when fading a Media with Audio an Video. I marked the functions as async, but that did not help. (See lisp/cues/media_cue.py)

[FrancescoCeruti]

@tobi08151405 since Fader.fade() is blocking, you cannot simply iterate over them, or they will run sequentially. async is a whole different world.

What I would do is one of these two:

• refactor BaseFader and subclasses to allow for multiple "targets" at the same time
• create a FadersGroup class that can "orchestrate" multiple Fader objects, it should implement a fade() method that, using a ThreadPoolExecutor, can start the faders and wait for them to finish

[tobi08151405]

@tobi08151405 since Fader.fade() is blocking, you cannot simply iterate over them, or they will run sequentially. async is a whole different world.

What I would do is one of these two:

* refactor `BaseFader` and subclasses to allow for multiple "targets" at the same time

* create a `FadersGroup` class that can "orchestrate" multiple `Fader` objects, it should implement a fade() method that, using a `ThreadPoolExecutor`, can start the faders and wait for them to finish

I implemented a FaderGroup as suggested,
I also refactored the whole alpha/fade pipeline which can be handled much easier

[tobi08151405]

I now added a few basic video filters.
And I also fixed up the review notes of #333 , without the separate pipelines, since I removed them in my branch

[s0600204]

Thank you for continuing on the work on this.

I haven't looked at the code: the following is merely from playing with a few random video clips. Also, as mentioned elsewhere, I don't have Wayland support on my computer yet, so the following is for the "System Out" sink only (and the List Layout).

(It's worth noting that I use the "Jack Sink" when running shows, and whilst that does work - to playback the audio of video clips - for obvious reasons I don't get the video output when doing this.)

General notes:

• It would be nice to specify where the video output is sent (instead of a new window on top of LiSP). I realise (from the documentation) that AutoVideoSink doesn't directly provide this functionality (unlike the Wayland sink), but the documentation for xvimagesink (which autovideosink uses under the hood on my machine) mentions GSTVideoOverlay, an interface through which it is possible to designate a pre-existing window to draw video on top of. Whether it is possible to create a dedicated, borderless, window that is placed programmatically, and draw all video there, is perhaps something to look into.

• If the user closes the output window, an error is raised (ERROR GStreamer: Output window was closed) that should probably be caught and handled gracefully.

The new media elements:

• Adding the "Alpha" element appears to break media looping for the clip it's added to - on some clips it doesn't loop at all, on others the audio loops but the video stalls/glitches before freezing.

• Adding the "Rotate" element makes the output image somewhat fuzzy. Then again, this happens outside of LiSP by simply invoking gst-launch-1.0 -v videotestsrc ! rotate angle=0 ! videoconvert ! autovideosink on the command line, so it's not your code.

• Also, with "Rotate" - moving the slider to the right spins the images to the left (counter-clockwise), which is backwards to how I'd expect it. Whilst this is probably down to the backend interpreting positive numbers as a CCW rotation and negative as CW, it still seems (to me) to be un-intuitive. Perhaps a rotational widget (see QDial) would be better?

• May I suggest adding a caption to the configuration of the "Blur" element so as to (a) explain what "Sigma" means, (b) hint at what a negative value is supposed to do, and (c) warn that high (positive or negative) values will/may cause juddering?

[s0600204]

Vertical

[linuxnow]

Could this be included in next version? This is a game changer :)