Final Cut Pro X Released

[Bruce Allen]

Regarding background rendering... the problem is that the background rendering in FCPX pauses even when you scrub through your timeline. If you are actively editing then it's pausing way too much. Actively editing means scrubbing, playing or browsing through clips.... basically interacting with your timeline. Now that doesn't make any sense. It's not really background rendering. It's waiting for FCPX to be idle so it can render.

What you want is:

FOREGROUND (EDITING) THREADS: sufficient cores and hard drive bandwidth allocated in order to keep things realtime
BACKGROUND (RENDERING) THREADS: everything unused should be rendering the timeline like crazy, stopping for now man.

This is theoretically possible.

I think the problem is that it's REALLY HARD to predict in advance exactly how much resources the foreground thread is going to need.

I mean... FCP X would have to predict: oh shit, the user hit play and there's a bunch of layers coming up... and they have a 3rd party plugin on them adding flares to the highlights - and I think there are 25 highlights in the next shot... and one of them is using footage that is on some fragmented files so drive latency is going to go up... I'd better take 3 cores off of the background tasks, give it 90% of my GPU and restrict background storage bandwidth to 38.3MB/s.

...and then you have the variable of all of the other processes running in your system. That's really difficult to get right and not drop frames!

For now I think they just said "screw it, we'll just tell it to render the moment the user stops editing."

Acceptable compromise for now, I think!

Bruce Allen
www.boacinema.com

 

[Tim Morten]

Chris, you have a tendency to post information which lacks basis, and then get upset when you get called out on it. You would be better served by qualifying your posts as your own understanding or your own opinion.

LCD panels are not inherently locked to 60hz, to the best of my own knowledge and experience, and I've yet to see evidence from you that they are.

I'm going to refrain from responding to your insults and mischaracterizations, as I don't think there is value to anyone on this thread in continuing along those lines. I leave it as an exercise for the reader to evaluate the validity of your ongoing assertions, which you often seem to state as fact.

Cheers,
Tim

 

[Andrae Palmer]

Bruce,

If it's background rendering when the user stops editing... that's exactly what we have now in FCP and Premiere Pro. The only progress is that it's saving us from telling it when to render. Since it's needlessly rendering most of the time now... I would rather just tell it when to render.

 

[Terry VerHaar]

The problem is that it's not background rendering while you are editing. The process is paused while you are scrubbing, playing or trying out new effects. My issue with it is that it's not doing it's job. It's only background rendering when you are idle... basically not interacting with FCPX.

Honestly not trying to be argumentative, just trying to understand. It seems like it is more of a psychological annoyance (and an inaccurate term?) than a real "issue." On the one hand, it never slows down your work because it abruptly halts whenever you start to work, thus allocating all resources to be dedicated to your foreground work. On the other hand, the rendered files are not essential for your work to proceed so you don't experience any problems there. Also, as long as you don't quit, the rendering will eventually finish and FCP-X will make then use of your optimized files.

Kind of like having a guy who washes your car whenever you are stopped but never while you are driving? :lol:

 

[Andrae Palmer]

Well what it's like right now is... that I'm driving my car and the bum comes up to my car at the stop light and starts washing my car window (without asking my permission) when I'm just trying to drive my car somewhere. FCPX is rendering like crazy without knowing your intent.

 

[Terry VerHaar]

Chris, you have a tendency to post information which lacks basis, and then get upset when you get called out on it. You would be better served by qualifying your posts as your own understanding or your own opinion.

LCD panels are not inherently locked to 60hz, to the best of my own knowledge and experience, and I've yet to see evidence from you that they are.

I'm going to refrain from responding to your insults and mischaracterizations, as I don't think there is value to anyone on this thread in continuing along those lines. I leave it as an exercise for the reader to evaluate the validity of your ongoing assertions, which you often seem to state as fact.

Cheers,
Tim

Tim, I am sure you're going to slam me for butting in here but, what the heck... :w00t:

Actually, I would love to get to the bottom of this because I am quite interested in the validity of Apple's claim of "color managed workflow." So I think there is value in resolving the disputed "facts." Just my two cents.

And, to be quite honest, it does seem like Chris is handling his end of the discussion quite well... you tell him he is "out of his depth" but he seems to calmly respond with facts. I'll admit I can't yet discern who seems to be "more right" but you seem to be the one who is unwilling to cite anything to back your claims. Sorry, just my perception. And, like I said, I'd really like to understand this.

 

[Terry VerHaar]

Well what it's like right now is... that I'm driving my car and the bum comes up to my car at the stop light and starts washing my car window (without asking my permission) when I'm just trying to drive my car somewhere. FCPX is rendering like crazy without knowing your intent.

OK - I'll back off. It was my silly analogy. But, what if the bum was invisible and did it without slowing you down one iota when the light turns? Would he still be a nuisance? :001_smile:

 

[Andrae Palmer]

I'm mostly debunking a lot of nonsense about there being anything particularly unique about broadcast monitors.

Albeit he is defending his position... but statements like this don't help. You are telling me you don't see anything unique in a broadcast monitor vs computer lcd monitor? Well broadcast monitors are unique simple because they have more input/outputs and have builtin color profiles. Take mine for example... it's 10 bit, DCI-P3, REC709, 3Gb/sec single link HD-SDI, waveform and a bunch of other scopes, ac or dc operation, 64x64x64 Matrix 3D LUT color management. Those are just a few of the features... now that's pretty damn unique. Unless you can verify the Colorsync/colorimeter workflow being good enough... then you can't make a statement that there is nothing unique in a broadcast monitor.

I'm not trying to defend a position... I'm trying to get it working. I could hardly give a damn about being wrong or right. I want to know what's a good workflow and what's an affordable workflow.... the pros and cons. You tell me I can get rid of my Flanders monitor... then I'm like... o' wow... I can sell this baby and get at least 4k to acquire a new MacBook Pro with thunderbolt for Pegasus RAID. I'm all practical. That's why I'm a big proponent on here of getting rid of a RED Rocket card and just purchasing a 12 core Mac pro which is good enough (2k realtime playback in Davinci Resolve and Premiere Pro via CPU debayering).

 

[Santiago Marti]

I still don't get why reduser is giving so much space to fcpx. Really, it seems not one person is using it for r3d. It doesn't open or import or "ingest" r3ds.

We never had imovie threads in reduser, well, maybe one, i don't know, but is useless.

For what i read and the little time i spent with it is really useless for what most of us do, only the auditioning function is really cool. The rest is like a bad joke, the magnetic timeline, only one monitor, etc...

Even red giant software's president said "we will be ready when you are", talking to the users, so i don't see any plugin working in the near future, or maybe ever. I can't imagine the foundry working on their plugins for fcpx.

I am not willing to start another flamewar, but let's move on, if you like fcpx, use it at your own risk.

Ps: please avid and adobe, don't think you have to bring some magical things of fcpx to your soft, please keep going your way. Well, auditioning would be great, the rest, leave it there.

 

[Andrae Palmer]

Santiago,

I'm trying to learn it not necessarily to support existing workflows... but just to see if this is really the platform for the future. Basically to see if there is anything to it. No doubt this is a very powerful software. I love the realtime playback effects and I could actually use the darn thing if Apple just supported broadcast monitoring and XML. Just those two additions alone would make it functional for my intended uses. It's kind of a love hate relationship... I want to use it but I can't. For the life of me I can't think why they would add many features from Color into FCPX and not support a broadcast monitor. Since I've started playing around with it many other issues have been raised. Like do you really want to build your business with Apple when they don't communicate anything to you? God knows revolutions can be very disruptive.

Ps: please avid and adobe, don't think you have to bring some magical things of fcpx to your soft, please keep going your way. Well, auditioning would be great, the rest, leave it there.

Yeah please don't add gimmicky marketing tools... like background rendering that doesn't render in the background. Just work on Adobe Media Encoder and make it more powerful.

 

[Santiago Marti]

I know Andrae, but it seems no one here or at apple knows exactly what they are talking about, because, you know, there isn't any explanation anywhere of how colorsync works. I really would like the simplicity of a quadro card, 10bit displayport to my dreamcolor, easy and unexpensive, but i don't know if that works, probably not, and i can't find my magical connector, don't know where i put it.

 

[D Fuller]

Honestly, this kind of thing grows tiring. ... Frankly, you can make a compelling argument on this basis that it's actually advantageous to monitor in 8-bit, if you want your material to look as good as it can for the largest number of viewers.

Honestly, this argument is just silly. By this logic, you could argue for grading on a 6-bit monitor. Plenty of people are watching YouTube on laptop.

Is that where you think we're going? Or is that just where you think Apple thinks we're going?

For what it's worth, I've always agreed with you that Apple is not seriously concerned with the "pro" market, and that this has always been the case. They are a consumer products company that has dallied in various pro spaces. And you are right that the elegance they bring to consumer products has often benefitted more serious users.

But to argue that a cinematographer should not care about the very real differences between 8 and 10-bit color because some peop,e can't see them is akin to arguing that a painter shouldn't paint in oils because the full effect won't be seen in a print. That dog just won't hunt.

 

[Alan Dang]

LCD panels are not inherently locked to 60hz, to the best of my own knowledge and experience, and I've yet to see evidence from you that they are.

After agreeing that we were beating a dead horse on FCP, I promised myself I wouldn't post in this thread unless I could mention a horse in almost every sentence. <sigh> Refresh rates between CRTs and LCDs are a horse of a different color.

CRT
On an analog CRT, the refresh rate reflects the time that it takes for the system to display an entire screen. Since it's analog, everything is direct coupled. It starts with the RAMDAC (which is integrated into a GPU nowadays) which reads the data from the framebuffer and sends it directly to the display. The display then scans the electron beam across the glass at that same speed. When the e-beam hit the phosphot, it lit up "instantly' but the decay is slower. The decay is what allows monitors to refresh at a specific rate and also account for the flicker. The intensity/decay depends on the type of phosphor used (P22, SMPTE-C, Trinitron, etc.). I know that the P22 consumer phosphor had a decay rate of something like 0.8ms for a 10% shift but that the colors decayed slightly differently and that the P22 was engineered to give a punchier, more saturated color for consumers (this in the pre-color calibration era).

72 Hz was reported as "flicker free" by manufacturers because the decay was small enough that by the time it was perceived by the average user, the electron beam was already redrawing/re-energizing the phosphor. This was a marketing number since it was possible to notice an improvement in flicker with increasing refresh rates.

LCD
The signal path for an LCD is different than that of a CRT. I will focus on the pure-digital transmission since analog transmission is the same thing with a DAC and ADC on each end. With LCDs, the source sends data via a protocol such as DisplayPort, SDI, DVI/HDMI. Although displayport can theoretically "directly drive" an LCD panel, the majority of panels are still driven by LVDS controllers.

Most LVDS controllers output at 60Hz.

This is the bottleneck in which the LVDS chip may be receiving data from the PC at >60Hz but the LVDS only changes the pixels of the LCD at 60Hz.

However, unlike the CRT, this isn't a problem. In a CRT (or plasma) situation, the electron beam directly energizes phosphors. Without a refresh, the image begins to decay. With LCD, there is a continuous light source whether it be CCFL or LED. CCFLs aren't like old-school fluorescent bulbs powered by magnetic ballasts that refreshed at 60Hz. Electronic ballasts refresh at 20kHz to 60kHz depending on the model. So even though the phosphors in the CCFL decay, they're being re-energized at a faster rate (and therefore do not flicker).

Recently, improvements have allowed for 120Hz and now 240Hz LCD displays. At least for conventional PC monitors, this is the exception rather than the norm.

LCDs work by changing the alignment of crystals in the matrix to control the amount of light that is filtered. The response-time of the LCD reflects the speed with which the alignment can change. So one speed is the one that the computer is barking instructions to the display and the other speed is the ability for it to "keep up" with the orders.

Originally, LCD pixel refresh was reported in black-to-white-to-black, the slowest/worse case scenario. Technologies such as overdrive (changing the voltage and pattern of voltage) allowed faster gray-to-gray transitions, and since gray-to-gray is statistically more common, is how manufacturers report their numbers. Still, this is the best case rather than the worst case scenario.

Further complicating the LCD situation is the balance between color accuracy and performance. TN-film based displays offer the fastest pixel refresh times and are cheaper and easier to manufacture. These have poorer color accuracy (as many are based on dithering) and poor viewing angles with greater color shifts. IPS displays offer the widest viewing angles and the most accurate color, but are classically slower and more prone to smearing and also suffer from worse black levels. MVA/PVA are supposed to the middle ground compromise.

OLED
OLED is the future. The best viewing angles, and a response time in the 0.01 ms range. All OLED is not created equal and historically the challenge with OLED has been color accuracy, durability and cost. I haven't seen the Sony OLED displays, but presumably it's pretty accurate.

 

[Scott Crawley]

How it's working right now in FCPX is if you scrub through your timeline background rendering pauses. If you add a new video effect background rendering stops and restarts from the beginning. You can set when the background rendering starts but it pauses for everything you are doing on the timeline. Your method of working is what anyone can currently do with Premiere Pro and FCP by utilizing Adobe Media Encoder or Compressor. Apple is trying to reinvent something... their way of implementing it doesn't make much sense... because it's not really background rendering if you can't use FCPX while rendering.

If I understand you correctly FCPX manages render files worse than FCP 7. If you add an effect it trashes all previously rendered frames? Not just the changes? That could be disheartening.

 

[Andrae Palmer]

If I understand you correctly FCPX manages render files worse than FCP 7. If you add an effect it trashes all previously rendered frames? Not just the changes? That could be disheartening.

Yes... that's exactly what it's doing. In FCP7 you render in the foreground and it's a complete render out to a clip file. You then decide to change your mind and it keeps your old rendered files and then renders out new files. In FCPX it stops in the middle of the process and then restarts. It looks like it's rendering out file frames to a few cryptic folders... I guess it deletes those file frames and starts over again. It's doing all this automatically and stopping and starting all on its own... it has no way to read your mind to see what your intent is... so it just starts rendering any changes.

 

[Chris Kenny]

LCD panels are not inherently locked to 60hz, to the best of my own knowledge and experience, and I've yet to see evidence from you that they are.

LCD panels are not inherently locked to 60 Hz. That it, it's not a fundamental limitation of LCD technology. But it is the only refresh rate mainstream desktop displays support. Hilariously, this is somewhat hard to demonstrate, because there's so little variation that this is rarely broken out on spec sheets, but I recommend you open the display settings on the next dozen computers you run across, and see what refresh rates are selectable. Unless those machines are hooked up to specialty monitors like the Dreamcolor, or to TVs or video projectors, 60 Hz is generally going to be the only option you'll see.

Albeit he is defending his position... but statements like this don't help. You are telling me you don't see anything unique in a broadcast monitor vs computer lcd monitor? Well broadcast monitors are unique simple because they have more input/outputs and have builtin color profiles. Take mine for example... it's 10 bit, DCI-P3, REC709, 3Gb/sec single link HD-SDI, waveform and a bunch of other scopes, ac or dc operation, 64x64x64 Matrix 3D LUT color management. Those are just a few of the features... now that's pretty damn unique. Unless you can verify the Colorsync/colorimeter workflow being good enough... then you can't make a statement that there is nothing unique in a broadcast monitor.

Just to clarify here, it's not my position that there's literally no difference between a broadcast monitor and modern computer display. That would be silly. Rather, my point is that a lot of people seem to believe there's something fundamentally different about broadcast monitors that enables them to display accurate Rec. 709 color, whereas computer monitors can never do this. This is not actually the case. Broadcast monitors (at least until you get into really expensive things like Sony's new OLED broadcast displays) aren't using fundamentally different and superior display technologies. Rec. 709 is not even a very big color space by modern standards. Displaying accurate Rec. 709 color is just a matter of doing the right sort of image processing, and any image processing a broadcast monitor does with onboard electronics can theoretically be replicated by hardware/software on a computer, these days generally in real-time.

Honestly, this argument is just silly. By this logic, you could argue for grading on a 6-bit monitor. Plenty of people are watching YouTube on laptop.

If you're primarily working on web content it's probably not an especially crazy idea to check it on a 6-bit monitor at some point.

But to argue that a cinematographer should not care about the very real differences between 8 and 10-bit color because some peop,e can't see them is akin to arguing that a painter shouldn't paint in oils because the full effect won't be seen in a print. That dog just won't hunt.

Err... I'm talking about post, not acquisition. Acquiring a high bit-depth image is useful regardless of deliverable format, because it lets you push things around more. And processing at a high bit depth is useful, for similar reasons. I just think some folks are more concerned with the monitoring issue than the technical realities suggest is sensible. Is it better to monitor at 10 bits? Sure, in general. Will anyone be able to tell from the finished product if you monitored at 8 bits? Realistically, no.

 

[Jonathan LeDuc]

Yes... that's exactly what it's doing. In FCP7 you render in the foreground and it's a complete render out to a clip file. You then decide to change your mind and it keeps your old rendered files and then renders out new files. In FCPX it stops in the middle of the process and then restarts. It looks like it's rendering out file frames to a few cryptic folders... I guess it deletes those file frames and starts over again. It's doing all this automatically and stopping and starting all on its own... it has no way to read your mind to see what your intent is... so it just starts rendering any changes.

One aspect I've found frustrating with FCPX is that without the ability to set scratch disks, it's near impossible to spread out the hard drive thrashing. As a test project I tried to recreate a project I had already finished, one utilizing 4 separate cameras. Leaving aside the lack of multicam support, I figured it would be a good project to test the basics of the program.

The 13 different clips from the 4 different cameras (which had already been transcoded to prores) all happened to reside on one hard drive (which despite not being the ideal proved to work just fine in earlier versions of FCP as well as Premiere). I had set FCPX to not move the files, nor to transcode them, which I assume meant it wouldn't have to do any rendering. Instead, upon ingest the system becomes bogged down as it tries to render 13 files at once. I have no idea what it's actually doing with these files, it doesn't tell me. There's so much overhead going on during "background rendering" that the system ends up being slow enough that it's not really worth editing on. The hard drive ends up thrashing so much trying to work on so many files concurrently that I have to manually go in and pause the renders. Mind you, I've actually TURNED OFF background rendering, but it seems to make no difference.

The synchronize clips feature seems like a great feature, except it randomly doesn't work on certain clips, and seems to take forever compared to Pluraleyes.

The stinger came when a few days after working with all this I got yellow exclamation marks and red screens on all my footage, as if the files had moved, which they hadn't. But I have no way to reconnect those files, because according to everything I read, clips don't get disconnected in FCPX.

 

[Hrvoje Simic]

The discussion with opposing views often tends to get more and more detailed, leading to discussing things looked under the microscope.
While that does carry the potential to add beneficial information to a discussion, often the focus gets lost in the abundance of details.

Sometimes things like dissecting and analyzing "biochemical compounds and nutritive elements for soil contained within a fertilizer" need zooming out.

Using a wide shot of the scene discussed, many highly detailed analysis become redundant,
failing to justify a steaming pile of sh*t on a breakfast table.