Hello folks!
I want to participate in a Google Summer of Code 2014, working for KDE
organisation. I want to propose my own project, which is a screencast
recording app for KDE.
I'd be very glad if someone (I think kdemultimedia or kdegraphics
participants could find it useful) can review my proposal and accept to
be my mentor. I'm sending a draft of my application idea for now -
please tell me if you want a document in a GSoC format if you're interested.
I attach my description written so far.
Thank you in advance!
Marcin Grzywaczewski
Institute of Computer Science on University of Wrocław
KoolKast - easy screencasting tool for KDE
Features:
* Recording user's screen:
* All screens
* Certain screen
* Window
* Region of screen
* Recording audio
* Microphone
* System sounds
* Encoding created screencast to WebM
* Timers
* Integration with KDE notifier
And, when we'll have some time:
* (OPTIONAL) Modification of created file's metadata
* (OPTIONAL) Very simple video manipulation
* deleting parts of the video
* inserting static frames [like company logo, or chapter description text]
Motivation:
Screencasting gains more and more popularity as a tool for sharing knowledge -
many software houses which aiming for a remote work start to use it widely
within their knowledge bases. It's also a great tool for an end-user - rather
than creating an article about process you want to share, you can record the
process and explain it in plain
words. In Ruby on Rails community we can talk about 'screencasting culture'
already - services like RailsCasts, excellent screencasts made by Gary
Bernhardt (Destroy All Software series) and many more.
Unfortunately, Linux and Open Source systems lack the proper tools for creating
screencasts - every one of them is too complicated, have weird issues (like
Kazam - a tool which I'm using right no. It lacks, for example, encoding status
and when something goes wrong it doesn't even inform you such case happened) or
is not suitable for easy sharing (lacking WebM standard encoding, which is a
web standard).
I think providing an easy software for creating screencast within KDE project
can greatly increase value of our DE. Many professionals these days are using
Apple Mac just because such tasks like screencasting just works - you press one
button and you are done. When we provide such tool as the part of KDE, we can
convince those people, who would like to use Linux, but they're angry now
because there is no good tooling for this kind of easy tasks.
As an user of Linux and KDE (love it since version 3) and programmer in a
software house which has grown 'screencasting culture', I would be glad to
provide such solution to our Desktop Environment.
Scope:
During GSoC I'd like to focus on very narrow scope of providing critical
features in a proper way. I'm open for suggestions - if you want to mentor my
project, I'd be glad to discuss about my proposed scope and change it
accordingly.
Features desciption (with insight about implementation and architecture):
* RECORDING USER'S SCREEN
Yeah, it's the most important part of the screencasting app (with audio
recording, of course). During the work on this feature I'd like to create an
architecture for 'exchangeable' adapters for recording screen technique (expose
an interface for future development of new adapters and provide a way to
'register' it within KoolKast. This way you can have many techniques of
recording) and ability of defining the very basic settings of this - like
resolution, quality and framerate. I'd like to create one basic adapter for
recording screencasts, mostly QScreenshot based - but I'm open for suggestions.
My 'must-be' part of this feature is to be able to record all screens, certain
screen and a window. When I'll have time for it I'll also try to implement
region recording.
We can also re-use or take inspiration from recordmydesktop if license allows
us to do so.
Challenges: It can be tricky to synchronize audio with video when there are
performance problems - I'd like to take a closer look on it.
* RECORDING AUDIO
When it comes to recording audio, my goal is to provide a good support for a
microphone - recording system sounds is less major than a mic, just because
that's why screencast are created for - to provide a vision of the process (by
an example) and to explain it in the same time using speech. I'm not sure about
technical implementation right now - I think we have an abstraction in Qt
called QAudioRecorder which we can use in this case. Encoding it to a proper
format will handled by the encoder.
I'd like to provide very basic settings within UI - selecting audio input,
setting volume and quality of the recorded audio.
Challenges: There can be a requirement to provide a service to interact with
encoder and an audio recording module.
* ENCODING CREATED SCREENCAST TO WEBM
WebM becomes more and more popular because it's natively supported by major
browsers. When it comes to encoders, my primary goal is to provide encoding to
this format.
I'd prefer to include WebM encoder as an Adapter, sharing the similar approach
to Video Recorders - they should be interchangeable and providing a new encoder
should be totally decoupled from the previous code - we provide an interface
and we're done. For initial implementation for WebM, technically we can use
ffmpeg for it (as a spawned background process or some kind of integration via
library), but ideally I'd like to find and use a native library for it. My
rationale is that kazam is *SLOW* and providing no feedback - there is no
encoding status and such things.
Challenges: Future Video Recorders can provide different data format of encoded
frames - I need to include it within my architecture ideas. I think there can
be some kind of intermediate Service object required between an encoder adapter
and screen recording adapter.
* TIMERS:
When preparing to create a screencast it's important to have some time to
prepare yourself - for example, to take a deep breath before your talking ;).
For this case I'd like to create a very simple countdown timer working like an
Amarok's OSD - we can also provide (configurable in settings) OSD for
displaying screencast time elapsed (for interest of recording user). It's
especially important when you create microcasts - screencasts equivalent to
lightning talks on conferences.
Challenges: I don't know it'll be easy to remove this OSD from a recorded video
- it can be tricky on this part.
* INTEGRATION WITH KDE NOTIFIER:
It's important to provide a feedback to the user - especially when we're
encoding video, which can be a long process. In applications like Kazam (I'm
using ArchLinux) you don't have any feedback when encoding at all - you don't
know if your encoding will take 10 minutes or 10 hours. It's frustrating. Also,
you don't have any feedback about errors.
I think one of the killer features of KDE is this kind of unified notifications
within notification bar - we can use it do provide a proper feedback for an
user.
I'll use KNotification class for this feature - and ensure it's working well.
Challenges: It can be tricky to use KoolKast without KDE and maintain these
kind of notifications - I'll take an effort to provide a fallback solution when
KNotification won't be available.
* (OPTIONAL) MODIFICATION OF VIDEO METADATA
Many screencast tools don't treat metadata as a first-class citizen - all they
do is to record video and provide no information about it. When it comes to
upload this kind of screencast to a service which uses metadata to position
video, it can be tough to make it right without this option. I'm sure that
ActivePresenter (big tool for creating screencasts and more for Windows) treat
metadata badly - even without writing when video was created at! I'd like to
implement when I'll have time some kind of basic metadata modification - like
dates and author.
Challenges: Metadata can be format-specific - I need to abstract interfaces to
provide metadata modification to future encoder adapters.
* (OPTIONAL) VERY SIMPLE VIDEO MANIPULATION
Modifications like cropping part of the screencast (whoops, I made a mistake on
X:XX!), or inserting static frames (insert the company logo at Y:YY for 5
seconds) can be handy - I'd like to provide a very simple solution for this.
It's a very optional feature in my plan - I'll do it only when I'll have some
time to do so.
Challenges: Providing this feature can be costly - I believe video manipulation
libraries are fat, also not quite friendly for programmer to do such simple
tasks. It can be also a case to provide a minimal player within this app - I'd
like to avoid it, just because it can make an app grow significantly.
Schedule:
List of features is already prioritised - you should go from top to bottom to
know my priorities. I'd like to end video recording at 15~th June, recording
audio the next 15 days, encoding within the next 10 days, and the rest of
features to the about 5~th August. I'd like to have some 'extra' time and I
included it on my schedule. I don't know what problems arise when creating such
software - but I think with a proper mentor we can easily avoid obstacles.
Technology:
My technology of choice is C++, mostly because I can't use C (Qt is C++
library). Of course we'd like to use an additional libraries - like for WebM
encoding and such. My main background is Ruby, but I'll be happy to provide a
solution in C++ - mostly due that I'm tired of sloppiness of such applications
on Linux. In fact Qt provides most of the features 'out of the box' for this
app.
Thank you for reading such 'long' description!
Marcin Grzywaczewski
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<