[PD] GEM: pix_film terribly slow in Ubuntu
Matteo Sisti Sette
matteosistisette at gmail.com
Wed Aug 18 14:26:59 CEST 2010
I recoded my files (actually tested with only one of them) with MJPEG,
and now it works great and performs very well!
I am reading 5 files at a time (actually the same file 5 times at
differenty positions, but i guess it stresses the OS equally if not
more), though displaying a cropped portion of each, and it's consuming
around 60-70% of each CPU only :)
At the moment I am happy with this; having to recode the files is not an
issue, as far as there's a codec that will work equally well in Windows
and/or Mac (have to test yet). I'm working at this in linux but it will
have to be deployed most probably on Mac or Windows.
I'm afraid it will have to be Windows, as I remember GEM performing 5-6
times worse on Mac than on Windows (reading and rendering video files
i.e. using pix_film) and not only with h264.............
Thanks everybody for your help
On 08/18/2010 10:58 AM, IOhannes m zmoelnig wrote:
> On 2010-08-17 23:24, matteo sisti sette wrote:
>> Is there anything more I can try to find out what's wrong? I'm a bit
> i tried to reproduce the problem and can confirm it (even with gmerlin
> i reported the problem upstream to the gmerlin developers, and we found
> out that the h.264 file we used was weird: while it reported a constant
> framerate, in reality the framerate was slightly variable (slightly
> being in the permille range), which was enough to let the frame accurate
> seeking go havoc.
> Gem uses frame accurate seeking even for "auto 1", where it simply seeks
> to the next frame.
> other applications don't have this problem, as they just play the "next
> frame" (without seeking).
> i hope that this get's fixed in gmerlin-avdecoder asap.
> however, i'm not so confident about libquicktime (while both
> libquicktime and gmerlin-avdecoder have the same upstream author, he
> basically only supports gmerlin-avdecoder and lets the "community" fix
> things in libquicktime)
> if you need a quick fix and don't care about frame-accurate seeking at
> all (including resetting to 0 so that you can loop) and are not afraid
> of compiling things yourself, you could simply hack the
> src/Pixes/filmQT4L.cpp file:
> right at the beginning of the changeImage() function (around line 155)
> add a line "return FILM_ERROR_SUCCESS;", and recompile Gem.
More information about the Pd-list