Files
monibuca/CLAUDE.md
eanfs 2311931432 feature:mp4-upload-s3 (#325)
* iFLOW CLI Automated Issue Triage

* Update for ai

* Revert "Update for ai"

This reverts commit b85978298a.

* Update ai md

* feature:mp4-upload-s3
2025-09-08 08:53:15 +08:00

11 KiB

CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

Project Overview

Monibuca is a high-performance streaming server framework written in Go. It's designed to be a modular, scalable platform for real-time audio/video streaming with support for multiple protocols including RTMP, RTSP, HLS, WebRTC, GB28181, and more.

Development Commands

Building and Running

Basic Run (with SQLite):

cd example/default
go run -tags sqlite main.go

Build Tags:

  • sqlite - Enable SQLite database support
  • sqliteCGO - Enable SQLite with CGO
  • mysql - Enable MySQL database support
  • postgres - Enable PostgreSQL database support
  • duckdb - Enable DuckDB database support
  • disable_rm - Disable memory pool
  • fasthttp - Use fasthttp instead of net/http
  • taskpanic - Enable panics for testing

Protocol Buffer Generation:

# Generate all proto files
sh scripts/protoc.sh

# Generate specific plugin proto
sh scripts/protoc.sh plugin_name

Release Building:

# Uses goreleaser configuration
goreleaser build

Testing:

go test ./...

Architecture Overview

Core Components

Server (server.go): Main server instance that manages plugins, streams, and configurations. Implements the central event loop and lifecycle management.

Plugin System (plugin.go): Modular architecture where functionality is provided through plugins. Each plugin implements the IPlugin interface and can provide:

  • Protocol handlers (RTMP, RTSP, etc.)
  • Media transformers
  • Pull/Push proxies
  • Recording capabilities
  • Custom HTTP endpoints

Configuration System (pkg/config/): Hierarchical configuration system with priority order: dynamic modifications > environment variables > config files > default YAML > global config > defaults.

Task System (pkg/task/): Advanced asynchronous task management system with multiple layers:

  • Task: Basic unit of work with lifecycle management (Start/Run/Dispose)
  • Job: Container that manages multiple child tasks and provides event loops
  • Work: Special type of Job that acts as a persistent queue manager (keepalive=true)
  • Channel: Event-driven task for handling continuous data streams

Task System Deep Dive

Task Hierarchy and Lifecycle

Work (Queue Manager)
  └── Job (Container with Event Loop)
      └── Task (Basic Work Unit)
          ├── Start() - Initialization phase
          ├── Run() - Main execution phase
          └── Dispose() - Cleanup phase

Queue-based Asynchronous Processing

The Task system supports sophisticated queue-based processing patterns:

  1. Work as Queue Manager: Work instances stay alive indefinitely and manage queues of tasks
  2. Task Queuing: Use workInstance.AddTask(task, logger) to queue tasks
  3. Automatic Lifecycle: Tasks are automatically started, executed, and disposed
  4. Error Handling: Built-in retry mechanisms and error propagation

Example Pattern (from S3 plugin):

type UploadQueueTask struct {
    task.Work  // Persistent queue manager
}

type FileUploadTask struct {
    task.Task  // Individual work item
    // ... task-specific fields
}

// Initialize queue manager (typically in init())
var uploadQueueTask UploadQueueTask
m7s.Servers.AddTask(&uploadQueueTask)

// Queue individual tasks
uploadQueueTask.AddTask(&FileUploadTask{...}, logger)

Cross-Plugin Task Cooperation

Tasks can coordinate across different plugins through:

  1. Global Instance Pattern: Plugins expose global instances for cross-plugin access
  2. Event-based Triggers: One plugin triggers tasks in another plugin
  3. Shared Queue Managers: Multiple plugins can use the same Work instance

Example (MP4 → S3 Integration):

// In MP4 plugin: trigger S3 upload after recording completes
s3plugin.TriggerUpload(filePath, deleteAfter)

// S3 plugin receives trigger and queues upload task
func TriggerUpload(filePath string, deleteAfter bool) {
    if s3PluginInstance != nil {
        s3PluginInstance.QueueUpload(filePath, objectKey, deleteAfter)
    }
}

Key Interfaces

Publisher: Handles incoming media streams and manages track information Subscriber: Handles outgoing media streams to clients
Puller: Pulls streams from external sources Pusher: Pushes streams to external destinations Transformer: Processes/transcodes media streams Recorder: Records streams to storage

Stream Processing Flow

  1. Publisher receives media data and creates tracks
  2. Tracks handle audio/video data with specific codecs
  3. Subscribers attach to publishers to receive media
  4. Transformers can process streams between publishers and subscribers
  5. Plugins provide protocol-specific implementations

Post-Recording Workflow

Monibuca implements a sophisticated post-recording processing pipeline:

  1. Recording Completion: MP4 recorder finishes writing stream data
  2. Trailer Writing: Asynchronous task moves MOOV box to file beginning for web compatibility
  3. File Optimization: Temporary file operations ensure atomic updates
  4. External Storage Integration: Automatic upload to S3-compatible services
  5. Cleanup: Optional local file deletion after successful upload

This workflow uses queue-based task processing to avoid blocking the main recording pipeline.

Plugin Development

Creating a Plugin

  1. Implement the IPlugin interface
  2. Define plugin metadata using PluginMeta
  3. Register with InstallPlugin[YourPluginType](meta)
  4. Optionally implement protocol-specific interfaces:
    • ITCPPlugin for TCP servers
    • IUDPPlugin for UDP servers
    • IQUICPlugin for QUIC servers
    • IRegisterHandler for HTTP endpoints

Plugin Lifecycle

  1. Init: Configuration parsing and initialization
  2. Start: Network listeners and task registration
  3. Run: Active operation
  4. Dispose: Cleanup and shutdown

Cross-Plugin Communication Patterns

1. Global Instance Pattern

// Expose global instance for cross-plugin access
var s3PluginInstance *S3Plugin

func (p *S3Plugin) Start() error {
    s3PluginInstance = p  // Set global instance
    // ... rest of start logic
}

// Provide public API functions
func TriggerUpload(filePath string, deleteAfter bool) {
    if s3PluginInstance != nil {
        s3PluginInstance.QueueUpload(filePath, objectKey, deleteAfter)
    }
}

2. Event-Driven Integration

// In one plugin: trigger event after completion
if t.filePath != "" {
    t.Info("MP4 file processing completed, triggering S3 upload")
    s3plugin.TriggerUpload(t.filePath, false)
}

3. Shared Queue Managers

Multiple plugins can share Work instances for coordinated processing.

Asynchronous Task Development Best Practices

1. Implement Task Interfaces

type MyTask struct {
    task.Task
    // ... custom fields
}

func (t *MyTask) Start() error {
    // Initialize resources, validate inputs
    return nil
}

func (t *MyTask) Run() error {
    // Main work execution
    // Return task.ErrTaskComplete for successful completion
    return nil
}

2. Use Work for Queue Management

type MyQueueManager struct {
    task.Work
}

var myQueue MyQueueManager

func init() {
    m7s.Servers.AddTask(&myQueue)
}

// Queue tasks from anywhere
myQueue.AddTask(&MyTask{...}, logger)

3. Error Handling and Retry

  • Tasks automatically support retry mechanisms
  • Use task.SetRetry(maxRetry, interval) for custom retry behavior
  • Return task.ErrTaskComplete for successful completion
  • Return other errors to trigger retry or failure handling

Configuration Structure

Global Configuration

  • HTTP/TCP/UDP/QUIC listeners
  • Database connections (SQLite, MySQL, PostgreSQL, DuckDB)
  • Authentication settings
  • Admin interface settings
  • Global stream alias mappings

Plugin Configuration

Each plugin can define its own configuration structure that gets merged with global settings.

Database Integration

Supports multiple database backends:

  • SQLite: Default lightweight option
  • MySQL: Production deployments
  • PostgreSQL: Production deployments
  • DuckDB: Analytics use cases

Automatic migration is handled for core models including users, proxies, and stream aliases.

Protocol Support

Built-in Plugins

  • RTMP: Real-time messaging protocol
  • RTSP: Real-time streaming protocol
  • HLS: HTTP live streaming
  • WebRTC: Web real-time communication
  • GB28181: Chinese surveillance standard
  • FLV: Flash video format
  • MP4: MPEG-4 format with post-processing capabilities
  • SRT: Secure reliable transport
  • S3: File upload integration with AWS S3/MinIO compatibility

Authentication & Security

  • JWT-based authentication for admin interface
  • Stream-level authentication with URL signing
  • Role-based access control (admin/user)
  • Webhook support for external auth integration

Development Guidelines

Code Style

  • Follow existing patterns and naming conventions
  • Use the task system for async operations
  • Implement proper error handling and logging
  • Use the configuration system for all settings

Testing

  • Unit tests should be placed alongside source files
  • Integration tests can use the example configurations
  • Use the mock.py script for protocol testing

Async Task Development

  • Always use Work instances for queue management
  • Implement proper Start/Run lifecycle in tasks
  • Use global instance pattern for cross-plugin communication
  • Handle errors gracefully with appropriate retry strategies

Performance Considerations

  • Memory pool is enabled by default (disable with disable_rm)
  • Zero-copy design for media data where possible
  • Lock-free data structures for high concurrency
  • Efficient buffer management with ring buffers
  • Queue-based processing prevents blocking main threads

Debugging

Built-in Debug Plugin

  • Performance monitoring and profiling
  • Real-time metrics via Prometheus endpoint (/api/metrics)
  • pprof integration for memory/cpu profiling

Logging

  • Structured logging with zerolog
  • Configurable log levels
  • Log rotation support
  • Fatal crash logging

Task System Debugging

  • Tasks automatically include detailed logging with task IDs and types
  • Use task.Debug/Info/Warn/Error methods for consistent logging
  • Task state and progress can be monitored through descriptions
  • Event loop status and queue lengths are logged automatically

Web Admin Interface

  • Web-based admin UI served from admin.zip
  • RESTful API for all operations
  • Real-time stream monitoring
  • Configuration management
  • User management (when auth enabled)

Common Issues

Port Conflicts

  • Default HTTP port: 8080
  • Default gRPC port: 50051
  • Check plugin-specific port configurations

Database Connection

  • Ensure proper build tags for database support
  • Check DSN configuration strings
  • Verify database file permissions

Plugin Loading

  • Plugins are auto-discovered from imports
  • Check plugin enable/disable status
  • Verify configuration merging

Task System Issues

  • Ensure Work instances are added to server during initialization
  • Check task queue status if tasks aren't executing
  • Verify proper error handling in task implementation
  • Monitor task retry counts and failure reasons in logs