I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's

I have about HAD IT with Canon's slowness when it comes to their camera software so I have decided to take the bull by the horns and since I have corporate access to EVERY Canon EOS Cinema and DSLR camera in their sales inventory, I have decided to code and test a Magic Lantern-like CODEC addition to the Cinema and DSLR cameras....AND...since Canon uses DIGIC processors which have RISC Chip ARM-based cores and I am an ABSOLUTE EXPERT in programming those chips and in coding 2D/3D Wavelet codecs at the lowest machine-code levels, I will give you Canon followers the following ABSOLUTELY FREE AND OPEN SOURCE VIDEO CODEC which hook into the Canon Camera BIOS'es and allow you to do the following:

I've got an i-frames-only version of the MP4 codec ALREADY up and running on an ARM chip board (ARM is what Canon DIGIC's are based upon). I am using the Pascal Lazarus development environment on Linux so that my code can cross-compile to almost ANY chip.

I had to convert the ENTIRE MP4-spec codec to the Pascal programming language so I could make it READABLE for me and others AND THEN PROPERLY COMMENT IT ALL so as to illustrate HOW the algorithms work! --- That was a complete NIGHTMARE to do! Now I need to finish the 3D search pixel-search algorithms so that the in-between frames (B and P frames) can be encoded which is what REALLY compresses a video stream down a whole lot.

My custom MP4 codec is now FULLY user-selectable 4:4:4, 4:2:2, 4:2:0 and 4:1:1 colour space encoding in USER-SELECTABLE 16-bits, 14-bits, 12-bits, 10-bits and 8-bits per colour channel (with an extra specialized 8-bits greyscale and 6-bits colour codec for long duration security video) AND I have put in a custom-built Flat Log-C, Log-C2 and Log-C3 LUT along with allowing OTHER user-installable LOG LUTS that can be USER-UPLOADED AND SELECTED for SEPARATE on-screen display and assign the same or different LOG/LUT for save/output to the memory cards, HDMI/DisplayPort or USB2 and USB3 ports when they are available on your camera's DIGIC chips. This means you can save to the internal cards using a flat Log-C2 LUT but output a normal REC 2020 HDR or BT.709 video frame LUT for HDMI/Displayport/USB2/USB3 output at ANY resolution and frame rate. Since this codec HOOKS into the Canon Camera BIOS'es it won't affect your OTHER settings but is a mere menu addition to the main screen.

This codec is WORLD-CAPABLE with USER SELECTABLE per minute and per hour frame rates for time lapse and astrophotographers and pre-defined 1/2/3/4/5 fps, 10 fps, 15 fps, 20 fps, 23.976, 24 fps, 25 fps, 29.97 fps, 30 fps, 50 fps, 59.94 fps, 60 fps, 100 fps, 119.88 fps, 120 fps, 200 fps, 240 fps, 300fps, 500 fps, 1000 fps frame rates which my codec actually TESTS to see if your camera hardware can actually support the higher frame rates at the selected resolution.

I ALSO HAVE a built-in Peaking/Zebra Stripes, RGB Vectorcope and Luminance Waveform and RGB Parade monitor overlay (which you can turn on/off) for live video monitoring! Output through the HDMI/Displayports/USB2/3 will be user-selectable clean or with overlays. I have embedded predefined recording and output resolutions at 180x120, 320x240, 360x240, 480x270, 640x360, 640x480, 852x480, 1024x768, 1280x720, 960x540, 1920x1080, 1024x540, 2048x1080, 3840x2160, 4096x2160 pixels and various 5k/6k/8k resolutions. These frame sizes can be assigned to the frame rate your camera hardware can PHYSICALLY support. This means at lower frame sizes you can get higher frame rates. I will LET YOU the user decide which frame rate to use with WHICH frame size! You will be given the CHOICE to downsample from the FULL native Sensor size or do a middle-of-chip sensor crop. The camera hardware test will tell you if it can support the selected frame size and frame rate! Downsampling will be Lanczos-3 for BEST image resampling quality
with a user-selectable ON or OFF for an added "UnSharp Mask" edge-sharpening
for saved-to-cards and port-output video streams. This makes your images APPEAR sharper at lower resolutions.

I also have an ALL i-frame wavelet-based INTRAFRAME compression mode with user-selectable bit rates and a FULL-RAW and RAW 4:1/6:1 compression modes for those of you who want the BEST IMAGE QUALITY! (if your flash cards can PHYSICALLY support the higher data rates -- my codec is able to test the cards!) The pre-defined bit rates for INTERFRAME 4:2:2 16/14/12/10/8-bit MP4 will be 8 mbps, 12, 17, 35, 50, 75, 100, 125, 150, 200, 300, 400 and 500 megabits per second AT EVERY resolution. You are ALSO ALLOWED to SPECIFY a custom data rate which IS STRICTLY ADHERED TO by the codec!

For you Windows users, I will put out at the SAME TIME a signed DirectShow codec plugin which will allows Win7/Win8/Win10 machines and software to READ and WRITE the files made by my codec which allows the files create by the NEW Canon camera codec addition to be read on Adobe Premiere/After Effects, BMP Resolve/Fusion, AVID, Corel Video Studio, TMPEG, AVIdub, and ANY OTHER Directshow/Direct-X/Windows Media Foundation compatible piece of Windows software. For you MAC enthusiasts, I will TRY and make a Premiere CC and FCP compatible codec and Quicktime plugin after I finish the Windows versions!

I expect at the very least, a BASIC B and P frame ALPHA TEST version of the CODEC to be ready sometime between January 15 to 30, 2018 and a beta-testable version two weeks later.

The first cameras tested will be for 7Dmk2, 6Dmk2, 5DMk3/5Dmk4, 1DxMk2, C100, C200 and C300...in that order! I may even be able to port to the Canon XC10 and XC-15 cameras and the Sony a7s, Panasonic G5 and Olympus/Pentax/Fuji cameras a few weeks later but we shall see which ones have ARM-based CPU chip cores! I will be testing on the Canon 6D and 7D first because they are our cheapest cameras to test in case I accidentally brick them with my code!

Please be PATIENT !!! Software development is HALF an ART and HALF AN ENGINEERING SCIENCE !!!! Nothing is guaranteed until I see my new interface and CODEC actually RUNNING on the cameras!

AND TO RE-ITERATE, this will be ALL FREE and OPEN SOURCE for your technical pleasures and use on your cameras! Leave comments below as to what features YOU WANT and I will see what I can do...I've got 30+ years of systems level coding experience in C/C++ Delphi/Lazarus, ARM, x86, superSPARC assembler, and other multi-core and multi-chip coding experience so I think I can QUITE outperform Canon's coding techs since much of my experience is with MISSION CRITICAL REAL-TIME AEROSPACE SYSTEMS....!!!!!

I hope this will HELP you Canon Camera Enthusiasts EVERYWHERE!

AGAIN! This will be an ABSOLUTELY FREE AND OPEN SOURCE CODEC
to use FOREVER and ever!

Thank You!

Make ALL Feature Requests Down Below in your REPLY COMMENTS:
 

hne

Gear limits your creativity
Jan 8, 2016
331
53
snoke said:
I want it make coffee too.

Considering the heat output of the video transcoder farms I'm usually working with, I bet such a video encoder would get your camera boiling hot in a few minutes of real-time 4:2:2 12-bit 100Mbps h264 encoding. Unless you add a fan, of course.

The Canon 5DmkIV already requires about 8W recording video (12.5Wh battery, 100min recording time give or take), which you can actually easily feel. With a few clever optimisations (aka short-cuts) in the video encoding and the help of some specialized hardware, I'd guess 1-2 W of those went into actual compression. Anything you add on top of that will cause the camera to overheat more quickly and battery life to suffer.

If anyone can pull 12bit 4K h264 at <400Mbps off without frying our cameras, that'd been fantastic. I'm just not holding my breath.
Oh, and you are probably violating a few patents if you do it as free software.
 
Upvote 0

hne

Gear limits your creativity
Jan 8, 2016
331
53
Don Haines said:
In the meantime, I am training one of my cats to operate my cameras and another of the cats to use photoshop. That way, I will have an automated photography system. It's every bit as likely as your wonder codec and invisible large format camera...

I think you are either overestimating the difficulties of implementing efficient video codecs by a few orders of magnitude or know enough about training cats to have already taught them to dance.

I'm not one to say what HarryFilm is trying would be impossible, just improbable to get running faster than the input stream while staying within the thermal limits.

Varying bitrates and frame rates in 1080p, yes. Not an issue as long as the sensor readout allows and it isn't faster than what's already there.
If the team of experienced video coder devs at canon decided 720p120, 1080p60 (which are both roughly 120Mpx/s) could be done in h264 but 4096p30 (240Mpx/s) had to make do with a less computationally complex codec, I find it improbable that one person would come up with code that is more than twice as fast as their best effort. It is definitely not unheard of, but I'm not betting on it.
 
Upvote 0