[GEM-dev] Playing HDV video with frame accurate seeking on Linux

Winfried Ritsch ritsch at iem.at
Wed Aug 26 09:23:05 CEST 2009


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

Am Wednesday 26 August 2009 04:59:14 schrieb B. Bogart:
> Hey Chris,
>
> I scaled my video down to 1024x768 (from 1440x1080) and not seeing any
> improvement. Using mjpeg or any other codec I recall using before gives
> me the same results as my mpg2 with all iframes.
>
> I'll keep messing with settings to increase disk IO and decrease decoding.
>
> I wonder has anyone played HDV footage using frame seeking on Linux?
>
> I'm seeing all kinds of things, like ffmpeg-mt for multi core systems,
> for mplayer, but nothing that will help in PD.
>
> Say Johannes, does gstreamer allow you to play video backwards? In
> mplayer the xv output uses much less cpu than gl or gl2, so opening a xv
> port to play the video, rather than GL, could be the trick?
>
> I managed to encode a lossless jpeg AVI from ffmpeg, but that does not
> load in Gem, so I could not test it.
>
> I'll keep tinkering.
>
> .b.
>
> chris clepper wrote:
> > On Tue, Aug 25, 2009 at 5:02 PM, B. Bogart <ben at ekran.org
> > <mailto:ben at ekran.org>> wrote:
> >
> >     One thing that is clear is that the CPU overhead is too high, but the
> >     disk usage very very low. I'd rather balance things out to use more
> > disk IO to save decoding cycles.
> >
> >
> > That is the key to all codecs.  Uncompressed doesn't require CPU to
> > decode but the disk requirements can be very high.  Delivery codecs like
> > MPEG and H.264 are the reverse situation.
> >
> > Use a JPEG based or professional capture codec like DVC whenever
> > possible.
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev






More information about the GEM-dev mailing list