BBC approves Canon cameras for HD delivery 20/01/2011
A little late here with this one but always good to know and keeping up with some of the tests I've been doing with cameras and Avids MC5 software... "Canon’s XF305 and XF300 HD camcorders have been added to the BBC’s list of approved HD cameras, allowing them to be used to produce shows for the broadcaster’s HD channels" Get the full story at Broadcast 1 Comment Happy New Year for 2011. 04/01/2011
With an eye to the future I thought I’d just put my bit into the pot for what looks like a very challenging year ahead. With the current trend for high quality programmes in HD and in some cases 3D and the ever diminishing funding streams for video production it is time for companies to look to what they can save in a production and look for cost effective innovative production workflows that help to minimise both time and effort. This was the mantra from last year and it is ever more so important now. That said, its time like this that the strong come to the front of the pack and strong doesn’t always means deep pockets, but cleasr ways of thinking and clear ways of auctioning those thoughts. OSX – What’s in a name? 30/11/2010
For those of you out there who get confused about OSX and what the Leopard and Tiger reference means (I know I do sometimes)here’s a simple outline lifted from Wiki. OSX Beta: Kodiak - Code name used by apple only OSX 10.0: Cheetah OSX 10.1: Puma OSX 10.2: Jaguar - The first named release of OSX OSX 10.3: Panther OSX 10.4: Tiger OSX 10.5: Leopard OSX 10.6: Snow Leopard OSX 10.7: Lion - Not released as of yet ;) Want more info see… http://en.wikipedia.org/wiki/Mac_OS_X IBC 2010 - How fast is your workflow? 16/11/2010
We were lucky enough to be asked to take part in an event at IBC2010 which wanted to help define what workflow is for the Post community and whats been already carried out 'at the coal face'. Sadly we were not able to attend the show owing to prior commitments but we were able to still get our presentation over to Informed Sauce and they 'electronically' placed us into the event. Below is Chapter 1 of the event which makes for great listening.... but then we are a little biased. Avid has produced its shared storage solution for well over a decade which has seen it established as possibly the worlds most popular NLE shared storage solution. With Avid’s latest Unity (version 5) release saw a big change on a number of fronts but 2 of the largest changes were the physical components that made up a unity and more3 importantly the location of the systems metadata. Pre v 5 Unity Unity hardware used to be made up of 3 key components 1 - Unity file manager (Intel 2u server - version specific) This handles requests from clients and maintains and tracks the Unity files systems metadata in RAM. This is the heart of the system and acts like a librarian, directing workstations to the appropriate drives to find media. 2 - Unity Fibre channel switch (Vilex or Qlogic) This is the interconnect between Server, storage and clients operating at varying speeds depending upon the age of the system (1Gb, 2Gb and 4Gb Fibre Channel) 3 - Unity storage (Avid bandaged Fibre attached JBODs) This is the physical storage that holds both media AND 3 working copies of the Unity systems metadata (backup up every 20 seconds) These early Unity systems run with drive block sizes or either 128kB or 256kB, depending upon the version of Unity software they’re running. Ethernet connectivity is only available on early Unity systems via the use of Port Servers (separate Intel servers that ‘bridged’ between Ethernet clients and the Fibre channel storage.)  Figure 1: Original Unity 1.0 with 1Gb Fibre switch and 90GB JBOD Version 5 Unity Version 5 saw a move away from the previous traditional Unity model to something that resembled its baby brother, Unity Lanshare EX. Gone is the separate File Manager server (so losing any fail over possibility) and in is the Avid Media Engine, this chassis now contains 16 media drives as well as the file manager software and is known as an Avid Media Engine. As well as being able to have fibre clients attached it also used the Lanshares model of supporting Ethernet and Fibre clients from the same system without the use of additional servers offering a total of 46 users (26 Fibre and 20 Ether). Version 5 also saw the block size increase from 256KB to 1MB! While this meant that the system could now handle HD media (especially single large files greater than 2GB i.e. MXF media) for a much reduced metadata count. However this does mean that small files (Project information for example) does make for rather inefficient use of the drive space. For example a 329KB folder or audio render must sit inside a 1MB block meaning that over 600KB of space on this particular block is lost. Which is why shared projects running from v5 Unity may not always be prudent. A Unity system is still made up 3 components but this has changed too... 1. Unity Media Engine As in previous releases the Media Engine still fulfils the role of the previous File Manager and handles requests from clients and maintains and tracks the Unity file systems metadata, held in RAM. But just like Lanshare, the system also houses 16 media drives. However, the Media Engine is also the sole location of the Unitys metadata, held on the Engines mirrored D partition. 2. Unity Fibre channel switch (Qlogic only) This is the interconnect between Server, storage and clients and operates at 4Gbs over Fibre Channel and supports either a single 10port Qlogic switch or up to 2 cascaded 16 port Qlogic switches 3. Unity storage (Avid Fibre attached JBODs) This is the physical storage that holds ONLY media, Unity metadata is now held entirely by the Media Engine.  Figure 2 Unity5 metadata location on MediaEngine Avid and the use of Anti Virus Software 25/10/2010
After speaking with several customers who have been riddled with viruses owing to the fact that they didn't bother to install any AV software as they thought that Avid wouldn't support it! So heres a little note about the needs for AV. First off Avid DO recommend that people use Anti Virus software and this information is found at the Avid Knowledge Base in the document named Avid Security Guide lines, which at the time of writing is found at http://tiny.cc/9lwtj This document has a clearly marked section on Anti Virus and reads... Best Practices 1. Install Anti-virus Software Using anti-virus software to protect your site and to thwart potential viruses is extremely important. Avid recognizes this and has qualified the anti-virus solutions listed below. However, please be aware that even with anti-virus software installed, you may still be susceptible to viruses. It is important to keep up to date with the latest virus definitions. We recommend that you have a properly trained IT administrator install and configure the Anti-virus software, so that you do not have performance problems. Avid Supports the following antivirus solutions Symantec Endpoint Antivirus Corporate Edition, v. 11 Symantec (Norton) Antivirus Corporate Edition, v. 9.0 and v. 10.0.1.1007 and higher NOTE: Scheduling updates during off-hours is advisable. Critical operations could be interrupted if an Automatic update were to occur (e.g.- digitize, digital cut, send to playback). Also, you can consult with an Avid Certified Support Representative (ACSR) for assistance. See the “Suggestions for Setup and Configuration of Anti-Virus Software” in Appendix 1 and “Information about Viruses in Appendix 4 for more information. Looking over the Avid Community web sites there is also a strong community of users who have experimented with various free antivirus software such as AVG Free or Microsoft's Free AV software, all with varying results and recommendations. This is a great way of investigating what works for some and not for others. Remember that with shared storage becoming common place in post houses the need for AV has an even stronger I can only recommend that you use common sense and ensure that your systems are protected at least on the most fundamental level! Don't wait till you are infected before you investigate the need for AV!! Flip minoHD camera tests with Avid MC 5.0 18/10/2010
With an almost saturated market of file based cameras, we here at CauseandFX have started to think and worry about the about the impact of domestic cameras on the Post Production workflow and the effects of the ‘lower end’ of the camera spectrum pushing into the professional arena. We've carried out some simple tests on the ever popular Flip minoHD in conjunction with Avid MC 5.0.To read more, please download the report in pdf form below. Thanks to Brian for the loan of the camera 
Compression or no compression or do I care? 05/10/2010
In September Andrew Brearley from MediaSmiths posted an interesting blog article (http://tiny.cc/ike3gqqq1) about the woes of compression within a Post Production workflow. And this led me to think long and hard about the valid case he put forward. But what, in the practical world, does that mean to a post house? Source Compression Tape has been with us for many years, and, for almost all of its history, compression has closely followed it. Most noticeably, compression fell into the two camps of Digi Beta with its DCT encoding (2:1 compressed - even though this was treated by the production as uncompressed!), and (a firm favourite) DV 4:1:1 or 4:2:0 (5:1 compressed – remember the arguments we had with this format by broadcasters?). Unless you were dealing with the likes of D1 material, then compression was an everyday feature of editing pictures, be it in a linear or non-linear sense. When NLE systems became capable of capturing images suitable for transmission (AVR75 anyone?), compression had to be used in order to allow the locally-attached disks to handle the data-rates. As time has progressed, uncompressed SD streams from local drives have become the norm, as indeed has multi-stream SD playback from centralised storage (SAN solutions), a point we will come back to later. Timed almost to perfection, not only did the production industry leap into HD images using tape formats, HDCam or HDCam SR 4:4:4 for example, but these vastly detailed images fuelled the need for source compression to reduce the data-rate overheads while maintaining picture quality, which in turn led to file-based cameras and acquisition codecs. With the current migration from tape to file-based camera formats, it is impossible to escape any need for post houses to pay close attention to the size of files the compression creates, as well as how much the codec compresses the image. Video compression codecs offer varying degrees of compression, both spatial and spectral, but, broadly speaking, they fall into either IFrame or LongGOP compression types. IFrame is particularly useful for editing, as each frame is uniquely described (though each frame also has a heavy storage footprint), whereas LongGOP can be much more problematic to edit with. A majority of frames need to be calculated from a ‘full’ IFrame image located some frames away on a system’s timeline from the viewing frame in question. It’s also fair to say that you need to understand which specific file you are dealing with, as its very acquisition format may well dictate if material can be used in the production of true HD images suitable for transmission. 35Mb HD images, for example, are not accepted by the likes of Sky and the BBC. Sadly, in the space where most Post Houses operate, source compression is an evil you need to come to terms with, as it’s firmly here to stay, with the likes of Super Hi-Vision (SH-V) looming on the horizon (some distance off I’m glad to say). Already being investigated by the BBC and NHK, this format is rated at 4320p, and has 16 times the resolution of HD 1080i transmissions (7680 x 4320) at 60 frames per second (fps). SH-V also offers 22.2 channels of audio. The data-rates needed, by today’s standards, are staggering, as a single stream requires a storage system with an 8TB uncompressed disk array and a 24Gb/s transfer rate! And the compression used here? ‘Dirac’, a video compression system devised by the BBC, which is based on wavelets and differs from MPEG in that it does not break an image into blocks or compress these blocks for the purpose of transmission. Instead, according to NHK researcher Yoshiaki Shishikui, it delivers images by means of a series of approximations of increasing resolution. Post Compression and Compression Types Once we understand that tape is fast becoming a breed of the past we need to see how this affects the equipment and infrastructure a facility will need to survive in the not-too-distant future. Your facility will need to ensure that its workstations and edit suites are powerful enough to handle the decompression of the acquisition formats. For example, I have found that an IFrame-based codec such as Avid’s DNX120 is light on the CPU for playback, placing only a 12-15% load on a dual core xw4600 we have here in the office, However, an H.264-compressed image from a Canon D5 MkII camera was taking over 80% of the CPU’s effort to play a single stream back! Some of the old workstations at a post house will simply have to go in an ever CPU-hungry environment! Sadly, the option for most people of preserving the quality of an image and converting it into uncompressed IFrame edit-friendly media is not an option, be this because of the sheer volume of media that would have to be ‘transcoded / transwrapped’, or the time needed to carry out this operation. Not to mention the storage needed to receive the new media that would be created. As much as an offline / online process has been thought of as dying out, the actual volume of material that can now being created for productions using low-cost cameras means that this practice is still very much in place, which in turn means that further compression for the offline material is needed. Maybe automated proxy creations, as suggested by Andrew Brearley (which means perhaps Final Cut server now does have its place in the smaller production community?), for importing material and ‘transcoding’ to an agreed resolution for the offline? In either case, further time is needed to facilitate this ‘conversion’ operation, which at one time was handled during the ingest process from tape, but now needs to be handled somewhere else. NLE Storage HD, by its very nature, means that the images that are being dealt with are on average 4 times the size of SD images. Therefore, in an uncompressed world, using the rule of thumb, HD images occupy 4 times the space SD images occupy, unless we’re talking about dual-link HD where the figure is even greater still. This is merely the physical storage requirement, and does not take into account the bandwidth requirements on the storage being used – be this local disks or network-shared storage. This is where source compression actually helps a post house, as its data-rate is always much lighter than that of its ‘uncompressed’ ideal, which in turn allows it to be delivered over modest 1Gb or 10Gb Ethernet networks rather than bespoke high speed Fibre or Infiniband Networks. This leads on to the need to store rushes in a secure (RAID) location on a network-available device, which can be as simple as a cost-effective NAS device. This will allow for access to material should it need to be revisited for conforming needs, as well as providing a secure backup location. Some productions may be small enough to have the material attached directly to the NLE workstation or copied to high performance disk sets, if needed. Or, in the case of productions that need shared access to material, it can also be copied to workspaces on high-performance, NLE-ready SANs. For most post houses running various suites, all forms of storage would need to be addressed to ensure that the most effective workflow can be established, and while the ideal would be to have an infinite amount of storage on the fastest network available this simply is not achievable. Therefore stepping stones and tiered storage is currently the most cost-effective solution for the masses.  Summary for the real world Post. File based workflows in Post bring with them… Compression: You can not get away from it, whether you want to or not (for most of us mere mortals that is). Be careful and mindful what you do with your rushes if you want to maintain your final finished picture quality. Storage: This is best broken down into further subsections: 1. Rushes: Most rushes will be received on ‘commodity’ storage i.e. Firewire or USB drives. These will probably be moved to more secure ‘RAID’ storage which will equally have to be cheap commodity network available storage. 2. Editing: This could be local storage for high image resolutions such as DualLink HD or even network storage for ‘compressed’ material. Be mindful of your total capacity and the performance your storage, as this is directly linked to your ability to handle some resolutions. Workstations: When using some native source compression codes, there can be a large overhead to the base workstations being used to carry out the edit. Ensure your CPU is up to it and running the latest version of NLE software to allow you to access the source footage. Above all, TEST, TEST, TEST! Ask for some sample footage from the camera being used and actually push it through your simulated workflow, as the devil is always in the detail! Is Andrew asking too much of the current model for independent post production facilities? Well, perhaps not. The need to re-tool is vital in moving forward within the ever-evolving production market,. Failure to do so simply means the death of a company. With prices for software (NLE and storage) and high-performance, generic, IT-based tools dropping all the time, the argument is more that the post houses should understand what is available to them as technologies, and then use them in an effective way. Innovation is always key to any market place, and, in this case, the innovation needs to be provided from within the post houses, in terms of how they can facilitate the current needs of their clients. Avid HPxw8400 and network playback 05/10/2010
Just some background info and the cure for stammering playback on Avids running on the HPXW8400 chassis. Customer complained of stammering audio and video when playing back from the Editshare system. This was only noticed on the HP XW8400 with DNA hardware attached but not on the newly installed Z800 or the upgraded Mac (also with SDI Mojo attached) All systems were running 4.0.5.5 with XP32 SP3 and 4GB Ram. When playing back either a sequence or a master clip the material would either stammer picture or audio at any given point. On further investigation the console was showing the following errors Error/Status [0x80001013]Error/Status Reporting: Your hardware has detected a serious error. Please quit the application and power cycle the hardware. [Error: DMPort Error] Error/Status [0x80001013]Error/Status Reporting: Hardware detected a host vsync error On the HP XW8400 systems a BOS (Blue Screen of Death) crash caused a reboot and then the following error was seen during the BIOS boot stage. 922 – FATAL ERROR on DIMM Motherboard Slot XMM5 M9 Error by M4Err 925 – Non Fatal uncorrectable ESI error on PCI-X 133 Slot 5 Looking at the Configuration Guideline for the 8400 and the fact that the error reported an issue with SLOT 5 it was apparent that the customer was using the Pyro card that had been placed into SLOT5 but is NOT supported for the connection of DNA device. Once the DNA devices were attached to the Local onboard Firewire port then all came good. Errors went from the Console and the stammering stopped. JVC GYHM100E tests with Avid MC5.0 22/09/2010
With an almost saturated market of file based cameras, we here at CauseandFX have started to think and worry about the about the impact of domestic cameras on the Post Production workflow and the effects of the ‘lower end’ of the camera spectrum pushing into the professional arena. We have become fascinated with the uptake of D SLR cameras and some of the smaller file based domestic cameras that can be found in the likes of Argos and Tescos! With this in mind we decided to try and test some camera of varying ‘breed’ ... (more) To read more, please download the pdf below
| CauseandFX ArchivesFebruary 2012 | ||||
RSS Feed