July 19, 2018, 11:48:07 AM

Author Topic: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's  (Read 66288 times)

HarryFilm

  • EOS M5
  • ****
  • Posts: 212
Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #90 on: March 16, 2018, 07:14:37 PM »
I read CR for the humour!

Jack

---

Then humour you shall have....my special sources have come through again... Let us just say that Canon will be making a VERY SPECIAL ANNOUNCEMENT regarding a very new codec coming your way that is going to be coming to ONE VERY VERY SPECIAL camera ...and a few others while we are at it....during NAB week AND shortly afterwards :-) ;-) ;-) ;-) ....

This is going to be very very very VERY SPECIAL
FOR ALL OF YOU CANON SHOOTERS !!!!!!!!!!!!!!!!!!

MY LIPS ARE NOW SEALED ABOUT THIS ...... :-) :-) :-) ;-) ;-) ;-) :-) :-) :-)


canon rumors FORUM

Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #90 on: March 16, 2018, 07:14:37 PM »

neuroanatomist

  • CR GEEK
  • ***************
  • Posts: 22829
Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #91 on: March 16, 2018, 07:16:09 PM »
 ::)
EOS 1D X, EOS M6, lots of lenses
______________________________
Flickr | TDP Profile/Gear List

Jack Douglas

  • Canon EF 400mm f/2.8L IS II
  • *********
  • Posts: 5402
  • http://www.gohaidagwaii.ca/blog/eagle-photography-
1DX2   11-24 F4   24-70 F4   70-200 F2.8 II   300 F2.8 II   1.4X III   2X III   400 DO F4 II 

http://yourshot.nationalgeographic.com/profile/647784/

HarryFilm

  • EOS M5
  • ****
  • Posts: 212
Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #93 on: March 16, 2018, 08:57:44 PM »
::)

Should I hold my breath? ;)

Jack

---

Now onto the original subject of my OWN CODEC, I've done a version that works for the 7D, 5D, 6D and am testing that NOW. That can be released pretty much anytime but I do want to make sure it does not brick the Canon BIOS upon upload which is a VERY REAL DANGER if unusual circumstances are present. This is WHY I use a technique called DEFENSIVE PROGRAMMING which entire all major errors and exceptions are TRAPPED and handled immediately. Of course his does require testing IN THE REAL WORLD and on multiple cameras (which we have plenty of!) and in MULTIPLE upload scenarios.

Magic Lantern went through the same thing I am doing now but unfortunately I need to do this myself and on my gear which has taken much more time than originally expected since I am the ONLY person doing this. At this time I am testing/uploading the BIOS addition onto ONLY personal gear rather than company-owned gear because if I brick a company 1Dc or a 1DxMk2 or a C100, C300, C500 or C700 there will be hell to pay. Anyways, it's better to be safe than sorry!

ethanz

  • EOS 5D Mark IV
  • ******
  • Posts: 619
  • 1DX II
    • my website
Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #94 on: March 16, 2018, 11:51:25 PM »
::)

Should I hold my breath? ;)

Jack

NAB is several weeks away, so unless you are some breathing master, I suggest not.  ;D
1DX II, 16-35L f/4 IS, 24-70L f/2.8 II, 70-200L f/2.8 IS II, 200-400L f/4 IS w/1.4 EXT
http://ethanzentz.com/

bhf3737

  • EOS M5
  • ****
  • Posts: 160
  • ---
Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #95 on: March 16, 2018, 11:57:27 PM »

---

Now onto the original subject of my OWN CODEC, I've done a version that works for the 7D, 5D, 6D and am testing that NOW. That can be released pretty much anytime but I do want to make sure it does not brick the Canon BIOS upon upload which is a VERY REAL DANGER if unusual circumstances are present. This is WHY I use a technique called DEFENSIVE PROGRAMMING which entire all major errors and exceptions are TRAPPED and handled immediately. Of course his does require testing IN THE REAL WORLD and on multiple cameras (which we have plenty of!) and in MULTIPLE upload scenarios.

Magic Lantern went through the same thing I am doing now but unfortunately I need to do this myself and on my gear which has taken much more time than originally expected since I am the ONLY person doing this. At this time I am testing/uploading the BIOS addition onto ONLY personal gear rather than company-owned gear because if I brick a company 1Dc or a 1DxMk2 or a C100, C300, C500 or C700 there will be hell to pay. Anyways, it's better to be safe than sorry!

Now I am sure you are not a programmer, or at least not a good one!
Using defensive programming in any codec is absolutely nonsense.
you may want to put some safe-guards in the frame buffer and with lesser extent in de-multiplexer but beyond those modules defensive programming in the coding/decoding mechanisms is meaningless.
Defensive programming is a CPU hog. It wastes time checking for things that are caught by ordinary exceptions and it eats CPU cycles. Anything passing the frame buffer is already safe and ready to go. You will  never want to add unnecessary checks in the encoding/decoding modules of your code to further slow it down. 

HarryFilm

  • EOS M5
  • ****
  • Posts: 212
Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #96 on: March 19, 2018, 02:32:16 AM »

---

Now onto the original subject of my OWN CODEC, I've done a version that works for the 7D, 5D, 6D and am testing that NOW. That can be released pretty much anytime but I do want to make sure it does not brick the Canon BIOS upon upload which is a VERY REAL DANGER if unusual circumstances are present. This is WHY I use a technique called DEFENSIVE PROGRAMMING which entire all major errors and exceptions are TRAPPED and handled immediately. Of course his does require testing IN THE REAL WORLD and on multiple cameras (which we have plenty of!) and in MULTIPLE upload scenarios.

Magic Lantern went through the same thing I am doing now but unfortunately I need to do this myself and on my gear which has taken much more time than originally expected since I am the ONLY person doing this. At this time I am testing/uploading the BIOS addition onto ONLY personal gear rather than company-owned gear because if I brick a company 1Dc or a 1DxMk2 or a C100, C300, C500 or C700 there will be hell to pay. Anyways, it's better to be safe than sorry!

Now I am sure you are not a programmer, or at least not a good one!
Using defensive programming in any codec is absolutely nonsense.
you may want to put some safe-guards in the frame buffer and with lesser extent in de-multiplexer but beyond those modules defensive programming in the coding/decoding mechanisms is meaningless.
Defensive programming is a CPU hog. It wastes time checking for things that are caught by ordinary exceptions and it eats CPU cycles. Anything passing the frame buffer is already safe and ready to go. You will  never want to add unnecessary checks in the encoding/decoding modules of your code to further slow it down.

---

You're assuming I am using Try-Exception based coding for EVERY Pixel or line of pixels which I am not. I only want the size of frame buffer and non-corruption of pixels and any numeric underflow/overflow and real-number based NAN scenarios
when I get data from the ADC.

You can trigger those to branch to an in-CPU instruction cache for mitigation and skip-over so I don't lose those precious microseconds on raising a soft BIOS exception or lower-level hardware-exception which of course can take MILLISECONDS to run through.

By defensive programming, I mean that I run my code through an ARM emulator to figure out for every pixel what would happen if I get values from the ADC that are out of range of the current numeric type being used. What would also happen if a pointer to a buffer is screwy and other buffer overrun/underrun scenarios which I plan for in my code. I also profile EVERY VALUE of EVERY PIXEL operation which at 16 bits per channel is quite a lot of profiling on the emulator AND even on ARM hardware. That's ANOTHER reason it's taking so long to get this codec out.
YOU TRY and profile 2^48th and 2^64th pixel values and pixel operations
in multiple buffers for 2k, 4k and 8k frame buffers!

Why do you think I am running this ARM emulation all on an AMD superworkstation? I've got MUCH MORE system system RAM than most AND LOTS of terabytes on my local SAN and it's STILL not enough!

To emulate and profile multiple clock frequencies from 25 MHz to the 1.4 GHz that Canon uses on their DIGICs so I can keep per-frame 24 fps compression at less than 42 milliseconds and 60 fps at less than 16 milliseconds is a ROYAL PAIN!

I'm also doing CLEAN ROOM-based work so that I can PROVE TO ANY patent and copyright judge that I didn't reverse-engineer in any MPEG-LA and Canon patent and copyright-infringing manner which makes me legally free to do this type of work without getting sued by the MPEG-LA patent pool or Canon itself on a purely malicious basis.

I will of course VIGOROUSLY DEFEND myself if Canon or MPEG-LA DOES try any legal stunts on me regarding my codec. If they want to go against a legal team with THOUSANDS OF HOURS of very real Deposition (NOT just Discovery!) but actual court-ordered deposition experience, they will find out that I ABSOLUTELY LOOOOOVE LOOOOOOOOONG LEGAL FIGHTS --- and I will remind them that I am VERY-WELL-USED-TO to dealing with legal cases which ON AVERAGE range from 4 years to 17+ very long years of legal wrangling...I can EASILY WAIT THAT LONG for a judgement (i.e. 17+ years!) AND I DON'T DO SETTLEMENT OFFERS !!! ---- I ALWAYS GO TO TRIAL!

I WANT MY arguments, decisions and precedents HEARD AND SET IN STONE by a judge and jury! I know the hard rules of evidence very well and and can MAKE SURE the Trier-of-Fact will base their decisions on HARD PROVABLE OBJECTIVE evidence and not the legal mumbo jumbo USUALLY used to obfuscate many Patent/Copyright cases. I have LOTS of experience in ensuring the evidence REQUIRED for a favourable judgement actually gets presented in a meaningful manner to said judge/jury!

Anyways, that rant was for the MPEG-LA and Canon lawyers reading this so they understand I AM VERY VERY WILLING TO WAIT AND FIGHT for 20+ Years on a legal case TO ENSURE I GOTO TRIAL........and GET MY LEGAL ARGUMENTS SET IN STONE!

Programming-wise, defensive programming for me means emulating and checking all my input/output values and injecting hard or soft errors to see what happens and then mitigating or failing-over quickly if at all possible.

canon rumors FORUM

Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #96 on: March 19, 2018, 02:32:16 AM »

LDS

  • EOS 5DS R
  • ******
  • Posts: 1291
Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #97 on: March 19, 2018, 05:50:55 AM »
I'm also doing CLEAN ROOM-based work so that I can PROVE TO ANY patent and copyright judge

Evidently, you don't even know the difference between copyright and patents...

Mariandvd

  • PowerShot G7 X Mark II
  • **
  • Posts: 11
Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #98 on: March 19, 2018, 07:07:36 AM »

---

Now onto the original subject of my OWN CODEC, I've done a version that works for the 7D, 5D, 6D and am testing that NOW. That can be released pretty much anytime but I do want to make sure it does not brick the Canon BIOS upon upload which is a VERY REAL DANGER if unusual circumstances are present. This is WHY I use a technique called DEFENSIVE PROGRAMMING which entire all major errors and exceptions are TRAPPED and handled immediately. Of course his does require testing IN THE REAL WORLD and on multiple cameras (which we have plenty of!) and in MULTIPLE upload scenarios.

Magic Lantern went through the same thing I am doing now but unfortunately I need to do this myself and on my gear which has taken much more time than originally expected since I am the ONLY person doing this. At this time I am testing/uploading the BIOS addition onto ONLY personal gear rather than company-owned gear because if I brick a company 1Dc or a 1DxMk2 or a C100, C300, C500 or C700 there will be hell to pay. Anyways, it's better to be safe than sorry!

Now I am sure you are not a programmer, or at least not a good one!
Using defensive programming in any codec is absolutely nonsense.
you may want to put some safe-guards in the frame buffer and with lesser extent in de-multiplexer but beyond those modules defensive programming in the coding/decoding mechanisms is meaningless.
Defensive programming is a CPU hog. It wastes time checking for things that are caught by ordinary exceptions and it eats CPU cycles. Anything passing the frame buffer is already safe and ready to go. You will  never want to add unnecessary checks in the encoding/decoding modules of your code to further slow it down.

---

You're assuming I am using Try-Exception based coding for EVERY Pixel or line of pixels which I am not. I only want the size of frame buffer and non-corruption of pixels and any numeric underflow/overflow and real-number based NAN scenarios
when I get data from the ADC.

You can trigger those to branch to an in-CPU instruction cache for mitigation and skip-over so I don't lose those precious microseconds on raising a soft BIOS exception or lower-level hardware-exception which of course can take MILLISECONDS to run through.

By defensive programming, I mean that I run my code through an ARM emulator to figure out for every pixel what would happen if I get values from the ADC that are out of range of the current numeric type being used. What would also happen if a pointer to a buffer is screwy and other buffer overrun/underrun scenarios which I plan for in my code. I also profile EVERY VALUE of EVERY PIXEL operation which at 16 bits per channel is quite a lot of profiling on the emulator AND even on ARM hardware. That's ANOTHER reason it's taking so long to get this codec out.
YOU TRY and profile 2^48th and 2^64th pixel values and pixel operations
in multiple buffers for 2k, 4k and 8k frame buffers!

Why do you think I am running this ARM emulation all on an AMD superworkstation? I've got MUCH MORE system system RAM than most AND LOTS of terabytes on my local SAN and it's STILL not enough!

To emulate and profile multiple clock frequencies from 25 MHz to the 1.4 GHz that Canon uses on their DIGICs so I can keep per-frame 24 fps compression at less than 42 milliseconds and 60 fps at less than 16 milliseconds is a ROYAL PAIN!

I'm also doing CLEAN ROOM-based work so that I can PROVE TO ANY patent and copyright judge that I didn't reverse-engineer in any MPEG-LA and Canon patent and copyright-infringing manner which makes me legally free to do this type of work without getting sued by the MPEG-LA patent pool or Canon itself on a purely malicious basis.

I will of course VIGOROUSLY DEFEND myself if Canon or MPEG-LA DOES try any legal stunts on me regarding my codec. If they want to go against a legal team with THOUSANDS OF HOURS of very real Deposition (NOT just Discovery!) but actual court-ordered deposition experience, they will find out that I ABSOLUTELY LOOOOOVE LOOOOOOOOONG LEGAL FIGHTS --- and I will remind them that I am VERY-WELL-USED-TO to dealing with legal cases which ON AVERAGE range from 4 years to 17+ very long years of legal wrangling...I can EASILY WAIT THAT LONG for a judgement (i.e. 17+ years!) AND I DON'T DO SETTLEMENT OFFERS !!! ---- I ALWAYS GO TO TRIAL!

I WANT MY arguments, decisions and precedents HEARD AND SET IN STONE by a judge and jury! I know the hard rules of evidence very well and and can MAKE SURE the Trier-of-Fact will base their decisions on HARD PROVABLE OBJECTIVE evidence and not the legal mumbo jumbo USUALLY used to obfuscate many Patent/Copyright cases. I have LOTS of experience in ensuring the evidence REQUIRED for a favourable judgement actually gets presented in a meaningful manner to said judge/jury!

Anyways, that rant was for the MPEG-LA and Canon lawyers reading this so they understand I AM VERY VERY WILLING TO WAIT AND FIGHT for 20+ Years on a legal case TO ENSURE I GOTO TRIAL........and GET MY LEGAL ARGUMENTS SET IN STONE!

Programming-wise, defensive programming for me means emulating and checking all my input/output values and injecting hard or soft errors to see what happens and then mitigating or failing-over quickly if at all possible.

Thanks for the info. I do not tend to belive something until or i can check it. But i do belive you Harry. You seem like an intelligent person. I see a lot of people "just talking" here on this post but i don't see intelligence from them. They just don't have much to do with their time. I would not bother to unswer to these people. Take as long time as you need and finish this big project. Good luck.

Jack Douglas

  • Canon EF 400mm f/2.8L IS II
  • *********
  • Posts: 5402
  • http://www.gohaidagwaii.ca/blog/eagle-photography-
Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #99 on: March 19, 2018, 09:51:52 AM »
I'm not the genius in this group for sure but having lost my wife to cancer at a young age I'm smart enough to know there isn't a person on earth who can guarantee they have X number of years left.  Furthermore, it's not a demonstration of wisdom to brag about things that could very well be out of one's hands. 

While this is entertaining, if there were a call for funding for this project, I would never lay my money down. ;) :)

Jack
1DX2   11-24 F4   24-70 F4   70-200 F2.8 II   300 F2.8 II   1.4X III   2X III   400 DO F4 II 

http://yourshot.nationalgeographic.com/profile/647784/

neuroanatomist

  • CR GEEK
  • ***************
  • Posts: 22829
Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #100 on: March 19, 2018, 10:12:28 AM »
But i do belive you Harry. You seem like an intelligent person.

Sounding intelligent and being intelligent are not synonymous.  I can’t speak for programming skills, but on the occasion where he dipped his toes into the realm of biological science, I can tell you with absolute certainty that he was full of sh!t.
EOS 1D X, EOS M6, lots of lenses
______________________________
Flickr | TDP Profile/Gear List

unfocused

  • Canon EF 400mm f/2.8L IS II
  • *********
  • Posts: 4206
    • Mark Gordon Communications
Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #101 on: March 19, 2018, 10:33:41 AM »
I consider this entertainment. Nothing more. I do almost no video so I could not care less about the final result that has been promised.

I also would never download a third-party software to my camera, including Magic Lantern.

So, my main interest is in seeing if this magical video software actually comes to fruition or if Mr. Film turns out to be a hoax or is a sincere but delusional hacker.  I readily admit my skepticism, since I have dealt with any number of people in a variety of situations who make big claims that never materialize.

When I was a child, I had friends who believed with absolute certainty that the big three car makers (And there were only the three when I was a youth) had invented a super carburetor that got 100 miles to the gallon, but that they were keeping it off the market to protect the oil industry. I have lived through many hoaxes, conspiracy theories and con artists since and have found a healthy skepticism serves me well. 

I would like to see if Harry can give us a firm date for having something tangible, or if the intent is simply to see how many years we can string this thread out.
« Last Edit: March 19, 2018, 10:40:16 AM by unfocused »

bhf3737

  • EOS M5
  • ****
  • Posts: 160
  • ---
Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #102 on: March 19, 2018, 02:31:54 PM »
...
I'm also doing CLEAN ROOM-based work ...

Yet, another evidence that you are not a programmer at least not from this planet.
Didn't you learn, wherever you got your degree, that cleanroom work does not need extensive testing? Because the code is already "clean" (i.e. requirements verified logically and converted to code semi-automatically, there is no emergent or unwanted or unspecified behavior to expect), therefore it only needs statistical testing. But all your claim so far has been that your code needs "extensive" testing!! 
All you have generated so far in your messages as evidence of your work has been pseudo-scientific mumble jumble that contradicts not only common sense but also your own arguments.
Congrats! you have some followers on this planet believing you and cheering for your yet to be available intellectual achievement!

canon rumors FORUM

Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #102 on: March 19, 2018, 02:31:54 PM »

HarryFilm

  • EOS M5
  • ****
  • Posts: 212
Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #103 on: March 19, 2018, 07:35:03 PM »
I'm also doing CLEAN ROOM-based work so that I can PROVE TO ANY patent and copyright judge

Evidently, you don't even know the difference between copyright and patents...

---

Hardware DESIGNS can be copyrighted or filed under a Design Patent.

I am doing stuff that MAY fall under patent OR copyright -- Depends upon how MPEG-LA or Canon file their suits and what they claim...BUT...since I have 2700 hours+ of deposition experience I think I've learned a few battle strategies when it comes to lawyers argue cases of many types...so I have generally tried to avoid ANYTHING that could be construed as violating design-oriented copyrights OR basic hardware and software patents.

HarryFilm

  • EOS M5
  • ****
  • Posts: 212
Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #104 on: March 19, 2018, 07:53:16 PM »
But i do belive you Harry. You seem like an intelligent person.

Sounding intelligent and being intelligent are not synonymous.  I can’t speak for programming skills, but on the occasion where he dipped his toes into the realm of biological science, I can tell you with absolute certainty that he was full of sh!t.

---

I never did claim I was medical personnel or bio-whatever research scientist of ANY kind. Hell I KNOW my foray into your area of expertise was full of utter horse hockey but it was rather interesting to see if there was some overlap in skillset. I should note however that on a technical basis, my grid-computing code actually CAN be used for CRISPR applications AND organic and nuclear chemistry bond finding/evaluation applications so it actually MIGHT be useful in your area of exploration. I probably SHOULD get it evaluated though by someone in that field.

My diploma is actually IN Cinema, Television, Stage and Radio Arts, but of course, I've done work in Oil & Gas data visualization, machine vision, low-level systems programming, grid-compute and encryption systems so the television aspect of my actual (formal) education has DEFINITELY helped in that sort of work.

I'm just annoyed at Canon for REFUSING to see the light and give us a decent codec so I will build and test my own. Not That Hard To actually DO programming-wise, but test and evaluation is DEFINITELY a whole'nother ball of wax!

I also KNOW that the MPEG-LA group holds the patent pool for the DCT-based and Wavelet-based Group-of-Frames based compression systems AND Canon who holds numerous copyrights and patents on user interfaces, hardware designs, etc. MIGHT take legal exception to my efforts...BUT...then again, my 2700+ hour so legal video experience helps me formulate viable BATTLE STRATEGIES for legal cases of all kinds and since I also am a total A-whackin-whole, I am stubborn enough and utterly retentive enough to see through a legal case that might drag on for 20 years or more !!! I also know enough of what judges and juries want to see, hear and know when they are tasked as being Triers-of-Fact. This should give pause to ANY group that thinks I've infringed upon their patents. I will show that I have NOT DONE SO!

canon rumors FORUM

Re: I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
« Reply #104 on: March 19, 2018, 07:53:16 PM »