Hey all, here is a report for the 2nd week cut and pasted from my blog,
if you already read my post scroll down to the end since there is a bit
more than what I've written there (hint: Post Scriptum).
========================================================================
2nd Week Report
Within last week I kept on working on gstreamer gl library, I’ve
finished and committed the first draft of a shader abstraction library,
it’s capable of creating program and shader objects with usual gobject
methods, compile shaders, attach them to a program, link and attach them
to GL pipeline.
At the moment, so, it simply wraps the correspondent gl methods, take
care of error handling, and clean up everything when program or shader
ref count reaches 0.
The gobject abstraction, though, will simplify, for example adding
support for ARB programs (asm shaders) and use them with the same api of
GLSL ones.
It would also allow to have convenience methods like gst_gl_shader_add
(not yet implemented) to have a shader compiled, attached and linked
with just one call, or to keep track of multiple shaders attached to the
same program object so that it would be easy to release them all at
once. Furthermore the use of gobject makes code clean, and easier to
read and debug.
There are still a couple of things I’m not quite sure about:
* How to handle errors?
GLSL shaders are designed to resemble C programs, hence they
have to be compiled and linked before attaching them to the GL
state. This process could rise errors, warnings and info
messages that can be queried and are extremely useful for
debugging. How should my library handle them? At the moment I’m
setting a GError with compilation and linking messages and
leaving to the user (the GstGLFilter element) the task to handle
them. Should I use g_error, g_warning and g_message instead? Or
should I use GstInfo debug macros directly from the shader
objects?
* Ehm.. I forgot the others while writing about the previous :)
I’ve also started to write the real GstElement that all my summer
project is about, GstGLEffects (the name is not definitive).
It’s a subclass of GstGLFilter written taking David’s GstGLFilterExample
as a model. I didn’t commit this yet, but it’s already capable of using
the new shader abstraction library and can be used as a starting point
to develop the effects.
It maps video texture to a GL quad (at the moment switched right to left
to resemble looking at a mirror when used with webcam stream, but I plan
to set this with a property sooner or later).
Effects are being selected with a enum property that sets an
effect_changed attribute and binds an effect function pointer to the
right effect. This is needed because gl functions have to be called
within the basetransform filter methods where we can be sure there is a
valid gl context and display is locked. This has a positive side effect
to allow to set effects even when the pipeline is paused (and of course
when is playing). There is also no need to rebuild the pipeline every
time like Cheese does at the moment since we just have one element that
does all the work.
To concentrate on effects developing at the moment only one effect at
the time can be used (since it was simpler to implement) but I plan to
add support for multiple effects in the future.
I also began to play a bit with some effect, mainly distortion ones, but
they are still at an early stage so stay tuned during next weeks to see
more!
I think that’s all for this week, I surely have forgotten something and
as always I didn’t manage to be concise :) I promise to post more often
so each post will be shorter next times ;)
========================================================================
Post Scriptum
It turned out that there was a guy, Julien Isorce, working on a
separate, private branch of gstreamer-gl that made a lot of big changes
and whose work would probably will be merged this summer.
It's obviously my fault to notice this now since I was not subscribed to
gstreamer devel list (ehm..) :P
http://thread.gmane.org/gmane.comp.video.gstreamer.devel/20588/focus=20765
At first I was a bit worried about it since there are a lot of
architectural changes that could lead to a drastic rethinking of my
project.
Then after talking a bit with Julien and David I'm quite confident that
my work and gstreamer gl as a whole will surely take benefits from his
changes. Multiple FBOs and glut support will surely lead to a great
speed increase with less load on the cpu.
He's currently working on restoring three element design (video to gl
uploader, gl filter, gl downloader) that he had removed, and making some
other architectural change that David suggested. When these changes will
be ready my work could be hopefully be integrated with minor changes.
There is nothing definitive already decided, I don't know when it will
be ready, if it will be commited to main branch as it is or would
require more changes, but I'm quite sure that my work won't be affected
negatively by this.
Again, that's all, for real now, hear you the next week probably with a
shorter report since June exams are getting close ;)
Cheers
Filippo
Attachment:
signature.asc
Description: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente