[gst-devel] Summer Coding: Screen Recording on the Free Desktop

[cellenro cellenro]

> Interesting choice of technologies. May i ask why
> you've choosen for JRuby and
> thus a java VM (java is still a bit of an odd kid in
> the open source world) ?
> And which set of gstreamer java bindings you intend
> to use?
> 
>   Sjoerd
There was a great presentation on JRuby at FOSDEM 08
(fosdem.org/2008/schedule/events/jruby) that talks
about JRuby's excellent experience with the open
source process, calling it a success story. The
OpenJDK project (openjdk.java.net) is making
significant progress toward a fully open source JVM. 
I think that projects such as this one play a useful
role in accelerating Java's transition into the open
source world. 

"the JNA project[1] has been used to successfully
build bindings
for the gstreamer multimedia framework.  The resulting
bindings are pure
java (except for a dependency on JNA itself), and run
without modification on
Linux/x86, Linux/amd64, Windows/x86, MacOSX/x86,
Solaris(x86, sparc, sparcv9)
and FreeBSD/x86." --
http://mail.openjdk.java.net/pipermail/challenge-discuss/2008-February.txt

I plan on using the gstreamer-java bindings
(http://code.google.com/p/gstreamer-java/)

There have been some recent discussions on using
gstreamer-java and Gnonlin from JRuby and it looks
promising.

jruby and gstreamer-java
http://groups.google.com/group/gstreamer-java/browse_thread/thread/6be0fde2713f1eb5

Gstreamer-java and Gnonlin / DV
http://groups.google.com/group/gstreamer-java/browse_thread/thread/58a96d3dcb0ce3c1



> If you want to use this argument then you will have
> to explain what is wrong
> with the technologies Istanbul uses for your
> purposes and why your chosen set
> is better.
> 
> > The goal of the project is to bring a professional
> > screen casting application to GNU/Linux. Creating
> a
> > new project, as a result of this different
> direction,
> > seems to be the best way forward.
> 
> Ditto. Please explain why it will be hard to modify
> istanbul to reach your
> goals. I'm not saying your wrong, but at some
> rationale to support your
> arguments is really needed.
> 
>   Sjoerd
Thank you for your important question. 

The technologies Istanbul uses are:
GPL v2
GTK
Python

and was last modified (according to the ChangeLog)
2007-02-23
The actual programming logic of how the application
facilitates the screen recording process is
significantly different from the design I outline in
the initial post. 

Here are some of the motivations behind the
technological selections made for this project:
 * make it easier for developers to use JRuby to
create desktop multimedia applications on GNU/Linux by
documenting the process and overcoming potential
limitations of the technology (ex: using GStreamer
from JRuby)
 * use the Qt 4.4 GUI framework with JRuby (trolltech
has a posting about using Qt with Jython on one of
their blogs which also uses the JVM)

Progress made in creating this application will have
potential positive effects on all screen recording
software for GNU/Linux. One example is that if
Schroedinger is extended with an encode screencast
mode, other projects such as Istanbul can take
advantage of it. Platforms like JRuby and Jython
empower developers to create more open source software
by enabling languages to be used together instead of
in isolation.

> Hi,
> 
> in fact, some weeks ago I played with the thought of
> extending KSnapshot 
> with regard to supporting screen recording. I wanted
> to use ffmpeg (which 
> IMHO delivers very good quality when using the
> "qtrle" codec) as recorder 
> and use the capabilities of KSnapshot only for
> selecting the window or 
> region and starting/stopping the recording.
> 
> This would support X11 only, though.
> 
> Regards,
> Bernd
The qtrle codec
(wiki.multimedia.cx/index.php?title=QTRLE)  does seem
to be capable of good quality screen recording. I
looked into other lossless codecs utilized by existing
proprietary screen recording software but the legal
situation of using them in GPL software was not very
clear to me. This lead  to the evaluation of Driac's
potential because they have a crystal clear legal
situation and the technology is excellent. According
to a recent presentation on GStreamer it was stated
that they also have a clear legal situation (in
contrast to ffmpeg) and that Schroedinger is being
provided as a GStreamer plugin is a nice bonus.

For the first phase of the application I think the
best way will be to develop the screen recording
functionality with JRuby and Qt 4.4 using a place
holder codec ogg Theora via gstreamer with the intent
of replacing the codec with Schroedinger once
development on its "screencast mode" starts. 

Editing the recorded video will be explored with the
Gnonlin plugin and looking at what the PiTiVi project
has accomplished so far.


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs