live video switching (was: Linux Tools for Serious > Photographers)

[Luke Kuhn]

I didn't know LiVES could do anything like that, as it has to "import" all video files before use. Kdenlive (in repo, and which I use for making activist videos) works directly from existing video files or clips, does not need to import anything. Playing back a timeline in Kdenlive essentially live switches between them, but bogs down in transitions as that requires playing two videos at once.  I did find that using a rather large (100W) Nvidia450GTs video card with Noveau (NOT the proprietary driver) gave far better results in Kdenlive transitions than anything from ATI or any prop driver. Too bad OpenGL with that setup sucked.

Kdenlives uses KDE and ffmpeg (now avconv), would be a bear to package by default unless the QT libraries and a fair amount of KDE stuff also included. It's what I use, though, and I've tried most of the video editors I've seen for Linux, never once found one that was better or even remotely as good for making complex videos, from a wide variety of clips that may come in multiple formats.  Even AVCHD clips can be used, though I use avconv (formerly ffmpeg) to repackage their streams in .flv containers instead of .MTS to get reasonable seek times within them.

Putting Kdenlive and kgpg into a GNOME based intro, it's usually reasonable to throw in the rest of a basic KDE desktop as there's not a whole lot not already being pulled in, and you are going to have a rather large root filesystem. I did manage to get an old Maverick based system with these down to 2.7GB for a flash drive, but I'm usually looking at 4GB plus, especially with what happened in GNOME after Maverick.  On the other hand, if anyone ever made a "kubuntustudio" metapackage, Kdenlive would be a no-brainer to include in it.

Openshot (in repo) uses the same mlt/ffmpeg backend as Kdenlive and is GTK instead of QT based, unfortunately with far fewer editing capabilities.  Presumably that also plays back by liveswitching videos. The same concept is used commercially by some online video editing tools that work with previously uploaded videos only and do not make a new file, doing this whole liveswitching process on the remote end and feeding the resulting clips to Flash one after another. Usual privacy and security concerns of all "cloud computing" apply to their use, of course.

I don't know if Openshot lets you maximize the playback window, but Kdenlive does. Set up a timeline, maximize the window and you have a live video switcher ready to run, with just the playback window and play/ff/rw/stop/pause controls showing. In fact, this is the best way to check your work before you render.


> Date: Wed, 8 Aug 2012 07:59:14 +0900
> From: Emmet Hikory <persia at ubuntu.com>
> To: Ubuntu Studio Development & Technical Discussion
> 	<ubuntu-studio-devel at lists.ubuntu.com>
> Subject: Re: live video switching (was: Linux Tools for Serious
> 	Photographers)
> Message-ID: <20120807225914.GG3199 at gerdhr.shipstone>
> Content-Type: text/plain; charset=utf-8
> 
> Len Ovens wrote:
> > Took a while to find any docs for it... in the doc directory of the src
> > package. freemix is designed to do live showing switching of videos stored
> > as file on the computer like a VJ. I don't know if it can connect to a
> > gstream opened by another app or not. But it is not designed for it. It is
> > only available as a src package right now.
> 
>    Ah, indeed: the demo I saw must have either used named pipes or been
> a derivative of the sources currently on launchpad (engine.py would need
> extension to directly access non-file sources, although it's all gstreamer).
> Packaging this source is fairly trivial, if it's considered particularly
> useful: it's a clean setup.py and fairly sensibly licensed.
> 
> > However, I tried looking up VJ in synaptic and that spit out "LiVES",
> > already in the repos. In it's features page it says "Support for live
> > firewire cameras and TV cards". I don't know that we should ship it by
> > default, but extra sw yes.
> 
>     Unless someone can document a sensible video processing workflow
> (VJ, broadcasting, etc.) which is known to be well-done with it, I'm
> not sure it ought get any more or less attention than any of the other
> audio/video tools in the archive that aren't part of known workflows:
> while there's *lots* of software in the archive, and all of it is
> presumably useful and used by some folk, the more that we attempt to
> call supported (even as "extra sw"), the less I would expect we could
> refine the experience to be ideal for accomplishing real tasks.
> 
> -- 
> Emmet HIKORY
> 
> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-studio-devel/attachments/20120808/dd322c19/attachment.html>