No announcement yet.

Official word on 10bit or 8Bit in Edius?

  • Time
  • Show
Clear All
new posts

  • Official word on 10bit or 8Bit in Edius?


    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.

    Asus PrimeZ690A - Intel i9 13900K - 32GB RAM - NVidia GTX1070 - Edius X WG - BM Intensity 4k - Boris RED - Vitascene 2 - Windows 11

  • #2
    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.
    Edius 10 WG, Lenovo P72 workstation laptop, 64GB RAM, Xeon CPU, Windows 11 Pro (64 bits), 2 x 2TB Samsung M2.NVME and 1 x 4TB Samsung SSD internal. Panasonic UX180 camera, Blackmagic 4K Pocket Cinema


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


      • #4
        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.

        Asus PrimeZ690A - Intel i9 13900K - 32GB RAM - NVidia GTX1070 - Edius X WG - BM Intensity 4k - Boris RED - Vitascene 2 - Windows 11


        • #5
          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.


          • #6
            Originally posted by pjsssss
            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.
            Six Gill DV

            Vistitle YouTube Channel

            Main System:: Azrock z690 Taichi, [email protected], 64gb ram, Lian Li Galahad 360mm in push pull, Lian Li 011 Dynamic XL ROG case, 13 Lian Infinity fans, Win11 Pro , Samsung 980 1tb boot NVME, 2TB Sabrent M.2 NVME, 2 TB WD 850x NVME, 1TB Samsung SSD, 12TB Raid 0, BM MINI MONITOR 4K, , Dual LG 27GK65S-B 144Hz monitors, GTX 1080ti SC Black Edius X.

            Second System: EditHD Ultimax-i7, X58, [email protected], Corsair H80, Win764, 24gb ram, Storm 3g, Samsung 840 Pro 256, 4tb and 6tb RAID 0 on backplane, GTX 980ti Classified, Edius 9.55, Apple 30", Samsung 24", dual BD.


            • #7
              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!


              • #8
                Originally posted by 7hbg
                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.
                Triple boot:Win10Pro/I7-5930K/GTX780/SSD-RAID/HDD-RAID/10GbE Intel X550/BMD 4K Extreme 6G/32GB RAM
                Triple boot:Win10 Pro/I7-6950X/GTX1080/SSD-RAID/HDD-RAID/BMD 4K Extreme 12G/2 x 10GbE/64GB RAM
                both on: 10Gbps Media sharing Network, 10Gbps NAS


                • #9
                  Originally posted by Crespel
                  ...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.


                  • #10
                    Grass valley... where is ? tell us something.....