Show me 1 video with good HD quality using jitter
I have been rendering 1920 x 1080 using syphon recorder from jitter
but the quality is still not that impressive..not like other realtime software(touch designer) Is anyone working on making jitter a better graphic solution than it already is?
If someone wants to argue that jitter can already do Nice HD - Please show me 1 video on youtube or vimeo that looks good using jitter.
thanks
hello sebastian,
what kind of quality do you mean ?
my experience is, that the image qualiy in jitter is great, but it is impossible to play a single 1920 x 1080 file without stuttering.
even, if you use opengl/hap!
it is a shame, but it seems not to be on the focus of the cycling team.
the last 2 upates gave us a much better interface, but the bad playback performance is still there.
so it is not possible to play high quality hd files with jitter :-(
here are some theads concerning the issue (there are tons of it):
https://cycling74.com/forums/jit-qt-movie-playback-not-smooth/
https://cycling74.com/forums/smooth-video-playback/
https://cycling74.com/forums/stutter-on-loading/
perhaps this will be solved in a future version of max ....
best,
videomaker
he said he was rendering ... in case that means what i think – non realtime – , i wonder how a bad quality can happen at all.
i can render videos of any size in brilliant quality on my 12 years old 900 MHz computer when i choose "raw" as codec.
-110
yes I meant rendering -Roman thilenius we would have to define brilliant :).
What I am saying is Show me a non realtime or realtime rendering in youtube or vimeo of what can be consider a great or brilliant MaxMSp render.
It would be increadible if you find 2 or 3.
It seems to me that it would be great if the Cycling team put some effort and money into that.
with other realtime software i can show you some great renders but with jitter, sadly nop :(.
It sucks because I am better with Jitter than other software.
I've done a few things for Peter Gabriel using jitter in HD. Some very high quality stuff on this Blu-Ray - http://www.amazon.com/gp/aw/d/B005HS00V4/ref=mp_s_a_1_2?qid=1394528068&sr=8-2
Billy
@sebastian : perhaps you could show us the results you get (incl. patch) and what you'd expect. It's rather vague now.
okay, i see what you mean, and i try to accept that you mean realtime. :)
where in U&I software i can run movies and apply some simple effects at 800*400*24fps (G4) or 1600*800*24fps (xserve intel), doing the same in jitter only works with half the edge lenght or even less. is that what you mean?
of course in realtime the stuff written into the file sucks – because the realtime matrix does, too.
now for the solution you suggest (cycling should try harder) i am not so sure. the comparison of the two programs i mentioned above would be a bit unfair. in a native video application, video runs in the high priority thread, in jitter it does not for a reason, where in other programs effects do kind of connect "directly" to each other, in max you connect the objects only oin a symbolic layer, and so on.
your best bet is to find a strategy how to reduce CPU comsumption of your patch. which is why i suggested to not use any compression when rendering to disk, for a start. turning off any audio could also help. and turning off any jit.pwindow, of course.
yeah, i know, if you want to record your live session to disk, that wont help much.
-110
here's some videos i like, whether or not these are "great" or "brilliant" is subjective of course:
here's an demonstration of using jit.gl.hap to playback 4 1920x1080 movies:
https://vimeo.com/65325949
there's lots more videos to be found here:
https://cycling74.com/videos/
so, i'm not really sure what you're asking.
HI Rob, Thanks for posting those videos. I appreciate all of your help and dedication.
I am a big fan of Maxmsp but not when it comes to outputting hd videos - All of those posted videos seem to me low quality renderings compared to what other realtime softwares are capable.
this might have something to do with jitter I really don't know. I posted this in hopes that I would get a mod or someone from Maxmsp saying - We are working on this. I have to decide if I go deeper into maxmsp or if I should start learning another software.
Anyways see the following videos and compara quality - Maybe it is just me but I see a difference.
Select HD on the lower right hand side.
- touch designer - https://vimeo.com/24600874
- Quartz composer - http://www.youtube.com/watch?v=BjTSvEI-n6Y
- vvvv - http://www.youtube.com/watch?v=4qjqXJqRZnQ
It terms of brightness n sharpness of color, line definition etc.
All of those posted videos seem to me low quality renderings
i dont think that anyone ever was able to find out about the quality of the original from looking at a compressed web version, no matter how it was made. and when it comes to colorspaces or interpolation, the technology used in jitter should not really differ from the one in other programs.
creating a diagonal line in open GL and exporting that as H264 should look identically in max, java, quartz composer or after effects, because they all use the same open gl and the same quicktime codecs. :)
in jitter it just needs more CPU so you have to choose between "realtime recording" and "high resolution and using lots of stuff" when workin in maxmsp.
why do you need realtime? maybe you can avoid it?
-110
I use Black Magic Intensity when I need good quality real-time recordings. But for that you need also an extra computer...
When using (non real-time) rendering I never got good results. The quality of single frames is always perfect but I always get loads of frame dropping. Therefore I am very disappointed by jit.qt.record...
Here is a video I made yesterday:
And as you can see video clips are far from smooth. Some of them were recorded in real time using a screen capture software but 80% of them are recorded with jit.qt.record.
T, thank you for uploading - that is indeed a perfect example of the highest quality I had seen from jitter recording, and it is not great quality.
MOdular - It is just nice to be able to get good quality renders from the tools you use, specially if it is an expressive visual tool. I thought that maxmsp 6 and its update to jitter was going to give us higher quality renders but it looks about the same.
My disappointment is that I took hd renderingfor granted when I learned max msp and it was not until later that I realized that other realtime software give you better renders, so :(.
hopefully someone will work on this in the future.
But you have to know that I was using the default settings in jit.qt.record that compress image qite a lot, then the second compression took place when exporting from the editing software (codec H.264), and then the third compression was made by vimeo, that significantly reduced the bit rate. As a non pro user I am limited to 5000kbps and 1280x720 resolution. So there are many factors when judging the quality of videos from vimeo, youtube etc. as Roman Thilenius already mentioned.
So I think the only problem in Jitter is non real-time rendering since frames are dropping constantly. This video even better exposes the problem because I took longer clips when editing:
https://vimeo.com/71773102 (from 0:35 on)
And believe me, I took the best parts of my recordings where frame dropping is not so obvious. Everything here was recorded by using jit.qt.record at 30 fps, and again the default settings.
I'm pretty happy with the way this ended up looking on Youtube— generated in Jitter, captured with ishowU. Set to 1080p and fullscreen:
http://www.youtube.com/watch?v=v13wu3SbAzA
Yes thank T, and Antialias.
those examples are great indeed. I find that besides frame drop that the "good" hd quality still remains to be desired.
If you can get me black dots against white that look like the vid below, then I would be converted to maxmsp "hd" .. like I said my dissapointment is that no one seems to be addressing this.
from 0 - 18
I'm following this thread since a couple of days and I thought I would add my voice in.
I use max since about 10 years, mainly for jitter/visual and I must say that I've had some frustration about the graphic performances.
For many years I had a macbook pro, usually not the last one but the model 1-2 years older. And it has been many hours of optimization to find the right balance between what I want to do and the quality of the result (not even talking about recording a live performance)
A year ago I built a mackintosh with a decent graphic card (GTX670) and I must say that many issues disappeared.
I'm more interested in images, I mean, not 3D/generative things.
For live performance I work mostly in 720p because many places/companies don't have HD capabilities.
Now I find that the result has the same quality as the original (many thanks to HAP !!)
+
I can record the result in ProRes.
(This felt really like a big improvement (like for my musicians friends, when the mini disc appeared))
Here is a link to a rehearsal with 2 musicians (Dar Krift)
https://vimeo.com/76847097
+
a screenshot of the title image as I recorded it (before any compression)
(I added the grain and, in general, the idea for this project is to have a dirty image, but still, the resolution and definition can be seen)
That's the positive part (but, yes, like Roman said, more CPU is needed)
The negative part for me is this timing,scheduler,priority... thing that max is based on.
Video, and graphics in general should be out of this and have their own "timing".
I've been struggling, for example, to scroll, smoothly, a text across the screen. Without any success.
I started live video with Max/Msp/Jitter and became fluent enough so I never really tried any other similar software (and I don't really like code), so I can't have an opinion about touch designer, vvvv…
Anyway, +1 in developing Jitter, maybe taking it out of a, almost 10 years old, quicktime 7.
I would definitely give some money for that ;)
Black dots moving on a white background.
I'm actually way too busy for this but had to try it for myself. I did a quick record of a patch I'm working on with the basic jit.gl.asyncread + jit.qt.record method, settings: 1920x1080 30fps raw max 600. Converted to high quality H264, then uploaded to vimeo.
Password = jittest (be sure to enable HD)
Looks fine to me. I intentionally included the jaggy, non-antialiased lines, to show the detail is there.
One thing is that the patch normally runs at 60fps while with asyncread in the loop it only gets 30fps. I haven't looked into optimizing this as I wanted to do just a very quick test.
Jesse, i have no more than 9 fps with your patch on a mbp of 2011, 2.66 GHz i7, 4 Go ram ; it does seem to be a counterperformance
but when activating the qmetro, my kernel_task goes from 3% to 175% of cpu ; Max from 5% to 60%. I'm not sure, i might have problems with graphics :/
(off topic)
yeah Jesse's patch runs heavy... 21fps on a 3Ghz i7 quad core with GTX 670 graphics card... highly inefficient for showing a couple of balls floating around ;)
the cause is the high dim on the gridshape. lower to improve things.
I get 30fps on my 2011 MBP, 2.3 GHz i7 quad core, 8GB RAM, Radeon HD 6750M. Obviously all of this has to be tuned for your particular setup, with @dim or the number of gridshapes.
Here's a more efficient version. I'm getting ~50fps with this one.
@T: for nonrealtime i use to use metro and overdrive on, and as far as i can tell i have never seen framedrops.
So is this myth debunked now?
maybe i am just not up to date with technology (as we all know), but somehow it does not make sense to complain about problems playing a 1920x1200 video file. sure there are solutions which play that much better than jitter, but saying that is too slow ignores that this is a relative thing.
i mean, 1920, wft! did you play files of that size say ten years back? most of us just got monitors of that size ten years back, when they were like 3000 dollars and above per monitor.
here i am afraid that you will try to play 10000x6000 video back on a 32 core i13 in 2020 and still complain about the "no more than 10 frames in jitter" problem.
if time resolution matters, and the performance is limited, you must lower the size until you reach the desired framerate, it is as simple as that. or, use aftereffects and v-track. but then dont complain about "no loadbang object".
-110
So is this myth debunked now?
Loadmess I saw your video looks good for very thick white jaggie lines :). My problems is when you go delicate(thinner) on those lines and render it out of jitter. Nevertheless I guess it is the best quality vid I've seen here. And I am still not convinced.
The fact that you can get 1920 by 1080 is not the issue, the issue is that it just doesn't look as good as other Realtime Software. It is more blurry, jaggy, etc. If you can do anything with maxmsp why haven't I seen stunning videos?
So I am still wondering if this has to do with jitters capabilities. I really hope someone knowledgeable from cycling74 shines a light on this issue. Since I much rather go deeper into jitter than switch software.
If you really want to see some good graphics - search for Cinder Video or Open Frameworks.
things people are doing with those softwares are stunning. My question is will maxmsp ever get there? I am crossing my finger some moderator says -"yes we are working on this"
Or is jitter going to remain forever well... jittery :).
First Cinder video I found on google shows my point = http://vimeo.com/19413569
instead of the comparison of jitter-made and other videos on youtube, we should try to do an 1:1 comparison between jit.qt.record nonrealtime render and the results other programs produce.
but i wonder what one should use as reference process. an app like FCP or AE? or is there something more "native", like using corevideo on OSX via shell commands?
-110
why oh why are you guys loosing precious time dealing with someone who is obviously a troll?
listing .mp4 compressed clips to judge image quality is vainly.
on the other hand i really love to see the jitter 'best of' stuff on vimeo.
it would be nice to have a list of interesting online stuff, works that not centers not only on image quality but on creative quality ...
but then: what would be the parameters for the judges ...
ond the oscar goes to ...
CtrlzJones - someone has an opinion that goes against general conception and he becomes a troll.
Well so be it. I am a troll. If it weren't for "trolls" through history this world would be a messed up place.
This thread will be here in the future for other people interested in generating high quality videos that they can potentially sell to their clients, saying that I am troll doesn't do much help. :)
My purpose is not to piss people off but to see visual quality generated from jitter. Hence the title says SHOW me.
I have only been doing visual arts for over 20 year, and I am letting my eye be the judge of comparison between compressed video from VARIOUS realtime software. And from my experience rendering videos many different ways using Jitter and comparing it to other realtime Software renders I have done.
Parameters for judgment would be Something you can truthfully sell to a client, or broadcast on tv. I have various big projects in the horizon and I am trying to decide what would be the best software to use. My problem is that I reallly like maxmsp
I agree Roman with what you propose although if a cycling guy care to shine some light on this that would be even better.
no, the first turn is yours. :)
show us an example where a played and recorded sequence using maxmspjitter looks worse than the one from AE. because some here tend to not believe there is a difference ... me for example ...
it could also be we´re just talking about different things here.
Roman
the videos I posted from other software should show you a difference in quality.
I can't render for example the node and line detail in max msp that you can see in the second 2 of the video - (When the planes are deformed and the z axis is raised)
http://www.youtube.com/watch?v=1jhdJ8P7N-M
1 pixel lines: https://vimeo.com/89224570 (pw : jittest)
Vimeo compression blurred out the lines somewhat. You can download my uploaded H264 file from vimeo.
To be honest, I'm getting the feeling that the problem is not with the tool but with the user. Do you get better results when using say Cinder? Sure other people might be getting greater results with Cinder than you with Jitter but that doesn't necessarily mean Cinder is a better tool. Though it could be. Or not but it might just be easier to get 'pretty' results with it.
The fact that you can get 1920 by 1080 is not the issue, the issue is that it just doesn’t look as good as other Realtime Software. It is more blurry, jaggy, etc. If you can do anything with maxmsp why haven’t I seen stunning videos?
Blurry I haven't seen anywhere. If there is it's compression artifacts and that's not Jitter's fault. Jaggy is something else. When you render plain lines like I did you get jaggy lines because that's how any openGL engine renders a line primitive. So if I haven't done anything to it I want Jitter to render the jags. That's the correct rendition of things. Now if I want to get rid of the jags I have a whole bunch of options with antialiasing, shaders and so on. But Jitter isn't pre-cooking that for me.
Now it could very well be that you find it easier to get the results you want with other tools. And likely other tools have features that Jitter doesn't have, and viceversa. Fine, but that doesn't mean Jitter is a bad rendering tool.
If you can do anything with maxmsp why haven’t I seen stunning videos?
Maybe because Jitter users aren't so preoccupied with showing things off on youtube/vimeo?
Here's some shiny eye candy: https://cycling74.com/forums/sharing-raymarching-in-jit-gl-pix/
hm, by the way, fwiw, i once launched a jitter patcher on my windows seven boot (same mbp computer) and, with absolutely no change, it looked undeniably smoother and nicer than on my mac boot. Slightly so, but still. There was jit.gl.material in the patch, which might have done the difference.
my very 2 cents here:
capturing video directly using the screen capture (here screenflow) is my always best solution for that.
I know what you mean exactly Sebastien and even though you are probably aware of it yourself, I will say it too. If you want to have the fancy stuff, which most people doing visuals want, you should move away from Jitter and focus on Cinder/OFx or TD.
Each software has its own style, look at VDMX, or VVVV, or Jitter and you will see a certain aesthetic. Some have a workflow that pushes the aesthetic in a certain direction, and can create wonderful results, but often its hard to break of that style and do something completely different. Of course, everything is possible, but the workflow often dictates the style, which is sad since it should be the other way around (all though it is interesting have the sculpture show itself instead of allowing the sculptor define its every angle).
I am not a pro in anything really, but I can quickly see qualities and potential, that much experience and keen eye I possess.
Technically, sure, you could probably reach equal results through software, but to spend hours optimising technical infrastructure should be a thing of the past for modern visual designers. For sure, there should be some level of engineering but not to the extremes of spending 50% of the time figuring out the best ways of rendering, compiling or what not. But it depends on your interests. As a web developer I happily spend hours optimising JS-code and CSS, because it kind of goes with the territory, and you want to shave of kilobytes, even though it does not really matter. But I try to let go of this mentality and use tools that provide me with a workflow where these things does not matter.
Long story short, make the switch. Knowing languages is always a good investment, especially if several others are speaking it too. TD is killing it right now, and I feel confident that learning to use TD, Unity and having VDMX/Max in the bag is a strong combo.
what is TD ?
Td = touch designer.
Loadmess thanks for the link but the problem we are referring to is video capture not a patch.
I lose resolution when rendering. Also Maxmsp has a big community, anyone in their right minds after creating something beautiful with jitter(or any software) will record it and put in youtube or vimeo.
I am still looking for that jitter rendered "eye candy" as you call it.
Jnsjohansson thanks for the heads up, I was starting to think I might be going crazy(when people don't see what you are seeing) hahaha .
Your comment confirms some of my doubts, so for now I might just start learning TD. thanks
Since no one from cycling is shinning in- and unless someone puts up an Awesome jitter rendered video, I don't see the point on keeping this discussion going.
thanks to everyone.
P.S - I am still in love with Maxmsp and the ability it has to actually create anything, I have done lots of crazy cool projects. So Cycling people please update jitter & its rendering. thanks
Loadmess thanks for the link but the problem we are referring to is video capture not a patch.
Well didn't I just demonstrate Jitter does pixel-accurate rendering and recording? So A+B is that any patch that looks good can get recorded and look the same. There is no voodoo to it. If you do it right your recorded render will be exactly what you have on your live monitor. If you lose resolution then you're doing something wrong.
Gives us your patch to look at so we can finally talk about something concrete. 'Awesome' isn't the most precise qualifier here.
And you keep mixing 2 things: Jitter supposedly not being able to accurately record output (objective) and awesomeness of visuals (subjective). Those are separate topics.
the videos I posted from other software should show you a difference in quality.
no they dont, because those are compressed videos, and we have no clue how they were made.
in theory, recording a movie to disk can not cause any loss or change because it is just copying digital data.
i bet that the problem you see has something to do with limited processing power, different framerates, interpolation, or compression. in this field you might be right claiming that this is more difficult in jitter compared to a mastering app such as FCP or AE, where you only work in non realtime and with a steady and linear framerate. but this doesnt mean you couldnt do the same in jitter (until you run out of CPU).
[jit.qt.record awesomeness 2.0 raw 600]
btw, an uncompressed video of 1920*1080 has a bandwith of more than 155 mb/s (with alpha channel over 200.) you dont record that to disk in vvvv either during a live show. hence my (probably not perfect) note in my first post, that rendering usually means non realtime.
It is almost impossible to render a video in 1920 by 1080 raw without frame drops - Obviously this is A big issue.
But nevertheless if we disregard the frame drops and render out 1920 by 1080 raw video - Here are some captures for you to see the difference.
The last one is the rendered out video.
Although people may say there is not so much difference. When you reduce it to 1280 by 720 the difference is more palpable, and then when you compress it even more for youtube it is even more palpable. My key intention is for you to see the difference.
(i am a jitter noob and i am llooking at the patch only in patch2canvas, so pls someone correct me if i am wrong!)
i believe this is exactly what i exspected.
you are using qmetro but then record this using the record object with a fixed framerate.
have you tried recording the same in nonrealtime mode and/or putting qmetro (or metro!) to 1000/15 ms, so that frames are in sync?
-110
yeap I have tried non realtime recording before although it does help lower the drop frames there was no increase in quality.
what you are suggesting should help with framedrops but I personally don't know how it will help with quality.
it would make interpolation no longer neccessary but copies frames 1:1.
but actually i have no clue why those diagonal lines look strange in the recorded version. it shouldnt.
IMHO Jitter required general redesign. Issues related to performance, problems with recording, video input, etc. - all these things seems to be signs of that.
From the other hand: I can't say, that Jitter is outdated or "not good" - if we imagine a line between "outdated" and "cutting edge" Jitter will be located very near to "cutting edge" and very far to "outdated".
@SEBASTIANTSIWT: I'm not sure what kind of a system you want to build, but I think, you can test several strategies for better quality image, eg. for off-line (non realtime) rendering try to render-to-texture/matrix workflow, and set the texture/matrix size as high as possible (double HD resolution will be nice) - save every texture/matrix to uncompressed image, and finally use any video editor to make movie from saved images and rescale the movie to HD resolution - this is a technique I'm typically using when I'm working with video in Processing, but it should be universal. Anyway: I have no ready-made solution for your problem, but in my opinion it's rather technical question, which can be solved on patch-design level. Of course, if you can produce acceptable results using other tool just use this tool.
Boy there is a lot here on the subject. Before i read it all, can i ask a question?
I have some very nice 3D jitter things going using textures and getting all the computation on the GPU.
So far all my fancy stuff runs with only a few minor glitches at 1280 x 720 60 fps. Good enough
for live performance.
When it comes time to record, I have only found screen recording via QuickTime Player and Syphon.
Both drop frames.
jit.record and jit.qt.record (are they the same thing?) accept frames as they come. Before GPU, I
was able to get very good results by telling jit.record to record 1280 x 720 60 fps by slowling down
the rate on qmetro. That takes me out of real time but that is OK. Problem is, jit.record wants
matrices and I have textures. Is there a way to convert texture to matrix at the last minute before jit.record?
BTW. I am running on an iMac 27" at 4GHz.
jit.gl.asyncread should do the trick.
if non-realtime, you can also send a gl-texture through a jit.matrix to read the texture back as a matrix for recording. this is generally a cpu intensive task that will slow your framerate, hence the non-realtime qualifier.
With syphon try setting jit.window to visible 0. Its in the patch i posted in the facebook forum.
Once syphon is connected you don't need to see jit.window.
Also try presentation mode with no max objects visible that need to redraw like float or message boxes.