Author Topic: REC COMMAND via the HDMI trigger - Atomos (Read 67847 times)

kfprod · « **Reply #25 on:** June 09, 2014, 05:59:47 PM »

While looking for how to do this I found a thread where this was discussed previously (2014-01-19) "With this, one can handle easily the case where you want to record both raw and h264, for example." Can't really tell if anything was implemented though

https://bitbucket.org/hudson/magic-lantern/pull-request/336/1100d-fix-recording-macros/diff

dmilligan · « **Reply #26 on:** June 09, 2014, 06:39:39 PM »

that's simply about handling the status of "recording"/"not recording", not the actual recording itself

Susteren · « **Reply #27 on:** June 11, 2014, 10:48:36 AM »

Any updates?

a1ex · « **Reply #28 on:** June 11, 2014, 10:57:09 AM »

Yeah, here: http://www.magiclantern.fm/forum/index.php?topic=934

kfprod · « **Reply #29 on:** June 11, 2014, 12:01:34 PM »

I have a fairly good idea about how to handle the separation of raw/H.264 files to different cards and to listen for the trigger but I can't for the life of me figure out where the H.264 gets turned off and taken over by the RAW recorder.

RECORDING_RAW takes over RECORDING_H264 somewhere, is it recording / recording custom that can't be active at the same time? (edit)

Any pointers appreciated, I’m such a noob.

a1ex · « **Reply #30 on:** June 11, 2014, 01:45:38 PM »

In the key handler from the raw recorder.

Key events get sent by Canon firmware (or maybe faked by ML), and they are intercepted in the GUI task (gui.c) by ML key handlers. These handlers will decide whether the event is interesting for them or not (so they might do some action when they receive a certain event), and they also decide whether the event should be sent to the next handlers (the last one being Canon's own button handler). To allow an event to be handled by other routines (including Canon's), a key handler should return 1; to block it, should return 0. The order in which ML key handlers are called is hardcoded in gui-common.c.

kfprod · « **Reply #31 on:** June 14, 2014, 08:57:37 PM »

Thank you,

So I actually managed to get the camera to write both RAW and H264 to different cards. Unfortunately the camera freezes after about 12 seconds when using these settings and I don't understand why. It's not about the screen size that gets put through the raw module: I tried both 640x360 and 1920x1080 but no matter the setting the camera freezes.

What I've tried is:

Code: [Select]

    if (rec_key_pressed)
    {
        switch(raw_recording_state)
        {
            case RAW_IDLE:
            case RAW_RECORDING:
	    raw_start_stop(0,0);
	    return 1; //Lets the camera carry on with what it was doing.

What could be the problem, not enough computing power?

I used

Code: [Select]

( filename[0] = 'A'; ) to make sure the RAW always goes to the CF Card and I'm setting the H264 to go to the SD through the normal Canon menu.

Still looking for either the solution to write the H264 to the SD card and the RAW to the CF or to find the HDMI REC trigger so the Atomos can auto start recording (and forget about the H264).

Also added seconds to the file name for my own module, that gives a smaller chance of same file names when shooting 2 cameras. Would be better to have a hex file name structure as RED has. When using MLV Mystic and RAW Magic the programs crash if the file names are the same. I'll write a separate post about that.

kfprod · « **Reply #32 on:** June 16, 2014, 04:14:26 PM »

Possible breakthrough:

I found this string
ff1936c8 PROP_TIMECODE_HDMI_REC_COMMAND (%d)

(Also:)
ff1f18b4 PROP_TIMECODE_HDMI_REC_COMMAND:%ld
ff75bd50 DlgMnTimeCodeHdmi.c IDC_DPM_REC_COMMAND
ff75bf48 DlgMnTimeCode.c PROP_TIMECODE_HDMI_REC_COMMAND

In ROM1.BIN.strings converted from the ROM1.BIN of the 5d3.123 release.

Can someone please help me turn this into a function that I can trigger?

Thank you for the tutorial a1ex you should make it a sticky: http://www.magiclantern.fm/forum/index.php?topic=12177.0

kfprod · « **Reply #33 on:** June 16, 2014, 05:13:55 PM »

Something like:
prop_request_change(PROP_TIMECODE_HDMI_REC_COMMAND, &v, 1);

I'd love to give it a go... Only this comment scares me off.
/** Properties are persistent (saved in NVRAM) => a mistake can cause permanent damage. Undefine this for new ports. */
/** The 5D3 port is young, but... let's give it a try! **/
#define CONFIG_PROP_REQUEST_CHANGE

Please help!!

a1ex · « **Reply #34 on:** June 16, 2014, 07:45:02 PM »

Nice find. These seem to be from some GUI code which I don't quite understand. However, if you look at ff75be7c, you can extract some property numbers (easier if you have a decompiler):

Code: [Select]

0x8003002C PROP_HDMI_PHYSICAL_CONNECT
0x80040056 PROP_TIMECODE_HDMI_OUTPUT
0x80040057 PROP_TIMECODE_HDMI_REC_COMMAND

This code seems to react to these properties, but it doesn't look like a prop handler; instead, it's in the middle of Set***ToWinSystem (which I believe it's used to print GUI symbols).

Let's see how Canon calls it (look for 80040057 => ff19d8ac). The code is roughly like this:

Code: [Select]

uint32_t aux = arg0;
prop_request_change(0x80040057, &aux, 4);

The above code is called from CtrlSrv task I think (where most Canon GUI stuff happens) when some GUICMD event code is 0xB IDC_DPM_REC_COMMAND (these are not our usual button codes, but one layer above that). The REC button is defined as 0x1E in gui.h, which gives a GUICMD code = 0x1000000f (at ff1a7ddc+8+0x1e*4). So, I'm not exactly sure what triggers it. Anyway, the argument (arg0) seems to be *0xFF9E898C, which is 0.

It's unlikely that our property would be a permanent setting in NVRAM (it looks more like something that triggers an action), so I'd say it's worth trying (but that's not a guarantee). If g3gg0 confirms my analysis, it's probably safe.

I've tried the following code on my 5D3 (don't click me), without a recorder attached, and the property handler did not trigger.

Code: [Select]

PROP_HANDLER(0x80040057)
{
    NotifyBox(1000, "%d ", buf[0]);
}

static void run_test()
{
    msleep(1000);
    uint32_t aux = 0;
    prop_request_change(0x80040057, &aux, 4);
    beep();
}

mixmastermike · « **Reply #35 on:** June 16, 2014, 09:21:53 PM »

Really encouraging, thanks to @ kfprod and @ a1ex for the efforts being made

Chucho · « **Reply #36 on:** June 17, 2014, 05:43:31 AM »

A couple of weeks ago I was playing with the HDMI functions on the 70d. The 70d has PROP_TIMECODE_HDMI_REC_COMMAND (0xff19f6d8) PROP_TIMECODE_HDMI_OUTPUT (0xff19f5b4) PROP_DUAL_OUTPUT (0xff19b6c8) (mirroring) and PROR_HDMI_FLAME_RATE (0xff19b6a8) (HDMI frame rate). The 70d is missing the GUI function that display the HDMI menu but with some simple code you can achieve the desire outcome. Maybe debuging the TIMECODE HDMI rec command will give you some usefull information. Debug(GUI, 3, "PROP_TIMECODE_HDMI_REC_COMMAND (%d)", r4 + 0x4)); in cause of the 70d r4 is 0x98E30.

kfprod · « **Reply #37 on:** June 17, 2014, 09:40:05 AM »

I love that the firmware coming out of Japan has FLAME_RATE instead of FRAME_RATE

Lock and LoLL!!!

It would be good to hear from g3gg0 if he confirms a1ex's analysis that it should be safe to play around with and I'll do that.

A1ex is that going through and checking all the different states of PROP_TIMECODE_HDMI_REC_COMMAND? In prop_request_change(0x80040057, &aux, 4); would it make sense to step through &aux and 0-4 or does the test function do that?

Could also be that because you don't have anything connected to the hdmi port it just won't trigger, maybe just putting a cable in to a TV (or at least just putting a cable in) would do the job and give you that triggered NotifyBox?

Susteren · « **Reply #38 on:** June 17, 2014, 07:37:46 PM »

Great guys, keep on goin'!

actingnurse · « **Reply #39 on:** June 18, 2014, 08:49:47 AM »

This is awesome! I'm putting the purchase of the Atomos Ninja Blade on hold for a few until I see what develops here... If we could get realtime playback with audio by shooting the H264 file to the SD slot then COUNT ME IN!!! Although, the blade still has the benefit of recording 10bit footage (not as good as ML's 14bit, but better than the H264's 8bit) as a backup in case of card or file corruption through ML or card issues.... Keep up the good work! Ya'll rock!

kfprod · « **Reply #40 on:** June 18, 2014, 09:38:54 AM »

It's not 10 bit but 8 bit, that is what the Canon camera HDMI outputs. It is however 422 instead of 420 and it has never been through an h264 codec so that's good.

But if someone does get the h264 simultaneous recording to work without problem I'd suggest buying the SmallHD dp7 instead of the Atomos though, it's a better monitor and you'll only use the h264 files as proxies anyway. Unless you do a lot of interviews where you can't shoot raw, then the benefits of the recorder will be worth it.

kfprod · « **Reply #41 on:** June 19, 2014, 01:26:34 AM »

So I've tried this with the recorder attached but as you say it doesn't trigger.

Code: [Select]

PROP_HANDLER(0x80040057)
{
    NotifyBox(1000, "%d ", buf[0]);
}

static void run_test()
{
    msleep(1000);
    uint32_t aux = 0;
    prop_request_change(0x80040057, &aux, 4);
    beep();
}

What about the others

ff1f18b4 PROP_TIMECODE_HDMI_REC_COMMAND:%ld
ff75bd50 DlgMnTimeCodeHdmi.c IDC_DPM_REC_COMMAND
ff75bf48 DlgMnTimeCode.c PROP_TIMECODE_HDMI_REC_COMMAND

Could any of them be used? I don't have a decompiler set up unfortunately. Most of this is really over my head

I tried a couple of other ways to do the raw to the CF card and h264 to the SD but it always crashes after a while.

kfprod · « **Reply #42 on:** June 29, 2014, 04:15:48 PM »

Back from a job and doing some tests again. When I do

prop_request_change(0x80040057, &aux, 0);

I get a red box with PROP_LEN(80040057) and

ML ASSERT:
PROP_LEN(80040057) = 0
at ../../src/property.c:325 (prop_request_change), task GuiMainTask
lv:1 mode:3

This is not the same as earlier. Perhaps it's only the error handling code that has changed?

I'm still wondering if it would be worth it to try and do the same test with these values (converted to 0x800...) but I can't decompile ff1f18b4 -> 0x800...

ff1f18b4 PROP_TIMECODE_HDMI_REC_COMMAND:%ld
ff75bd50 DlgMnTimeCodeHdmi.c IDC_DPM_REC_COMMAND
ff75bf48 DlgMnTimeCode.c PROP_TIMECODE_HDMI_REC_COMMAND

Susteren · « **Reply #43 on:** June 29, 2014, 11:44:04 PM »

So you got an error, the h264 didn't start recording?

a1ex · « **Reply #44 on:** June 30, 2014, 08:42:23 AM »

To avoid this error, place a PROP_HANDLER (even if it's empty). It's a safeguard.

kfprod · « **Reply #45 on:** June 30, 2014, 05:00:21 PM »

I did put in the PROP_HANDLER with a Notify Box, it was there all the time..

Lars Steenhoff · « **Reply #46 on:** July 03, 2014, 05:59:08 PM »

Great that this is looked at, it is the missing link for a good RAW / Playback workflow, if no code can be found, perhaps atomos could give a clue about the command.

kfprod · « **Reply #47 on:** August 07, 2014, 11:22:39 AM »

This may help: Atomos have released their HDMI START/STOP TRIGGER & TIMECODE standard as open source. The Atomos protocol for HDMI is available for free from www.atomos.com/hdmi-protocol

I received the PDF by just filling in the form. Unfortunately "Neither the whole nor any part of the information contained in, nor the product described in, this document may be adapted or reproduced in any material form except with the written permission..."

So sign up there if you want to have a look and you'll get it within 24hrs.

On another note the Atomos can trigger by just listening to if the camera outputs a REC RUN hdmi time code (not using the REC COMMAND) so if we could just make the camera output that instead that would also work...

Regarding the other part of what I've been testing, writing h264 to the SD card and RAW to the CF card, there is something that happens after 12 seconds and the camera crashes. Is that the processor that's overused? Perhaps someone could look into this. If you do just set

Code: [Select]

            case RAW_RECORDING:
                raw_start_stop(0,0);
                break;

to

Code: [Select]

            case RAW_RECORDING:
                raw_start_stop(0,0);
                return 1;

and change the normal camera setting to write to the SD card but the RAW file to the CF card. This is the quickest way

Code: [Select]

        //if(card_spanning)
        //{
            filename[0] = 'A';
        //}

If we could get this to work this would also solve the Atomos recording as return 1 will let the normal camera h264 recorder get on with what it was doing with all the HDMI stuff as well.

Lars Steenhoff · « **Reply #48 on:** October 17, 2014, 01:59:06 PM »

Is anyone looking into this already?

beasone · « **Reply #49 on:** December 09, 2014, 10:27:23 AM »

Any updates?

News:

Author Topic: REC COMMAND via the HDMI trigger - Atomos (Read 67847 times)