Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Cineform?

David,

I am with Joon. We are looking at at the following combos for some new workstations for Prospect, AE & Speedgrade XR using Cineform RAW on XP64 platform:

High - Quadro FX5500 1GB & Aja Xena 2K 10-bit PCIe
Middle - Quadro FX4600 768MB & Aja Xena-LH 10-bit PCI-x

Would it make more sense to get a single Quadro FX5500 SDI instead of the two cards?

Thanks.

Edgar
 
We get better on Mac with each release. Our Mac release about 3 weeks ago increased performance. We're now preparing for our next new release, probably Tuesday (plus or minus a day) this week that adds *many* new features on Mac including:

- many new Active Metadata features and control panels. This will finally exceed the features and performance we showed at NAB.
- Active Metadata added to CineForm 444 files
- second monitor support
- further performance increases

With new Active Metadata support in CineForm 444 you now have identical features as are in CineForm RAW where White Balance, Saturation Matrix, and 3D LUTs are carried as Active Metadata. With Active Metadata support in C444, all cameras - not just RAW - can benefit from this workflow.

Regarding performance, we'll want users to chime in also after the next release, especially those with Dual Quads. We have an older 2.66 GHz Dual Core 2 Duo Mac - we don't yet have a dual Quad (that will change in the near future). For external compression solutions (like CineForm) FCP is a MAJOR obstacle to performance because of the way it interfaces to external codecs. We continue to try to work around these oddities, and each release gets better.
 
Thanks David.. so I suppose my ultimate question is .

What's not possible still on osx with the next release.. say on Quad core

reason I ask we entirely mac based so would be buying the whole thing just for the codec.. If I understand your sales structure and you dont just sell the codec for osx to encode to.

S
 
HD-SDI monitoring will *probably* not work yet. We have added the pixel format necessary for supporting the Kona card, but we haven't yet spent any time testing it. But we'd like some feedback from those who have this configuration setup.

Also, we don't yet have the HD Link image processing and conversion utilities running natively on Mac. This is a scheduled task - we realize many want this - but it will be a few months yet. Until this is ported we will continue to provide both Mac and Windows S/Ns so you can run these utilities on Windows (or Parallels or Bootcamp).

The above comments apply to our upcoming release in 2-3 days. Flameop, give it a try when released and give us some feedback. It will operate fully in Trial mode for 15 days.
 
Brian, I was posting more information about the new Mac build in the Mac Workflow section of RedUser. For all Mac-interested people please take a look at my new post. You can download a Trial and also some CineForm MOV clips to test with.
 
Maybe one day. Currently we don't use or need GPU acceleration, we find that sending data from CPU to GPU and back again losses most of the benefits of the GPU. Most compression algorithms are not suitable for GPU acceleration and the entropy coding/decoding stages are much faster on the CPU. All our compression transforms, while suitable for GPU accleration, where designed for fast SSE2 (CPU SIMD) implementation, so again we don't need the GPU.
 
It would seem your doing well in terms of acceleration at this point with your threading working pretty well... I mean your stuff is getting really fast on multi core machines. Why not support the r3d files direct david, instead of transcoding into your format? I guess you will say something along the lines of your code is faster and more optimized..but still, once we hit the horsepower we need why not just natively support the r3d files and cut out all the huge render time to get from r3d to yours?
 
I could see you using the SDK to just "grab" data from the r3d files and then use it as you want inside your engine?
 
Not our business model. Think of all the camera format we support, not one do we need to support in it native format. The whole point of the CineForm workflow to avoid the myrid of input formats, and normize to one format that can hold all the source data. This make both product development and many elements of the post production faster.
 
Right David, that's the whole idea why we chose cineform for our intermediate codec. And the fact that it preserves raw all in one codec!

Thanks for the update! Was looking forward to this ever since I saw it demoed at NAB 08!

Cheers
 
What about cineform RAW david, will it decode the RED RAW into RGB and then re-encode into cineform RAW? or just transcode the REDRAW DIRECT in the native bayer black and white info into native RAW cineform? in other words will you loose info from the RED RAW and re-encode from RED RGB?
 
what about supporting the camera LOOK data? so the color comes across from the camera preset?
 
You must log in or register to reply here.
Back
Top