Comments

Spot|DSE wrote on 5/23/2005, 11:06 AM
For some reason, Vegas defaults to the Best/largest files setting rather than the Medium that Cineform uses. Therefore the Vegas files are larger, and potentially slower than the Cineform-generated files.
David Newman wrote on 5/28/2005, 10:49 AM
Vegas actually defaults to the Medium quality setting but it is not using the temporal compression that is the default though the rest of the CineForm product line. So the files are bigger and only a little slower as Vegas isn't using any temporal compression. The quality is the same between the two modes.

David Newman
CTO, CineForm
Spot|DSE wrote on 5/28/2005, 11:32 AM
Thanks for the clarification, David. This is different info than I was given by one of the Sony team, and I've incorrectly posted this info a couple times.
David Newman wrote on 5/28/2005, 11:54 AM
It understandable a little bit confusing. We have two versions of the encoder, a Video for Window (VfW) engine than Vegas uses and a DirectShow Encoder that Connect HD uses. The VfW codec doesn't have all the features as DirectShow and the temporal compression support was one of those missing items. However with the Vegas team we did add items to the VfW engine in 6.0, like the support for all the color space combinations 601/709/cgRGB/vsRGB. So the VfW engine is getting pretty close to the DirectShow encoder in term of features.
Wolfgang S. wrote on 5/29/2005, 7:59 AM
What about file size? If I render to an Pal Intermediate, the cineform file creates by Vegas-6 and the VfW codec huge files, that would require 85 Mbps for real time preview.

Given the fact, that even my Raid-5 SATA system delivers 65 Mbps only, this seems to be a major drawback. Compared with the desired 25 fps (PAL), my system displays only half of that, using the Cineform intermediates.

Frankly spoken, to my opinion that makes the Cineform intermediates very questionable - compared with a workflow based with Gearshift, where you work with proxy files (DV-avi, mjpeg-avi), and switch back to original m2t material for the final rendering process.

Desktop: PC AMD 3960X, 24x3,8 Mhz * RTX 3080 Ti (12 GB)* Blackmagic Extreme 4K 12G * QNAP Max8 10 Gb Lan * Resolve Studio 18 * Edius X* Blackmagic Pocket 6K/6K Pro, EVA1, FS7

Laptop: ProArt Studiobook 16 OLED * internal HDR preview * i9 12900H with i-GPU Iris XE * 32 GB Ram) * Geforce RTX 3070 TI 8GB * internal HDR preview on the laptop monitor * Blackmagic Ultrastudio 4K mini

HDR monitor: ProArt Monitor PA32 UCG-K 1600 nits, Atomos Sumo

Others: Edius NX (Canopus NX)-card in an old XP-System. Edius 4.6 and other systems

David Newman wrote on 5/29/2005, 9:39 AM
Wolfgang,

something is wrong with you RAID-5 if is can only do 65Mbps (M bits per second.) -- I think you mean 65MBytes per second -- that is moderate RAID speed. CineForm Intermediate files only require between 10-12 MBytes per second (for 1080i.) So you RAID should be able to read 5 streams in real-time -- not that you CPU(s) could decode all of them (modern systems can decode 2-4 depending on configuration.) The low-res proxy based work-flow you describe is good for low end systems but it does add many restrictions. Proxies can't be used for effect creation and are often poor for color correction. Proxies are an off-line work-flow, whereas CineForm Intermediate is an on-line work-flow -- it is a matter of choice.

David Newman
CTO, CineForm
Wolfgang S. wrote on 5/29/2005, 1:27 PM
No, I think nothing is wrong with the raid-5 - there was an calculation error only. According to the benchmark by Dr. Harware 2005, it has an average read-throughput of 66482 KB/s, what are 66482*8/1024 = 519 Megabit pro second (I missed the mulitplication by 8).

Ok, but the problem ist following:
I have here an m2t file, size 341.062.644 byte, and a playback length of 103,838 seconds.

If I render that to HDV 1080-50i Intermediate - an template that uses the Cineform Codec 1.2 of Vegas-6, I end up with a file size of 1.128.991.744 bytes (1.05 GB for 104 seconds!). If I calulate the required transfer rate, I end up with 83 Mbps, or 10.4 megabyte per second. So, very similar to the number you mention.

So, it should be played back with 25 fps at PAL - with project properties set to HDV 1080-50i. But that is true for the preview quality "draft (auto)", "draft (full)" and "preview (Auto)" only. With a higher quality preview that goes down to something about 10 fps "Best (Auto)", what is really poor.

Ok, for m2t material I have a preview of 10 or 11 fps in "draft (auto") only.

So, if the raid-system is not the bottleneck at all, it seems to be the processor speed that tends to become the limitation here (3.2 Ghz P4, 1 GB RAM, Auss P4P800-E deluxe board).

Right, for color correction I see the potential thread that the proxys does not show the correct colors. Funny enough, mjpeg-avi by PIC seems to show the correct color, as far as I have seen up to now. And these proxys can be much smaller in file size - and have better playback properties too.

But conclusion for me: for a lower preview quality Cineform seems to be fine, as long as you use the lower preview quality. But proxys will make sense on many systems today, too.

Desktop: PC AMD 3960X, 24x3,8 Mhz * RTX 3080 Ti (12 GB)* Blackmagic Extreme 4K 12G * QNAP Max8 10 Gb Lan * Resolve Studio 18 * Edius X* Blackmagic Pocket 6K/6K Pro, EVA1, FS7

Laptop: ProArt Studiobook 16 OLED * internal HDR preview * i9 12900H with i-GPU Iris XE * 32 GB Ram) * Geforce RTX 3070 TI 8GB * internal HDR preview on the laptop monitor * Blackmagic Ultrastudio 4K mini

HDR monitor: ProArt Monitor PA32 UCG-K 1600 nits, Atomos Sumo

Others: Edius NX (Canopus NX)-card in an old XP-System. Edius 4.6 and other systems