AFAIK, the reason this stuff is not in ML is (this is just my understanding, someone correct me if I'm wrong):
- Just setting these h.264 settings causes Canon firmware to throw lots of errors.
- Using "cache hacks" (patching values in the cache to override Canon firmware behavior), 1% suppressed these errors to allow the settings to actually work.
- a1ex and other devs consider it "dangerous" to patch out and ignore these errors, without understanding *why* the Canon firmware is throwing them. Also, all this cache hacking code is very hard to understand.
Here's a summary from a1ex's code review of TL from a long time back. I've quoted the relevant sections below.
http://www.magiclantern.fm/forum/index.php?topic=9510.msg78084#msg78084As I'm currently in the middle of porting some changes from Tragic Lantern, here's my detailed code review, based on this diff (ML 4b3129d vs TL 7a5ccc6). I hope it answers the questions about safety and about the differences between TL and ML.
...
Major concerns:
- In many places, Canon error checking code is disabled (examples: beep.c or bitrate-6d.c, especially the second one). This is a no-no for me, and it's like running with a bike downhill at full speed without brakes. Just try understanding that code if you don't believe me.
....
- Error handling in bitrate code is done by rebooting the camera in the middle of recording!
Minor concerns
- no checks before patching Canon code
...
Conclusion: personally I'm afraid to run Tragic Lantern on any of my cameras. Sure, I don't remember anyone bricking his camera with TL code, but I've learned about some dangerous things the hard way, by bricking my own cameras (and then learning how unbricking them). Of course, you should not trust me blindly, you should review the code on your own (even the code from the main repo).
Sorry if I sound like bashing or underestimating the contributions from 1%. I've just tried to do an objective review of Tragic Lantern, especially regarding code safety, and I've tried to back every argument with a link or a code snippet. These are the main reasons TL code didn't get merged into main repo; I've pointed them out many times, but the issues were not solved, so a little reminder shouldn't hurt.
Now, I have to admit I don't have a better solution. The main repo for 6D (and other cameras, e.g. EOS M) was not touched for months, so it's completely untested. I can't help with that, because I don't own these cameras, and I already have too many of them). I just want people follow some really basic development guidelines, and submit their changes to the main repository, where they will be subject to code review from me, g3gg0, nanomad and many others - both devs and nondevs). Now, the entire 6D/EOSM/7D development is done in a fork where the core ML developers have absolutely no influence, and most people are not aware of that.
So, it's not really a matter of getting the code to work, that's easy, it already works. If you want to see this in ML, then you need to
prove that this stuff is not 'dangerous' (just testing it and saying 'hey it works for me' is not good enough). That will require a lot of work and reverse engineering/analyzing the Canon firmware.
