I'm making a 4:4:4/4:2:2 16/14/12/10-bit codec for Canon DSLR's
- Thread starter HarryFilm
- Start date
Don Haines said:
That's interesting, and makes you wonder why Canon don't add a "slow mode" - for some kind of photos where you have time it could be interesting - although I'm sure they are worried of people who activate it and the complain about the camera speed...
Upvote
0
LDS said:
You've fallen victim to one of the classic blunders. The most famous is never get involved in a land war in Asia, but only slightly less well known is this: never go up against a Canadian when politely imitative trolling is on the line!
Upvote
0
Don Haines said:
---
Well...from a programmer and engineering point of view ALL OF THE ABOVE
is technically correct and possible, but I would put a heat sink on the chip.
Are you talking about the ARM big.LITTLE dynamic voltage and frequency scaling
pull backs? That is not true throttling and dynamic sleep mode like what
x86's do! And at anywhere up to 100+ microseconds, i need that time for
compression tasks.
The Coretex core on DIGICs only goes to 1.4 GHz so unless you saw something different the 2.0 GHz is out of spec! But it is rather ingenious if that is what has happened.
If you're using a decent Agilent or Lecroy scope you might see the chip doing all this, but since I don't have those, i've had to do it the hard way doing test after test to see if any throttling occurs and whether I can do frame compression at speeds up to 16-to-42 milliseconds per frame depending upon frame-rate.
100 MHz sounds rather low for ANY throttling and it can take MILLISECONDS
to throttle down cores and peripherals on low-power ARM cores unlike what Intel x86 and AMD chips do on their cores instantaneously. That wouldn't allow for me to compress frames fast enough to output to storage. I will look further but so far at 24 fps (42 milliseconds per frame at 1080p) 4:4:4 and 4:2:2 14 bits real colour channel bits (the ADC is only 14 bits), I can live with that for now on the Canon 7D/6D.
Obviously you're educated enough that your words make TECHNICAL sense to me but on a practical sense with DIGIC's specifically I see no such behaviour AND since my equipment is basic, I have to do it the hard way by doing something called CPU Instruction Set Profiling figuring out how fast each instruction is on given set of data so I can keep compression below 42 milliseconds per frame for 24 fps realtime video performance.
Upvote
0
Don't y'all know who this guy is? He wrote the original Pong program back in the 1970s and then got hired on by... wait for it... Sony to do the VCR program codes and directions. ;D
Upvote
0
Don Haines said:
===
Sorry! But you're rather WRONG in your assumptions !!!!
You didn't even POST the rest of my comments as see the OBVIOUS sarcasm I was dripping into the conversation. I call that POOR JOURNALISM!
I've done work like this before so this coding is not that big of a deal for me. YOU are NOT taking the risk of MPEG-LA suing YOU for Patent Infringement (ya know the 1.5 to 3 million dollars in lawyers fees that I --ME!-- have to put UP FRONT to ensure YOU have a pot to slurry in) Obviously you know ABSOLUTELY NOTHING ZERO, ZIP, ZILCH -- NOT A DAMN THING! about U.S. Patent law and Intellectual Property Rights! How much actual EFFORT is required to make sure a compression algorithm doesn't infringe on patents...in a country where a copyright violation is $150,000 PER EVENT -- A country where 20 year old kids goto prison for 30+ years for downloading "improper" software! Where a decent IP lawyer is between $500 to $1000 PER HOUR and i need to pay up a $50,000 RETAINER UP FRONT before they will even talk with me!
This is AMERICA...where the last time I dealt with a bunch of US attorneys, it was to witness the $6,000 PER HOUR to pay the 12 lawyers in the boardroom at $500 per hour being spent like so much water! So for that 8 hour day that was a $48,000 US lesson in the US legal system. So when YOU have $48,000 US PER DAY (36 000 Euros) to spend on legal fees, then PLEASE DO TELL ME HOW DO MY BUSINESS of software development !!!!
So have some tea and crumpets when I'm done. I'm done and you'll see the final result WHEN I'M ACTUALLY DONE AND TESTED! Plus you wouldn't want to see YOUR CAMERA BRICKED by some wayward fancy-BIOS-trickery software upload would you?
Plus it's OUR $6000 1Dx/x series of cameras and $10,000+ C200/300/500/700s. When YOU have all those cameras yourself and am WILLING to BRICK THEM...then do please email me and I will send you the upload now and you can tell me how it went and THEN tell Canon CPS what you did! Good! You now have a $10,000+ wall ornament...THINK ABOUT WHAT YOU SAY!
Upvote
0
Jack Douglas said:
---
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 ......
;-) ;-) ;-)
Upvote
0
Jack Douglas said:neuroanatomist said::
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!
Upvote
0
Jack Douglas said:neuroanatomist said::
Should I hold my breath?
Jack
NAB is several weeks away, so unless you are some breathing master, I suggest not. ;D
Upvote
0
HarryFilm said:
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.
Upvote
0
bhf3737 said:
---
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.
Upvote
0
HarryFilm said:
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.
Upvote
0
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
While this is entertaining, if there were a call for funding for this project, I would never lay my money down.
Jack
Upvote
0
Similar threads
