Magic Lantern Forum

Developing Magic Lantern => General Development => Topic started by: dpjpandone on August 13, 2015, 05:31:22 AM

Title: New Discussion about the merits of Video Hacks
Post by: dpjpandone on August 13, 2015, 05:31:22 AM
I am test various fps settings on EOSM, and I need to enable gop and flush rate to find the upper limits of overcranking. I have successfully recorded up to 45fps in 1080p crop mode (h264), but to do this, gop must be set to 1 and flush set to 4. (This was on an earlier build that had video hacks enabled)

I have #define FEATURE_VIDEO_HACKS in my features file, but the video hacks don't show up in the menu. What else do i need to change to get this back?

Title: Re: defined video hacks in features, not showing up in menu
Post by: dpjpandone on August 14, 2015, 07:29:29 PM
OK, i figured it out,

I was missing the file video_hacksU.o
and I also had to add:

ML_SRC_EXTRA_OBJS = \
video_hacksU.o \


to my makefile.setup in the platform directory.

So I've got it working now.

If i recall correctly, the reason this is not included in main, is because the settings persist until you restart the camera, not only this, but the camera must be restarted with the same card (with the current implementation) in order to clear the settings, this presents a dangerous situation, as someone who isn't aware of this might remove their magic lantern card, and the GOP/flush settings don't go back to default.

So please give me a hint as to an example of different code that had this problem (of having to reboot to turn off feature) and was fixed. I think it's worthwhile to work on this because control over gop settings allows the EOSM (and probably other digic 5 cameras) to record up to 45fps in 1080p crop mode. I would like to eventually implement a slow-mo module that automatically applies the best settings for overcranking.

Is anyone willing to help me with this? Or should I just keep it to myself? I know this is an advanced use case (expert users only...) but I think we could make it easy to understand and safe for the masses with correct implementation (module?). I know that the perceived benefit of these controls did not show much in the way of video quality improvement when it was being investigated, but no one ever talked about overcranking. I feel this warrants further discussion. If you disagree, and think it's just going to be a support nightmare, let me know, and I'll stop talking about it.

Thanks
~Jon
Title: Re: New Discussion about the merits of Video Hacks
Post by: dpjpandone on August 16, 2015, 05:47:00 AM
In my experiments with video hacks, I have found the following:

1. Setting Flush rate to anything other than default yields no improvement. This is because the The SD card bus (EOSM) is faster than the max data rate the .h264 encoder can handle.

2. Setting GOP to anything other than 1 (ALL-I) yields negligible gains in video quality. Sure, GOP4 looks slightly better than the default of 1/2FPS, but it's not that big of a difference,  1/2FPS is probably close enough to optimal for IPP.

3. The advantages of using ALL-I are as follows
  A. Encoder doesn't have to work as hard, and so can reliably encode up to 44fps @ 1080p (it's limited to about 35 fps otherwise)
  B. Less macroblocking, better motion cadence, resolves more detail in complex scenes
  C. Performance is better when editing

So, in light of these experiences, I propose:

- "Flush Rate" should not be user selectable. (just leave it at default)
- GOP has only two settings - 0 or 1 (IPP, or ALL-I) - menu help should say "Choose ALL-I for best quality (fast card), IPP for smaller file size"
- the name of the menu is "Compression Method" instead of "Video Hacks"

Would this simplify the user experience enough so that forum moderators don't have to answer a million "what's the best settings"questions?


 
Title: Re: New Discussion about the merits of Video Hacks
Post by: DeafEyeJedi on August 16, 2015, 06:27:41 AM
Makes sense and agree that it may be best to leave "Flush Rate" out of reach for users and I like the idea of changing the phrase from "Video Hacks" to "Compression Method" and thanks for a great read as always!
Title: Re: New Discussion about the merits of Video Hacks
Post by: EosM-User on January 05, 2016, 05:42:16 PM
Hi,

i know the topic is a bit old but i played with the video hack feature and try to understand a few things.

First of all i know about the risk using the Video hacks since they make persistent changes and can only be undone by ML firmware.
I think video hacks especially GOP would be a nice improvement for h264 without messing around with raw and the needed post workflow. 

Now i have the following questions:

1. The video hack code disables audio recording. I set GOP to 1 and leave flush rate at 4, went back to the stock canon menu and turned audio recording on. I was able to record audio and video in 1280x720 @ 24p with CBR 1.2 so why does the video hack disable the sound recording ?

2. Is there an easy way to check if the GOP setting really has influence for the H264 compression ? I would like to check/verify if it really generates only I-Frames after setting GOP to 1.