Jitter Video Playback - Amatuer or Professional Grade?
This is a simple question.
Can jitter be relied upon to provide stable playback at 30 fps
with more than 1 jit-object at 720x486?
If I have just 1 jit.qt.movie object all playsback fine but
I now extract an alpha with let's say jit.unpack or jit.coerce,
etc, I can surely expect inconsistent playback, despite any
system specs (mine are beefy pc w/intel quad core).
Playback is ok most of the time, but "most of the time" isn't
good enough for broadcast work.
Is there a consensus on this?
help!!!
I would most definitely not use jitter in a broadcast environment.
You can guarantee a stable 30 fps *video signal* output from
something like a Kona card which jitter can output, but that doesnt
guarantee that the content will look like it has a stable 30 fps.
Yeah, I would shy away from that very fast.
On Jun 30, 2007, at 10:33 PM, robert vanrhyn wrote:
>
> This is a simple question.
>
> Can jitter be relied upon to provide stable playback at 30 fps
> with more than 1 jit-object at 720x486?
>
> If I have just 1 jit.qt.movie object all playsback fine but
> I now extract an alpha with let's say jit.unpack or jit.coerce,
> etc, I can surely expect inconsistent playback, despite any
> system specs (mine are beefy pc w/intel quad core).
>
> Playback is ok most of the time, but "most of the time" isn't
> good enough for broadcast work.
>
> Is there a consensus on this?
>
>
> help!!!
>
>
v a d e //
www.vade.info
abstrakt.vade.info
Can anyone run me through exactly why Jitter can't run smoothly at 30fps (or 25fps)?
I can understand it when you're doing lots of complicated processing. But when you're just trying to play back a quicktime with a few objects in the chain? And the processors are barely breaking into a sweat?
Is it to do with where Jitter is getting it's timing from? From other posts I'm presuming that the metro object is not up to the task...
Is it a deep-rooted issue that is intrinsic to the program architecture? Or is it something that could be sorted out with a 'timing external' or something similar?
Could the output be buffered in some way to make it smoother? Even an additional frame delay would be tolerable if it was predictable and gave smooth output. This issue is the single thing that stops me using Jitter for a whole bunch of 'professional' projects. Looking forward to doing my design work with a graphics tablet, a Lemur, a Matrox MXO and a (rented in) HD deck. Someday?
Well. Its complicated, you could probably improve your timing by
a) if just using playback use direct to window method (see help)
b) not use any UI elements that update rapidly, and if you have to
use qlim to slow them down.
c) if using matrix manipulation
use @unique and qmetro
play with your performance settings to optimize based on your patch
requirements.
d) use clocker message to spawn only one central clock (each metro,
delay, speedlim, qlim etc object spawns its own timer). (only matters
if you are using tons of line/delay etc objects)
and of course, try and optimize your patch.
But, im a professional video engineer as my day job (and a vigilante
jitter programmer at night ), and as far as I can tell, there is some
inherit jitter (pun intended) with the scheduler, and since at most
you will have one extra thread, youre going to hiccup occasionally.
I hope Jitter 2.0 tries to solve some of these issues, but its been
mentioned before numerous times.
On Jul 1, 2007, at 5:45 PM, marcus lyall wrote:
>
> Can anyone run me through exactly why Jitter can't run smoothly at
> 30fps (or 25fps)?
>
> I can understand it when you're doing lots of complicated
> processing. But when you're just trying to play back a quicktime
> with a few objects in the chain? And the processors are barely
> breaking into a sweat?
>
> Is it to do with where Jitter is getting it's timing from? From
> other posts I'm presuming that the metro object is not up to the
> task...
>
> Is it a deep-rooted issue that is intrinsic to the program
> architecture? Or is it something that could be sorted out with a
> 'timing external' or something similar?
>
> Could the output be buffered in some way to make it smoother? Even
> an additional frame delay would be tolerable if it was predictable
> and gave smooth output. This issue is the single thing that stops
> me using Jitter for a whole bunch of 'professional' projects.
> Looking forward to doing my design work with a graphics tablet, a
> Lemur, a Matrox MXO and a (rented in) HD deck. Someday?
>
>
>
>
v a d e //
www.vade.info
abstrakt.vade.info
Thanks for the advice, Vade.
Not much point in using Jitter unless you're getting into some GL at this point.
will look at clocker more carefully.
In the past, even a simple movie-playing patch has had problems playing back smoothly. (especially in PAL)
normally I run everything from a single qmetro or metro object and use the trigger object.
Inherent jitter sounds bad though. Obviously patches all do different things, but if we can't get a basic movie player to work accurately, there's not much of a benchmark.
Here's what I'd like to do as a minimum:
play a quicktime movie in PAL or NTSC format.
do some minor processing (cropping thru submatrix, colour correction)
display 2 videos on videoplanes in window.
no tearing. locked 25fps or 30 fps playback.
output thru Matrox MXO or similar.
Any chance for Jitter 2.0, cyclists?
Stable playback= commercially viable = prepared to pay more money for product!
you're going to have inherit issues with compositing in openGL and
then reading back to main memory to output to the MXO or other type
of professional playback device, since they dont have accelerated 3d
chipsets.
Ill agree with whats below.
If you have fast enough disks, try working with uncompressed
quicktime movies, you'll get less CPU usage for qt decompression
which is currently not threaded, as far as my understanding is
concerned.
On Jul 1, 2007, at 7:47 PM, marcus lyall wrote:
>
> Stable playback= commercially viable = prepared to pay more money
> for product!
>
v a d e //
www.vade.info
abstrakt.vade.info
mxo runs straight outta the dvi output.
it basically converts dvi to hd-sdi. Sweet!
so whatever you do on the graphics card gets turned into video.
like a fulsom imagepro but cheaper......
M
Oh. thats fucking sexy. Nevermind then. I havent used a matrox
product in a long time. My bad !
On Jul 1, 2007, at 8:45 PM, marcus lyall wrote:
>
> mxo runs straight outta the dvi output.
>
> it basically converts dvi to hd-sdi. Sweet!
>
> so whatever you do on the graphics card gets turned into video.
>
> like a fulsom imagepro but cheaper......
>
> M
v a d e //
www.vade.info
abstrakt.vade.info
Thanx Vade, as usual, your posts are excellent.
Its sooooooooo disappointing max/jitter isn't ready for prime time. We should all ask Cycling'74 to officially comment on this issue of Jittery playback with Jitter... that's probably
why they named it Jitter!
Having a "video product" produce unreliable playback at
"video resolution" is not kool. How about a car with oval
wheels... yeah it works.. but would you want to drive it?
C'mon Cycling'74, what's your position on Jittery playback.
Why isn't this a TOP PRIORITY!!!
I'm not pissed - just very disappointed. Max/Jitter is very
kool software - but seriously hobbled for professional video
usage.
rvr :<
Hey Guys,
What about the "movie" object via MAX (no jitter).
Since there are no metros involved in its usage, should I expect
perfect playback as long as I have good hard-drive speed?
rvr
kinda sounds like you could use quartz composer then and save some money. Or are there similar problems there as well?
And if we keep this thread really active, do you think a cyclist will eventually bestow us with some info?
Seriously though, we all realise that we're asking for a lot here. We haven't bought a broadcast-spec product, nor are many of people concerned with this.
But. If it could be done, it would seriously open the market up.
It would mean I could actually get paid to use Max. Which would make a huge difference. Still dreaming of doing my moving graphics work with a wacom pen and lemur while humming and pretending I'm in a life drawing class. And smoothly outputting to that hd deck. And receiving cheques for it.
Does anyone else see the attraction?
I think a much much better option is to make pluggo for jitter, and
output an AE/Core Image compatible plugin that you can then use in
traditional media and more easily mix into existing workflows.
yes, ive made this feature request.
On Jul 2, 2007, at 8:43 PM, marcus lyall wrote:
>
> kinda sounds like you could use quartz composer then and save some
> money. Or are there similar problems there as well?
>
> And if we keep this thread really active, do you think a cyclist
> will eventually bestow us with some info?
>
> Seriously though, we all realise that we're asking for a lot here.
> We haven't bought a broadcast-spec product, nor are many of people
> concerned with this.
>
> But. If it could be done, it would seriously open the market up.
> It would mean I could actually get paid to use Max. Which would
> make a huge difference. Still dreaming of doing my moving graphics
> work with a wacom pen and lemur while humming and pretending I'm
> in a life drawing class. And smoothly outputting to that hd deck.
> And receiving cheques for it.
> Does anyone else see the attraction?
>
>
v a d e //
www.vade.info
abstrakt.vade.info
So, the technical essence of this problem is that jit.qt.movie defers all its input to the low priority (main) thread, right? You'd want an output at scheduler rate, which is currently impossible.
So I was thinking about two possible solutions:
a) provide an object that stores matrices and supports scheduler rate access (something like jit.matrixset except that it also defers to main).
b) currently, querying an attribute of any jitter object is also deferred. This is illustrated in the patch below. Now if for example the gettime message to jit.qt.movie in scheduler thread would not be deferred to the main thread, it would be possible to at least record the current times with a separate (scheduler-rate) metro and render the movie back later in a non-realtime situation. In broadcast quality.
Mattijs
And here is what I think could be a solution with the current options:
Mattijs
I was going on about the fact that Jitter doesn't output at a clean frame-rate. (I know there are also other scheduling issues). But it turns out that very few QT apps do, unless they are in 'mastering mode'. While researching the Matrox MXO, I found this......
"When Matrox MXO is used with QuickTime-based applications that support the V-out component including Final Cut Pro, Soundtrack Pro, Motion, and After Effects, it operates in ?Mastering Mode?.
:....Matrox MXO patent-pending technology uses the DVI port on your Mac computer in a unique way to provide frame-accurate audio/video output for insert editing and print-to-tape with guaranteed a/v sync......"
patent pending not so good. but frame accurate does...
"Normally when previewing video from a QuickTime application, the native YCbCr video (sometimes inaccurately called ?YUV? video) is converted to the RGB color space for output over the DVI connection. The frame rate of the RGB video does not match the standard for broadcast video. For example, it may be 75 Hz rather than the 59.94 Hz standard for NTSC. The frame sequence, therefore, inevitably includes dropped and/or repeat frames"
which is why you get problems with standards converters..
"....Matrox MXO, on the other hand, takes the YCbCr video from the QuickTime application and sends it directly out over the DVI connection with time-stamping information that allows the MXO box to reconstruct the frame sequence at the broadcast standard frame rate. It also sends eight digital audio tracks that are then embedded in the SDI signal in perfect sync with the video....."
Has anyone got one and tried to get broadcast video out of it?
Well, see, the thing here is that Jitter still wont provide clean
framerate to the device. The device will clean this up and output a
solid 59.94/29.97 or whatever standard you want. Same for Decklink
and Kona cards, which I have tried this, and you get a perfectly
standard video signal, but it looks wobbly because jitter is..
jittery :)
from the MXO forums: http://forum.matrox.com/mxo/viewtopic.php?
p=252&sid=af33dc44c79859c043ab9a13bd775352
The MXO works in Mastering mode with any application that is based on
the QuickTime engine and has a *video output component*. If the app
is not based on the QT engine it will not work in Mastering mode.
There is nothing specific that we would be able to tell their
developers other than the above.
Since Jitter does not have a quicktime output component, no joy.
You'd probably not want that anyway, as youd have to readback from
the GPU, and the GPU is where all the fun is at.
THis is also the first I have heard of Mastering Mode in QT. Curious.
I could be wrong about all that though, but it makes sense to me.
On Aug 24, 2007, at 2:59 PM, marcus lyall wrote:
>
> I was going on about the fact that Jitter doesn't output at a clean
> frame-rate. (I know there are also other scheduling issues). But it
> turns out that very few QT apps do, unless they are in 'mastering
> mode'. While researching the Matrox MXO, I found this......
>
> "When Matrox MXO is used with QuickTime-based applications that
> support the V-out component including Final Cut Pro, Soundtrack
> Pro, Motion, and After Effects, it operates in ?Mastering Mode?.
>
>
> :....Matrox MXO patent-pending technology uses the DVI port on your
> Mac computer in a unique way to provide frame-accurate audio/video
> output for insert editing and print-to-tape with guaranteed a/v
> sync......"
>
> patent pending not so good. but frame accurate does...
>
> "Normally when previewing video from a QuickTime application, the
> native YCbCr video (sometimes inaccurately called ?YUV? video) is
> converted to the RGB color space for output over the DVI
> connection. The frame rate of the RGB video does not match the
> standard for broadcast video. For example, it may be 75 Hz rather
> than the 59.94 Hz standard for NTSC. The frame sequence, therefore,
> inevitably includes dropped and/or repeat frames"
>
> which is why you get problems with standards converters..
>
> "....Matrox MXO, on the other hand, takes the YCbCr video from the
> QuickTime application and sends it directly out over the DVI
> connection with time-stamping information that allows the MXO box
> to reconstruct the frame sequence at the broadcast standard frame
> rate. It also sends eight digital audio tracks that are then
> embedded in the SDI signal in perfect sync with the video....."
>
> Has anyone got one and tried to get broadcast video out of it?
>
>
>
>
v a d e //
www.vade.info
abstrakt.vade.info
And interestingly enough, a search for mastering mode quicktime -mxo
(no mxo references) yeilds just about pure noise.
Methinks mastering mode is a marketing gimmic. But ive never worked
with the QT apis so im just shooting from the hip.
On Aug 24, 2007, at 2:59 PM, marcus lyall wrote:
>
> I was going on about the fact that Jitter doesn't output at a clean
> frame-rate. (I know there are also other scheduling issues). But it
> turns out that very few QT apps do, unless they are in 'mastering
> mode'. While researching the Matrox MXO, I found this......
>
> "When Matrox MXO is used with QuickTime-based applications that
> support the V-out component including Final Cut Pro, Soundtrack
> Pro, Motion, and After Effects, it operates in ?Mastering Mode?.
>
>
> :....Matrox MXO patent-pending technology uses the DVI port on your
> Mac computer in a unique way to provide frame-accurate audio/video
> output for insert editing and print-to-tape with guaranteed a/v
> sync......"
>
> patent pending not so good. but frame accurate does...
>
> "Normally when previewing video from a QuickTime application, the
> native YCbCr video (sometimes inaccurately called ?YUV? video) is
> converted to the RGB color space for output over the DVI
> connection. The frame rate of the RGB video does not match the
> standard for broadcast video. For example, it may be 75 Hz rather
> than the 59.94 Hz standard for NTSC. The frame sequence, therefore,
> inevitably includes dropped and/or repeat frames"
>
> which is why you get problems with standards converters..
>
> "....Matrox MXO, on the other hand, takes the YCbCr video from the
> QuickTime application and sends it directly out over the DVI
> connection with time-stamping information that allows the MXO box
> to reconstruct the frame sequence at the broadcast standard frame
> rate. It also sends eight digital audio tracks that are then
> embedded in the SDI signal in perfect sync with the video....."
>
> Has anyone got one and tried to get broadcast video out of it?
>
>
>
>
v a d e //
www.vade.info
abstrakt.vade.info
On Aug 24, 2007, at 12:16 PM, vade wrote:
>
> Since Jitter does not have a quicktime output component, no joy.
> You'd probably not want that anyway, as youd have to readback from
> the GPU, and the GPU is where all the fun is at.
I would need to do more research before commenting on "mastering
mode", as this is the first I'd heard of it, but if the matrox has a
QT video output component, jit.qt.videoout will work with it just
like it does for DV, Media-100 cards, etc. on Macintosh. On windows,
we only support DV with jit.dx.videoout.
In general for future major upgrades, we're considering ways to
improve stable clock timing for video output, but it will require
some alternate threading models, and possibly some different video
specific objects.
-Joshua
I have to say, as someone who gets paid to watch/configure/set up
professional gear all the time, seeing those small but noticeable
hiccups in Jitter is really disheartening from an end user
perspective. Id say its really my largest complaint quality of life
wise.
Id really be more than happy to abandon some backwards compatibility
for new threading 'apparati' and objects.
Thanks! Not trying to prod or rip on jitter, but some constructive
observations!
Id also be very curious professionally about this 'mastering mode'.
An apple developer docs search yielded nothing either.
:)
On Aug 24, 2007, at 4:30 PM, Joshua Kit Clayton wrote:
>
> On Aug 24, 2007, at 12:16 PM, vade wrote:
>
>>
>> Since Jitter does not have a quicktime output component, no joy.
>> You'd probably not want that anyway, as youd have to readback from
>> the GPU, and the GPU is where all the fun is at.
>
> I would need to do more research before commenting on "mastering
> mode", as this is the first I'd heard of it, but if the matrox has
> a QT video output component, jit.qt.videoout will work with it just
> like it does for DV, Media-100 cards, etc. on Macintosh. On
> windows, we only support DV with jit.dx.videoout.
>
> In general for future major upgrades, we're considering ways to
> improve stable clock timing for video output, but it will require
> some alternate threading models, and possibly some different video
> specific objects.
>
> -Joshua
v a d e //
www.vade.info
abstrakt.vade.info
"In general for future major upgrades, we're considering ways to
improve stable clock timing for video output, but it will require
some alternate threading models, and possibly some different video
specific objects."
I cannot express how great this would be.
>I think a much much better option is to make pluggo for jitter, >and output an AE/Core Image compatible plugin that you can then >use in traditional media
It would be so great !
Mastering-mode is simply matrox's term for "outputting to tape".
There is no "Apple Quicktime-Mastermode".
VideoOutComponent (on Macs) is what is necesary for stable
NTSC output.
If Jitter could output stable video I believe my professional
life would change drastically... for the better.
I wonder when Cycling 74 will publically address this issue...
Its so disappointing because Max/Jitter is such an awesome program - so fuc$#@g habit-forming once you GET-IT!
So now I look for other applications because of unstable video..
me soooo sad :<
..but me still love max/jitter :> :<
Well, you could always render to disk using something like Render
Node, and save in a broadcast formay lik Uncompressed 4:2:2 and drop
it into FCP :)
On Aug 27, 2007, at 1:48 PM, robert vanrhyn wrote:
>
> Mastering-mode is simply matrox's term for "outputting to tape".
> There is no "Apple Quicktime-Mastermode".
> VideoOutComponent (on Macs) is what is necesary for stable
> NTSC output.
>
> If Jitter could output stable video I believe my professional
> life would change drastically... for the better.
>
> I wonder when Cycling 74 will publically address this issue...
> Its so disappointing because Max/Jitter is such an awesome program
> - so fuc$#@g habit-forming once you GET-IT!
>
> So now I look for other applications because of unstable video..
> me soooo sad :<
>
>
> ..but me still love max/jitter :> :<
>
>
>
>
v a d e //
www.vade.info
abstrakt.vade.info
Vade,
I work in a TV broadcast environment as well... live TV.
I have 20 quicktime clips w/alpha... each clip is under 5 seconds - they are keyable animations actually... 720x486.
I want to be able to INSTANTLY playback any clip via a KEYBOARD
press or MIDI input. I also need to have the alpha extracted
as well because the clips will be keyed with a video switcher -
a Sony MVS 8000...but any switcher will do.
My plan was to use a "Miranda SDI DVIramp2" to extract the
VIDEO and ALPHA imagery straight from the DVI output... as per
DVIramp2 documentation.
There are many ways to build such a patch using Jitter or with
MAX using the MOVIE object. I have built many variations and
they all work very well... except for those damm HICCUPS...
I even see hiccups when not using Jitter! :
Yeah, I tried using editing apps but none have the response time of Max/jitter and dont allow for customization... these
apps are closed... you know what I mean...
So I am now going to look into other tools like QComposer,
diadora, cdmx, etc, etc, etc...and some VJ apps... I just keep coming back to max/jitter because... I dunno... I just want
to... I dig it.
But thanx Vade..
much appreciated.
There's a big market out there now for video playback servers for live events. Maybe have a look here, to see how big.
All of them are expensive, closed systems. So I don't want to give these people my money. I want to give it to you. Because you have a community of artists that really want to push the envelope. And your software allows me to build things the way I need them.
But all of these other systems have perfect video timing. This means they can be used on professional jobs today. Video technicians will smile at me. Clients will comment on the smoothness of the playback. I will feel confident that the guitarist, looking at how his hugely magnified arm moves across a screen, will not be distracted by dropped frames. So they get the budget instead.
I've had a tiny Jitter patch out on the road with a large rock tour for about 12 months now. The crew have never had a crash. Even the video delay isn't a problem, as the sound is often 3-4 frames late for a lot of the audience anyway.
But it's only one scene in amongst many. You don't notice the glitching too much, but I couldn't do a whole show using it. We're just dipping a toe in the water. In theory we could run the whole show from Jitter.
Now I know that non-jumpy video playback through Quicktime and OpenGL is possible, because I just worked on another show that uses Catalyst for playback, and it does just this.
OK, so my use is a little specialised, But what about trade show stands, public LED screen displays, point-of-sale screens, live TV, live concerts and a million other uses where client won't pay for glitchy video playback? Especially when it's forty feet high.
I know I'm sounding dreadfully commercial here, but those are the jobs that pay for me to do art. It's deeply frustrating to know that I can make something great in Jitter, but I can't use it on 99% of paid jobs because people will moan about the glitchy playback. Why bother to launch fully into Jitter, if you're going to have to find another way to deliver the idea anyway? It kinda relegates Jitter to being a prototyping tool.
Hmmm. Another rant there. I guess I have a bit to get off my chest. Again, not trying to be critical, just trying to point out the potential for what you have.
yesyesyes,
I can blow-away so many "professional-broadcast" products
with max/jitter... if there were no hiccups/stable 30fps :<
maybe someday... :<
Hi Guys,
In the interest of keeping this critique constructive, could somebody
post an example patch that demonstrates the issue clearly, with
supporting media if necessary?
FYI, there isn't much action in Jitter-land these days, as all of our
resources are being focussed on the next big version of Max. However,
these issues are important to us, and we hope to address it in some
various ways in a future version of Jitter.
Best,
Andrew B.
Try playing an uncompressed 1080P movie off of a fast enough disk
into Jitter, with multiple slab processing (order of 10 slabs or more).
This has been mentioned and documented many times. Its CPU/System
dependent, but you can get any system to hiccup.
ie: if someting hiccups on my Macbook Pro, it may not hiccup on a
Quad G5, but, if I push the patch more I can get things to hiccup.
Multiple QT clip playback blocks OpenGL drawing (I saw this quite
often today), even with an idle 30% CPU usage on my performance patch
(lots of OpenGL).
If really need a specific patch, in 2 weeks i may have some breahting
time to document Jitter VS other environments to show the difference
in performance with playback and GL effects.
BTW, I dont think this was a rag on Jitter, I think we all know it
wasnt designed to do this, and those who are trying know damn well
they are pushing it. Its just.... *so close* :)
On Aug 27, 2007, at 8:08 PM, andrew benson wrote:
> Hi Guys,
> In the interest of keeping this critique constructive, could
> somebody post an example patch that demonstrates the issue clearly,
> with supporting media if necessary?
>
> FYI, there isn't much action in Jitter-land these days, as all of
> our resources are being focussed on the next big version of Max.
> However, these issues are important to us, and we hope to address
> it in some various ways in a future version of Jitter.
>
> Best,
> Andrew B.
v a d e //
www.vade.info
abstrakt.vade.info
andrew, i have. there was no answer from cycling at all.
https://cycling74.com/forums/index.php?
t=msg&goto=108347&rid=0&S=e1eb31609661290bc11abd264858ee62&srch=hd
+performance+with+jit.qt.movie#msg_108347
is that sufficient?
On Aug 27, 2007, at 8:08 PM, andrew benson wrote:
> Hi Guys,
> In the interest of keeping this critique constructive, could
> somebody post an example patch that demonstrates the issue clearly,
> with supporting media if necessary?
>
> FYI, there isn't much action in Jitter-land these days, as all of
> our resources are being focussed on the next big version of Max.
> However, these issues are important to us, and we hope to address
> it in some various ways in a future version of Jitter.
>
> Best,
> Andrew B.
>
regarding smooth multiclip playback via jitter...
I have noticed that if you use a STOP message, then a START
message... you will get smooth playback more consistently,
not always :>, but better...
also, audio will always be in sync if you use a STOP, START.
but these audio issues (on my pc, not mac - mac is fine) may be specific to my pc - not sure - will test further..
anyway, for example...
my BANG triggers a message "time ####, stop, start" to a
jit.qt.movie object. This appears to help a bit.
I use the "time" message because I condensed my 20 clips
into 1 long clip, then loadram the entire clip.
Yes, this doesnt give the HYPER-SUPER-CRAZY cueup/playback
speed of merely sending a "time ####" message only...
buts its fast enough for some of my usages...
rvr
also vade,
regarding disk speed... wouldnt loading an entire clip into ram
via LOADRAM be better than any disk based recalls?
have you ever played with ramdrives?
ive tried commercial apps which make s RAMDRIVE with whatever amount you specify... let my content live in the RAMDRIVE... then still use LOADRAM for my clips... I see no performance
difference...
that kinda tells me that LOADRAM (without RAMDRIVE) is doing
a nice job... i tried this because I wanted to see if diskspeed
was ever a culprit... seems for me... its loadram or nothing.
rvr
marcus,
thanx for those links - those products look like "GVG-profile"
units after they have ingested ECSTACY... instead of NTSC...
very trippy video servers.
IN the US broadcast we use a lot of "grass valley profile
video servers"... but they dont have trippy software like your
links...
but like you... i prefer to "roll my own" :>
er. you cant load a 1080p clip into ram, #1. #2, disk access with
those drives are inredibly sub par. Ive read quite a few testimonials
with people moding Mac Book Pros with ramdrives, and all have had
worse performance.
and if you mean Ram Disk, you deal with the OS's concept of ram,
which also contains virtual memory, which also hits the disk.
This is not a problem with disks, this is a jitter problem, as
Quicktime, QC Modul8, etc, can handle this more robustly.
On Aug 30, 2007, at 4:41 PM, robert vanrhyn wrote:
>
> also vade,
>
> regarding disk speed... wouldnt loading an entire clip into ram
> via LOADRAM be better than any disk based recalls?
>
> have you ever played with ramdrives?
>
> ive tried commercial apps which make s RAMDRIVE with whatever
> amount you specify... let my content live in the RAMDRIVE... then
> still use LOADRAM for my clips... I see no performance
> difference...
>
> that kinda tells me that LOADRAM (without RAMDRIVE) is doing
> a nice job... i tried this because I wanted to see if diskspeed
> was ever a culprit... seems for me... its loadram or nothing.
>
> rvr
>
v a d e //
www.vade.info
abstrakt.vade.info
*tiny*
This is what I see as one of the issues. It is my belief that these
performance problems come from complicated patches above a certain
threshold of events. I can make a simple one slab 1080p clip playback
fine, but adding more slabs, even if disabled, cause slowdowns (yes,
there is more processing that has to be done), but more importantly,
larger hiccups. I understand reduced performance, but the hiccups are
serious. I can tolerate 20 fps, but not 25->15 ->20 etc.
yes, I know, I know, not constructive, but I think at some point, it
becomes very very hard to submit a bug report of a simple test case,
because inherently the issue is due to the size of the patch, number
of gl calls, or something that becomes an issue as patch complexity
grows.
On Aug 27, 2007, at 7:34 PM, marcus lyall wrote:
> 've had a **********tiny******** Jitter patch out on the road with
> a large
v a d e //
www.vade.info
abstrakt.vade.info
rvr: the concert stuff I do is very similar to broadcast tv. we use profiles, doremis and 360's to do playback. same sort of thing.
Very aware that I am trying to replace about $100,000 of dedicated video hardware with home-brew software. It just seems so close...
If FCP and Catalyst can sort out the timing issues, I'm sure it's possible to sort it out in Jitter.
Not trying to criticise C74's efforts at all. It's wonderful to even imagine being able to write my own video software, something I wouldn't have dreamt of doing ten years ago.
andrew, will do some more testing soon, new mac arriving next week.
Hi vade and cycling and others following this thread,
Once again, don't you think the hiccups are inherent to the fact that jit.qt.movie (and everything later in the chain) operate in the low priority queue? Low priority threads are likely to be interrupted by any kind of threads running in the background.
Isn't what you want simply a jit.qt.movie in the scheduler thread?
Mattijs
Quote: vade wrote on Thu, 30 August 2007 23:55
----------------------------------------------------
> *tiny*
>
> This is what I see as one of the issues. It is my belief that these
> performance problems come from complicated patches above a certain
> threshold of events. I can make a simple one slab 1080p clip playback
> fine, but adding more slabs, even if disabled, cause slowdowns (yes,
> there is more processing that has to be done), but more importantly,
> larger hiccups. I understand reduced performance, but the hiccups are
> serious. I can tolerate 20 fps, but not 25->15 ->20 etc.
>
> yes, I know, I know, not constructive, but I think at some point, it
> becomes very very hard to submit a bug report of a simple test case,
> because inherently the issue is due to the size of the patch, number
> of gl calls, or something that becomes an issue as patch complexity
> grows.
>
>
>
>
> On Aug 27, 2007, at 7:34 PM, marcus lyall wrote:
>
> > 've had a **********tiny******** Jitter patch out on the road with
> > a large
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
>
>
>
>
>
>
----------------------------------------------------
here's a test patch.
running this patch alongside qt player.
same media on two different fast drives.
qt movie is uncompressed, captured from decklink card.
macpro 8core. 16gb ram.
mostly the playback is excellent, but stuttering after the movie loops around to the start, from then on...
seems to be intermittent. sometimes it's fine. sometimes not.....
doesn't seem to be losing time though. was running in sync with the qt player over 4 mins.
As you have a bumping machine just well it might be a dum question
but why not use qmetro 40 instead of clocker to feed the bumper
> what happens with short DV movies is there any difference???
Hubert
I've tried qmetro, clocker, the lot.
someone else sent me a patch with exactly that in it.
but there's still an issue with qmetro too.
Interestingly, I just went to look at a 'professional video server', a piece of software (written by a company that shall remain nameless) and costing some thousands of pounds.
And guess what? They've got exactly the same problem too. Stuttering video images. And they hadn't even noticed it. The sales guy phoned the programmer and asked him what was up. He hadn't seen it either and is checking it out.
I've done a lot of online editing for broadcast, so I'm used to looking for picture errors.but don't think i'm being stupidly anal about this. Stick it on a big screen, and the problem becomes pretty obvious. As it does when you try to play back 'narrative film' instead of abstract stuff.
Reading between the lines, it looks like this company's clients use this software for playing back video on low-res screens where you don't notice the glitches, then use Doremi's for SD playback.
They were using a very similar method to Jitter, texturing videoplanes with video. As do pretty much all the other software servers out there.
What does this tell us?
We were playing back AVI's and QT's on a PC. So the issue is not exclusive to Mac, or to quicktime, or to Jitter. But there is no issue if you play back the same media using Quicktime Player on the mac.
I thought it could be a screen refresh problem, but the QT Player test kinda rules this out.....
Well, I can also say FCP Studio 2.0 does not have this issue as well,
and they use OpenGL for playback. If you set Dynamic RT to Full,
Resolution to Full and Framerate to full within the timeline, you can
play back up to 2K material on an FCP station at full framerate
supposing you have the drive bandwidth. Of course other software wont
be as optimized, and I dont think anyone said this was a jitter only
issue, but lets flip it around and say, other people are doing it,
and we would absolutely love to be able to do it, and I also think,
at this point, Cycling understands, gets that we want to do it, has
other priorities with getting Max 5 out the door, and has publicly
stated they would love to do this as well, but if it will happen, it
will happen in Jitter 2.0
I think that about sums it up.
:)
On Sep 28, 2007, at 11:53 AM, marcus lyall wrote:
>
> I've tried qmetro, clocker, the lot.
> someone else sent me a patch with exactly that in it.
> but there's still an issue with qmetro too.
>
> Interestingly, I just went to look at a 'professional video
> server', a piece of software (written by a company that shall
> remain nameless) and costing some thousands of pounds.
>
> And guess what? They've got exactly the same problem too.
> Stuttering video images. And they hadn't even noticed it. The sales
> guy phoned the programmer and asked him what was up. He hadn't seen
> it either and is checking it out.
>
> I've done a lot of online editing for broadcast, so I'm used to
> looking for picture errors.but don't think i'm being stupidly anal
> about this. Stick it on a big screen, and the problem becomes
> pretty obvious. As it does when you try to play back 'narrative
> film' instead of abstract stuff.
>
> Reading between the lines, it looks like this company's clients use
> this software for playing back video on low-res screens where you
> don't notice the glitches, then use Doremi's for SD playback.
>
> They were using a very similar method to Jitter, texturing
> videoplanes with video. As do pretty much all the other software
> servers out there.
>
> What does this tell us?
>
> We were playing back AVI's and QT's on a PC. So the issue is not
> exclusive to Mac, or to quicktime, or to Jitter. But there is no
> issue if you play back the same media using Quicktime Player on the
> mac.
>
> I thought it could be a screen refresh problem, but the QT Player
> test kinda rules this out.....
>
>
>
>
>
>
>
>
>
v a d e //
www.vade.info
abstrakt.vade.info
but isn't this a drive-related (or throughput you might say) issue?
if you're working with HD on FCP you need a RAID or striped array to
play back cleanly. without the redundancy you'll get dropped frames
and such. and if you add any processing into the equation you'll
suffer even more, whereas working with final cut or after effects
you'll need to render out your effects.
b
On Sep 28, 2007, at 12:46 PM, vade wrote:
> Well, I can also say FCP Studio 2.0 does not have this issue as
> well, and they use OpenGL for playback. If you set Dynamic RT to
> Full, Resolution to Full and Framerate to full within the timeline,
> you can play back up to 2K material on an FCP station at full
> framerate supposing you have the drive bandwidth. Of course other
> software wont be as optimized, and I dont think anyone said this
> was a jitter only issue, but lets flip it around and say, other
> people are doing it, and we would absolutely love to be able to do
> it, and I also think, at this point, Cycling understands, gets that
> we want to do it, has other priorities with getting Max 5 out the
> door, and has publicly stated they would love to do this as well,
> but if it will happen, it will happen in Jitter 2.0
>
> I think that about sums it up.
>
> :)
>
>
> On Sep 28, 2007, at 11:53 AM, marcus lyall wrote:
>
>>
>> I've tried qmetro, clocker, the lot.
>> someone else sent me a patch with exactly that in it.
>> but there's still an issue with qmetro too.
>>
>> Interestingly, I just went to look at a 'professional video
>> server', a piece of software (written by a company that shall
>> remain nameless) and costing some thousands of pounds.
>>
>> And guess what? They've got exactly the same problem too.
>> Stuttering video images. And they hadn't even noticed it. The
>> sales guy phoned the programmer and asked him what was up. He
>> hadn't seen it either and is checking it out.
>>
>> I've done a lot of online editing for broadcast, so I'm used to
>> looking for picture errors.but don't think i'm being stupidly anal
>> about this. Stick it on a big screen, and the problem becomes
>> pretty obvious. As it does when you try to play back 'narrative
>> film' instead of abstract stuff.
>>
>> Reading between the lines, it looks like this company's clients
>> use this software for playing back video on low-res screens where
>> you don't notice the glitches, then use Doremi's for SD playback.
>>
>> They were using a very similar method to Jitter, texturing
>> videoplanes with video. As do pretty much all the other software
>> servers out there.
>>
>> What does this tell us?
>>
>> We were playing back AVI's and QT's on a PC. So the issue is not
>> exclusive to Mac, or to quicktime, or to Jitter. But there is no
>> issue if you play back the same media using Quicktime Player on
>> the mac.
>>
>> I thought it could be a screen refresh problem, but the QT Player
>> test kinda rules this out.....
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
>
>
>
bruce tovsky
www.skeletonhome.com
"The secret to creativity is knowing how to hide your sources."
Albert Einstein
I didnt say it was a drive related issue. Read more closely.
And you will always have a limit of how many effects you can have on
a hardware of sofgtware based system. You never have unlimited and
infinitely efficient processing. We are discussing a playback issue
withing Jitter. I think youve misunderstood what ive stated, and
perhaps others.
On Sep 28, 2007, at 1:20 PM, bruce tovsky wrote:
> but isn't this a drive-related (or throughput you might say) issue?
> if you're working with HD on FCP you need a RAID or striped array
> to play back cleanly. without the redundancy you'll get dropped
> frames and such. and if you add any processing into the equation
> you'll suffer even more, whereas working with final cut or after
> effects you'll need to render out your effects.
> b
>
> On Sep 28, 2007, at 12:46 PM, vade wrote:
>
>> Well, I can also say FCP Studio 2.0 does not have this issue as
>> well, and they use OpenGL for playback. If you set Dynamic RT to
>> Full, Resolution to Full and Framerate to full within the
>> timeline, you can play back up to 2K material on an FCP station at
>> full framerate supposing you have the drive bandwidth. Of course
>> other software wont be as optimized, and I dont think anyone said
>> this was a jitter only issue, but lets flip it around and say,
>> other people are doing it, and we would absolutely love to be able
>> to do it, and I also think, at this point, Cycling understands,
>> gets that we want to do it, has other priorities with getting Max
>> 5 out the door, and has publicly stated they would love to do this
>> as well, but if it will happen, it will happen in Jitter 2.0
>>
>> I think that about sums it up.
>>
>> :)
>>
>>
>> On Sep 28, 2007, at 11:53 AM, marcus lyall wrote:
>>
>>>
>>> I've tried qmetro, clocker, the lot.
>>> someone else sent me a patch with exactly that in it.
>>> but there's still an issue with qmetro too.
>>>
>>> Interestingly, I just went to look at a 'professional video
>>> server', a piece of software (written by a company that shall
>>> remain nameless) and costing some thousands of pounds.
>>>
>>> And guess what? They've got exactly the same problem too.
>>> Stuttering video images. And they hadn't even noticed it. The
>>> sales guy phoned the programmer and asked him what was up. He
>>> hadn't seen it either and is checking it out.
>>>
>>> I've done a lot of online editing for broadcast, so I'm used to
>>> looking for picture errors.but don't think i'm being stupidly
>>> anal about this. Stick it on a big screen, and the problem
>>> becomes pretty obvious. As it does when you try to play back
>>> 'narrative film' instead of abstract stuff.
>>>
>>> Reading between the lines, it looks like this company's clients
>>> use this software for playing back video on low-res screens where
>>> you don't notice the glitches, then use Doremi's for SD playback.
>>>
>>> They were using a very similar method to Jitter, texturing
>>> videoplanes with video. As do pretty much all the other software
>>> servers out there.
>>>
>>> What does this tell us?
>>>
>>> We were playing back AVI's and QT's on a PC. So the issue is not
>>> exclusive to Mac, or to quicktime, or to Jitter. But there is no
>>> issue if you play back the same media using Quicktime Player on
>>> the mac.
>>>
>>> I thought it could be a screen refresh problem, but the QT Player
>>> test kinda rules this out.....
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> v a d e //
>>
>> www.vade.info
>> abstrakt.vade.info
>>
>>
>>
>
> bruce tovsky
> www.skeletonhome.com
>
> "The secret to creativity is knowing how to hide your sources."
> Albert Einstein
>
v a d e //
www.vade.info
abstrakt.vade.info
no, YOU read more closely - i said "isn't this a drive related
issue?" i believe my response was on topic and relevant, though my
experience is more in the commercial video world rather than with
jitter or gl specifically. however, they all have to deal with the
same set of hardware requirements. i think we're both saying the same
thing (i saw you mention drive bandwidth, i was just adding some
detail) and optimization is also very important, and of course apple
has the inside edge on that front. but i think that data bandwidth is
more critical than optimization, but that's just me... ;-)
cheers
bruce
On Sep 28, 2007, at 2:29 PM, vade wrote:
> I didnt say it was a drive related issue. Read more closely.
>
> And you will always have a limit of how many effects you can have
> on a hardware of sofgtware based system. You never have unlimited
> and infinitely efficient processing. We are discussing a playback
> issue withing Jitter. I think youve misunderstood what ive stated,
> and perhaps others.
>
> On Sep 28, 2007, at 1:20 PM, bruce tovsky wrote:
>
>> but isn't this a drive-related (or throughput you might say)
>> issue? if you're working with HD on FCP you need a RAID or striped
>> array to play back cleanly. without the redundancy you'll get
>> dropped frames and such. and if you add any processing into the
>> equation you'll suffer even more, whereas working with final cut
>> or after effects you'll need to render out your effects.
>> b
>>
>> On Sep 28, 2007, at 12:46 PM, vade wrote:
>>
>>> Well, I can also say FCP Studio 2.0 does not have this issue as
>>> well, and they use OpenGL for playback. If you set Dynamic RT to
>>> Full, Resolution to Full and Framerate to full within the
>>> timeline, you can play back up to 2K material on an FCP station
>>> at full framerate supposing you have the drive bandwidth. Of
>>> course other software wont be as optimized, and I dont think
>>> anyone said this was a jitter only issue, but lets flip it around
>>> and say, other people are doing it, and we would absolutely love
>>> to be able to do it, and I also think, at this point, Cycling
>>> understands, gets that we want to do it, has other priorities
>>> with getting Max 5 out the door, and has publicly stated they
>>> would love to do this as well, but if it will happen, it will
>>> happen in Jitter 2.0
>>>
>>> I think that about sums it up.
>>>
>>> :)
>>>
>>>
>>> On Sep 28, 2007, at 11:53 AM, marcus lyall wrote:
>>>
>>>>
>>>> I've tried qmetro, clocker, the lot.
>>>> someone else sent me a patch with exactly that in it.
>>>> but there's still an issue with qmetro too.
>>>>
>>>> Interestingly, I just went to look at a 'professional video
>>>> server', a piece of software (written by a company that shall
>>>> remain nameless) and costing some thousands of pounds.
>>>>
>>>> And guess what? They've got exactly the same problem too.
>>>> Stuttering video images. And they hadn't even noticed it. The
>>>> sales guy phoned the programmer and asked him what was up. He
>>>> hadn't seen it either and is checking it out.
>>>>
>>>> I've done a lot of online editing for broadcast, so I'm used to
>>>> looking for picture errors.but don't think i'm being stupidly
>>>> anal about this. Stick it on a big screen, and the problem
>>>> becomes pretty obvious. As it does when you try to play back
>>>> 'narrative film' instead of abstract stuff.
>>>>
>>>> Reading between the lines, it looks like this company's clients
>>>> use this software for playing back video on low-res screens
>>>> where you don't notice the glitches, then use Doremi's for SD
>>>> playback.
>>>>
>>>> They were using a very similar method to Jitter, texturing
>>>> videoplanes with video. As do pretty much all the other software
>>>> servers out there.
>>>>
>>>> What does this tell us?
>>>>
>>>> We were playing back AVI's and QT's on a PC. So the issue is not
>>>> exclusive to Mac, or to quicktime, or to Jitter. But there is no
>>>> issue if you play back the same media using Quicktime Player on
>>>> the mac.
>>>>
>>>> I thought it could be a screen refresh problem, but the QT
>>>> Player test kinda rules this out.....
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> v a d e //
>>>
>>> www.vade.info
>>> abstrakt.vade.info
>>>
>>>
>>>
>>
>> bruce tovsky
>> www.skeletonhome.com
>>
>> "The secret to creativity is knowing how to hide your sources."
>> Albert Einstein
>>
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
>
>
>
bruce tovsky
www.skeletonhome.com
"The secret to creativity is knowing how to hide your sources."
Albert Einstein
..............
You pointed out that other systems have the same issue as Jitter with
regard to hiccuping playback.
I pointed out that other systems, software based, can, in fact play
back HD without dropping a frame. It seems we both interface with
these sorts of systems daily.
I mentioned drive throughput offhandledly as a pre-requisite for
simply being able to read the data at its required bitrate (obvious).
It is clear drive throughput is NOT the problem with jitters playback
hiccups, but an obvious pre-requisite FOR ANY system to be able to work.
if you cannot get the data fast enough, how on earth do you expect to
be able to play it sans hiccup?
Anyway, i think are in agreement .
FLAME OFF!
On Sep 28, 2007, at 2:56 PM, bruce tovsky wrote:
> no, YOU read more closely - i said "isn't this a drive related
> issue?" i believe my response was on topic and relevant, though my
> experience is more in the commercial video world rather than with
> jitter or gl specifically. however, they all have to deal with the
> same set of hardware requirements. i think we're both saying the
> same thing (i saw you mention drive bandwidth, i was just adding
> some detail) and optimization is also very important, and of course
> apple has the inside edge on that front. but i think that data
> bandwidth is more critical than optimization, but that's just
> me... ;-)
> cheers
> bruce
>
> On Sep 28, 2007, at 2:29 PM, vade wrote:
>
>> I didnt say it was a drive related issue. Read more closely.
>>
>> And you will always have a limit of how many effects you can have
>> on a hardware of sofgtware based system. You never have unlimited
>> and infinitely efficient processing. We are discussing a playback
>> issue withing Jitter. I think youve misunderstood what ive stated,
>> and perhaps others.
>>
>> On Sep 28, 2007, at 1:20 PM, bruce tovsky wrote:
>>
>>> but isn't this a drive-related (or throughput you might say)
>>> issue? if you're working with HD on FCP you need a RAID or
>>> striped array to play back cleanly. without the redundancy you'll
>>> get dropped frames and such. and if you add any processing into
>>> the equation you'll suffer even more, whereas working with final
>>> cut or after effects you'll need to render out your effects.
>>> b
>>>
>>> On Sep 28, 2007, at 12:46 PM, vade wrote:
>>>
>>>> Well, I can also say FCP Studio 2.0 does not have this issue as
>>>> well, and they use OpenGL for playback. If you set Dynamic RT to
>>>> Full, Resolution to Full and Framerate to full within the
>>>> timeline, you can play back up to 2K material on an FCP station
>>>> at full framerate supposing you have the drive bandwidth. Of
>>>> course other software wont be as optimized, and I dont think
>>>> anyone said this was a jitter only issue, but lets flip it
>>>> around and say, other people are doing it, and we would
>>>> absolutely love to be able to do it, and I also think, at this
>>>> point, Cycling understands, gets that we want to do it, has
>>>> other priorities with getting Max 5 out the door, and has
>>>> publicly stated they would love to do this as well, but if it
>>>> will happen, it will happen in Jitter 2.0
>>>>
>>>> I think that about sums it up.
>>>>
>>>> :)
>>>>
>>>>
>>>> On Sep 28, 2007, at 11:53 AM, marcus lyall wrote:
>>>>
>>>>>
>>>>> I've tried qmetro, clocker, the lot.
>>>>> someone else sent me a patch with exactly that in it.
>>>>> but there's still an issue with qmetro too.
>>>>>
>>>>> Interestingly, I just went to look at a 'professional video
>>>>> server', a piece of software (written by a company that shall
>>>>> remain nameless) and costing some thousands of pounds.
>>>>>
>>>>> And guess what? They've got exactly the same problem too.
>>>>> Stuttering video images. And they hadn't even noticed it. The
>>>>> sales guy phoned the programmer and asked him what was up. He
>>>>> hadn't seen it either and is checking it out.
>>>>>
>>>>> I've done a lot of online editing for broadcast, so I'm used to
>>>>> looking for picture errors.but don't think i'm being stupidly
>>>>> anal about this. Stick it on a big screen, and the problem
>>>>> becomes pretty obvious. As it does when you try to play back
>>>>> 'narrative film' instead of abstract stuff.
>>>>>
>>>>> Reading between the lines, it looks like this company's clients
>>>>> use this software for playing back video on low-res screens
>>>>> where you don't notice the glitches, then use Doremi's for SD
>>>>> playback.
>>>>>
>>>>> They were using a very similar method to Jitter, texturing
>>>>> videoplanes with video. As do pretty much all the other
>>>>> software servers out there.
>>>>>
>>>>> What does this tell us?
>>>>>
>>>>> We were playing back AVI's and QT's on a PC. So the issue is
>>>>> not exclusive to Mac, or to quicktime, or to Jitter. But there
>>>>> is no issue if you play back the same media using Quicktime
>>>>> Player on the mac.
>>>>>
>>>>> I thought it could be a screen refresh problem, but the QT
>>>>> Player test kinda rules this out.....
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> v a d e //
>>>>
>>>> www.vade.info
>>>> abstrakt.vade.info
>>>>
>>>>
>>>>
>>>
>>> bruce tovsky
>>> www.skeletonhome.com
>>>
>>> "The secret to creativity is knowing how to hide your sources."
>>> Albert Einstein
>>>
>>
>> v a d e //
>>
>> www.vade.info
>> abstrakt.vade.info
>>
>>
>>
>
> bruce tovsky
> www.skeletonhome.com
>
> "The secret to creativity is knowing how to hide your sources."
> Albert Einstein
>
v a d e //
www.vade.info
abstrakt.vade.info
hi vade
On Sep 28, 2007, at 3:16 PM, vade wrote:
> You pointed out that other systems have the same issue as Jitter
> with regard to hiccuping playback.
well, the potential issue if not correctly hardware/software
optimized, yes. i work on an Avid system (turnkey/hardware optimized)
at work and Final Cut at home, and i know how tricky it can be
optimizing a FCP system: video cards, RAIDS, software settings all
combine to make a big headache. the edit facility i rent a room in
has switched from Avid to FCP for cost savings but the headaches are
fierce.
> I pointed out that other systems, software based, can, in fact play
> back HD without dropping a frame. It seems we both interface with
> these sorts of systems daily.
more than i like, for sure. just getting my feet wet with HD, about
to upgrade to avid adrenaline HD.
> I mentioned drive throughput offhandledly as a pre-requisite for
> simply being able to read the data at its required bitrate
> (obvious). It is clear drive throughput is NOT the problem with
> jitters playback hiccups, but an obvious pre-requisite FOR ANY
> system to be able to work.
interesting. i haven't seen much mentioned about that in the posts
i've read. i would assume that people who are trying to work with HD/
2K must be knowledgeable about drive bandwidth... as you said "obvious".
> if you cannot get the data fast enough, how on earth do you expect
> to be able to play it sans hiccup?
you said it! can our expectations be too high? ;-)
> Anyway, i think are in agreement .
across the board.
> FLAME OFF!
never was on, on my side...
cheers
b
bruce tovsky
www.skeletonhome.com
"Flying is learning how to throw yourself at the ground and miss."
Douglas Adams
Er..
I just thought it would be useful to post a patch that showed the problem, even on a fast machine, as requested.
The point I was trying to make was that you don't need a complex chain of slabs to see the problem. Just playing the movie back on a gl videoplane shows it.
I went to see this video server software because I've got a job coming up which needs video playback from a computer. What interested me was the fact that these guys had released the software with a similar stuttering problem and hadn't noticed it.
So it's obviously not an easy one to spot.
FCP is built around playing stable video. You can't do anything to it while it's playing. I've been wondering whether there's an intrinsic issue with keeping a stable frame rate and being able to 'play with' the video at the same time.
I'm not asking for the problem to be solved overnight. I was just curious about whether it's a relatively straightforward thing to do, or a massive change in software architecture.
So what happened in the past 3 years? Has jitter improved it's clock? Does any of you now use it for commercial purposes or is it too much of a custom multimedia software thing?
And now ? What's new ? I noticed this problem is still not solved ? Any trciks ? Or did I miss something ? Thx.
Lots of threads on video performance in the forums. What's your specific issue? What playback method are you using? There's a lot of common patching inefficiencies to avoid before the only thing left to blame is Jitter or Quicktime.
hello, I'm not really a noob. I use optimization patch like Vade and others posted few years ago. If you need it I can detailed what the format of movies and the programming I use. but I'm pretty sure all is optimizated. the problem is that the rate oscillates between 35 and 50 fps and make a stroboscopic movie (at 25fps) not playing accurate...
"So what happened in the past 3 years? "
Video performance seems to be a bit problematic (especially when build around [jit.qt.movie])... I think, many things are now open for changes, with 64bit Max...
Moreover, personally, I'l be very happy with deeper integration with Quartz - on OSX Quartz can offer some useful things.
give us something to test... ideally with the actual video that causes problems
> the problem is that the rate oscillates between 35 and 50 fps and make a stroboscopic movie (at 25fps) not playing accurate…
why play back a 25fps movie at higher frame rate? seems to me it's always going to be jittery unless multiples of the original fps are used (50, 75, etc).
>why play back a 25fps movie at higher frame rate? seems to me it’s always going to be jittery unless multiples of the original fps are used (50, 75, etc).
yes I konw and tried already, for sure. but the framerate is NEVER exactly at 25, 50, 75 fps but oscillates a little bit up and under this value. in that case there's some frames dropped and make the movie playing not straight.
the test is easy. make a movie with a stroboscopic effect and try to play it in openGL with accuracy. the problem is well related in this thread. jit.qt.movie is set on unique 1, preload 1, with a preload ram of the first 2s, playing to few ji.gl.slab, then jit.gl.cornerpin... then render and window.
you know, I noticed this problem for looooong time but until now it was not a real problem. and if I want to solve it just I have to use modul8 or resolume... :-)
find enclosed a capture of propriety of the movie.
a snippet of a movie would be real handy...
As Vade said : This is what I see as one of the issues. It is my belief that these performance problems come from complicated patches above a certain threshold of events. I can make a simple one slab 1080p clip playback fine, but adding more slabs, even if disabled, cause slowdowns (yes, there is more processing that has to be done), but more importantly, larger hiccups. I understand reduced performance, but the hiccups are serious. I can tolerate 20 fps, but not 25->15 ->20 etc.
yes, I know, I know, not constructive, but I think at some point, it
becomes very very hard to submit a bug report of a simple test case,
because inherently the issue is due to the size of the patch, number
of gl calls, or something that becomes an issue as patch complexity
grows.
here's extracts but I suppose it will be difficult to notice the same problem as it appears sometime after few seconds, sometime after one min...
And once again, just make a simple movie with a stroboscopic effect. play it with QT, and play with a simple openGL player with max and you'll see the difference.
Make the test with a second screen or a vp.
have you tried jit.gl.hap?
https://cycling74.com/tools/jit-gl-hap/
I tried your test2 movie with the patch below. I definitely saw stutters at some point while trying different frame rates. Then it went away and didn't reappear, also not at the frame rate I first saw it. I seem to be having good results with rendering at my monitor's refresh rate with sync on (60Hz). I'm not seeing fps fluctuations regardless of the set frame rate.
Out of curiosity, what OS and system are you on?
Btw, I've had my share of GL rendering jitter in the past:
https://cycling74.com/forums/cyclical-frame-rates (resolved by swapping the gfx card...)
https://cycling74.com/forums/gl-render-weirdness-fluctuating-fps-with-2-contexts-2-screens/
@rob: oooooh yes it seems very intereting. I'll check this asap. thx a lot.
@dtr: os10.6.8, max6.1.2 - I didn't get time to go furtherwith this problem. will check your links asap.
Could using an external sync source such as an AJA Gen10 help solve some of these problems? In broadcast land they are used to ensure that the frame rate always stays locked at the desired rate.
IIRC these devices just put out a signal of clicks at a precise rate. Using a small buffer frames could theoretically be drawn and output at each click. Video gear with SDI genlock input is necessary of course.
Back to this big issue. jit.gl.hap didn't solve as I suspect the problem comes from the fact we have to use qmetro to render. And qmetro is not stable...
So the only solution we found is to use another software to play the videos (like resolume)...
It's really bad for Max and a little bit disappointing...
yes, it is really a shame, that we can not play a single movie without stuttering.
so we can not use max in a proffessional show context :-(
which i would love to do !!!
it is so disappointing that these smal, but important things are not on the roadmap of cycling ....
i think jit.gl.hap was a big step in the right direction !
perhaps something is happening in max7 :-)
Can you share your patch and a sample video? I'd like to try it too.
Btw, I think anyone criticizing C74 on this should provide material to confirm the claims.
Also, there's no obligation to use qmetro over metro.
Even with metro it's not accurate. I just tried it...
but for sure HAP improves te result...
Patch and sample?
What do the glitches look like? Are you sure it's not a combination of display refresh frequency, (q)metro frequency and video framerate? Respectively 60 / 24 / 23.976 hz (for example) is bound to yield duplicated or skipped frames. Don't forget that the frequency of the display is also a factor.
hello dieter, we had already this discussion just above in this thread... ;-)
the problem is still the same. I tried already many different configurations.
here's a patch and a sample. try to play one with QT and one with the patch. the strob and the move are not constant in the patch.
for sure it's better with the HAP codec but not perfect in my performance patch.
maybe it's because of other process (kinect, sound, multi tracks audio in the video file, etc)
video test PhotoJPEG : http://we.tl/sk2yGqZLYI
video test HAP : http://we.tl/aMDccrsPnP
hello all,
its good that this thread is comming up.
it would be great, if it could be possible to play and mix full hd movies without hickups in max/msp/jitter !
i had the best experience in making a standalone hap movie player+mixer, which does not have any gui element inside.
all the gui elements i put in a seperate standalone connected with osc to the player.
smaler patches plays fine, if the 2 applications are on the same computer.
if i still have hickups, i use a macpro for playing and a seperate computer for organizing the movies.
@ft: the moviefiles, you have uploaded are damaged !
best,
pc
ha maybe because the wetransfer...
here it is in zipped : http://we.tl/w7VFh3sSis
Ok I'm seeing stutters as well. 1 video playing is smooth but with 2 I get occasional stutters.
This might sound counter intuitive but I seem to be getting it smooth again by increasing the qmetro frequency to a multiple of the video framerate. In attached patch I set it to 10ms, which clips to 60hz/16ms because of sync enabled on jit.window. I didn't test it awfully long though.
I have a feeling that when the (q)metro is set at exactly the video frame rate Max misses a frame when it lags a little bit. By increasing the qmetro frequency we're banging the player multiple times per frame, making sure that we're not missing any. Something like Nyquist rate in the audio domain. Now if jit.gl.hap had a 'unique' attribute like jit.qt.movie we wouldn't get unnecessary processing of doubled frames down the line.
This is all total hypothesis so please confirm/negate...
I'm on a beefy i7 quad-core desktop with GTX 670 graphics.
I confirm your feeling. In the case of my performance patch, I can't set to 60Hz because I have variations from 40Hz to 60Hz due to the other processes. so...
but I will try the tricks of 2 applications asap.
I'm doing this for my heavy setups too. Separate apps for camera/kinect tracking, sensor inputs, openGl rendering, etc. Data gets passed via Max's networking objects, which also makes it easier to spread things over multiple computers if need be.
Is there a patch demonstrating 'off-line' rendering to a matrix and subsequent sequencing of matrix frames to a video recording device without frame drops?
That should work by setting the render metro (not qmetro) to something slow (to make sure every frame has the time to be rendered) and jit.qt.record/jit.vcr (don't remember which) to non-realtime mode.