crop_rec on steroids: 3K, 4K, 1080p48, full-resolution LiveView

[a1ex]

Thanks Danne - taking a still photo (CR2) in movie mode was the key to reproducing the issue.

With silent pics (silent.mo):
- start the camera in movie mode, make sure silent pics are disabled
- take a still photo (CR2, not JPG)
- enable silent pics (simple, lossless DNG)
- take 2 silent pics using half-shutter
- the second one will trigger the error in about 90% of cases

The error does not happen if the above sequence is performed in photo mode.

With raw recording (mlv_lite.mo):
- start the camera in movie mode (any, even plain 1080p)
- take a still photo (CR2, not JPG)
- enable raw video if it isn't already, with lossless compression
- start recording => kaboom

Was the second sequence working in any of the previous builds? (back to April 1st 3rd - older builds here)

[Danne]

Reproduced the second sequence (raw recording opening up straight into movie mode) with the latest build.

Then jumped to test april 10th build and the same test is working without errors (lossless 14-bit 1920x1080) opening up straight into movie mode. Will try and see what build starts to fail.
Did the test wrong. Let me check again.

Ok, reproduced the error also on april 10th build.

[a1ex]

Apr10 fails here after taking a CR2.

[Danne]

Yes, sorry, false positive, was doing the test wrongly. Updated my post. Only happens with lossless. Regular 14bits are dandy even after firing of a pre CR2 file...

[budafilms]

August 20 fail in Emergency when have set 3,5K Crop, 12 bit lossless, and press rec without 5x zoom.
THis expected? Should work without zoom.

Battery out solve the issue.

Mlv play work very good in 14-12 bits lossless.

[Lars Steenhoff]

I'm looking for a build that has these functions:

MLV crop 3x
MLV sound
10/12/14 bit lossless
lossless in camera playback
I don't need the 3k, 4k. 1080 for all is good.

Is there such a build?

[Markus]

I'm looking for a build that has these functions:

MLV crop 3x
MLV sound
10/12/14 bit lossless
lossless in camera playback
I don't need the 3k, 4k. 1080 for all is good.

Is there such a build?

No, the closest one is the crop rec + 10-12bit (without compression) build that was up on experiments until recently. It included sound module.

[ludzik3d]

Short summary of latest updates:

- lossless compression for 700D and EOS M, thanks ErwinH and dfort
- included the 3x3 50/60p for EOS M and 700D from the original crop_rec, thanks rbrune and dfort
- compressed playback (mlv_play) also working on 5D3 1.2.3 (g3gg0 did the initial implementation on 1.1.3)
- lua_fix included ( cc @garry23 )
- dynamic my menu included (already found a couple of bugs)
- full-res silent picture automation (still a bit rough, but it's one tiny step towards the "5D Mark III Mirrorless Edition")
- lossless DNG playback (with pic_view/file_man)

So Eos M could also record in 24fps 3x3 in full-resolution liveview without h-264 now?

Im not sure, is compressed dnd in 700D and Eos M are only in 14 bit or it could by also in 10 Bit with compression ?

[Lars Steenhoff]

Would be happy with that, do you still have the build somewhere? for 123 5d mk3 ?

[mr.smith]

2017-08-22 build,

How long can I shoot with 4096x2560@24p ?

I am considering to install the latest build.

[nikfreak]

why just consider and not try yourself? 5k even at 60fps no problem because the 1st post does exactly contain that info. 

* 4096x2560 @ 12.5p (1:1 crop) - continuous*) at 8 FPS

24p should be a second - maybe!?

[mr.smith]

thanks for telling. but only a second? really? a second? at 24p?

why just consider and not try yourself? 5k even at 60fps no problem because the 1st post does exactly contain that info. 

24p should be a second - maybe!?

[nikfreak]

i recommend the calculator:

http://rawcalculator.bitballoon.com/calculator_desktop

[extremelypoorfilmaker]

Nikfreak, you are being so super nice! As soon as I have a free moment I will try to do some testing using an external monitor while shooting "4K" in my mind, using an external monitor should help while shooting with frozen liveview.. but again, I don't trust what my mind thinks

[a1ex]

Took a closer look at the recent error messages. These problems were there in previous builds as well; they were just silent (in other words, I was unaware of the issues). Most of them appeared when estimating the compression ratio during standby - in this case, I've been calling the lossless compression routine in the so-called "dummy mode" (without image output - just to have it report the compression ratio). Turns out, when the planets were aligned, this method resulted in some left-overs on the EDMAC write channel (the one that writes the compressed output in memory); as a result, the first frame was sometimes invalid.

As I couldn't figure out how to clean the EDMAC channel, the easiest way was to avoid calling the lossless compression routines in "dummy mode" - that is, always provide a valid output buffer. If I go that far, I might as well refactor the memory management, so the raw recording buffers are always allocated during standby (and freed when exiting LiveView or when going to photo mode). It was a bit of work, but that's what I did.

You may ask, why?

Allocating memory for video buffers is slow (takes a few seconds to allocate the entire shooting memory) and complicated (see exmem.c and RscMgr thread). So, having the memory allocated in advance means recording can start right away (already discussed a few pages earlier).

By contrast, creating the MLV file is very fast, so there's very little to gain by opening it in advance.

Minor: the status bar also shows how many buffers we have allocated, and their size.

Regarding 1080p48 - it was pushed a bit over the safe limit, so I've reduced its resolution to 1040. You still have the option to go back to 1080 in the crop_rec submenu; however, you'll get a lot of errors. With some fiddling, you can probably get 1060 (e.g. set Target YRES to 1060 and Delta HEAD3 to -20), but I wouldn't trust it yet.

Also found a way to sync the H.264 proxy with the raw stream - by making the extra frames black. The first non-black frame from H.264 will match the first frame from MLV. Easy.

I've also integrated the thread-safety annotations (using clang) and fine-tuned the dynamic menus to make them halfway usable.

Overall, the build is still too buggy for my taste, but at least it's a small step forward.

[Kharak]

Tremendous work, A1ex!

May we call it MLV 3.0 ?

[Danne]

poor man's sync between RAW and H.264 proxy

 
I like it. Will experiment with some automation scripts around this.

[Licaon_Kter]

Trying to build EOS M (toolchain 6.3.1-q2-2017) commit cffeb48 yields this error:

Code: [Select]

mlv_rec.c:4183:5: error: implicit declaration of function 'raw_force_aspect_ratio_1to1' [-Werror=implicit-function-declaration]
     raw_force_aspect_ratio_1to1();

The *official-experimental build* has this too: https://builds.magiclantern.fm/jenkins/job/crop_rec_4k/42/consoleText

/LE: Fixed https://bitbucket.org/hudson/magic-lantern/pull-requests/851/

[dfort]

Nice find @Licaon_Kter -- so does that mean we can have a choice of the latest mlv_lite developments or the legacy mlv_rec with mlv_snd in the same build? I want it!

However -- not all is rainbows and unicorns in EOSM and 700D land.

The 700D saved a crash log and made a core dump when recording 10-bit lossless:

Code: [Select]

[2] raw_rec_task: NULL PTR (80c3e100,e1a00000)
pc=    c288 lr=    c288 stack=1abdd0+0x1000
entry=ac2fac(0)
e1a00000 e59ff014 e59ff014 e59ff014
e59ff014 e1a00000 e59ff010 e59ff010

Magic Lantern version : crop_rec_4k.2017Aug26.700D114
Mercurial changeset   : cffeb4898221 (crop_rec_4k) tip
Built on 2017-08-26 21:27:15 UTC by jenkins@nightly.
Free Memory  : 128K + 2524K
The EOSM didn't save a core dump but created this assert log when recording 10-bit lossless with H.264 Proxy (the only way to get mv1080 on the M):

Code: [Select]

ML ASSERT:
slots[slot_index].size < max_frame_size
at mlv_lite.c:3344 (raw_video_rec_task), task raw_rec_task
lv:1 mode:3

raw_rec_task stack: 1ded20 [1dede0-1ddde0]
0x0009EBBC @ ab9178:1ded50
0x0009E548 @ 9ec1c:1ded20

Magic Lantern version : crop_rec_4k.2017Aug26.EOSM202
Mercurial changeset   : cffeb4898221 (crop_rec_4k) tip
Built on 2017-08-26 21:27:48 UTC by jenkins@nightly.
Free Memory  : 148K + 2722K

Logs and core dump uploaded to dropbox.

[Licaon_Kter]

Had some issues too, indeed, too bad I deleted the logs/dmp by mistake though.

[Danne]

Aren´t mlv_rec and mlv_snd deliberately out of the equation on these builds? Wouldn´t mind them getting back of course  .

Just recorded a few takes with H.264 proxy and 14bit compressed. The black frames seems to work as advertised which is friggin´ great. Back to script automation. Start by matching feature:
MLV:
Time:        08:29:45 (GMT+0)
H.264:
Create Date                     : 2017:08:27 08:29:43

Convert(imagemagick) will determine what is black or not:

Code: [Select]

convert test.jpg -colorspace hsb -resize 1x1 test.txt# ImageMagick pixel enumeration: 1,1,255,hsb
0,0: ( 77,220,  1)  #4DDC01  hsb(30.1915%,86.2547%,0.546273%)
Black 0.546273%
# ImageMagick pixel enumeration: 1,1,255,hsb
0,0: ( 25, 86, 96)  #195660  hsb(9.99924%,33.7636%,37.4884%)
not black 37.4884%

Maybe someone knows how to read pixel brightness from ffmpeg by the way? Won't be needing convert if so.
*Found something interesting here myself:
http://www.ffmpeg.org/ffmpeg-filters.html#blackdetect

After some tweaking from this:
https://stackoverflow.com/questions/18722747/can-you-put-the-result-of-a-blackdetect-filter-in-a-textfile-using-ffmpeg

Code: [Select]

ffmpeg -i IMG_7621.MOV -vf "blackdetect=d=0.5:pix_th=0.01" -an -f null -Yields:

Code: [Select]

[blackdetect @ 0x7f8b08d1d600] black_start:0 black_end:1.37637 black_duration:1.37637Output blackframes longer than 0.5 seconds and pixel threshold set to 0.01. If set to 0.00 it won´t work.
Next find a way to interpret numbers to frames and search only beginning of the file to save time.
Probably just cut off 0-1.37637 and export this example file to a new MOV should do the trick. Will check some more into this tonight.

[Lars Steenhoff]

@Danne,  I dont know if its deliberate that mlv_rec and mlv_snd don't compile?
when I make a build they dont compile because of an error not because they are excluded as far as I can see.

[Lars Steenhoff]

I just did a build from the latest crop_rec4k with the aspect ratio fix from @Licaon_Kter.
All the modules compiled and I installed it on the 5d mk3 1.13.

mlv rec and mlv sound works
mlv rec + mlv crop + mlv sound works ( tested only 1080 )
mlv crop + mlv rec works
mlv crop + mlv lite works
mlv lite works

mlv lite + mlv snd does not work, but we know that.
mlv play does not work in combination with mlv_rec, check the screenshot for the error



Very exciting progress!

[12georgiadis]

Also found a way to sync the H.264 proxy with the raw stream - by making the extra frames black. The first non-black frame from H.264 will match the first frame from MLV. Easy.

Overall, the build is still too buggy for my taste, but at least it's a small step forward.

Thank you Alex, h264 proxy is a very good and complete feature now ! I use it to playback easily (of course) but also to use and sync the sound from H264 proxy with the raw stream. It solves temporarily the lack of mlv sound with comressed raw.

[12georgiadis]

Aren´t mlv_rec and mlv_snd deliberately out of the equation on these builds? Wouldn´t mind them getting back of course  .

Just recorded a few takes with H.264 proxy and 14bit compressed. The black frames seems to work as advertised which is friggin´ great. Back to script automation. Start by matching feature:
MLV:
Time:        08:29:45 (GMT+0)
H.264:
Create Date                     : 2017:08:27 08:29:43

Convert(imagemagick) will determine what is black or not:

Code: [Select]

convert test.jpg -colorspace hsb -resize 1x1 test.txt# ImageMagick pixel enumeration: 1,1,255,hsb
0,0: ( 77,220,  1)  #4DDC01  hsb(30.1915%,86.2547%,0.546273%)
Black 0.546273%
# ImageMagick pixel enumeration: 1,1,255,hsb
0,0: ( 25, 86, 96)  #195660  hsb(9.99924%,33.7636%,37.4884%)
not black 37.4884%

Maybe someone knows how to read pixel brightness from ffmpeg by the way? Won't be needing convert if so.
*Found something interesting here myself:
http://www.ffmpeg.org/ffmpeg-filters.html#blackdetect

After some tweaking from this:
https://stackoverflow.com/questions/18722747/can-you-put-the-result-of-a-blackdetect-filter-in-a-textfile-using-ffmpeg

Code: [Select]

ffmpeg -i IMG_7621.MOV -vf "blackdetect=d=0.5:pix_th=0.01" -an -f null -Yields:

Code: [Select]

[blackdetect @ 0x7f8b08d1d600] black_start:0 black_end:1.37637 black_duration:1.37637Output blackframes longer than 0.5 seconds and pixel threshold set to 0.01. If set to 0.00 it won´t work.
Next find a way to interpret numbers to frames and search only beginning of the file to save time.
Probably just cut off 0-1.37637 and export this example file to a new MOV should do the trick. Will check some more into this tonight.

Great Danne !