LiveView Investigation

[ZEEK]

Legend 👏

[Grognard]

Thank you Bilal, you are a wizard! Realtime preview without global draw it's crasy. You gave a big boost with sd overclock and now realtime preview!
Will it be possible to have good ratio for 1×3 mode too? Porting on EOS m should be easy but on 5diii and 5dii more work to do.

[GullRaDriel]

How can I test this on the 5DIII ?

I have firmware 1.13 and I can compile ML myself, at least for 5DIII. Is there a repo somewhere where I can download a file, or did you just go with atgd gui ?

Well, all said: is there something implemented already ?

[theBilalFakhouri]

3- The full 1080 height isn't showing, a bit cut in the bottom Edit: Fixed.

Narrowed down this mother f*cker and fixed it.

[theBilalFakhouri]

Legend 👏

Glad you are following this development

Thank you Bilal, you are a wizard! Realtime preview without global draw it's crasy. You gave a big boost with sd overclock and now realtime preview!

You're welcome! , Thanks, I thought enhanced sd_uhs and real-time correct preview is the two last thing we could get on DIGIC 5 Canon cameras, a new ML decade has started for newer cameras, I don't think any of main Developers would work on DIGIC 5 cameras again, just a thought . .

Will it be possible to have good ratio for 1×3 mode too? Porting on EOS m should be easy but on 5diii and 5dii more work to do.

For 1x3 mode In theory it's possible, but more knowledge is required, I am working on it, EOS M shares identical registers and values, I sent same preset to @Danne and Confirmed it's working, 5D3 have different set of registers, it might be easy to port if we the effects of registers were the same, I don't have the camera I can't work on it, Sorry . . 5D2 is another story, and might be simpler.

How can I test this on the 5DIII ?

I have firmware 1.13 and I can compile ML myself, at least for 5DIII. Is there a repo somewhere where I can download a file, or did you just go with atgd gui ?

Well, all said: is there something implemented already ?

There is nothing for 5D3, Sorry, No one has worked on it yet, I can't work on it too because I don't have the camera.

Anything working on eos m? I think this is what I've been dreaming about for like 2 years... it's real live view in real time right? The choppy preview live view that shows the framing is all we have now. Or real live view with the wrong framing. If this is real live view with correct framing you'll be the hero of all time:)

Already working on EOS M, no available build yet, It's Real-Time Correct Framing, real-time as Canon Preview, correct Framing as ML Framing, both in one, you are welcome.

This is so exciting! Keep experimenting please!!!!

And it gets more and more exciting

[theBilalFakhouri]

RAW data compared to Normal x5 Preview and the new Expanded Preview:



-These three images are dumped from the Camera.
-The new Expanded Preview is in real-time and responsive as normal 1080p.
-Aspect ratio is correct in LiveView for The new Expanded Preview, no need to enable ML Global Draw.
-Framing is correct if you consider there will be data in the Black Bar on the right.
-No overhead or slowness.
-Works on external HDMI monitor too.
-Only working for 700D and *EOS M (*Confirmed by Danne) for now . . unless someone work on other cameras.

-Last limit of this preview is the Black Bar in the right, still working on it.

Releasing soon for testers.

[Danne]

Jedi skills man  .

[yourboylloyd]

Wowwwww. This is crazy!

[IBIRRU]

Woow!
I'm available for testing on 700D

[2blackbar]

very exciting news, great work

[andy kh]

This is amazing

[Teamsleepkid]

Thanks for your reply bilal can't wait to test. Thanks for this. I'm sure everyone is very excited:)

[guerchi]

This is Incredible! What you've already achieved is a huge leap from the preview possible with Canon's 5x crop.
2.5K mode will be the real king and the EOS M will reach its perfection after this.
Thanks @theBilalFakhouri

[theBilalFakhouri]

Test Builds are out for 700D, and *EOS M (*Thanks Danne), You will find it on the new thread:
Experimental Real-Time Correct Framing Preview

-Let's keep this thread for development, and move on to the new thread for sharing thoughts and community discussions.

-Thanks all for your words.

[Levas]

Does this liveview resolution change mean you can record 2.5k in h.264 ? What happens when you disable raw video and hit the record button, how does the canon mov file look.
Just curious
(Since raw is way too good to go back to h.264 compression  )

[Danne]

Canon mov file looks...*drum roll'...................like shit!  .

[Levas]

Are you talking about 2.5k liveview or not? Because Canon mov files always looks like shit 

Compared to raw that is 

[Danne]

Not working to record when in x5zoom.

[theBilalFakhouri]

First we need to patch x5 Mode into mv1080, then apply the new preset, then use YUV Upscaling/Downscaling registers to make YUV resolution as mv1080, after that we should try Hitting the record button and see what H.264 file look like

However patching x5 Mode isn't working, we can baypass patching and adjusting YUV res, instead of that we can patch mv1080 to 1:1 by Using ADTG[800C] and CMOS 5, then increasing RAW data, fixing LiveView, Increasing Preview region, Hitting record button, But also fixing LiveView after increasing RAW data in mv1080 isn't working

[Danne]

Yes, or modify movie crop mode. The holy shortcut .

[theBilalFakhouri]

Movie Crop Mode has 720x404 16:9 AR YUV image with black borders in top and bottom, otherwise x5 Mode and mv1080 has 720x480 YUV 3:2 AR, without the black borders, I didn't study MCM yet, this might help us to center the x5 new preview on screen, there is register controls black borders natively from Canon starting from the right and from the bottom, but has no effect in x5 Mode: C0F08554

[Grognard]

It works, thank you Bilal. But it's difficult to keep concentration on the screen with the stuck frame bug or the white noise in the bottom.
I've found a little trick to keep the black bar in the bottom screen by pressing menu button untile the black screen appear then quickly toggle to framing mode by pressing focus button.

We can also toggle in photo mode and quickly go back in video mode.

I also notticed that if we reduce resolution, in 2,5k mode, the preview is still the same and then larger than the correct frame. It's better than the otherwise!

[theBilalFakhouri]

@Grognard
Black bars could be added from mlv_lite, using ML Global Draw, it's very easy task and doable, this is still very new stuff, I might add them in the future, glad you liked it

Regards,

[theBilalFakhouri]

-My notes for 5D3 (where to start looking):

-I have started looking in my 700D between x5 and x10 modes, and identify cropping registers by using adtg_gui module. On 5D3 I couldn't see registers between x5 and x10 mode, a1ex has mentioned that cropping is happening using Eeko core (second core for DIGIC 5). adtg_gui won't help here.

So in this case you need to capture DebugMsg log from 5D3, between x5 and x10 mode. And look for the functions which being called, try to identify which one crops the image.
Try for example do x15 cropping instead of x10 using the discovered functions, maybe play with some registers related to cropping if you found any.

Cropping functions/registers between x5 and x10 might not be needed, because it might help with only increasing the cropped area, not decreasing it. If it were required to decrease cropping then understanding it would be important.

-Compare 1080p mode against 720p. adtg_gui would show registers between the two modes. try to understand the registers and identify its effect.
in 1080p mode 1920x1280 RAW data is being processed in LiveView
in 720p mode 1920x648 RAW data is being processed in LiveView

From 720p mode set Binning mode to 3x3, increase RAW data to 1920x1280 (using adtg_gui, take the values from 1080p mode), no you will have stretched LiveView as in 1x3 mode in 5D3, try to recover the cropped part (bottom part of the frame) from your the registers you have found out (I couldn't do it on 700D, LiveView freezes).

-Compare 1080p mode vs x5 mode, a lot of registers would presented here, probably a part of these presented registers are all of what you need. Well, you need to figure out how they work togather.

-Try to identify YUV scaling registers, e.g.
In 720p RAW data would be down scaled from 1920x648 to 1280x720 in LiveView (YUV HD stream).

In 1080p 1920x1280 RAW data is being down scaled to 1904x1151
In LiveView Photo mode 1920x1280 RAW data is being down scaled to 1620x1080, in this case capture DebugMsg log between LiveView photo mode and 1080p mode, this way you might identify YUV scaling registers (on 700D I skipped these registers, doesn't help with increasing processed RAW data in LiveView).

-No idea if there other easier way, probably looking into *SetVram/ClearVram functions (in ROM1.BIN using Ghidra) in different LiveView modes. comparing them might help.
-*on 700D all preview registers are being set after calling SetVramPath (each video mode has its own SetVramPath, see strings in ROM).

-Probably most important thing is to LOG Eeko core activity, as far as I know we don't log its activity currently, would be there new range of registers? no idea.
-I think on 700D Eeko is being used too (not as much as 5D3), e.g. for centering YUV paths on screen, look at this experiment, in that experiment preview was showing in the top of screen, not centered, even though I applied patched all registers from movie crop mode to x5 mode using adtg_gui.

[theBilalFakhouri]

-Problem: lowering RAW video resolution in various movie movie mode will freeze LiveView and the camera will crash after some seconds.

-Preventing the crash: I discovered two ways:

1- by Calling ClearVramPath, this will clear both YUV LV and HD paths (will freeze preview), and no crash would happen after lowering RAW video resolution. (I noticed this a year ago)
2- by suspending aewb task (LiveView hacks), I figured this out after some digging some days ago:

LiveView crashes after lowering RAW video because of ClrCalc task, ClrCalc is probably expecting returning some certain values and if that didn't happen it will lead the camera to a crash, there is a function which stops ClrCalc task but I didn't try yet, well, I remembered that suspending aewb task will make a call to stop ClrCalc task too, so I lowered RAW video resolution then called aewbSuspend, and the camera didn't crash.

So the camera crash when lowering RAW video resolution isn't related to preview task/s itself.

-Why this is helpful:
-Making preview experiments without worrying about crashes during the experiments
-Enables high FPS, e.g. I got 88 FPS (not new BTW) in 1736x338 5x3 14-bit lossless and it was continuous without corrupted frames, write speed up to ~50 MB/s thanks to suspending aewb task, also the camera was responsive (aewb is the most CPU hungry task, at high FPS it suck all of the CPU power).

-Only YUV LV path is frozen when lowering RAW resolution, YUV HD path is working (we already have code (e.g. fisheye) which redirect YUV HD path to YUV LV path).

-fully Patching mv720 mode into mv1080 is working with working preview :
Set cam to 1080p, adtg_gui "Modified from now on", set cam to 720p, lock registers, skip C0F26810/C0F26808 (related to EDMAC, overriding them will freeze the camera), switch to 1080p --> frozen LiveView, hmm let's suspend aewb task --> LiveView is working again (a little choppy) and RAW data is valid.

Doing the same experiment but by patching mv1080 mode into mv720, will have working YUV HD path and RAW data but both streams will have only 1736x696 from the top of frame working, the bottom part of frame will be frozen, something is restricting the amount of data, figuring this out (by comparing 720p vs 1080p configuration, and this time it's not the displayed registers in adtg_gui) will allow us to process more than 1736x1160 in LiveView in 1080p mode.

Tests were done on 700D.