Author Topic: ProcessTwoInTwoOutLosslessPath  (Read 129899 times)

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12317
  • Emergencies only
Re: ProcessTwoInTwoOutLosslessPath
« Reply #425 on: November 04, 2018, 08:59:57 AM »
I think we may have a encoder size/resolution  miss match on the 5d2/d4 ,

Encoder is always configured from full raw buffer size. Active area is just how these pixels are interpreted by ML or post-processing software; the lossless encoder does not know which pixels are active and which ones are not; it simply doesn't care about that. The lossless routine does not use the active area parameters in any way.

reddeercity

  • Contributor
  • Hero Member
  • *****
  • Posts: 2095
Re: ProcessTwoInTwoOutLosslessPath
« Reply #426 on: November 05, 2018, 05:13:53 AM »
Ok , understood -- Is there any way to see or log what the encoder is doing ?
Is it that the expected data is not where the encoder needs it to be ?
other words the address mem1 is not right ? 

ArcziPL

  • Contributor
  • Member
  • *****
  • Posts: 135
Re: ProcessTwoInTwoOutLosslessPath
« Reply #427 on: March 05, 2019, 11:47:20 PM »
lossless-1080-qemu-5D3-vs-6D.html
lossless-1080-qemu-5D3-vs-70D.html

Hi there. There's some progress on a lossless RAW compression on 70D. Not as far, as I'd wish but still.

The starting point was a recent revision of crop_rec_4k_mlv_snd, where the stubs and two image size registers were already set. However, the compressed image shown heavy deviations from a reference non-compressed one. It was similar to the initial distortions seen on 6D and 650D.

Uncompressed FRSP vs. compressed FRSP:
   


I've found two solutions leading to a working losslessly compressed FRSP ("Full-res" option in Silent Picture sub-menu) and losslessly compressed LV buffer ("Simple" option).


1. Overriding register 0xC0F373B4

Whetever it really does, a value of 0 in register 0xC0F373B4 results in a valid compressed DNG.
Code: [Select]
EngDrvOut(0xC0F373B4, 0);
Interesting fact: originally the camera sets this register to 0x11. A similar change of another register, also from a value 0x11 to 0 is needed for 6D and 650D.
Code: [Select]
    if (is_camera("6D", "*") ||
        is_camera("650D", "*"))
    {
        /* not sure what exactly these do, but they seem to be required to get correct image
         * taken from register log diffs: http://www.magiclantern.fm/forum/index.php?topic=18443.msg197987#msg197987 */
        EngDrvOut(0xC0F37610, 0);       /* 0x11 on 650D, 0 on all other D5 (not sure if needed) */


2. Second, independent solution is an overriding of register 0xC0F373F4

This one is really interesting.

Original log from the 70D:
Code: [Select]
[0xC0F373F4] <- 0x7FFF7FFF: ???
[0xC0F373F8] <- 0x1111BBBB: ???

The first register contains two 16-bit words, which seem to define horizontal and vertical boundaries of a slice, which should get somehow processed.

By lowering the least significant word ([0xC0F373F4] <- 0x7FFF1111) we get such a picture:


By lowering also the most significant word ([0xC0F373F4] <- 0x01000A00) it looks like this:


What it really is used for, I've no idea.

Changing any (or both) of the words to 0x0000 will give us a nice, valid, losslessly compressed DNG. E.g:

Code: [Select]
EngDrvOut(0xC0F373F4, 0x7FFF0000);
I wasn't able to find the meaning of the second mentioned register. There was no visible difference when changing it. Maybe it refers to another processing mode of the compressor module or maybe to a different write channel?

Interesting fact: similar values can be seen other cameras; here 5D3:
Code: [Select]
177 [0xC0F375B8] <- 0x7FFF7FFF: ???
178 [0xC0F375BC] <- 0x7FFF7FFF: ???
179 [0xC0F375C0] <- 0x7FFF7FFF: ???
180 [0xC0F375C4] <- 0x7FFF7FFF: ???
181 [0xC0F375C8] <- 0x7FFF7FFF: ???
182 [0xC0F375CC] <- 0x7FFF7FFF: ???
183 [0xC0F375D0] <- 0x7FFF0000: ???
184 [0xC0F375D4] <- 0x7FFF0000: ???
185 [0xC0F375D8] <- 0x7FFF7FFF: ???
186 [0xC0F375DC] <- 0x7FFF7FFF: ???
187 [0xC0F375E0] <- 0x7FFF7FFF: ???


The miniature picture embedded in DNG is unfortunately all black in the compressed files (despite being fine on the uncompressed FRSP). But I don't see it as an issue now, as it's same on 700D.


Now the sad part. Despite silent pictures are working very well with these changes, the compressed MLV still doesn't. The symptoms are still like in the past:

#dfort  tried installing your latest crop rec4k for 70D. after installing  i turn On crop rec and mlv lite. restart my camera. no buttons would work after that. i tried reinstalling your build 2 times but no luck
with your latest build i get this FRSP https://files.fm/u/3kc5sbt if i activate mlv lite, recording button nad trast button dont response

Describing it a bit more detailed:

If mlv_lite is activated and configured to 14-bit uncompressed, the camera will normally record MLV.

If being already in the movie mode, opening ML menu, changing bit-depth to 14-bit lossless: the ML menu will freeze immediately just after highlighting this option (without clicking SET button). No reaction to menu navigation, ML menu can't be closed. However, the cam still works, it can be switched to photo mode and will work normally showing "Raw detect error" for a while.

When being in photo mode, you can select 14-bit lossless in RAW video menu. Apparently there is no initialization of buffers/compressor executed at that point. When switching the camera to movie mode the buttons themself are working properly. ML console shows even "REC key pressed" (when pressed) and "Starting raw recording..." but the recording doesn't start. You can enter ML menu but it will freeze as soon as you change the tab to Movie. To unfreeze the menu: change mode to photo.


I have a feeling it will unfortunately not be enough to play with some more registers in lossless.c to fix the RAW video. I've "simulated the 650D" behaviour with wrongly configured compressor by applying wrong values on 700D.

Result: silent picuteres had distorted colors but the lossless MLV were still working (with distorted colors as well).

Could it rather be related to some buffer allocation, conflicting resources or waiting for flags/semaphores? How can it be further debugged?

1. What is exactly executed as soon as the 14bit lossless option is only highlighted in the ML menu when being in the video mode?
2. What and how to debug? I have already compiled with #define RAW_DEBUG but I don't know how to store the content of the console to a file O_o
3. How does compression differ in photo mode ("simple" option should be the LV buffer?) from movie mode?
4. Can these be conflicticting/wrong EDMAC resources in video mode? I am reluctant to play around with it on my own, as I have no idea how it works but it's clear for me, that a wrong change might results in "random" writes into any memory area.
5. Any other ideas...?
70D.112 | M50.102 | M.202

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12317
  • Emergencies only
Re: ProcessTwoInTwoOutLosslessPath
« Reply #428 on: March 06, 2019, 12:10:40 AM »
Very nice!

1. ML is attempting to compress the LiveView frame every 2 seconds, to find out the compression ratio. This happens in measure_compression_ratio -> forwarded to compress_task -> it compresses one frame as usual.

2. Hard to answer... I'd probably get some MMIO logs (io_trace_full branch), and... from there I'll probably end up staring at them.

3. In full-res mode, ML is operating outside LiveView (only the mirror is still up). In other words, all the image processing resources are available. In LiveView, some of them may be used. In movie mode, the configuration performed by Canon might be slightly different.

Need to read more carefully, but if the simple silent picture, saved as lossless DNG, works in movie mode, I see no reason why MLV compression wouldn't work. The former would be a lot easier to debug, too.

I'm starting to think we were really lucky on most DIGIC 5 models, where the resources used by lossless compression weren't in conflict with resources used by LiveView (well, there were a few conflicts that we knew how to solve). I had many attempts to get it working on DIGIC 4, but didn't document them, because... it just didn't work in LiveView.

4. EDMAC resources: will check. You could experiment with edmac.mo and see what it prints - screenshots, free channels, logs. These should help refreshing my memory. General idea: you can pick any unused channels (not active in the overview screen, and reported as "free" when you run the "Find free EDMAC channels" test). By default, the ones used for edmac_memcpy (i.e. uncompressed raw video) are reused, so I don't expect any trouble here.

Other ideas... not sure, maybe near the end of the week.

"The miniature picture embedded in DNG is unfortunately all black in the compressed files" -> expected; it's not implemented.

ArcziPL

  • Contributor
  • Member
  • *****
  • Posts: 135
Re: ProcessTwoInTwoOutLosslessPath
« Reply #429 on: March 06, 2019, 10:24:51 AM »
Need to read more carefully, but if the simple silent picture, saved as lossless DNG, works in movie mode, I see no reason why MLV compression wouldn't work

Hi Alex, that's a great point! I tried silent pictures in photo mode only, as the hint in the menu was showing that full-res silent pics are not working in movie mode. But you're fully right, simple silent pictures can be also done in movie mode.

So, here comes more:

1. Only silent.mo loaded: simple compressed DNG in movie mode works
2. Only silent.mo + mlv_rec.mo loaded, RAW video set to off: simple compressed DNG in movie mode works
3. Only silent.mo + mlv_rec.mo loaded, RAW video set to on: simple compressed DNG in movie mode works, raw video recording is also working (uncompressed of course)
4. Only silent.mo + mlv_lite.mo loaded, RAW video set to off: simple compressed DNG in movie mode works
5. Only silent.mo + mlv_lite.mo loaded, RAW video set to on, bit depth to 14bit uncompressed: simple compressed DNG in movie mode doesn't work!

In case 5 it stucks with "Preparing..." on the screen. The camera is still responsive. Just the text stays there until mode is changed to photo.


For a start I made some screenshots of EDMAC channels.

Photo mode:



Video mode:


I'm a total noob here but they seem for me nearly the same.

BTW: no in-cam screenshots for the last case, as trying to take them in movie mode results in a memory error. Just checked on 700D and it's same.

70D.112 | M50.102 | M.202

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12317
  • Emergencies only
Re: ProcessTwoInTwoOutLosslessPath
« Reply #430 on: March 06, 2019, 10:48:59 AM »
With mlv_lite's RAW Video enabled, the entire memory is preallocated during stanby. I'm seriously thinking to revert this change, just haven't managed to code anything in this direction. Been focusing on new ports + QEMU lately (as my main camera is defective anyway).

I forgot one important detail - in crop_rec_4k, the silent picture module will go out of LiveView to save images, even simple ones. That change was done for being able to show a preview, but... the image processing resources are also free in this "paused LV" mode; no wonder it worked :D

Try undoing out this change; will it still work? The goal is compressing one frame while LiveView is still running.

ArcziPL

  • Contributor
  • Member
  • *****
  • Posts: 135
Re: ProcessTwoInTwoOutLosslessPath
« Reply #431 on: March 06, 2019, 11:30:13 AM »
With mlv_lite's RAW Video enabled, the entire memory is preallocated during stanby.
Sounds not that "lite" at all. ;)

I forgot one important detail - in crop_rec_4k, the silent picture module will go out of LiveView to save images, even simple ones. That change was done for being able to show a preview, but... the image processing resources are also free in this "paused LV" mode; no wonder it worked :D

Try undoing out this change; will it still work? The goal is compressing one frame while LiveView is still running.
Changes in silent.c undone. Result:

silent.mo + mlv_rec loaded, RAW video on: simple silent pictures can be taken (both compressed and uncompressed)

silent.mo + mlv_lite loaded, RAW video on (14-bit selected): simple silent pictures can't be taken (both compressed and uncompressed) -> stuck at "Preparing..."

EDIT:
I've just double checked. Before reverting the change in silent.c, I was also not able to save uncompressed simple silent pictures with mlv_lite loaded and activated.
I also don't see any perceptual difference in behaviour between these two versions. Shall there be any? (to be sure it worked as expected, i.e. simple pictures are taken without pausing LV...)

EDIT #2:
700D behaves the same. The simple silent pictures don't work in movie mode with mlv_lite activated. However, lossless MLV videos do work... Looks like a non-related (?) issue.
70D.112 | M50.102 | M.202

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12317
  • Emergencies only
Re: ProcessTwoInTwoOutLosslessPath
« Reply #432 on: March 06, 2019, 02:14:04 PM »
You don't have to try saving pictures with mlv_lite active. It just won't work, because the silent picture module will not be able to allocate memory.

The goal is compressing one frame while Canon's LiveView is running (in both photo and movie mode).

You can tell whether the picture is saved outside LiveView or not, by looking at the screen. Does the image pause for a moment (with a short flicker), or does it stay real-time while the image is saved?

You could call the following from 'don't click me' (run_test in debug.c):
Code: [Select]
msleep(2000);
PauseLiveView();
ResumeLiveView();

You will notice a difference. The same "flicker" (or stuttering or whatever) happens on crop_rec_4k with simple silent picture - it pauses LiveView for a moment. On the "unified" codebase, a simple silent picture is saved right away, without pausing LiveView, so there will be no "flicker" or stuttering.

ArcziPL

  • Contributor
  • Member
  • *****
  • Posts: 135
Re: ProcessTwoInTwoOutLosslessPath
« Reply #433 on: March 06, 2019, 06:23:42 PM »
Thank you a1ex!

My previous post was garbage. The silent.mo didn't compile after my manually entered changes and I didn't notice immediately... There were also leftovers of the previous build on the card...

Code: [Select]
silent.c: In function 'silent_pic_take_lv':
silent.c:1250:14: error: too many arguments to function 'silent_pic_save_file'
         ok = silent_pic_save_file(&local_raw_info, 0);
              ^
silent.c:560:12: note: declared here
 static int silent_pic_save_file(struct raw_info * raw_info)
            ^
../../Makefile.filerules:31: recipe for target 'silent.o' failed
make[5]: *** [silent.o] Error 1

Now it's fixed, I can confirm there is no visible "flicker" when taking a simple silent photo anymore and no preview is shown afterwards, so we can be sure LV is not paused anymore.

Result with silent.mo + mlv_rec loaded, RAW video on (just in case it matters):

Simple silent pictures do work, both compressed and uncompressed, in photo and in video mode! The compressed ones look identical to uncompressed and are 48% smaller, so all as it should be.  8)

You could call the following from 'don't click me' (run_test in debug.c):
Thanks for reminding where to find it. I will definitely need it sooner or later.
70D.112 | M50.102 | M.202

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12317
  • Emergencies only
Re: ProcessTwoInTwoOutLosslessPath
« Reply #434 on: March 06, 2019, 07:40:24 PM »
Sounds good!

In this case, debugging should be "just" a matter of adding printf's in mlv_lite, possibly in compress_task, to find out where it gets stuck. Just a random thought - does that task even start? Most of ML code does not check whether a task could be successfully started; need to fix it.

Otherwise, lossless.c has its own share of debug messages - enable them with verbose=1 or verbose=2 (just hardcode the value). These are also useful, to see whether the encoder is called with the right arguments, whether it starts, whether it finishes, how long it takes and so on. These are very useful hints if things don't work.

I was afraid of something worse, i.e. one of these cases where only a MMIO trace could help - assuming it could get saved to card before the camera locked up completely. That's harder to debug, but usually not impossible.


ArcziPL

  • Contributor
  • Member
  • *****
  • Posts: 135
Re: ProcessTwoInTwoOutLosslessPath
« Reply #435 on: March 06, 2019, 10:45:32 PM »
Let me say it again: my previous post was garbage. >:(

Implementing a lot of printf() in
mlv_lite.c -> compress_task()
lossless.c -> lossless_compress_raw_rectangle()

let me find out, that the camera stucks at

Code: [Select]
lossless_compress_raw_rectangle():
    ...
    /* configure the processing modules */
    TTL_Prepare(TTL_ResLock, &TTL_Args);

I checked it closer to find out, that it stucks also in photo mode (sic!) when saving simple silent photos with L-DNG option (with the modified simple.c, so LV is not paused)  :-[

Previously I reported that it was working, because the file indeed got saved. Unfortunately this is what happens:
- entering LV
- pressing half-shutter
- lossless_compress_raw_rectangle() is started but stucks at the above mentioned line
- I did exit LV at that point...
- and only then the execution continued and file was finally saved.

If LV is not exited by user, you can't trigger second silent picture as the first one is still hanging and waiting.

Shit, so we're worse than thought.

I don't believe this log helps but posting anyway:
Camera start in photo mode -> LV entry -> simple silent photo (which stucks) -> exit LV -> card door open
Code: [Select]
Scanning modules...
Load modules...
  [i] load: SILENT.MO
Linking..
.text: 0
.data: 0
.config_vars: 0
.module_strings: 0
.text: 0
.data: 0
.config_vars: 0
.module_strings: 0
Register modules...
Load configs...
Init modules...
  [i] Init: 'silent'
  [i] prop 0x80000007
updating Movie Tweaks -> Movie Logging
  [i] prop 0x80000005
  [i] cbr 'CBR_CUSTOM_PICTURE_TAKING' -> 000BE738C
  [i] cbr 'CBR_SHOOT_TASK' -> 000BE8380
  [i] cbr 'CBR_VSYNC' -> 000BE685C
  [i] cbr 'CBR_DISPLAY_FILTER' -> 000BE66FC
Updating symbols...
  [i] 404: edmac_format_size 44d810
  [i] 404: edmac_format_size 44fba0
  [i] 404: edmac_format_size 459780
  [i] 404: edmac_format_size 45b3c0
  [i] 404: dual_iso_get_recovery_iso 4648c0
  [i] 404: dual_iso_is_active 4648c0
  [i] 404: auto_ettr_intervalometer_wait 46f7b0
  [i] 404: auto_ettr_intervalometer_warning 46f7b0
  [i] 404: auto_ettr_export_correction 47b880
  [i] 404: dual_iso_get_dr_improvement 488530
  [i] 404: dual_iso_get_recovery_iso 488530
  [i] 404: edmac_format_size 48d140
Modules loaded
Default raw buffer OK for 1984x761 (2.5MB).
raw update from shoot_task
LV raw buffer: b328000 (1984x761)
Skip left:144 right:8 top:28 bottom:0
Resolution changed: 0x0 -> 1984x761
Subsampling mode: 3B0Sx1B2S (5472x3648 1.62)
LV raw dimensions changed
raw update from shoot_task
LV raw buffer: b328000 (1984x761)
Skip left:144 right:8 top:28 bottom:0
Subsampling mode: 3B0Sx1B2S (5472x3648 1.62)
active area: x=144..1976, y=28..761
lv2raw sx:2565 sy:1529 tx:158 ty:36
raw2lv test: (-6,-6) - (725,485)
  should be: (0,0) - (720,480)
raw2bm test: (-6,-6) - (725,485)
  should be: (0,0) - (720,480)
bm2raw test: (158,36) - (1961,752)
  should be: (144,28) - (1976,761)
Black check 1/5: 2047…5.37, ref 2047…5.55, delta=0
Black check 2/5: 2047…5.21, ref 2047…5.55, delta=0
Black check 3/5: 2048…5.39, ref 2047…5.55, delta=1
Black check 4/5: 2047…5.86, ref 2047…5.55, delta=0
Black check 5/5: 2047…5.36, ref 2047…5.55, delta=0
Black check 1/5: 2047…5.78, ref 2047…5.55, delta=0
Black check 2/5: 2047…5.56, ref 2047…5.55, delta=0
Black check 3/5: 2047…5.79, ref 2047…5.55, delta=0
Black check 4/5: 2047…5.44, ref 2047…5.55, delta=0
Black check 5/5: 2047…5.68, ref 2047…5.55, delta=0
Black level: 2047
dynamic range: 10.70 EV (iso=200)
black=2047 white=10461
raw update from shoot_task
LV raw buffer: b328000 (1984x761)
Skip left:144 right:8 top:28 bottom:0
Subsampling mode: 3B0Sx1B2S (5472x3648 1.62)
Black check 1/5: 2047…5.80, ref 2047…5.64, delta=0
Black check 2/5: 2047…5.71, ref 2047…5.64, delta=0
Black check 3/5: 2047…5.40, ref 2047…5.64, delta=0
Black check 4/5: 2047…5.98, ref 2047…5.64, delta=0
Black check 5/5: 2047…5.56, ref 2047…5.64, delta=0
Black check 1/5: 2047…5.87, ref 2047…5.64, delta=0
Black check 2/5: 2047…5.36, ref 2047…5.64, delta=0
Black check 3/5: 2047…5.55, ref 2047…5.64, delta=0
Black check 4/5: 2047…5.44, ref 2047…5.64, delta=0
Black check 5/5: 2047…5.14, ref 2047…5.64, delta=0
dynamic range: 10.70 EV (iso=200)
black=2047 white=10461
srm_malloc_suite(1)...
[SRM] alloc all buffers
UILock: 00000000 -> 41000001 => 41000001
[SRM] buffer 5ca00064
[SRM] buffer 42000064
[SRM] buffer 44400064
UILock: 41000001 -> 41000000 => 41000000
[SRM] not using 5ca00064
srm_malloc_suite => ff5e8
Freeing LV raw buffer 4b328000.
ArcziPL: starting lossless_compress_raw_rectangle()
ArcziPL: lossless_compress_raw_rectangle, stage 1.
ArcziPL: lossless_compress_raw_rectangle, stage 2.
ArcziPL: lossless_compress_raw_rectangle, stage 3.
ArcziPL: lossless_compress_raw_rectangle, stage 4.
ArcziPL: lossless_compress_raw_rectangle, stage 5.
ArcziPL: lossless_compress_raw_rectangle, stage 6.
ArcziPL: lossless_compress_raw_rectangle, stage 7. <- printed just before TTL_Prepare(TTL_ResLock, &TTL_Args); the camera hangs here until I quit LV
ArcziPL: lossless_compress_raw_rectangle, stage 8. <- printed just after TTL_Prepare(TTL_ResLock, &TTL_Args);
ArcziPL: lossless_compress_raw_rectangle, stage 9.
ArcziPL: lossless_compress_raw_rectangle, stage 10.
ArcziPL: lossless_compress_raw_rectangle, stage 11.
ArcziPL: lossless_compress_raw_rectangle, stage 12.
[TTL] 1984x761 14bpp
 WR1: 46800064 EDMAC#17<45> (113428 2.0MB)
 WR2: 0 EDMAC#2<22>
 RD1: 4400080 EDMAC#25<1>
 RD2: 0 EDMAC#25<0>
ArcziPL: lossless_compress_raw_rectangle, stage 13.
ArcziPL: lossless_compress_raw_rectangle, stage 14.
ArcziPL: lossless_compress_raw_rectangle, stage 15.
ArcziPL: lossless_compress_raw_rectangle, stage 16.
ArcziPL: lossless_compress_raw_rectangle, stage 17.
[TTL] Elapsed time: 30483 us
ArcziPL: lossless_compress_raw_rectangle, stage 18.
ArcziPL: lossless_compress_raw_rectangle, stage 19.
[TTL] Output size : 1.3MB (51.25%)
ArcziPL: lossless_compress_raw_rectangle, stage 20.
srm_free_suite(ff5e8)
[SRM] free all buffers
UILock: 41000000 -> 41000000 => 41000000
Save configs...
70D.112 | M50.102 | M.202

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12317
  • Emergencies only
Re: ProcessTwoInTwoOutLosslessPath
« Reply #436 on: March 06, 2019, 11:23:55 PM »
Alright - it locks up while trying to get exclusive access to some image processing resources. This is because something else from Canon's LiveView is using some of them.

I'd say let's find out what resources are causing the lockup (by trial and error, commenting out some of them to narrow down). Once that is done, we can attempt to find what other code attempts to lock the same resources, and maybe - if lucky - we can find a way to disable it somehow.

ArcziPL

  • Contributor
  • Member
  • *****
  • Posts: 135
Re: ProcessTwoInTwoOutLosslessPath
« Reply #437 on: March 07, 2019, 10:13:28 AM »
I'd say let's find out what resources are causing the lockup (by trial and error, commenting out some of them to narrow down)

I guess this would mean removing some lines from
Code: [Select]
    else if (is_camera("5D3", "*") || is_camera("6D", "*") || is_camera("70D", "*"))
    {
        uint32_t resources[] = {
            0x00000 | edmac_channel_to_index(edmac_write_chan),
            0x10000 | edmac_channel_to_index(edmac_read_chan),
            0x30001,    /* Read connection 1 (uncompressed input) */
            0x2002d,    /* Write connection 45 (compressed output) */
          //0x20016,    /* Write connection 22 (for WR2 - not used) */
            0x50034,
            0x5002d,
            0x50010,
            0x90001,
            0x230000,
            0x160000,
            0x260000,
            0x260001,
            0x260002,
            0x260003,
        };

Is it right?
70D.112 | M50.102 | M.202

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12317
  • Emergencies only
Re: ProcessTwoInTwoOutLosslessPath
« Reply #438 on: March 07, 2019, 12:09:15 PM »
Yes, that's right. If you comment out all of them, it should go past TTL_Prepare, but... encoding is not going to work.

Besides, if you test this outside LiveView, it may work even without locking some of the resources. For example, IIRC EDMAC channels/connections don't *have* to be locked in order to use them; the locks are just a way to make sure each resource will be used by one task at a time. However, other resources seem to require locking; these routines will also perform some changes to clock enable bits (messages about ClockSave in the log file).

If lucky, some resources might be always locked during LiveView, but they might be used only during mode changes or autofocus or something like that. In this case, encoding might work with these entries commented out.

ArcziPL

  • Contributor
  • Member
  • *****
  • Posts: 135
Re: ProcessTwoInTwoOutLosslessPath
« Reply #439 on: March 07, 2019, 09:28:28 PM »
Hell yeah, first 14-bit lossless MLV from 70D! 8)



It's amazing what you know about and can do with closed internals of these cams!

The one to be commented out is
Code: [Select]
//0x5002d,
If too much was commented out (all but first four lines: EDMAC channels and read/write connections) it was still stucking at the same point and additionally locking the camera. LV couldn't be exited. After changing mode between photo/video it thrown Err80.

With only this one line removed I haven't noticed any side effects yet but wasn't focusing on it. I'll test it in the next days/weeks, report back and submit a pull request if all seems to be fine.
70D.112 | M50.102 | M.202

theBilalFakhouri

  • Contributor
  • Senior
  • *****
  • Posts: 356
Re: ProcessTwoInTwoOutLosslessPath
« Reply #440 on: March 07, 2019, 09:35:57 PM »
This is the right time to switch to 70D  :D
Great work!
700D 1.1.5 | no more ISOless LV err 8

Danne

  • Contributor
  • Hero Member
  • *****
  • Posts: 5997
Re: ProcessTwoInTwoOutLosslessPath
« Reply #441 on: March 07, 2019, 09:38:09 PM »
Thumbs up! Great job.

buro341

  • New to the forum
  • *
  • Posts: 5
Re: ProcessTwoInTwoOutLosslessPath
« Reply #442 on: April 11, 2019, 09:00:26 PM »
awesome, is there much difference between ML for 70D and 77D?

Walter Schulz

  • Contributor
  • Hero Member
  • *****
  • Posts: 6898
Re: ProcessTwoInTwoOutLosslessPath
« Reply #443 on: April 11, 2019, 09:02:20 PM »
Yes, there is a working ML for 70D but not for 77D.
Photogs and videographers: Assist in proof reading upcoming in-camera help!. Your input is wanted and needed!

2blackbar

  • Senior
  • ****
  • Posts: 262
Re: ProcessTwoInTwoOutLosslessPath
« Reply #444 on: June 25, 2019, 05:18:38 PM »
Great work ! ArcziPL Do You think 5D2 needs some code to be commented out to prevent camera lockup like 70D ?
Hell yeah, first 14-bit lossless MLV from 70D! 8)



It's amazing what you know about and can do with closed internals of these cams!

The one to be commented out is
Code: [Select]
//0x5002d,
If too much was commented out (all but first four lines: EDMAC channels and read/write connections) it was still stucking at the same point and additionally locking the camera. LV couldn't be exited. After changing mode between photo/video it thrown Err80.

With only this one line removed I haven't noticed any side effects yet but wasn't focusing on it. I'll test it in the next days/weeks, report back and submit a pull request if all seems to be fine.