We like to test things here at FCP.co, so when we had the chance to test FCPX with files written from the newly updated software on EVS servers, we were there the moment the streams were set going. Unfortunately, it didn't go to plan.
EVS servers form the backbone of many sports and news broadcasts. Not bad for a machine that started off as a video RAM buffer for analysing golf swings!
Using EVS streams in FCPX has been a problem as the ProRes files created by the servers and the associated boxes connected to them were not fully up to Apple's specification. This meant that things like Quick Look didn't work, but the killer for us was the lack of timecode on the files.
EVS were aware of the problem and at IBC we saw a glimpse of EVS streams working with FCPX, with the correct timecode. They had re-written the way that the files get exported and guaranteed us that the files being streamed were perfect.
The problem with new software is that OB companies and broadcasters who have large installations of servers won't just upgrade their versions of EVS software overnight. So it's only now that we have been able to test the new streams (in record) with FCPX 10.1.4
They don't work.
Let us clarify that. The files the EVS writes show up in FCPX fine, you can see from the 'Media is Growing' metadata tag that FCPX recognises these files as growing. The audio is mapped as per EVS settings and to our great relief we have correct timecode! Even the Varid comes across.
So what is the problem? We return to the waveform redraws that cause Final Cut Pro X to slowdown. When the file is still in record, the refresh rate of the growing file is set to 10 seconds. This is something that is controlled by EVS and as we understand, cannot be changed without digging into some complex code.
The refresh every 10 seconds causes FCPX to try to not only redraw the audio waveforms, but also redraw the video filmstrip as well. This makes FCPX slowdown to a point where it is unusable. Take a look at the video below where you will see skimming across a growing clip in the browser. Every 10 seconds the machine beachballs when the file gets updated.
The constant refresh doesn't give FCPX a chance to analyse and redraw the waveforms. In fact, if you load a clip up in list view with the waveform visible, it will never finish drawing the waveforms until the file has stopped recording!
EVS has done what they promised and their servers are writing the correct files, but they will not be usable in FCPX until Apple find a way to stop the constant waveform updating. This goes for all segmented growing files, not just EVS.
So how can you access a growing file such as those used on the Tour de France? That workflow used files from Softron's MovieRecorder in classic mode. Very different as these files have their duration set on record and then the application writes the video and audio information into that file. FCPX doesn't see them as growing files.
Toggle MovieRecorder into segmented mode and we bet that the files recorded that way will have exactly the same problem in FCPX as the EVS streams. We won't even mention how range based keywords don't work with growing files either.
Bottom line is Apple need to address the way growing files are handled and that includes the waveform issue. EVS has kept their part of the bargain by writing the correct files, but until FCPX has incremental waveform and filmstrip icon generation, they are going to be unusable in X whilst still in record. Which is the whole reason why those files are used in the first place.