Re: [Kdenlive-devel] Kdenlive and Movit

[Vincent P. <vin...@st...>]

Le samedi 8 février 2014, 14:37:36 Steinar H. Gunderson a écrit :
> Yes, I purposefully didn't tell too many before FOSDEM; it's much more fun
> to come with something new to demo when you can.

Hello,

I finally built latest movit, MLT and your patched kdenlive...
Wonderful to navigate in color-corrected clips without lag,
even with latptop's integrated HD3000
(I keep AMD chip off from BIOS to save power and noise!)

To build MLT I had to edit movit.pc(.in) :
* Cflags -I${includedir}/movit => -I${includedir}
(or in shell export CFLAGS=-I/opt/movit/include)
as includes are in <movit/*.h> form
* Libs: -lmovit @GLEW_LIBS@ => add -L${libdir}
(or in shell export LDFLAGS=-L/opt/movit/lib)


> i915 is probably a tad old to run Movit -- or are you talking about the
> newer Intel cards (that use the driver formerly known as i945/i965, now
> just “intel”)?

I initially tried from my netbook (almost my only free time is in the bus!): I 
got Atom's i915 (not that old) working with Qt'OpenGL demos, but get:

consumer thread 139911783401216 started,
creating new gl context shared with 0x2a33f50
now context is 0x7f3fac001800
GL error 0x501 at init.cpp:38
QtDBus: cannot relay signals from parent QObject(0x4864b00 "")
unless they are emitted in the object's thread QThread(0x1cf7300 "").
Current thread is QThread(0x7f3fac000c00 "").
KCrash: Application 'kdenlive' crashing...


In case you would like to digg the problem:
happening in the check after:
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA16F_ARB, width, 1, 0, GL_RGBA, 
GL_UNSIGNED_BYTE, NULL);

from glxinfo:
OpenGL renderer string: Mesa DRI Intel(R) IGD 
OpenGL version string: 2.1 Mesa 9.2.2
OpenGL shading language version string: 1.20

> Yes, I think one should simply drop support for non-OpenGL output. As I see
> it, there's very little end-user value to keeping both (and how would a user
> know which one to use anyway?). Some branches of open source has
> historically had what I call “checkbox syndrome”, in that one doesn't
> manage to take a clear stance on choices and instead offers a checkbox,
> which sounds like the ideal solution in the short term (you can have it
> both ways, which is nice, right?), but ends up becoming a maintenance
> burden as well as source of user confusion.
> 
> But if others disagree; yes, there would need to be a bunch of #ifdefs and
> probably some ifs (since this can also be selected runtime).

I admit that Atom is not likely to be a platform of choice to edit HD video
(even not for developing, compile is so slow),
I just wanted to be able test if I bring some changes here and there...

And maybe users with only this kind of low end machines (poor areas, students, 
people traveling light...) still might want to edit (SD) video and choose 
kdenlive?
So it makes sense to keep a checkbox to use it without GL(SL) if we don't 
maintain a pre-GL version?

BR,

Vincent.