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