Hi Winfried,
Your case seems to fit very well with what I've been doing.
Mind giving me the tech details you used to encode the video? Was ffmpeg used to encode it? What codec, GOP, container settings?
All my results using mjpeg are giving me files with the same size, and same decoding CPU as my mpg with all iframes.
The only way I've been able to keep the quality, and lower cpu usage, has been to decrease resolution.
I'm seeing almost no disk IO usage in this case, so I could stand a lot to see that part increase.
I managed to encode a 13GB MJLS video in ffmpeg, but Gem (not even mplayer) read it.
So far I'm stuck with a 1024x768 or 800x600 video. :\ too bad.
I just tried a huffyuv stream, and man does the colour look a lot nicer than the mjpeg. Gem does load it, but its a little slow. I guess I'll try a 1280x960 version.
Remember even software RAID systems make dist access much faster. Its a simple matter to make a RAID0 array from multiple disks to solve the IO issue.
.b.
Hello,
my two cents:
once upon a time (2005), we did a videoplayback with gem 2048x768 for two beams for a opera, (2 times 8x6m screens) syncronized to audio over SMPTE so we have to play frame by frame and jumping from one to another position,for stadtoper. Since the videoartists was very acurate with playback quality we did some tests and ended up with mjpeg codec. In fact our videos had the size of 2 times 100GB, i think, and we used two harddisk, each for one film, since the hardiskperformance was the critical part.
Maybe nowadays there is a better solution, but in my experience harddisk performance is important and didnt raise to much the last years, but CPU power did, mjpeg let you address each frame with a good quality.
Since we make a new production with 3 videos sum 7500x768, we need a new solution.
mfg winfried