I would say it also depends on what you want to do with the video. if you want to do scratching/forward backward, not all codecs will be able to do that. (am I wrong?) at least make sure that you don't use keyframes for that. marius.
IOhannes m zmoelnig wrote: > patrick wrote: >> hi, >> >> i am on linux running the very last version of gem from cvs. i am trying >> to find a good codec for gem. here's my basic research: >> >> --------------------------------------- >> the best codec for quicktime is jpeg: >> transcode -i yourvideo -y mov,null -F jpeg,,jpeg_quality=70 -o gem.mov >> >> gem cpu usage is 38% >> mplayer cpu usage is 27% >> ffplay cpu usage is 16% >> lqtplay cpu usage is 1% ** >> >> * lqtplay seems to make a excellent job for decoding is own codec. would >> it be possible to make a pix_qt based on the source of this player??? >> > > which coded is Gem using to decode the mov? > if it is quicktime4linux, then the results for _decoding_ should not > differ so much. > > apart from the fact that Gem uses openGL to display the video, which is > portentially slower than xv-overlay...could you test to only decode the > videos with [pix_film], without any [pix_texture] and compare these? > and put your video-files online so other people can participate in the > review? > > > fmar > IOhannes > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list