Hey Max & Roman,

I have not looked at VLC yet, but I did experiment with the mplayer method.

Problem is there is no way to play the video backwards, which is the main stumbling block there. This makes sense since most video codecs are meant to play in one direction.

For now I'll tinker with different codecs and see what I get.

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.

I thought using just mpeg2 iframes would be enough, but I suppose not. I guess I'll try a massive mjpeg file.

.b.

Max wrote:

hi,

you can control VLC by a socket connection and pyext/python like this: http://lists.puredata.info/pipermail/pd-list/2009-01/067316.html

actually while you are at it, it might be interesting for us if you compare the two methods.

m.

Am 25.08.2009 um 21:45 schrieb Roman Haefeli:

...

hi b.

if playing it in Gem is too slow (i guess, not only decoding, but especially in Gem also the transport to the gpu takes quite some processing power), it should be possible to use mplayer to display the movie, while using pd to control mplayer. if it's about displaying movies with 'big' (depends on the computer, of course) dimensions without any further processing, i found this setup to be more performant than playing the movie with [pix_film] directly.

just a few hints:

$ mknod mplayer.control p $ DISPLAY=:0.1 mplayer -slave -input file=mplayer.control -fs yourfile.m2t

DISPLAY=:0.1 assumes, that you have an xserver running on two monitors, so that still can edit the patch, while mplayer is playing in fullscreen mode. you can omitt it, of course.

and now you can write mplayer commands to 'mplayer.pipe' from pd using [textfile].

[commands( <- e.g. 'seek -10', 'seek 300' (relative values in seconds) | [t b a] | | | [list prepend add | | | [list trim] | / [write mplayer.pipe cr, clear( | / [textfile]

!! important!! mplayer HAS to be listening on the pipe 'mplayer.pipe', otherwise pd will hang until 'mplayer.pipe' is flushed (either by mplayer or by 'cat mplayer.pipe').

if you find a way, that is less likely to block pd (by not using pipes), let us/me know.

roman

On Mon, 2009-08-24 at 17:06 -0700, B. Bogart wrote:

...

Hey all,

I'm doing a new version of "Step and Repeat" and want to do the video in HD.

I'm already shot HDV footage, which plays very well in mplayer, but not so well in Gem.

I need to do frame seeking, so I've taken my original HDV (m2t) video and converted into a large mpeg2 with 1 frame GOPs and loading the TOC.

Everything plays fine, but the playback is extremely slow.

What are the best options for HDV playback on linux?

I could lower the resolution, and load all frames into a pix_buffer.

I could lower the resolution and just play the file.

Looks like there is no "RAM" message to load the whole file into RAM and playing from RAM on linux?

The target machine is a AMD dualcore 4500+ (or something close).

Any advice appreciated.

Anyone know if you can do frame-accurate mpg seeking in mplayer?

Thanks, B.

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev

---

Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

---

GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev

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@ekran.org mailto:ben@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.

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