Screen recorder - Kazam

Sun Jan 1 18:47:32 UTC 2012

Hi,

On Sun, Jan 1, 2012 at 5:59 AM, David Klasinc <bigwhale at lubica.net> wrote:
> Thanks for the response Sean,
>
> On 12/31/2011 09:03 PM, Sean McNamara wrote:
>
>> Very cool! While I completely agree that these codec choices should be
>> the default, is it easy for the user to configure Kazam to use some
>> other codec? I'm not saying VP8/WebM is bad; rather, I'm saying some
>> other codecs may have their uses (e.g. if you intend to distribute it
>> as a raw video and you want the highest platform compatibility, VP8 is
>> still not that heavily adopted on older Windows systems, or even older
>> Linux distros). And the quality will be much higher if it is encoded
>> directly to the format that you intend to distribute it in, rather
>> than performing lossy transcoding.
>
> VP8 is a trade-off between quality and availability. Codecs and their
> support in most modern Linux distribution is still a nightmare. There
> are different versions of libraries that support different sets of
> parameters and options. VP8 is something that is available everywhere
> and has a decent support in GStreamer.
>
> Kazam initially encoded videos with ffmpeg and used libx264 (getting
> this to work on Linux is not an easy task even now. You have to build
> ffmpeg from source because of all the licensing and patent issues.
>
> Personally I would prefer H264 over VP8. H264 is better, performance
> wise and quality wise. VP8 is still a resource hog and encoding full
> screen video with more than 15 fps in realtime can be challenging.
>
> In the long run I want to support different codecs with some kind of
> auto detection what is available and what not.

IMHO you shouldn't directly use ffmpeg, libx264, or any other library.
For all of your media needs, just use GStreamer. GStreamer has gst
plugin wrappers for all of the useful ffmpeg codecs (gst-ffmpeg), and
it has plugin wrappers for all of the important standalone codec
libraries (including x264). The challenge is getting the user to
install them. ;)

For starters, you could add most of the gstreamer plugins packages as
either suggested or recommended in the Debian source package. If the
packages somehow don't get installed automatically (they would get
installed if you Recommend them and install Kazam with apt-get), you
could write a simple "Available Codecs" screen as part of Kazam, which
iteratively goes through a pre-defined list of plugin classes trying
to use gst_element_factory_make() on the name of the class, and if
there is an error you can report that the codec is missing to the
user. As long as you have at least one supported video codec and one
supported audio codec, you can proceed to allow the user to use the
app, but you would want to make them aware that some of the supported
codecs aren't available due to missing packages.

If you're feeling really adventurous, you could even add in a button
for the user to click, to use the gstreamer packagekit integration to
automatically download and install missing codecs using apt. That
functionality works _reasonably_ well on modern distros with a working
policykit implementation; it works the best if the user has
repositories enabled which have proprietary codecs (because otherwise
packagekit won't be able to find any proprietary codecs that the user
wishes to install). So I believe x264 would automatically be out on
Fedora without using a third-party repo, but on Ubuntu, I think it's
there in gst-plugins-ugly in multiverse or restricted (correct me if
I'm wrong).

To get a sense of how to structure your code, and the kind of logic
you'll need to robustly wrangle Gstreamer codecs, you might want to
take a look at some of the software that uses GStreamer for
transcoding, since you're using it for a very similar purpose:
http://gstreamer.freedesktop.org/apps/
(Unfortunately, the software I wrote, rbpitch, does not do a whole lot
of poking around with plugin discovery etc, so I don't have existing
working code in Vala for this functionality.)

>
>
>> The best place to get started is to read
>> https://wiki.ubuntu.com/ContributeToUbuntu -- and follow the links
>> from there.
>
> I'll take a look there. Hopefully I can find a checklist document about
> inclusion in the distro. :)
>
>> Although if you are able, and there are no really challenging
>> roadblocks, you should go ahead and try with GTK3.
>
> I'd like to get rid of GTK2 as soon as possible. :) This is the very
> first thing on my agenda after I deal with the codec issues and ffmpeg.
>
>> Are there any really low-level GTK2 APIs that Kazam uses that might've
>> been removed or significantly changed in GTK3? I guess I could read
>> the source, but I'm getting ready to head out the door right now,
>> so...
>
> Kazam is written in python and uses pygtk. As far as I know pygtk is
> becoming obsolete fast and I'll have to do a rewrite sooner or later. I
> am still deciding if I should do a rewrite in Vala or keep python and
> use PyGobject. I am equally unfamiliar with PyGObject and Vala. :)

Personally I _love_ Vala. I have successfully used it to develop and
deploy a plugin for Rhythmbox, so I got a chance to learn the Vala way
of doing things for components such as GTK3, GLib/GObject, libpeas,
GSettings, and GStreamer. In fact you might be able to find useful
source code for accomplishing certain things in the source of my
plugin (just over 1000 lines). If you have pre-existing familiarity
with the syntax of languages such as Java or C#, you'll be right at
home with Vala; there aren't too many new syntactical surprises if you
are familiar with either of those. It's a "C-ish" language with
classes/objects/inheritance implemented by GObject-based C code,
basically.

Vala is wonderful... if you want to work on a rewrite of Kazam in
Vala, I will gladly help you. I might write some of it myself, and/or
give you detailed pointers and make myself available to help you out
interactively on IRC. I could spare a number of hours every weekend to
intensively help you work on this, as well as less-intensive emailing
at any time of the week.

I am not a fan of Python, but I know that Python bindings for the
GNOME3 platform will ultimately be handled by something called "PyGI",
which basically means that we use GObject-introspection to discern the
prototypes of the classes and methods in GObject-based libraries. PyGI
can automatically generate the Python bindings for the entire GNOME3
stack.

Now whether or not PyGI is ready for production, I honestly don't
know. But I'm pretty sure that the GNOME organization is putting a lot
of hope into this being the easiest and most viable solution going
forward.

Speaking of GObject-introspection, Vala has support for that, too. So
with one set of .gir files, it should theoretically be possible to
generate perfect bindings for Vala, Python, and any other language
that hooks into GI. Theoretically. But that's not quite how it works
in practice; the Vala folks have learned that .gir files don't always
give all the information that Vala needs to effectively bind to the
library, and so, they've hand-written or generated certain bindings
using custom tools. *In general*, though, if your library is
sufficiently simple (i.e. not GLib or GTK), there's a fair chance that
you can just convert a .gir into a .vapi using vapigen.

For my project (rbpitch / http://launchpad.net/rbpitch ) I ended up
using a combination of handwritten VAPIs shipped with the Vala
compiler, and GIR-generated VAPIs generated using vapigen. Both ways
have their uses, depending on what libs you depend on.

If you want to go with Python, I can't really help you with the
implementation details, since I am only a novice at Python
programming. But I can wish you lots of luck, and still help out with
things like the overall codec approach.

I'm allquixotic on freenode, so feel free to ping me. We can even
create a new channel for Kazam!

-Sean

>
>
> Regards,
> David
>
> --
> ubuntu-desktop mailing list
> ubuntu-desktop at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop