[PD] Gem CVS + pd-0.41-0test9 + Ubuntu Gutsy : Not reading videofiles

[Roman Haefeli]

On Sat, 2007-12-08 at 11:20 -0500, patrick wrote:
> hi jerome,
> 
> you can try my videos:
> http://www.workinprogress.ca/pd/gem/
> 
> but the xvid are not working (it's loading but the cpu don't like it). i 
> sent an email on gem-dev asking if someone could take a look. also, know 
> that transcode version on gutsy is too old, you need to compile it from 
> source. as an alternation, ffmpeg, mencoder are good too.
> 
> just to be sure it's not just on my box, anyone can test XVID with gem. 
> what's you cpu usage compare to mplayer, ffplay, aviplay?
> 
> patrick

both of them don't play in gem. i can load them, but they play very slow
and a major part of the image is just coloured garbage.

i am not sure, if i understand why you want to get xvid working with
gem. if you are interested in lowest possible cpu consumption, i
wouldn't expect xvid to give the best results, since it is optimized to
give very high compression and not to consume as little cpu as possible.
you said in another post, that you used a flag '-intra' wich turns every
frame into a keyframe. xvid is a codec, that is able to produce
mpeg4/ASP compliant video files. it is the nature of divx (and all
mpeg4/ASP codecs) to use interframe compression, which means: only
update parts of the image, that have changed. i don't quite see the
point of using xvid, when forcing intraframe compression (every frame
compressed seperately, without depending on previous [or even coming, as
used in some advanced codecs] frames). 

i haven't tested extensively myself, but there are some codecs around,
that do intraframe compression natively: dv/photo-jpeg/mjpeg/jpeg. don't
ask me about the details and differences between these codecs, but they
have in common, that they are designed to access arbitrary frames
randomly. some of them are probably optimized for good image quality
(dv), others probably for low cpu-consumption. if cpu load is the main
factor you are interested to optimize, try on of these, i'd suggest. 

probably some people with better knowledge (devs?) can shed light on
this, but i suspect, that the decoding might not be the major reason,
why gem uses so high cpu load, when displaying a video, but probably the
transport of the data. aaik, mplayer is highly optimized in that
respect, so if using a fast output as -vo xv, almost all cpu cycles are
used for decompression, neither for displaying nor for transport. -vo gl
eats 60% (50% @ 600MHz) more cpu than -vo xv (31% @ 600MHz). so
displaying through opengl (what gem does as well) seems to add some
overhead. 

roman

  


		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de