Hi, I want to use Gem to synchronize several linux machines playing high resolution videos 1440x1080 or 1920x1080. any comments on that??? At the moment I ran into some problems.
- when I load one movie and play it with pixfilm or pixmovie
(autoplay 1) it works fine, but when I want to change to another movie and send [open movie2.avi( then everything almost freezes and the speed of the gem output reduces to maybe one or two frames per seconds. (the movies are the same codec, the order does not matter, I also can't load the same movie twice.) 2) to get the highest quality I am playing around with mplayer to try some codecs. I found lavc in connection with mjpeg a working solutions, but if anyone could help me with that, would be great. (mencoder /data/chr.mov -oac pcm -o /data/chr_enc1.avi -ovc lavc -lavcopts vcodec=mjpeg) 3) please feel free to add any comments on high definition videos in connection with gem. like about the use of keyframes, preferable framerates, I searched the archieves, but all the threads seem to die after some time... marius.
On 12/8/06, marius schebella marius.schebella@gmail.com wrote:
Hi, I want to use Gem to synchronize several linux machines playing high resolution videos 1440x1080 or 1920x1080. any comments on that???
I do a lot of HD work using GEM on the Mac now and here is what I find most effective:
- Lossy intra-frame but not inter-frame codec. JPEG based ones including
DVCPRO_HD are the ones to use. Data rate will be around 100Mbit which standard SATA drives easily handle. The codec needs a ton of SIMD code and multiple threads for decompression.
- Decompression to the appropriate video color space. 4:2:2 YCbCr (YUV) is
the way to go. Conversions to RGB on the CPU are going to kill any efficiency. YCbCr textures are half the memory size of RGB ones too.
- Support for YCbCr textures in the OpenGL drivers. Upload as YCbCr and
let the hardware convert the colorspace.
- DMA texturing path with no extra caching and memory copies of the texture
data. By default the driver keeps one or more copies and the routines to make the copies are often slow. Also, the card may keep copies too but that is less of a problem.
For #1 libavcodec has some fairly efficient paths for MJPEG and MPEG2 - the former is probably the faster of the two although try I frame only MPEG2. The libavcodec will also deliver #2 but you are out of luck for #3 because ATI/Nvidia don't have any support for YCbCr on Linux or Windows so neither #2 or #3 work. Finally, #4 doesn't seem to be possible using the usual ATI or Nvidia drivers although there is supposedly a way to do fast texturing on Nvidia, but I haven't gotten it to work yet.
That 1 out of 4 score is what keeps most of my paying work on the Mac for now. I am working on getting Windows up to speed which could have the byproduct of making Linux faster too since the GL drivers are pretty much the same for Nvidia.
-
chris clepper -
marius schebella