FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Desktop

 
 
LinkBack Thread Tools
 
Old 12-31-2011, 07:03 PM
Sean McNamara
 
Default Screen recorder - Kazam

Hi,

On Sat, Dec 31, 2011 at 2:23 PM, David Klasinc <bigwhale@lubica.net> wrote:
> Greetings,
>
> Recently I picked up Kazam Screencaster. I needed to record something
> and noticed that Kazam is not working and has some dependency issues in
> Oneiric. After trying out few other solutions none of them really suited
> me. Around Christmas I started working on Kazam and made some
> improvements while solving those dependency problems.
>
> Andrew Higginson stopped working on the project and made me a member of
> Kazam team on Launchpad so I can take over from here.

Cool! Congrats on volunteering to maintain this project! I'm not
familiar with Kazam, but I'm learning about it now, since it seems
interesting and useful...

>
> https://launchpad.net/kazam
>
> Right now most of the development is done in my PPA until I get things
> stable enough and merge them in the stable branch of the project.
>
> https://launchpad.net/~bigwhale/+archive/kazam-oneric
>
> (yes, the typo should be there :/)
>
> Quick rundown of changes that I made:
>
> - Default backend is now gstreamer.
> - Video is encoded with vp8 instead of x264.
> - Audio is encoded with Ogg Vorbis.
> - Audio/Video container is now WebM.

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.

> - Package dependencies revised to include only essential packages.
> - Basic Pulseaudio support.
> - Independent audio input device selection
> - Volume setting slider in the works
> - The path to multiple source recording is now open. Next release should
> support recoding audio on two channels (application sounds and
> voice-over commentary, for example).
>
> Currently Kazam is still GTK2 and I'd like few pointers on what needs to
> be done if I want Kazam to be included in the Ubuntu repositories for
> Precise Pangolin. And if I missed the mailing list, someone please kick
> me in the right direction.

The best place to get started is to read
https://wiki.ubuntu.com/ContributeToUbuntu -- and follow the links
from there.

You're already very far along because you've already:
-Written the software
-Created a source package for DPKG
-Put it in a PPA
-Communicated with the community announcing your package and soliciting feedback

This is a very large step in the right direction. The rest, as they
say, is testing/validation and politics.

Also I'm not 100% sure but you can probably get it accepted into
Precise (in Universe, dunno about Main) with a GTK2 UI. The GTK2 libs
will continue to stick around for years and years (and years) to come.
Although if you are able, and there are no really challenging
roadblocks, you should go ahead and try with GTK3.

My general porting strategy for GTK3:

1. Build against the gtk3 libs and headers in your build system (easy)
2. Fix any compilation errors (can require some rewriting, but not
that much usually)
3. Fix any linkage errors (can be painful if your favorite API is gone)
4. Test it out like crazy to make sure that everything works
equivalently at runtime (time-consuming but easy)

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...

Anyway, Happy New Year to you as well, and thanks for working on this
and being interested in contributing!

Disclosure: I am not an Ubuntu Developer, though I do host a project
on Launchpad, package it in a PPA, and have expressed interest in
getting it into Universe in the past... so we are pretty much at the
same stage

Regards,

-Sean


>
>
> (more detailed explanation on my changes and future plans are posted on
> my blog: http://www.twm-kd.com/linux/kazam-screencaster-0-12/ )
>
> So much for now and a Happy 2021 to everyone!
>
> Regards,
> David
>
>
>
>
> --
> ubuntu-desktop mailing list
> ubuntu-desktop@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
 
Old 01-01-2012, 09:59 AM
David Klasinc
 
Default Screen recorder - Kazam

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.


> 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.


Regards,
David

--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
 
Old 01-01-2012, 05:47 PM
Sean McNamara
 
Default Screen recorder - Kazam

Hi,

On Sun, Jan 1, 2012 at 5:59 AM, David Klasinc <bigwhale@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@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop

--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
 
Old 01-02-2012, 08:28 AM
David Klasinc
 
Default Screen recorder - Kazam

On 01/01/2012 07:47 PM, Sean McNamara wrote:

> 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.

gst-ffmpeg is terribly undocumented and I think there is no real need
for me to use it. I need to support a handful of codecs, not every
single one there is.

x264enc didn't work because of unknown reasons at the time being and it
really pissed me off because I know it used to work. Five minutes ago I
realized why it didn't work and I got it working now. It was a serious
case of PEBKAC ... To make it short, I was testing with a smaller window
800x800, H264 video size must be divisible by 2 and x264 starts counting
with 0. :> I'll hack x264 as an option.

> 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

Right now I have base and bad plugins as a requirement and this covers
everything I need. For x264 I'll also need ugly plugins package. If that
is installed everything should work.

> 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.

This is a really neat idea. I'll probably make webm default and a
requirement and x264 will be an optional feature.

> but on Ubuntu, I think it's
> there in gst-plugins-ugly in multiverse or restricted (correct me if
> I'm wrong).

If I can read this page correctly and the information is valid, it seems
that uglies are in the universe.

http://packages.ubuntu.com/oneiric/libs/gstreamer0.10-plugins-ugly

> 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 still contemplating Python and Vala. I'll see what time will bring.
I'm quite fluent in python so it would be my first choice. Vala,
however, is becoming a defacto standard for Gnome development and that's
why I am considering it.

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

Not all that bad idea. I registered a channel, BigWhale will be idling
there mostly.

Regards,
David

--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
 

Thread Tools




All times are GMT. The time now is 03:22 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org