Official word on 10bit or 8Bit in Edius?

[Bassman]

Hello,

As you might know, Panasonic has released an under $10,000 HD camera which uses their AVC-intra codec.

This is a 10 bit codec.

I was wondering if somebody from GV could tell us how Edius will interface with a 10 bit codec?

Are any filters or effects in 10 bit?

Is a 10 bit codec extra information that will not be used by Edius?

Your information will help with camera purchase decisions.

Thanks

[tingsern]

I just downloaded the AVC-I samples (from DVINFO.NET). Played that 4 video files (1920 x 1080) from HVX-300 ... on EDIUS 5.01 - CPU was only 30% busy ... from timeline - no shuttering ... very smooth. Although EDIUS today is 8 bits only - it can definitely handle AVC-I files. So much better than AVCHD - which pushes my CPU to 95% - and shutters very badly when played from timeline.

EDIUS plays 10 bits 4.2.2 AVC-I ... no problems. But, the moment you edit the video or save it in Canopus HQ, it goes to 8 bits.

[pjsssss]

Edius is all 8 bit on any export at the moment. Though I would suspect that would change in the future.

[Bassman]

There seems to be the belief on the DVXuser board from a Panasonic rep that Edius has 10 bit effects processing and that only the export is 8 bit.

Any knowledge of that?

The 10 bit footage would be a help if the processing was 10 bit as well, but I would have a different opinion if the processing was 8 bit.

Thanks

[redgum]

10 bit footage will be seen as 8 bit in Edius anyway. It just holds up better in effects or rendering. When Edius (or any other 8 bit NLE) becomes 10 bit then you will notice the difference.

[Jerry]

Edius is all 8 bit on any export at the moment. Though I would suspect that would change in the future.

I guess that depends on the sale and subsequent buyer's mission for Edius.
As far as I am concerned, it couldn't happen fast enough.

[7hbg]

In my opinion it is not that long from now (in worst case 2 years...? Sooner, if Canopus is already working on it).

The reason why we are stacked at 8 bits has to do with two issues:

1. Real time processing (set at Canopus as a mandatory feature).
2. 32bit CPU (available hardware).

The biggest selling point that grabbed me and many others is the real time editing. In order to do that one can’t be bothered processing anything natively (too many variations), it has to be processed the same way no matter the source. So 8bit YUV+A @ 4:2:2 is how Edius is processing everything. This format is perfect for a 32bit CPU, because it can fetch or store one pixel in just one instruction (very important for real time). It will take a 64bit CPU to do the same for anything more than 8bits, up to 16bits per channel. So I don’t see it happening in version 5, maybe in 6, but (I hope) for sure in version 7. It will require complete rewrite. Nothing like we have seen this far. Honestly, I see traces of previous versions (especially bugs from previous versions) in each version released this far (I started with version 2.0), so they have not been rewritten – just copied, compiled with few additions and released as new version.
The key is 64bit CPU. When 64bit OS and software becomes the norm, I expect us to leave the 8bits per channel and maybe (hoping big here) process the data in us much as 16bits per channel but store it as 8, 10 or 12bits. It requires less CPU processing to work with 16bits then it is to work with 10 or 12bits. The one other cost associated with that is the RAM. It will take twice us much RAM to store the same information at 16bits. But as we all know, Edius is very good at managing RAM so this may never be an issue.

Hoping Big!

[Crespel]

It will require complete rewrite.

This is wrong !
It requires only a set up of a 64Bit development Environment(which they already have - because they have 64Bit drivers)
and it requires a 64Bit Compiler with which the 32bit Source Code is compiled to 64Bit Object Code.
That's it - not more.
But I suspect the programmers would like to hear that people see it as a big problem.

[7hbg]

...This is wrong !
It requires only a set up of a 64Bit development Environment
...
That's it - not more.
...

If all you do is compile the current source code into 64bit executable, you will still have only 8bits per channel processing. If you don’t change anything, a 64bit compiler will probably generate exactly same code as a 32bit compiler. It’s not the compiler but the code that determines how to work with the data, therefore the need for the re-write.

[maxmi]

Grass valley... where is ? tell us something.....