Hi,
I'm trying to play some mpeg4 and h.264-encoded video files with pix_film in Ubuntu 10.04, and it is terribly slow: it reads about 4-5 frames per second and eat 100% of the CPU.
The files have aproximately 900x500 resolution, which is nothing exagerate; and even Adobe Flash Player can reproduce the same files seamlessly at their full (25fps) rate without consuming more than about 40-50% of the CPU.
Any idea of what the issue can be? Is it the codecs? I guess I have whatever codecs came with the Ubuntu distro. Are there any codecs with better performance that I should insall? Or is this the best performance I can expect under linux?
Thanks m.
I don't have problems with codec performance in ubuntu 10.04. I would try playing the videos with mplayer, totem and/or vlc to see if the performance problem is a codec one. Also do you have a graphics driver with 3D hardware acceleration? if you type
glxinfo | grep direct
is direct rending a Yes or a no?
(if you don't have glxinfo installed, it's in mesa-utils i.e. sudo apt-get install mesa-utils)
-John
On 08/15/2010 03:53 PM, Matteo Sisti Sette wrote:
Hi,
I'm trying to play some mpeg4 and h.264-encoded video files with pix_film in Ubuntu 10.04, and it is terribly slow: it reads about 4-5 frames per second and eat 100% of the CPU.
The files have aproximately 900x500 resolution, which is nothing exagerate; and even Adobe Flash Player can reproduce the same files seamlessly at their full (25fps) rate without consuming more than about 40-50% of the CPU.
Any idea of what the issue can be? Is it the codecs? I guess I have whatever codecs came with the Ubuntu distro. Are there any codecs with better performance that I should insall? Or is this the best performance I can expect under linux?
Thanks m.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 08/16/2010 02:29 AM, John Harrison wrote:
I don't have problems with codec performance in ubuntu 10.04. I would try playing the videos with mplayer, totem and/or vlc to see if the performance problem is a codec one.
They play fine in totem; they seem to consume about 50% of each processor (if the System Monitor is to be trusted); I wouldn't expect that much but it's probably normal and at least they play smoothly. In pix_movie they eat 100% of one processor and run at about 4-5 fps or less.
Also do you have a graphics driver with 3D hardware acceleration? if you type
glxinfo | grep direct
is direct rending a Yes or a no?
Yes: direct rendering: Yes GL_EXT_Cg_shader, GL_EXT_depth_bounds_test, GL_EXT_direct_state_access,
Thank you very much for your help m.
On Mon, 16 Aug 2010, Matteo Sisti Sette wrote:
They play fine in totem; they seem to consume about 50% of each processor (if the System Monitor is to be trusted); I wouldn't expect that much but it's probably normal and at least they play smoothly. In pix_movie they eat 100% of one processor and run at about 4-5 fps or less.
If a movie decoding induces frame skipping, the frame skipping consumes a lot more CPU than the normal decoding. I've seen this happen in MAX as well.
Can you put it in slow motion (play at a lesser fps than what's indicated by the file) and confirm that below a certain wanted fps, it starts to take radically less real time per logical time ? that should be when it stops skipping frames.
The frame skipping problem does not happen for a file that doesn't have b-frames (most notably, all files in photo-jpeg format...)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Mon, 16 Aug 2010, Mathieu Bouchard wrote:
Can you put it in slow motion (play at a lesser fps than what's indicated by the file) and confirm that below a certain wanted fps, it starts to take radically less real time per logical time ? that should be when it stops skipping frames.
oops, I wanted to say "radically less real time per decoded frame".
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On 08/16/2010 05:37 PM, Mathieu Bouchard wrote:
If a movie decoding induces frame skipping, the frame skipping consumes a lot more CPU than the normal decoding. I've seen this happen in MAX as well.
The slowness and high CPU consumption happens even with "auto 1": shouldn't frame skipping happen only for speeds greater than the original framerate (that is, only when you actually have to skip frames)?
OR, maybe, it could also be expectable, if the implementation is not "overly smart", that it would do frame skipping (even to skip from frame n to frame n itself) whenever "auto" mode is turned off
Can you put it in slow motion (play at a lesser fps than what's indicated by the file) and confirm that below a certain wanted fps, it starts to take radically less real time per logical time ? that should be when it stops skipping frames.
I don't understand that very well: it should stop "skipping" frames as soon as the wanted fps is _equal_ to the file's fps; if you go much lower, I would guess it would actually not only stop "skipping" frames, but stop _decoding_ frames when it just repeats the same frame
Indeed, if it started taking less real time per frame only when demanded a _very_ low fps, I would rather interpret that it is actually doing "frame skipping" every time it is asked for a new frame, whichever it is (even the next one), except when it is the same frame it is already at.
...what am I missing?
Is there anything more I can try to find out what's wrong? I'm a bit desperate...
I'm getting significantly better performance in Windows 7 on a virtual machine on Ubuntu than natively in Ubuntu....
Thank you m.
2010/8/16 Matteo Sisti Sette matteosistisette@gmail.com:
On 08/16/2010 05:37 PM, Mathieu Bouchard wrote:
If a movie decoding induces frame skipping, the frame skipping consumes a lot more CPU than the normal decoding. I've seen this happen in MAX as well.
The slowness and high CPU consumption happens even with "auto 1": shouldn't frame skipping happen only for speeds greater than the original framerate (that is, only when you actually have to skip frames)?
OR, maybe, it could also be expectable, if the implementation is not "overly smart", that it would do frame skipping (even to skip from frame n to frame n itself) whenever "auto" mode is turned off
Can you put it in slow motion (play at a lesser fps than what's indicated by the file) and confirm that below a certain wanted fps, it starts to take radically less real time per logical time ? that should be when it stops skipping frames.
I don't understand that very well: it should stop "skipping" frames as soon as the wanted fps is _equal_ to the file's fps; if you go much lower, I would guess it would actually not only stop "skipping" frames, but stop _decoding_ frames when it just repeats the same frame
Indeed, if it started taking less real time per frame only when demanded a _very_ low fps, I would rather interpret that it is actually doing "frame skipping" every time it is asked for a new frame, whichever it is (even the next one), except when it is the same frame it is already at.
...what am I missing?
On Tue, 17 Aug 2010, matteo sisti sette wrote:
Is there anything more I can try to find out what's wrong? I'm a bit desperate...
can you recode the video with less pseudo-frames ?
for example, there is an encoding setting which, when set to '8', it encodes one frame completely (usually as some variant of JPEG) and then the next 7 frames are encoded as "diffs" of some kind (codec-specific format). It's possible that this setting is very high, and that halving this setting changes the fps radically in your decoding.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On 08/17/2010 11:30 PM, Mathieu Bouchard wrote:
On Tue, 17 Aug 2010, matteo sisti sette wrote:
Is there anything more I can try to find out what's wrong? I'm a bit desperate...
can you recode the video with less pseudo-frames ?
I'll try that, but as I mentioned other players are not having troubles decoding these files
On Wed, 18 Aug 2010, Matteo Sisti Sette wrote:
I'll try that, but as I mentioned other players are not having troubles decoding these files
but as I mentioned, players that would need a little bit more than 100% CPU are sometimes found to behave very erratically, such as look like they'd need 500% CPU, and produce 4 fps.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
ola
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 desperate...
i tried to reproduce the problem and can confirm it (even with gmerlin backend)
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.
fmgadr IOhannes
On 08/18/2010 10:58 AM, IOhannes m zmoelnig wrote:
i tried to reproduce the problem and can confirm it (even with gmerlin backend)
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.
Hi, thank you so much for your help.
Is there a way I can "inspect" my files to see whether they are "weird" as well? Also, I'm not sure I understand, how can the frame rate be different "in reality" than what is "reported" by the file? Isn't the framerate just something that is stated? Or you mean that the header of the file declares a constant frame rate and then, along the file, the framerate is actually changed at every frame, block or whatever...
In this case, it shouldn't be difficult to "recode" the file forcing a really-constant framerate (which shouldn't be a real recoding): can you suggest me a program to do that in Linux?
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).
That seems to perfectly explain why I don't have problems playing the files in other players.
Correct me if I am wrong: recoding the files with I-frames only wouldn't help, would it? But recoding them with a different codec would, wouldn't it?
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.
Oh thank you very much. Unfortunately, I do need frame-accurate seeking. My emphasis on the 1:1 playback speed and the auto mode was just meant to narrow down the source of the problem.
Thanks a lot again cheers m.
mjpeg is a good codec for gem, of course if you have hd space (like a lot of it) you can use a raw codec. as for the tools, there's ffmpeg or transcode:
transcode -i yourvideo.whateversupportbytranscode -y ffmpeg,null -F mjpeg -o 4gem.avi
ffmpeg -i yourvideo.whateversupportbytranscode -an -vcodec mjpeg -sameq 4gem.avi
On 2010-08-18 16:54, patrick wrote:
mjpeg is a good codec for gem, of course if you have hd space (like a lot of it) you can use a raw codec. as for the tools, there's ffmpeg or
raw codecs are usually a bad idea, as they soon max out your harddisk's performance.
you should choose a codec that balances CPU and harddisk consumption.
fgamsdr IOhannes
Hey!!
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
m.
On 08/18/2010 10:58 AM, IOhannes m zmoelnig wrote:
ola
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 desperate...
i tried to reproduce the problem and can confirm it (even with gmerlin backend)
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.
fmgadr IOhannes
On Wed, 18 Aug 2010, Matteo Sisti Sette wrote:
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.............
does it also happen when not reading and writing video ? I mean, make a patch that does a lot of pix processing on top of a [pix_image] and then just displays that with a single [pix_texture] or [pix_draw]. Is that kind of thing slower on OSX than on Windows and/or Linux ?
I ask because I wonder whether it can be linked with a problem I know about on OSX...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On 08/18/2010 06:23 PM, Mathieu Bouchard wrote:
On Wed, 18 Aug 2010, Matteo Sisti Sette wrote:
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.............
does it also happen when not reading and writing video ? I mean, make a patch that does a lot of pix processing on top of a [pix_image] and then just displays that with a single [pix_texture] or [pix_draw]. Is that kind of thing slower on OSX than on Windows and/or Linux ?
I ask because I wonder whether it can be linked with a problem I know about on OSX...
Sorry, I have no idea. All the patches I tried on Mac had only very basic or no pix processing but played back and displayed fragment of quite a few videos.
And right now (nor in the near future) I don't have access to a Mac to do more tests.
I thought the bottleneck was in reading and/or decoding the files rather than rendering, but now I can't remember what made me think that (if there was a good reason at all).
On Wed, 18 Aug 2010, Matteo Sisti Sette wrote:
Sorry, I have no idea. All the patches I tried on Mac had only very basic or no pix processing but played back and displayed fragment of quite a few videos. And right now (nor in the near future) I don't have access to a Mac to do more tests. I thought the bottleneck was in reading and/or decoding the files rather than rendering, but now I can't remember what made me think that (if there was a good reason at all).
What I know is that large memory allocation (128k and more) using the malloc() command, uses in turn the mmap() command, in a way that is much, much slower on OSX than on Linux.
In the end, my last question is surely quite wrong. I don't quite know where the malloc() command is used inside of GEM and how often. But that's one thing for which OSX is much slower than I expected, and it took me a long time to find out. (I have no figures about Windows's speed for that).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On 2010-08-15 22:53, Matteo Sisti Sette wrote:
Hi,
I'm trying to play some mpeg4 and h.264-encoded video files with pix_film in Ubuntu 10.04, and it is terribly slow: it reads about 4-5 frames per second and eat 100% of the CPU.
it seems like a missed the information about the exact version of Gem.
apart from that:
Gem has about 5 different backends available on linux for video decoding. 3 of those are generic backends which support loads and loads of different formats and can be extended with codec plugins.
thus "ubuntu 10.04" is definitely not enough information. we need to know at least which backends are enabled on your system (you get that information the first time you create a [pix_film] object). then we need to know which libraries you have installed to support these codecs (e.g. if you have the QT4L backend enabled, which version of libquicktime/libquicktim4linux do you have installed). it's probably enough to send the output of $ ldd /path/to/Gem.pd_linux
finally:
is it really [pix_film] that is so slow? what happens if you disconnect anything _below_ [pix_film]? any change in performance?
fgamsdr IOhannes
Hi IOhannes,
thanks a lot for your help.
it seems like a missed the information about the exact version of Gem.
It's 0.92.3 (Pd version 0.42.5-extended-20100601)
we need to know at least which backends are enabled on your system (you get that information the first time you create a [pix_film] object).
Here's what pix_film says:
pix_film:: quicktime support pix_film:: libmpeg3 support
I guess if only these are enabled it is because no more are available on the system, do I guess right?
then we need to know which libraries you have installed to support these codecs (e.g. if you have the QT4L backend enabled, which version of libquicktime/libquicktim4linux do you have installed). it's probably enough to send the output of $ ldd /path/to/Gem.pd_linux
Here's the output of ldd:
linux-gate.so.1 => (0x00e67000) libftgl.so.2 => /usr/lib/libftgl.so.2 (0x00521000) libv4l2.so.0 => /usr/lib/libv4l2.so.0 (0x00774000) libv4l1.so.0 => /usr/lib/libv4l1.so.0 (0x00479000) libquicktime.so.1 => /usr/lib/libquicktime.so.1 (0x0047f000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x00e87000) libz.so.1 => /lib/libz.so.1 (0x00e17000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00a9f000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x004f3000) libMagick++.so.2 => /usr/lib/libMagick++.so.2 (0x00c5b000) libMagickCore.so.2 => /usr/lib/libMagickCore.so.2 (0x00813000) libdv.so.4 => /usr/lib/libdv.so.4 (0x0064b000) libmpeg3.so.1 => /usr/lib/libmpeg3.so.1 (0x006dc000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0054e000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00d81000) libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1 (0x00aa3000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00d2d000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00d77000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00ea0000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00674000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00fbd000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x0077f000) libv4lconvert.so.0 => /usr/lib/libv4lconvert.so.0 (0x00b68000) /lib/ld-linux.so.2 (0x007f6000) libMagickWand.so.2 => /usr/lib/libMagickWand.so.2 (0x20a63000) liblcms.so.1 => /usr/lib/liblcms.so.1 (0x00693000) libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00716000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00a49000) libXt.so.6 => /usr/lib/libXt.so.6 (0x00bd5000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00ceb000) libltdl.so.7 => /usr/lib/libltdl.so.7 (0x006c7000) libSM.so.6 => /usr/lib/libSM.so.6 (0x006d0000) libICE.so.6 => /usr/lib/libICE.so.6 (0x00a6a000) libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00a83000) liba52-0.7.4.so => /usr/lib/liba52-0.7.4.so (0x00a91000) libGLcore.so.1 => /usr/lib/nvidia-current/libGLcore.so.1 (0x1d457000) libnvidia-tls.so.1 => /usr/lib/nvidia-current/tls/libnvidia-tls.so.1 (0x00519000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00c28000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x00c42000) libuuid.so.1 => /lib/libuuid.so.1 (0x0051b000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00644000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00c4b000)
Thank you very much m.
Hi
Just to say I have the same problem. (Pd version 0.42.5-extended-rc5 // Ubuntu 10.04) My avi file is in XVID MPEG-4. I can read it with VLC and others players but with [pix_film] it's slow like Matteo've described it.
If there's nothing below [pix_film] it's still slow.
2010/8/16 Matteo Sisti Sette matteosistisette@gmail.com
Hi IOhannes,
thanks a lot for your help.
it seems like a missed the information about the exact version of Gem.
It's 0.92.3 (Pd version 0.42.5-extended-20100601)
we need to know at least which backends are enabled on your system (you
get that information the first time you create a [pix_film] object).
Here's what pix_film says:
pix_film:: quicktime support pix_film:: libmpeg3 support
I guess if only these are enabled it is because no more are available on the system, do I guess right?
then we need to know which libraries you have installed to support these
codecs (e.g. if you have the QT4L backend enabled, which version of libquicktime/libquicktim4linux do you have installed). it's probably enough to send the output of $ ldd /path/to/Gem.pd_linux
Here's the output of ldd:
linux-gate.so.1 => (0x00e67000) libftgl.so.2 => /usr/lib/libftgl.so.2 (0x00521000) libv4l2.so.0 => /usr/lib/libv4l2.so.0 (0x00774000) libv4l1.so.0 => /usr/lib/libv4l1.so.0 (0x00479000) libquicktime.so.1 => /usr/lib/libquicktime.so.1 (0x0047f000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x00e87000) libz.so.1 => /lib/libz.so.1 (0x00e17000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00a9f000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x004f3000) libMagick++.so.2 => /usr/lib/libMagick++.so.2 (0x00c5b000) libMagickCore.so.2 => /usr/lib/libMagickCore.so.2 (0x00813000) libdv.so.4 => /usr/lib/libdv.so.4 (0x0064b000) libmpeg3.so.1 => /usr/lib/libmpeg3.so.1 (0x006dc000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0054e000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00d81000) libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1 (0x00aa3000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00d2d000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00d77000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00ea0000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00674000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00fbd000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x0077f000) libv4lconvert.so.0 => /usr/lib/libv4lconvert.so.0 (0x00b68000) /lib/ld-linux.so.2 (0x007f6000) libMagickWand.so.2 => /usr/lib/libMagickWand.so.2 (0x20a63000) liblcms.so.1 => /usr/lib/liblcms.so.1 (0x00693000) libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00716000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00a49000) libXt.so.6 => /usr/lib/libXt.so.6 (0x00bd5000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00ceb000) libltdl.so.7 => /usr/lib/libltdl.so.7 (0x006c7000) libSM.so.6 => /usr/lib/libSM.so.6 (0x006d0000) libICE.so.6 => /usr/lib/libICE.so.6 (0x00a6a000) libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00a83000) liba52-0.7.4.so => /usr/lib/liba52-0.7.4.so (0x00a91000) libGLcore.so.1 => /usr/lib/nvidia-current/libGLcore.so.1 (0x1d457000) libnvidia-tls.so.1 => /usr/lib/nvidia-current/tls/libnvidia-tls.so.1 (0x00519000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00c28000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x00c42000) libuuid.so.1 => /lib/libuuid.so.1 (0x0051b000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00644000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00c4b000)
Thank you very much
m.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If there's nothing below [pix_film] it's still slow.
I would say... If there's nothing below [pix_film] the CPU is stil at 100%... :-p
2010/8/16 Olivier Baudu lamouraupeuple@gmail.com
Hi
Just to say I have the same problem. (Pd version 0.42.5-extended-rc5 // Ubuntu 10.04) My avi file is in XVID MPEG-4. I can read it with VLC and others players but with [pix_film] it's slow like Matteo've described it.
If there's nothing below [pix_film] it's still slow.
2010/8/16 Matteo Sisti Sette matteosistisette@gmail.com
Hi IOhannes,
thanks a lot for your help.
it seems like a missed the information about the exact version of Gem.
It's 0.92.3 (Pd version 0.42.5-extended-20100601)
we need to know at least which backends are enabled on your system (you
get that information the first time you create a [pix_film] object).
Here's what pix_film says:
pix_film:: quicktime support pix_film:: libmpeg3 support
I guess if only these are enabled it is because no more are available on the system, do I guess right?
then we need to know which libraries you have installed to support these
codecs (e.g. if you have the QT4L backend enabled, which version of libquicktime/libquicktim4linux do you have installed). it's probably enough to send the output of $ ldd /path/to/Gem.pd_linux
Here's the output of ldd:
linux-gate.so.1 => (0x00e67000) libftgl.so.2 => /usr/lib/libftgl.so.2 (0x00521000) libv4l2.so.0 => /usr/lib/libv4l2.so.0 (0x00774000) libv4l1.so.0 => /usr/lib/libv4l1.so.0 (0x00479000) libquicktime.so.1 => /usr/lib/libquicktime.so.1 (0x0047f000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x00e87000) libz.so.1 => /lib/libz.so.1 (0x00e17000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00a9f000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x004f3000) libMagick++.so.2 => /usr/lib/libMagick++.so.2 (0x00c5b000) libMagickCore.so.2 => /usr/lib/libMagickCore.so.2 (0x00813000) libdv.so.4 => /usr/lib/libdv.so.4 (0x0064b000) libmpeg3.so.1 => /usr/lib/libmpeg3.so.1 (0x006dc000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0054e000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00d81000) libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1 (0x00aa3000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00d2d000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00d77000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00ea0000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00674000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00fbd000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x0077f000) libv4lconvert.so.0 => /usr/lib/libv4lconvert.so.0 (0x00b68000) /lib/ld-linux.so.2 (0x007f6000) libMagickWand.so.2 => /usr/lib/libMagickWand.so.2 (0x20a63000) liblcms.so.1 => /usr/lib/liblcms.so.1 (0x00693000) libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00716000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00a49000) libXt.so.6 => /usr/lib/libXt.so.6 (0x00bd5000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00ceb000) libltdl.so.7 => /usr/lib/libltdl.so.7 (0x006c7000) libSM.so.6 => /usr/lib/libSM.so.6 (0x006d0000) libICE.so.6 => /usr/lib/libICE.so.6 (0x00a6a000) libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00a83000) liba52-0.7.4.so => /usr/lib/liba52-0.7.4.so (0x00a91000) libGLcore.so.1 => /usr/lib/nvidia-current/libGLcore.so.1 (0x1d457000) libnvidia-tls.so.1 => /usr/lib/nvidia-current/tls/libnvidia-tls.so.1 (0x00519000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00c28000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x00c42000) libuuid.so.1 => /lib/libuuid.so.1 (0x0051b000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00644000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00c4b000)
Thank you very much
m.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
One curious thing is that totem and lqtplay seem to distribute the load among the two CPUs (I guess one thread is reading/decoding and another one is rendering the image), with a load of approximately 50% each; while GEM is consuming 100% of one CPU and less than 5-10% on the other one.
Is it possible that even using the same backend, media players do the reading and rendering in two different threads and pix_film does not?
(though, the difference in performance seems to me a bit bigger than this alone would explain...)
And a general question that is not related to GEM: is it reasonable that decoding and playing back a 950x540 25fps h264 video consumes in total about 50% of two 2.50GHz CPUs??
thanks m.
On 08/16/2010 12:46 PM, Olivier Baudu wrote:
If there's nothing below [pix_film] it's still slow.
I would say... If there's nothing below [pix_film] the CPU is stil at 100%... :-p
2010/8/16 Olivier Baudu <lamouraupeuple@gmail.com mailto:lamouraupeuple@gmail.com>
Hi Just to say I have the same problem. (Pd version 0.42.5-extended-rc5 // Ubuntu 10.04) My avi file is in XVID MPEG-4. I can read it with VLC and others players but with [pix_film] it's slow like Matteo've described it. If there's nothing below [pix_film] it's still slow. 2010/8/16 Matteo Sisti Sette <matteosistisette@gmail.com <mailto:matteosistisette@gmail.com>> Hi IOhannes, thanks a lot for your help. it seems like a missed the information about the exact version of Gem. It's 0.92.3 (Pd version 0.42.5-extended-20100601) we need to know at least which backends are enabled on your system (you get that information the first time you create a [pix_film] object). Here's what pix_film says: pix_film:: quicktime support pix_film:: libmpeg3 support I guess if only these are enabled it is because no more are available on the system, do I guess right? then we need to know which libraries you have installed to support these codecs (e.g. if you have the QT4L backend enabled, which version of libquicktime/libquicktim4linux do you have installed). it's probably enough to send the output of $ ldd /path/to/Gem.pd_linux Here's the output of ldd: linux-gate.so.1 => (0x00e67000) libftgl.so.2 => /usr/lib/libftgl.so.2 (0x00521000) libv4l2.so.0 => /usr/lib/libv4l2.so.0 (0x00774000) libv4l1.so.0 => /usr/lib/libv4l1.so.0 (0x00479000) libquicktime.so.1 => /usr/lib/libquicktime.so.1 (0x0047f000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x00e87000) libz.so.1 => /lib/libz.so.1 (0x00e17000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00a9f000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x004f3000) libMagick++.so.2 => /usr/lib/libMagick++.so.2 (0x00c5b000) libMagickCore.so.2 => /usr/lib/libMagickCore.so.2 (0x00813000) libdv.so.4 => /usr/lib/libdv.so.4 (0x0064b000) libmpeg3.so.1 => /usr/lib/libmpeg3.so.1 (0x006dc000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0054e000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00d81000) libGL.so.1 => /usr/lib/nvidia-current/libGL.so.1 (0x00aa3000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00d2d000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00d77000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00ea0000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00674000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00fbd000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x0077f000) libv4lconvert.so.0 => /usr/lib/libv4lconvert.so.0 (0x00b68000) /lib/ld-linux.so.2 (0x007f6000) libMagickWand.so.2 => /usr/lib/libMagickWand.so.2 (0x20a63000) liblcms.so.1 => /usr/lib/liblcms.so.1 (0x00693000) libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00716000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00a49000) libXt.so.6 => /usr/lib/libXt.so.6 (0x00bd5000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00ceb000) libltdl.so.7 => /usr/lib/libltdl.so.7 (0x006c7000) libSM.so.6 => /usr/lib/libSM.so.6 (0x006d0000) libICE.so.6 => /usr/lib/libICE.so.6 (0x00a6a000) libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00a83000) liba52-0.7.4.so <http://liba52-0.7.4.so> => /usr/lib/liba52-0.7.4.so <http://liba52-0.7.4.so> (0x00a91000) libGLcore.so.1 => /usr/lib/nvidia-current/libGLcore.so.1 (0x1d457000) libnvidia-tls.so.1 => /usr/lib/nvidia-current/tls/libnvidia-tls.so.1 (0x00519000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00c28000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x00c42000) libuuid.so.1 => /lib/libuuid.so.1 (0x0051b000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00644000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00c4b000) Thank you very much m. _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hi
On 2010-08-16 12:30, Matteo Sisti Sette wrote:
Hi IOhannes,
thanks a lot for your help.
it seems like a missed the information about the exact version of Gem.
It's 0.92.3 (Pd version 0.42.5-extended-20100601)
thanks.
we need to know at least which backends are enabled on your system (you get that information the first time you create a [pix_film] object).
Here's what pix_film says:
pix_film:: quicktime support pix_film:: libmpeg3 support
I guess if only these are enabled it is because no more are available on the system, do I guess right?
actually it means, that the version of Gem you are using has been compiled with only these 2 backends.
then we need to know which libraries you have installed to support these codecs (e.g. if you have the QT4L backend enabled, which version of libquicktime/libquicktim4linux do you have installed). it's probably enough to send the output of $ ldd /path/to/Gem.pd_linux
Here's the output of ldd:
[...]
aha. actually, my request was a bit non-sensical as i don't learn very much.
however, from your backend list i learn, that your h.264 file is decoded using libquicktime (since libmpeg3 won't). you could try to play back the movie with the command line player "lqtplay" (part of the quicktime-x11utils). see if this one behaves as badly (if it does, then Gem is not the culprit - it's just the backend library that is so slow)
fgmadr IOhannes
On 08/16/2010 12:46 PM, IOhannes m zmoelnig wrote:
I guess if only these are enabled it is because no more are available on the system, do I guess right?
actually it means, that the version of Gem you are using has been compiled with only these 2 backends.
Ok I guessed wrong :) I got the precompiled binaries from the nightly builds (of Pd Extended). Is there a way I can get a precompiled version compiled with more backends?
thanks m.
On 08/16/2010 12:46 PM, IOhannes m zmoelnig wrote:
however, from your backend list i learn, that your h.264 file is decoded using libquicktime (since libmpeg3 won't). you could try to play back the movie with the command line player "lqtplay" (part of the quicktime-x11utils). see if this one behaves as badly (if it does, then Gem is not the culprit - it's just the backend library that is so slow)
All files play fine with lqtplay (though with some of them I continuously get the message "consumed only X bytes instead of Y").
However now I doubt about the codec. Some of the files have the .mp4 extension and others .mov, but all of them say
codec: H.264/AVC
in nautilus' properties/"Audio/Video" tab.
Lqtplay says "compressor avc1".
Does that mean they are H.264?
thanks m.
-
IOhannes m zmoelnig -
John Harrison -
Mathieu Bouchard -
Matteo Sisti Sette -
matteo sisti sette
-
Olivier Baudu -
patrick