Lars,

"A) Can you fix the color, chroma so that the magenta cast goes away? A1) When?"

I mentioned earlier this would be in about a week.

"B) Can you fix your codec so it plays back as smooth as MXF? B1) If so - when?"

On a modern PC we are already as smooth running a full frame rate. For an older PC the half preview mode the CineForm codec a significantly faster (using less CPU than other codecs.) This has always been the nature of a wavelet codec, we are pretty fast at full resolution, but always the fastest at half res. -- the multiple resolution nature of wavelets have performance advantages over DCT codec. The confusion today is the half preview is inefficient for VfW in Vegas 9.0, so are all missing this benefit. We expect this will be addressed by Sony with 9.0a. I've been testing the pending Sony change and it works.

David Newman
CTO, CineForm

David, like another poster said above, most of this thread has gone over my head, but I've been following it just the same.

However, I do want to thank you for taking the time and communicating with the members of this forum. Would that ALL software producers behaved in this manner. This speaks volumes for you, personally, and CineForm in general.

""B) Can you fix your codec so it plays back as smooth as MXF? B1) If so - when?"

On a modern PC we are already as smooth running a full frame rate. For an older PC the half preview mode the CineForm codec a significantly faster (using less CPU than other codecs.) This has always been the nature of a wavelet codec, we are pretty fast at full resolution, but always the fastest at half res. -- the multiple resolution nature of wavelets have performance advantages over DCT codec. The confusion today is the half preview is inefficient for VfW in Vegas 9.0, so are all missing this benefit. We expect this will be addressed by Sony with 9.0a. I've been testing the pending Sony change and it works.

David Newman
CTO, CineForm"

------------------------------------------------------


David, compared to MXF how well will Cineform play? I assumed you have been running these side by side by now...

The reason I ask is this: If MXF and Cineform have a visual perceived quality for about for about 1-3 generations, then the codec that plays back "mechanically" - frame wise - is the codec that is far more attractive to use. For instance: If the image quality is similar and MXF will allow me to run dissolves in real time and Cineform stutrters during dissolves, then the choice is very easy. MXF.

***********So, again, compared to MXF how well will Cineform play? If MXF will allow me to run a dissolve with full frame rate maintained will Cineform do that too? Today it doesn't.*********

Thanks in advance fo your reply
Lars


----------------------------------------------

I guess this could be defined somehow couldn't it? Lets say you had a slider where you fine tuned the upper max limit MBps that you hard drive could deliver, and this was set just a little bit above what MXF required to play two stream continuosly, would then Cineform be able to play the two streams with full frame rate like MXF? This is for most users the most importat question (if the codecs look about the same 1-3 gen).

Bump...

Any word yet from Cineform on getting 64bit Neo Scene working in Vegas 9 64 bit

The added amount of time needed to convert to MXF isn't cost or time efficient for me so Cineform NEO is the ticket for my work. I can work around the Vegas 9 issues, but have elected to work in Vegas Pro 8 since Cineform Neo Scene is optimized for VP8 at the present time.

Cliff Etzel
Videographer : Producer : Web Designer
bluprojekt

This is a very interesting thread. I do use and own Cineform (and have paid many for upgrades as well)

But when I see statements like...

"The only way I could currently run a valid comparison between MXF 422 in V9 and the Cineform codec would be using our Prospect 4K codec. That of course doesn't work in Vegas so I'd have to do the tests using After Effects. Whatever the results it's hardly going to be fair comparing a $1,500 codec running in a $1,000 dedicated compositing application against something that's thrown in the box in a $500 NLE."


...it just smacks of desperation.

And that kind of talk deserves a reply.

And nevermind the rhetorical 'dedicated' bit.


Forget list price on that product - nobody ever pays list and rarely even pays anything more than upgrade price. Even more so, people will buy a suite if contains at least of couple or more of major applications that are of great use.

Let's see, CS4 Master Suite $2499 list, $899 upgrade. Wow - here we get to choose whether our consumer is to be a fool at a 277% markup, or Adobe actually values its products so little at 36 cents on the dollar. You choose the sad story trhat makes you snicker the most. (Heck you can buy somebodies used copy for its upgradeable license for less than than markup and *still* save money.)

Since a fairer valuation of products is its upgrade price, and adobe primarily sells via 'Suites' we can take the suite upgrade price and divide it by the of *major* notable applications. An extremely overgenerous count of just four, (count 'em) four *major* applications in CS4 Master Suite, we take that $900 and divide it by four and get a 'dedicated' compositing app for (drum roll..) $225. That's right - and sooner or later you're going to have to assign some nominal value to the remaining apps in the suite and the story just goes south from there.


Looks to me that Adobe's got the 'cheaper' NLE (and a cheap 'composting' [sic] app too...)


The 'Suite' game is nothing more than the price markup version of three card monty. It's a 'cheap' way to stroke consumer egos and box in a market. Heck - Microsoft invented this game with MS Office. (But, their Silverlight and Expression products are a sorry acknowledgement that they were a day late and a dollar short and lost the media market).

I'll stick with my '$500' NLE....

"I'll stick with my '$500' NLE...."

And which one would that be?

I just applied your logic to Vegas. $200 for the actual upgrade which is for a suite of two applications so you're saying Vegas is a $100 NLE?

If that's the way you want to look at it then fine I guess.

I still fail to see the relevance to what was being said in the context it was being said and where's the desperation, I was replying to the suggestion that I should do my own tests and pointing out that the only tests I could run would be an unfair comparison.

In the end I did run tests, using the free Cineform codec that ships with Vegas and blow me down, it still beat the XDCAM 422 codec in my opinion. Even then I'd say it wasn't a fair fight, two different codecs designed for two different purposes being stressed in ways no one is ever going to use them.

Bob.

"two different codecs designed for two different purposes being stressed in ways no one is ever going to use them." Technically speaking Bob, one would question the usefulness of this data and drawing any conclusions from it for daily production use would be marginal at best.

There are many published books about testing criterion and protocols for hardware, less meaningful ones for software so it's a little craze. I'm a little concern about the shifting one pixel over and up during the generation testing of a 422 compression codec, ie, how many times "over" then back? I fairly sure that you understand 411, 422,420, vs 444 pixel sampling, so, why, the induced sampling failure(?) in a multi generation test against origin material? Are you pushing wavelet frame analysis (which is based on the complete field before compression)?

Both codecs are great Bob. And Cineform is a great codec. Let's see how their next update is doing. As soon as CIneform releases this next update I'll come back with a new test. And much different from the previous one. Looking forward to your comments of course. I'm going to stay silent on this issue for a few days...

Best,
Lars

Is there any compelling reason to consider the transcoding of HDV m2t files to high bit rate MXF format? I would really like to utilize 64 bit Vegas Pro 9, but I can't seem to determine whether the extra time needed to transcode footage from m2t to MXF is worth the extra time and effort.

Any comments on this question?

Cliff Etzel
Videographer : Producer : Web Designer
bluprojekt

I hope to be able to write a post in a few days with some intresting observations I have made. I'm just waiting to see if CineForm will release something new.

I'm also drawn towards 64 bit, it's smoother, more ram, faster etc. Clearly the way to go... I'm surprised that getting it together isn't going faster.

Lars

"I just applied your logic to Vegas. $200 for the actual upgrade which is for a suite of two applications so you're saying Vegas is a $100 NLE?"

No, you just applied *your" logic, not mine.

As I said, I was being *extremely* generous, which you some how missed, when I said 4 applications, but since your counting DVD Architect, well have to count Encore for Adobe - heck let's take it to conclusion and count all **16** CS4 applications.

Hmm - that thar Prospects a 56 dollar NLE.

BTW, the upgrade price for vegas is 240 - but halving it gives $120 - by your logic.

Since Vegas cost twice as much Prospect - is it not twice as good? And if I mention it's dedicated, thrice?

This whole thing is academic.

In short - the point being that everybody *already knows* that one really shouldn't infer specious arguments based on rhetorical statements - hence rhetorical arguments made are a nuisance because they are not based on fact.

It's infuruating and somebody might just take it (deservedly) to task.

'Nuff said.

Back to our regularly scheduled Cineform comparo.

"I'm a little concern about the shifting one pixel over and up during the generation testing of a 422 compression codec, ie, how many times "over" then back?"

In my 20 generation test I did not do that.

Bob.

Did my own "quick" compression tests using "invert" plugin.

1.) Took 30 second AVCHD source file with decent anount of motion.
2.) Encode it to XDCAM 422
3.) Drop in on top of the original track
4.) "invert" the original track so that it is a "polar oposite" of the new track on top.
5.) Mix the top track together with the bottom at exactly 50/50%

What pixals are left visable are literally the difference between the two tracks. What you see was NOT in the original source and could not be canceled out by the phase shift.

What happened? HDCAM 422 left a totatly smooth gray screen...no variation whatsoever in 1 generation

When I did this with Cineform codec on Vegas 8, I saw very, very ,VERY light mosquito noise on tiny areas of the image.

Yeah,...V8 cineform is an "old" codec today so I dont fault it at all,..it's still very good. But the XDCAM 422? Crap,..that puppy had no loss whatsoever that I could see...I even threw a heavy sharpener into the preview just to try to reveal anything,..it was rock solid. (on 1 generation from teh original)

XDCAM is pretty cool,...no doubt.

CT

Great paper on HDCAM HD. I met Hugo (the guy that wrote this for Sony) and lemme tell you,...he is the smartest compression theory guy I have ever heard. (totatly brilliant man...the folks at SCS know him and will agree)

http://pro.sony.com/bbsccms/assets/files/micro/xdcam/solutions/XDCAM_WhitePaper_F.pdf

@cliff_622,

I've been also testing this out, but I came at from a few different directions. First I tried Eugenia's original test with the open source, still image comparator, perceptualdiff. I got very small differences in pixels per generation, via this method, using XDCAM 422. It's obviously not possible to duplicate the full extent of her excellent work, since a) I used my own original video file, b) my PC is different than her test machine and c) I'm using Vegas Pro 9 (32 bit), not 8.

Second, I also re-rendered the various generation MXF files as uncompressed and used After Effects CS4 to create a composition that showed the difference in pixels as you difference masked the two files. This approach was more qualitative, but it gave me a good idea of how motion was affecting the generational changes. Unfortunately, AE will not read XDCAM 422 MXF files natively.

Your approach is also a good way of looking at the whole clip. How did you prevent the XDCAM 422 encoder from smart rendering during subsequent XDCAM 422 generations or did you just do one generation? I just added an FX to the timeline at each subsequent generation and had the FX settings at no effect levels. This stops Vegas from smart-rendering.

I think that someone made this point further up in the thread, but even though the XDCAM HD 422 codec is 32 bit, Vegas Pro 9 x64 still can use it via the surrogate approach that Vegas x64 uses with all the built-in 32 bit codecs.

"in my 20 generation test I did not do that." Sorry about that, I though you said that you did the shifting between different generations. I was wondering if you were indirectly trying to point out the different in advantage of wavelet compression and "other" codecs.

"Did my own "quick" compression tests using "invert" plugin."

I did that as well and well, didn't see anything happening at all using the XDCAM 422 codec.

So I tried a different approach.
I applied Vegas's CK FX to the original frame, set it up so I was seeing a lot of the original artifacts in my footage e.g. blocking on fine detail and noise in the green screen with the Show Mask Only tick box checked. I saved that as a presset and applied it to the next generation.

The results were different. The noise in the screen is seemingly going through some form of low pass filter and the blocking in the fine detail is shifted around.

I suspect part of the problem with using Invert and add is small offsets in the values are very hard to see visually, especially if they're only in one channel.

What would be interesting to test is the impact of Vegas's Y'CbCr <> RGB conversion just by itself over generations. This alone maybe impacting all our testing.

Bob.

Bob:
"What would be interesting to test is the impact of Vegas's Y'CbCr <> RGB conversion just by itself over generations. This alone maybe impacting all our testing."


Would Cineform and MXF react differently here?
Lars

"Would Cineform and MXF react differently here?"

Reading what Dan had to say Vegas requires the codecs to perform this function and that's where the problem that you've seen was coming from.
The concern I have with this is when we switch Vegas to 32bit mode what do the codecs do. Tests on some of them indicated that they still only pass 8bit values. On the other hand if the codecs were to pass their native Y'CbCr values and the NLE does any conversion it requires then it (the NLE) can decode to 8bit or 32bit as it needs.

Maybe you could try 16bit still images and see what what happens.

Bob.

I wish I'd read this thread before buying NeoScene for $129 two months ago. :)

I didn't even know XDCAM existed within Vegas!

I guess I can take solace that for my $129 I can use Cineform in Virtualdub, whereas XDCAM can only be used within Vegas.

Congrats Lars on pressing David Newman for concrete answers! It's nice to see that someone is holding Cineform accountable for their terrible support for Vegas 8.1 and Vegas 9.0. They should have been on top of this and already have 64 bit versions of their codec. Otherwise, why would I pay $129 for their product? (and that's the cheapest, most limited version!)

I have used and liked Cineform since it came with Vegas, but have been really disappointed with their support of Vegas recently.

Now I find out about XDCAM and it makes me question my purchase of NeoScene even more.

"How did you prevent the XDCAM 422 encoder from smart rendering during subsequent XDCAM 422 generations or did you just do one generation?"

Easy,...just toss in a font like a small #2 on the very corner of the screen for the new render. This will always force smart render to deactivate.

After you render, that that bad boy back into your timeline directly on top of the "inverted" original. Your number will jump WAY out of the prewiew because 100% of it will not be phased out. (because it doesnt exist at all in the inverted original)

Remember, this trick reveals any pixels that are different between the inverted original and the new generation.

I'm sure Cineform has done this in their own testings too. It's not the "be-all, end-all"...but it's one visual tool to reveal generation loss. (it's nice to see what parts of the scenes get hit the hardest and how)

To exagerate the problem, try this test by rendering out MPEG1 at a deliberatly low bit rate. You will see artifacts galore that look like the "emboss" plugin in Photoshop.

CT

Mathematically,...you can think of the cancelation this way.

100.00 (original video)
- 99.99 (new generation)
______
= .01 (residual pixels...what you are seeing leftover in your preview window)

As of June 12th there is a new version of NEO Scene (v1.32 Build 117)

Enhanced: Faster playback for 8-bit modes in many NLEs.
Enhanced: Multi-generation quality enhancement for Vegas

Running a new series of tests now CF vs MXF. Including the MBAN test. I'll return later today.
Lars