refactor documentation for worker communication protocol; improve formatting and clarify crop coordinates and session ID handling

worker.md

@@ -20,16 +20,17 @@ Communication is bidirectional and asynchronous. All messages are JSON objects w
 To enable modularity and dynamic configuration, the backend will send you a URL to a `.mpta` file when it issues a `subscribe` command. This file is a renamed `.zip` archive that contains everything your worker needs to perform its task.
 
 **Your worker is responsible for:**
-1.  Fetching this file from the provided URL.
-2.  Extracting its contents.
-3.  Interpreting the contents to configure its internal pipeline.
+
+1. Fetching this file from the provided URL.
+2. Extracting its contents.
+3. Interpreting the contents to configure its internal pipeline.
 
 **The contents of the `.mpta` file are entirely up to the user who configures the model in the CMS.** This allows for maximum flexibility. For example, the archive could contain:
 
-*   **AI/ML Models:** Pre-trained models for libraries like TensorFlow, PyTorch, or ONNX.
-*   **Configuration Files:** A `config.json` or `pipeline.yaml` that defines a sequence of operations, specifies model paths, or sets detection thresholds.
-*   **Scripts:** Custom Python scripts for pre-processing or post-processing.
-*   **API Integration Details:** A JSON file with endpoint information and credentials for interacting with third-party detection services.
+- AI/ML Models: Pre-trained models for libraries like TensorFlow, PyTorch, or ONNX.
+- Configuration Files: A `config.json` or `pipeline.yaml` that defines a sequence of operations, specifies model paths, or sets detection thresholds.
+- Scripts: Custom Python scripts for pre-processing or post-processing.
+- API Integration Details: A JSON file with endpoint information and credentials for interacting with third-party detection services.
 
 Essentially, the `.mpta` file is a self-contained package that tells your worker *how* to process the video stream for a given subscription.
 
@@ -69,6 +70,7 @@ This message is crucial for the backend to monitor your worker's health and stat
 ```
 
 > **Note:**
+>
 > - `cropX1`, `cropY1`, `cropX2`, `cropY2` (optional, integer) should be included in each camera connection to indicate the crop coordinates for that subscription.
 
 ### 4.2. Image Detection
@@ -191,9 +193,9 @@ Instructs the worker to process a camera's RTSP stream using the configuration f
 ```
 
 > **Note:**
+>
 > - `cropX1`, `cropY1`, `cropX2`, `cropY2` (optional, integer) specify the crop coordinates for the camera stream. These values are configured per display and passed in the subscription payload. If not provided, the worker should process the full frame.
 >
-
 > **Important:**
 > If multiple displays are bound to the same camera, your worker must ensure that only **one stream** is opened per camera. When you receive multiple subscriptions for the same camera (with different `subscriptionIdentifier` values), you should:
 >
@@ -201,10 +203,8 @@ Instructs the worker to process a camera's RTSP stream using the configuration f
 > - Capture each snapshot only once per cycle, and reuse it for all display subscriptions sharing that camera.
 > - Capture each frame/image only once per cycle.
 > - Reuse the same captured image and snapshot for all display subscriptions that share the camera, processing and routing detection results separately for each display as needed.
->
 > This avoids unnecessary load and bandwidth usage, and ensures consistent detection results and snapshots across all displays sharing the same camera.
 
-
 ### 5.2. Unsubscribe from Camera
 
 Instructs the worker to stop processing a camera's stream.
@@ -286,6 +286,7 @@ Or to clear the session:
 ```
 
 > **Note:**
+>
 > - The worker should store the session ID for the given subscription and use it in subsequent detection or patch messages as appropriate. If `sessionId` is `null`, the worker should treat the subscription as having no active session.
 
 ## Subscription Identifier Format
@@ -303,6 +304,7 @@ This uniquely identifies a camera subscription for a specific display.
 When the backend sends a `setSessionId` command, it will only provide the `displayIdentifier` (not the full `subscriptionIdentifier`).
 
 **Worker Responsibility:**
+
 - The worker must match the `displayIdentifier` to all active subscriptions for that display (i.e., all `subscriptionIdentifier` values that start with `displayIdentifier;`).
 - The worker should set or clear the session ID for all matching subscriptions.