HD VIDEO ON MAX 6
Dear All,
I've been developping with MAX a video mixer for displaying video movies on stage, controling the mix time between sevral files and adjusting the playback time for theater peformances. (on i7 PC, SSD)
This project started years ago before HD was THE reference. I'm still improving the patch but I still have problems with smooth video playback.
I've been reading the jitter receipes and all the threads on the forums, Vade's advices and it all... most of them were posted 2 years ago...
Since Max 6, the "old" jit.qt.movie object seams to be the only one available and stays a poor alternative for HD playback within max.
I'd like to know where we are now.
Better objects? Better codecs? what's the deal with QT? in HD?
Using openGL and several slab for cropping, smooth edges and adjustment makes the video unsmooth in HD. I'd like to make some other treatments but the base is unconfortable with quicktime object.
Any new experience?
thanks.
Nicolight
Hello Nicolight,
I always use this routine of objects to get my fullHD video playing, without stuttering. The videos I use are mostly encoded in PhotoJPEG at quality 75%. This way I'm even able to play 15fps double fullHD (3840x2160) video.
If your on a mac, you can always try this external object jit.BC.QTKit which uses QTKit and copies directly to a jit.gl.texture via FBO copy.
https://cycling74.com/forums/announcing-jit-bc-qtkit-osx-only-qtkit-based-jit-qt-movie-replacement
HI Vjacobs
unfortunatly I'm under windows. thanks for the reply. 15fps is not really fine!
The 15fps was only referring to the double fullHD video, as it comes from a camera only outputting 15fps. For this reason I can't test it with higher framerates...
For 'normal' fullHD video ofcourse much higher framerates can be achieved!
What about the poor WINDOWS 7 users?...
I think there is a misunderstanding here.
For the last 3 years I have used the code snippet I posted above almost always on Windows 7 machines in very performance critic situations.
I never said it was MAC only (only the external is)
Please try for yourself...
Hi,
I thought youe patch was using the externals you were talking about. sorry. I opened it .
what's the deal with setting colormode to yuyvy in hte qt.movie object and then translating to rgba? I remove this step without any difference.
I post an extract of my mixer engine, any advice or any thing wrong?
regards.
nicolight
I think the majority of video codecs encode in that format (UYVY). By specifying it in jit.qt.movie, quicktime does not convert it to rgb using the cpu.
By converting it to RGB later using a jit.gl.slab, the computer uses the gpu instead, which is faster, and frees the cpu for the decoding and other tasks, potentially speeding up the frame rate. You also don't use so much bandwidth on the PCIe bus to the graphics card.
So, in a nutshell: performance optimization.
UYVY color space indeed uses less bandwidth in sending frames from CPU to GPU.
@nicolight: How about posting your performance patch so we can check if there's more of these potential performance gains?
Thanks guys for those advices.
any information about the autostart 0/1 that may change things?
I noticed that as soon as you add another slab to another, the frame rate gets down a little. I tried to make one with what all the slabs should do but I don't really understand how to do it properly (mixing, cropping, color correction...)
here will you find the patch I use for theater perfomances, I'm afraid it will scary you...
best regards
nicolight
Thank you Vjacobs for this trick.
As for testing with double full hd with more than 15fps, you could always make some tricks in premiere/after effects to make a 30fps version of it (even if it doesn't look right) with twixtor or another plugin or whatever just to test how well your machine runs double full hd at 30fps...
But even running 1280x720 hd is fine for most use.. this is jitter.. I don't happen to need full hd very often... it's just good to know that we aren't stuck on 640x360 or even lower.
You're right jbl, HD is not needed very often. When you use a dual or tiple head video card (matrox) it is good to know you can manage with jitter videos larger than the SD format 720x576 but 1440x576 (tested) or maybe 2160 x 576...)
Hey, all- a bizarre thing is happening with jit.bc.qtkit- I was hoping for some help. I'm trying to make a simple HD mixer, using jit.gl.pix and thought for best performance, I'd use jit.bc.qtkit. Everything works fine until I try to connect the output of jit.bc.qtkit to anything other than the syphon output. As soon as it's connected to, say, jit.gl.pix or jit.gl.slab, it seems as though the texture drops to a 1x1 resolution. I'm only getting the top left corner, I believe. And the biz arrest thing it, it effects the output from the jit.bc.qtkit itself, not just the output of the gl.pix, even once the connection is broken and the object is deleted. The only way to resolve is by closing the patch completely.
Any help would be greatly appreciated. Need something for a performance this week.
Here's what I've got:
Thanks!
Nicolight, did the uyvy trick increase the performance of your patch (quite impressive patch indeed btw!)
I'm using sometimes very high res video (3840x2160 which is in fact quadruple and not double hd) when working with spherical video. Every detail increase is beneficial in that case...
@goto10: it's probably due to changes in GL architecture in MAX6 because your patch works in Max5 (I had to insert a jit.gl.texture but everything stays on the GPU).
What does work in MAX6 iis that you use the second output form the left, which outputs the uyvy colormatrix which you can then convert back to rgba by a slab on the GPU. A bit less preferred, I know, but possible. I tried it with a fullHD movie...
Hi Vjacobs.it seems the uyvy increases the perormance well. THANKS!
The project is here :
https://cycling74.com/project/bplayer-simple-video-playlist-with-time-line-action/
and can be dowloaded here :
http://www.nicolight.fr/labo/softwares/VIMI2.zip
now another question : what's the best way for spliting one movie into 2 or 3 parts (in order to corner-pin separatly each part) just like jit.scissors do, but in OpenGl context?