Start / stop recording from API calls

[curtishall]

We need the ability to stop or start recording based on an API call. We should also create a new 'status' in the recording schedule area called 'Trigger'.

The API call should have priority over stopping or starting recording...so if the schedule is motion detection an an external trigger happens then the recording event starts.

Having a 'Trigger' schedule basically means no recording happens unless a trigger occurs.

[ghost]

* Current state:
* Continuous (C):
* source --> recorder
*
* Motion (M):
* V4L:
* source =(indication & stream)=> motion_handler --> recorder
* RTP:
* source -+-> motion_processor -(indication)-> motion_handler --> recorder
*         +---------------------(stream)-------^
* + race condition!
*/

Step 1. Fix race condition.

V4L:

source =(indication & stream)=> motion_handler --> recorder

no changes required.

RTP (lavf):

source -+-> motion_processor -(indication)-> motion_handler --> recorder
        +---------------------(stream)-------^

becomes:

source ==> motion_processor_m (data passthru, flag setting) ==> motion_handler_m ==> recorder

Note: _m stands for Modified

Step 2. Introduce Trigger mode (T)

source ==> trigger_processor (data passthru, flag setting) ==> motion_handler_m ==> recorder

If we need Trigger+Motion mode:

source ==> trigger_processor (data passthru, flag setting) ==> motion_processor_m (data passthru, flag setting) + patch: "if motion flag already set, skip algorithm" ==> motion_handler_m ==> recorder

Note: at this point trigger_processor is a stub.

Step 3. Implement triggering mechanism. Governing software --> HTTP request /trigger?cam=${cam_id}&trigger_reason=free-formed-descr --> Apache --> PHP script --> connect to local UNIX socket bind by bc-server (use status_server as starting point) --> trigger_processor flagging mechanism

Note: add authentication mechanism agreed with users: HTTP Digest auth, or auth token in GET param, etc.

Flagging mechanism implementation details

trigger_processor object has two sources of data:

• "source" gives media stream;
• "trigger_server" dispatches external requests.

Such designs are possible:

1. "trigger_server" sets a hash table entry when request arrives; "source" pushes media frames to trigger_processor; when this happens, trigger_processor checks a hash table entry, guarded by mutex. If the table entry is found, remove from hash table, and flag the frame.
2. trigger_processor registers itself in hash table by camera id as key; "source" pushes media frames to trigger_processor; "trigger_server" looks up for trigger_processor object when request arrives, then it calls its method, so that next media frame pushed to it will be flagged.

[curtishall]

We should also continue to support pre and post event recordings times like we do with motion based detection.

On a side note, most (non-ONVIF) IP cameras won't tell us when motion has ended via a URL, only when motion starts...so we should have the option to trigger motion recording via the event URL and then end recording once motion is finished.

[curtishall]

https://secure.helpscout.net/conversation/218066306/8926