Lycheese

As every other personal project in FOSS Lycheese is a personal itch in a software niche, video screencasting tools.

The main purpose is to be an alternative to other projects like kazam or vokoscreen, simpler than Open Broadcaster but still fast enough to be used on my laptop.

My first thought was to hack my way through the Cheese app and just re-route the video from the file to a RTMP server (Youtube) but I couldn’t really find a viable way, Cheese is written in Vala, a (de-facto esotheric) programming language sponsored by the Gnome Foundantion.

What I couldn’t learn from the source code I have learnt from the Vala subreddit and the documentation but after a while everything felt more connected and in place, I could see how Cheese was working and how could I learn to develop my idea from it.

So my first attempt was a draft made translating GStreamer commands in Vala but it could not record my screen in a file. I was very happy to see my idea working with the GStreamer script but it wasn’t working as expected when used from Vala, how disappointing!

I finally solved the issue crawling the web for more information on Gstreamer and how to use it. The issue was that when used from the “outside” GStreamer requires a loop to work. That was a good day!

My first draft for a real app with a user interface can be found here, I don’t even remember if it was working as expected but it felt glorious to have a project targeting my real issue.

What is the magic behind Lycheese

Obviously I’m no miracle worker and I used a lot of already available software to develop Lycheese. Even if someone may call it an application I prefer to say that it is a GUI wrapped around a GStreamer pipeline.

Working with GStreamer has been fairly easy, there are examples, tutorial, conference’s talks about GStreamer and how you should use it but the key point is that it has been thought in a really easy and obvious way, as a pipes, sources and sinks.

Everyone can understand sources, pipes and sinks; liquid flows from sources through pipes to sinks, that’s it. The same concept is adapted to video processing, there is a source, you can add a pipe where the transformation happens (think inverted colours), add another pipe (downscaling) and so on until the video is dropped into a sink (in a window, in a file, on the internet, is discarded, …).

It’s so easy you can write it as a story or as a flux diagram.

And now the story powering the Lycheese internal.

These are the nodes of my pipeline with the annotation of their role

Gst.Element audio; // audio source
Gst.Element audio_queue; // a bucket
Gst.Element aac_encoder; // a pipe that create a valid AAC audio stream
Gst.Element screen; // video source
Gst.Element color_convert; // a pipe that format correctly the video source
Gst.Element video_queue; // another bucket
Gst.Element x264_encoder; // a pipe that create a valid H264 stream
Gst.Element flv_muxer; // pipe junction
Gst.Element stream_queue; // another bucket
Gst.Element rtmp_sink; // sink

There are 2 sub-pipeline, merging in one that is the piped into a remote server.

The audio pipeline.

// audio pipeline

Gst.Element audio;
Gst.Element audio_queue;
Gst.Element aac_encoder;

// audio -> audio_queue -> aac_encoder

audio.link (audio_queue);
audio_queue.link (aac_encoder);

The video pipeline.

// video pipeline
Gst.Element screen;
Gst.Element color_convert;
Gst.Element video_queue;
Gst.Element x264_encoder;

// screen -> color_convert -> video_queue -> x264_encoder

screen.link (color_convert);
color_convert.link (video_queue);
video_queue.link (x264_encoder);

And the output pipeline

Gst.Element aac_encoder;
Gst.Element x264_encoder;
Gst.Element flv_muxer;
Gst.Element stream_queue;
Gst.Element rtmp_sink;

// aac_encoder    x264_encoder
//     |                |
//     ------------------
//              |
//          flv_muxer

 
// merge the audio and video in a unique container
aac_encoder.link (flv_muxer);
x264_encoder.link (flv_muxer);

// flv_muxer -> stream_queue -> rtmp_sink -> the internet

// ship the available data to the remote server
flv_muxer.link (stream_queue);
stream_queue.link (rtmp_sink)

This is it, easy to work with and flexible enough.

Why Vala for me

What I really enjoyed working with are signals; with signals I can keep my components decoupled and I feel confident that if needed I can swap everything without breaking the other components, when I read about them in the Vala tutorial I istantly new they were incredibily useful. Now I can’t imagine working with Gtk without signals, they are too convenient to be given up.

Overall working with Vala has been a good experience, I still have some issue to work with while polishing Lycheese but it’s getting there.

From my experience Vala really feels like you are using C but with a better understanding of the real world requests, it doesn’t feel like magic (Python, Ruby, ..), it does not make you feel stupid (C, C++, …), it works pretty much everywhere and has been thought for high level tasks.

The future

Coming back to Lycheese I have to say that there are still issues with the interface, the usability and the availability of Lycheese but here are the key point in the future development:

• Lycheese should be available with package managers as FOSS
• The interface should be simple but rock-solid

Package managers

Because no one install from source release anymore, even if it is as simple as

./autogen.sh
make
make install

My first target will be Debian, mainly because is my distro of choice, then maybe I can find some other mantainer for different distribution (Arch and Fedora are secondary target); I fiddled previously with the Debian package creator and I am confident I can find a reliable and semi-automatic process but I think I should ask a real mantainers what the real process is and what tools are out there.

Simpler interface

A simpler interface should be a good point both for the user and for me, the developer, easier to use, easier to mantain so why not?

Right now I am toying with the idea of strictly applying the Gnome Human Interaface guidelines and try to submit it to the Gnome Apps revision (is there a revision?) but there is always the idea to just ship it as an independent or with Elementary OS which, by the way, uses Vala as their tool of choice when developing their software.

A modern build tool and IDE

Right now I am pretty much satysfied with the GNU build tools chain I set up but I think a simpler approach could be using Gnome Builder.

Gnome Builder is the IDE for the Gnome Environment and it supports Vala (syntax highlighting, code completion, …) but I couldn’t use it because the requirements are too modern and I prefer a stabler environment (currently running Debian on all my machines).

If anyone is interested in porting the building pipeline to the Builder environment I’m open to contributions.