DOCSEARCHbyAlgolia
Submit Docs

Thingino Firmware

repository·master·Indexed 23 days ago

https://github.com/themactep/thingino-firmware

Open-source firmware for Ingenic SoC IP cameras. It features a containerized build environment using Docker or Podman, a strategic architectural shift called Thingino Next that moves from camera-hosted UIs to a centralized desktop hub model, and OpenIMP as an open-source replacement for the proprietary Ingenic libimp.so library. The documentation covers Buildroot scripts, package override management, and specific components like daynightd and the Strero package.

Tokens
194.2K
Snippets
297
Records
705
Agent score
83%

What's inside thingino-firmware

  1. Understand the Thingino Implementation Roadmap

    master

    The Thingino development roadmap follows a phased approach to transition from a backend-dependent architecture to a backend-neutral, canonical API model. The primary goal is to establish a 'hub-centric' management model where a central hub manages cameras via a unified API, while cameras remain capable of local operation and hosting optional UIs.

    Key Architectural Phases

    • Phase 1: Streamer-agnostic camera agent with initial adapters.
    • Phase 2a: Historical storage and analysis (Hub-local SQLite database for action history, state samples, and config changes).
    • Phase 3: Optional camera-hosted UI (Local fallback access that consumes the camera agent without duplicating business logic).
    • Phase 4: ONVIF daemon migration (Moving ONVIF to use the canonical camera model instead of CGI).
    • Phase 5: Additional streamer adapters (Making the API backend-neutral by adding adapters like raptor and strero).

  2. Compare supported web servers in Thingino

    master

    Thingino supports three different web server implementations, each with different trade-offs regarding footprint and features:

    • BusyBox httpd (default): Best for minimal footprint and embedded systems. It has no native SSL support (requires thingino-httpd-ssl for HTTPS). Configuration is handled via /etc/httpd.conf.
    • uhttpd: A modern HTTP server from OpenWrt. Supports optional TLS/HTTPS (via mbedTLS or wolfSSL), Lua scripting, session-based authentication, and automatic HTTP to HTTPS redirection. Configuration is located in /etc/uhttpd/.
    • nginx: A full-featured HTTP server and reverse proxy. It offers extensive module support but requires more resources and requires fcgiwrap for CGI script execution. Configuration is handled via /etc/nginx/nginx.conf.

  4. Supported VPN solutions in Thingino

    master

    Thingino provides an abstraction layer for several VPN solutions. Choose the one that best fits your hardware constraints and networking needs:

    • None: No VPN solution is included. Use this to minimize flash usage.
    • WireGuard (default): A fast, modern, and secure VPN tunnel with minimal overhead. It uses wireguard-tools for configuration and is typically included in the Linux kernel or as a kernel module.
    • ZeroTier-One: Creates virtual Ethernet networks that make the device appear as if it is on the same physical LAN. Requires a C++ toolchain and thread support.
    • Tailscale: A WireGuard-based mesh VPN with centralized coordination. It is easy to manage but requires a flash size of at least 16MB.

  6. Understand Thingino terminology and abbreviations

    master

    This glossary provides definitions for technical terms, hardware components, and protocols used within the Thingino firmware ecosystem. Key categories include:

    • Ingenic Platform Terms:
      • Archon: Ingenic Zeratul T31 Platform code name.
      • Immortal: Ingenic Zeratul T20 Platform code name.
      • IMP: Ingenic Media Platform.
      • ISVP: Ingenic Smart Video Platform.
      • Turret: Closed Source Zeratul Bootloader (U-Boot).
    • AI and Deep Learning:
      • MAGIK: Ingenic's deep learning neural network development kit.
      • JZDL: A software module in MAGIK used for AI inference acceleration.
      • MXU: Matrix Multiplication Unit.
      • NCU: Neural Compute Unit.
      • TOPS: TeraOperations Per Second.
    • Video and Image Processing:
      • 3A: Auto Exposure, Auto White Balance, and Auto Focus.
      • 3D-DNR: 3D Digital Noise Reduction.
      • DNR: Digital Noise Reduction.
      • WDR: Wide Dynamic Range.
      • HDR: High Dynamic Range.
    • SDK Modes:
      • SDK offline mode: The image is stored in DDR.
      • SDK online mode: The image is not stored in DDR.

  7. RTMPE Protocol Specification Overview

    master
    RTMPE is a clean-room specification of the RTMP "Encryption" scheme. It utilizes industry-standard cryptographic primitives including ARC4, HMACSHA256, and Diffie-Hellman. The protocol is designed to provide end-to-end secrecy similar to SSL, though it is noted to be vulnerable to man-in-the-middle attacks because it lacks authentication and relies on publicly obtainable information.

  9. What is Adobe's Real Time Messaging Protocol (RTMP)?

    master
    RTMP is an application-level protocol designed for multiplexing and packetizing multimedia transport streams (such as audio, video, and interactive content) over a reliable transport protocol like TCP. It provides a bidirectional message multiplex service, allowing parallel streams of video, audio, and data messages with associated timing information to flow between communicating peers.

  10. Security Model and Recommended Defaults for Thingino

    master

    The Thingino security model for remote camera control is designed around a 'local-only by default' posture. To enable remote access, users must explicitly enable it through pairing or enrollment.

    Key security principles include:

    • TLS for Remote Access: Remote control must use HTTPS; plain HTTP is not the standard remote path.
    • Camera-to-Hub Trust: The preferred method is mutual TLS between the hub and the camera. A fallback mechanism uses TLS combined with short-lived signed bearer tokens issued during the pairing process.
    • Scoped Permissions: Access is managed via capability-based scopes rather than all-or-nothing permissions. Available candidate scopes include:
      • read
      • control
      • admin
      • firmware
      • media

  11. Implement historical storage in the hub

    master

    When adding historical analysis (graphs, timelines) to the hub, follow a decoupled architecture to ensure analytics storage does not become a dependency for core camera operations.

    Recommended Implementation Pattern:

    1. History Writer: Add a small component within the hub service.
    2. Enqueueing: Enqueue action and state records from native API flows and probe loops.
    3. Persistence: Batch writes to a local SQLite database using WAL mode.
    4. Decoupling Rule: The control path (issuing live camera actions) must not require the database. The UI may read history from the database, but the core operation should remain independent of the storage layer.

  12. Optimize embedded services by minimizing fork depth

    master

    On resource-constrained MIPS systems, avoid using shell scripts that rely heavily on subshell expansions like $(...). Each expansion triggers a fork+exec cycle. On a loaded CPU, these forks incur significant scheduling latency that compounds quickly.

    Best Practices:

    • Avoid subshells: Instead of printf "...$(command)...", read data directly from /proc using shell built-ins like read and here-strings.
    • Batch operations: Combine multiple awk or sed queries into a single invocation rather than calling them sequentially.
    • Use compiled helpers: For performance-critical paths, use a compiled binary that can gather multiple system metrics in a single pass rather than spawning dozens of small processes.