Pre-recording for the raw_rec module?

[mk11174]

I was trying to film dogs catching Frizbee the other day, and was thinking, I wonder if there's a way to add a buffer record to Raw_Rec module, like have it record to buffer but not to file for the certain amount of frames the user chooses as a buffer, then when the action you want happens, you press the shutter and it records the buffer to video file? Might be a neat option to add to this module for wildlife or sports, especially if it will probably now save the camera settings you use in the video file as well. Or is this to much clutter for the module, maybe a separate module might be needed? I have been away from ML community for awhile and my coding skills are way to rusty to even know if this is possible or not. Thanks

[a1ex]

Pre-recording - indeed, would be a very nice feature. And it would provide a solid backend for your older experiments like the lightning trigger.

Currently, you have something similar in the silent module (the "end trigger" option)
- hold the shutter halfway
- when the action happens, release it
- it records 1-2 seconds of video (MLV/DNG) right before the shutter release

Problem: you are limited by how many frames fit in the memory. I have it updated locally to use both SRM and shoot memory buffers (part of an unrelated experiment), so I'll commit that for a quick workaround if it helps.

In any case, pre-recording shouldn't be very hard to implement in raw_rec. Basically it would be something like this:
- before pressing the button:
   - don't enqueue frames to the writing queue
   - after say half of the available memory gets used, discard the oldest frame and mark that slot as free

- after you press the button:
  - send all the frames to the writing queue (it will start saving frames at full speed)
  - keep recording normally

(I'm even tempted to try it, since I wanted to implement that for a long time)

[nikfreak]

Sounds like Panasonic's 4K Photo feature which they btw extended with a so called "post focus" feature:

[mk11174]

Oh yes, the frames limitation, I remember that, and every camera model would be different from what I remember.

And yeah, might help out with lightning trigger if I had a way to remote trigger, lol, good thing about lightning one, is I can hide in car when big bolts get close and the detection code will do the unsafe triggering for me. 

But with all these cell phone apps having these type of features, this addition to the DSLR camera would be great since there quality is way way better then a cell phone sensor.

Hopefully the frame limitation does not keep it from progressing if you decide to try to implement it, but I do understand that part.

And yes, very similar to End Trigger, only bad thing with End Trigger feature is you have to wait it out as each frame writes and goes through the previews and it doesn't include the camera settings in the file if I remember correctly, its been awhile since I was in testing mode, maybe I missed an update?

Thanks for the interest and reply! 

[a1ex]

Metadata is saved if you use MLV as file format, and previews aren't any slower than the ones from mlv_play.

Updated the silent picture module with SRM buffers, so it now uses all the available RAM.

[mk11174]

Cool, sounds interesting, I will check it out and see how it works from how I remember it working or compare to old end trigger before I copy new one over, just need to hope my VBOX still works and I remember how to do all the stuff I use to mess with to compile. 

As for preview, I would prefer no preview at all, just record buffer and wait for next shot, but wondering if it needs time to write anyway before you can record next shot, so maybe the preview is a must to slow the user down?

Am anxious to see if I get more frames with your new update though, Thanks!

Update: On 700D for silent pictures End Trigger, it went from 25 frames in buffer to 41! Nice update!

[a1ex]

Looks I've got the pre-recording mode working as well in raw_rec.

Bonus points: it merges cleanly with mlv_lite as well

[mk11174]

You got to be kidding me!!!! Very cool, will have to try this out for sure! Thanks! 

Update: pre-record works nicely, I like how it shows the amount of seconds capable of pre record, so if u pick 10 seconds,  it will show you while recording if its possible,  and if not, it will show how much you can get for the fps and resolution camera is set for.

I see its pre record time amount doubles pretty much with srm on, then if turned off, so that's obviously working good too.

At first I was confused cause when I started recording, I waited a bit, saw up top the pre record amount in seconds,  then I pressed shutter to save, but it started writing, then kept recording until I pressed shutter. I was thinking it was going to stop capturing and save all frames from pre buffer up to where I pressed shutter, eventually I figured out how u set it up and got use to it.

Pretty cool you got it coded so quickly.

I was using 700d for testing by the way.

[a1ex]

At first I was confused cause when I started recording, I waited a bit, saw up top the pre record amount in seconds,  then I pressed shutter to save, but it started writing, then kept recording until I pressed shutter. I was thinking it was going to stop capturing and save all frames from pre buffer up to where I pressed shutter, eventually I figured out how u set it up and got use to it.

Yeah, one of the harder steps was finding a help text that would fit in two lines, about 70 chars each. Can you suggest a better one?

[mk11174]

No, you did fine on help file, I was to anxious to try it, I didn't even know there was help text, lol. 

Yours makes perfect sense though.

[a1ex]

Shameless bump:

https://bitbucket.org/hudson/magic-lantern/pull-requests/728/pre-recording-feature-raw_rec/diff

[Lars Steenhoff]

so is it possible to use this ?

is it part of a nightly build?

Thanks

[Walter Schulz]

As long as a pull request's status is "open" it is not part of "main" branch (-> "unified") and main branch will be compiled to "official" nightly builds.
Therefore: Yes, you can use it if you compile it for yourself and no, it is not part of nightly build.

[a1ex]

Added to experimental builds.

[Lars Steenhoff]

Thanks for the update!

I just tested and works well on my canon 5d mk3
Super cool feature to have.

[janvkem]

Great feature! Excellent for unpredictable action. Am I impolite if I'd ask for a 10-bit capable version? 

[RenatoPhoto]

Oh yea! Yet another magic bullet to add to my arsenal.. I will have to test this soon..
Thanks A1ex mk11174!

[Frank7D]

Tested on 7D.

~ Used 2 sec delay
~ Video was 136 frames (0-135) but was reported as 873 frames by mlv_play (and by MlRawViewer). Is it possible it is counting the time from the first button push?
~ Last frame (135) has a pink band running across the very bottom of the image
~ The two anomalies do not make the feature unusable.

This is a wonderful feature. If it could be added to mlv with 10/12 bit recording it would be even better.

[Frank7D]

Here's the 136 frame raw file that is seen as 873 frames:
https://www.dropbox.com/s/rx1gnyd04m3serk/M17-1121.MLV?dl=0

[bouncyball]

Hehe nice one . Actually I have lot of MLV files (older/newer ones, recorded by mlv_rec not raw_rec) where real frame number is less than reported from the header(s). Differences like 2-3 frames are common. With multichunk MLVs even more (7-25 that I've seen myself). The files are all normal - no bad/corrupted frames nothing special but frame count is off. So I'm not sure about frame count until I index the MLV. However 737 frames difference is really strange .

Little bit OT... I also experienced the behavior when VIDF block size differs by 48 bytes from all other VIDF blocks. This always happening when VIDF is exactly before of after RTCI  (RTCI block exactly 48 bytes long). I guess it's related to EDMAC async transfers.

bb

[a1ex]

~ Video was 136 frames (0-135) but was reported as 873 frames by mlv_play (and by MlRawViewer). Is it possible it is counting the time from the first button push?

Thanks, fixed. The bug was present in the regular mlv_lite as well, but the difference wasn't that big (and went unnoticed since mlv_dump, and probably most other converters, only use the header counter for info purposes).

~ Last frame (135) has a pink band running across the very bottom of the image

Could not see it with mlv_dump; have a screenshot after conversion?

Little bit OT... I also experienced the behavior when VIDF block size differs by 48 bytes from all other VIDF blocks. This always happening when VIDF is exactly before of after RTCI  (RTCI block exactly 48 bytes long). I guess it's related to EDMAC async transfers.

Not sure how to reproduce this one. On the attached example, I checked with:

Code Select Expand


mlv_dump M17-1121.MLV -v | grep VIDF -A 2 | grep Size | uniq

Result:

Code Select Expand


    Size: 3629056


[bouncyball]

@a1ex

The assumption that size differs only by 48 bytes turned out to be wrong. Difference can vary. Here are the sample logs from various MLVs.

When using crop_rec there are no NULL blocks in MLV at all, Frame size also varies. ML version used to record these crops: magiclantern-crop3x.2017Jan13.5D3113.zip.

This somehow OT here b/c all of them recorded by mlv_rec (audio is on) not raw_rec/mlv_lite (to be inspected yet).

Here is excerpt from ordinary non crop MLV log recorded back in 2014:

Block: VIDF
  Offset: 0x0a628c60
    Size: 3629824
    Time: 2416.261000 ms
   Frame: #0048
    Crop: 152x132
     Pan: 146x133
   Space: 992
Block: RTCI
  Offset: 0x0a99f060
    Size: 48
    Time: 2436.508000 ms
     Date:        05.03.2017
     Time:        11:37:11 (GMT+0)
     Zone:        ''
     Day of week: 0
     Day of year: 63
     Daylight s.: 0
Block: VIDF
  Offset: 0x0a99f090
    Size: 3629264
    Time: 2458.010000 ms
   Frame: #0049
    Crop: 152x132
     Pan: 146x133
   Space: 432
Block: VIDF
  Offset: 0x0ad15260
    Size: 3629312
    Time: 2499.301000 ms
   Frame: #0050
    Crop: 152x132
     Pan: 146x133
   Space: 480
Block: VIDF
  Offset: 0x0b08b460
    Size: 3629824
    Time: 2541.135000 ms
   Frame: #0051
    Crop: 152x132
     Pan: 146x133
   Space: 992

Regards
bb

[a1ex]

Understood, so it's not related to mlv_lite.

Anyway, thanks for testing feedback. I've pushed a fix and now the frame counter from header matches the actual number of frames from the file. Merged into unified as well, since it seems pretty solid to me.

This development opened the door to another interesting feature - recording triggers using half-shutter. See this PR for details:

https://bitbucket.org/hudson/magic-lantern/pull-requests/819/half-shutter-triggers-for-raw-recording/diff

[Danne]

Wow. This is a major feature. Just tested and it works really good. There is a bunch of scenarios where this will be a game changer, nature filming for instance. Never miss a moment.
For anybody who wants to play with this put the mlv_lite.mo into your ML folder from the experimental section.
https://builds.magiclantern.fm/jenkins/job/rec-trigger/30/artifact/modules/mlv_lite/mlv_lite.mo

1 - In RAW video select Rec trigger and one of the options. Just tested Half-shut: start/pause and Half-shut: hold and both works. Briefly tested.
2 - Hit rec and then press half shutter either holding it down or simply press and release depending what is selected. When done hit rec again to end recording.

[Danne]

I really dig this rec_trigger. Did some more testing and it seems pretty solid already. Lacks 10/12-bit right now. The 1-frame shut is great to work with.
Tested working also with crop_rec module. Ran 1:1 (centred x5 zoom) solid working as well as 3x3 720p (1xwide) all three rec_trigger modes. Also tested with HDR filming enabled. Working.