Update files

parent bc26540c
Pipeline #194 failed with stages
# Changelog
All notable changes to Video AI Analysis Tool will be documented in this file.
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
......@@ -9,80 +9,20 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
### Added
- Multi-process architecture with separate web, backend, and worker processes
- User registration system with email confirmation
- Token-based usage system with configurable pricing
- Payment processing integration (Stripe, PayPal, cryptocurrency)
- Modern SaaS-style landing page for non-authenticated users
- REST API for programmatic access
- Job queue management with real-time status updates
- Admin panel for user and system management
- Email notification system for confirmations and receipts
- Support for both CUDA and ROCm GPU backends
- Comprehensive configuration system
- Professional documentation and licensing
- Support for CUDA and ROCm backends for analysis and training
- Configuration page to select GPU backends
- Self-contained communication using sockets
- GPLv3 license and copyright notices
- Build scripts for creating standalone executables
- Startup script for launching all processes
### Changed
- Refactored from monolithic Flask app to multi-process architecture
- Improved security with proper authentication and session management
- Enhanced user experience with modern web interface
- Better error handling and logging throughout the application
### Technical Improvements
- Socket-based inter-process communication
- SQLite database for persistent configuration and user data
- Modular code structure with clear separation of concerns
- Type hints and comprehensive documentation
- Automated build scripts for different GPU backends
## [0.1.0] - 2024-01-01
### Added
- Initial release with basic video/image analysis functionality
- Flask web interface for uploading and analyzing media
- Qwen2.5-VL model integration for AI-powered analysis
- Frame extraction from videos with configurable intervals
- Basic configuration system
- Simple build and deployment scripts
### Known Issues
- Monolithic architecture limiting scalability
- No user authentication or management
- Limited payment integration
- Basic documentation and testing
---
## Types of Changes
- `Added` for new features
- `Changed` for changes in existing functionality
- `Deprecated` for soon-to-be removed features
- `Removed` for now removed features
- `Fixed` for any bug fixes
- `Security` in case of vulnerabilities
## Version Numbering
This project uses [Semantic Versioning](https://semver.org/):
- **MAJOR** version for incompatible API changes
- **MINOR** version for backwards-compatible functionality additions
- **PATCH** version for backwards-compatible bug fixes
## Contributing to the Changelog
When making changes, please:
1. Update the "Unreleased" section above with your changes
2. Move items from "Unreleased" to a new version section when releasing
3. Follow the existing format and categorization
## Release Process
1. Update version numbers in relevant files
2. Move changes from "Unreleased" to the new version section
3. Create a git tag for the release
4. Update documentation if needed
5. Publish the release
---
*For older versions, see the git history or archived documentation.*
\ No newline at end of file
- Refactored monolithic Flask app into distributed processes
- Updated communication protocol to use sockets instead of multiprocessing queues
### Technical Details
- Backend process handles request routing based on configuration
- Worker processes register with backend and handle specific tasks
- Web interface communicates with backend via TCP sockets
- Results are passed via temporary JSON files
- Configuration stored in user config directory
\ No newline at end of file
......@@ -2,204 +2,82 @@
## Overview
Video AI Analysis Tool uses a multi-process architecture designed for scalability, reliability, and optimal GPU utilization. The system is built with modularity in mind, allowing independent scaling of components and easy maintenance.
Video AI is a multi-process application designed for analyzing images and videos using AI models. The system supports both CUDA and ROCm backends for GPU acceleration.
## System Components
## Components
### 1. Web Interface Process (`vidai/web.py`)
**Purpose**: Handles user interactions and serves the web application.
**Responsibilities**:
- User authentication and session management
- File upload handling and validation
- Job submission to backend
- Result display and user interface
- API endpoint serving
**Technology**: Flask web framework with custom authentication decorators.
**Communication**: Connects to backend via TCP sockets on port 5001.
- Flask-based web server
- Serves the user interface
- Sends requests to backend via TCP socket (port 5001)
- Polls for results via temporary JSON files
### 2. Backend Process (`vidai/backend.py`)
**Purpose**: Central routing and coordination hub.
**Responsibilities**:
- Request validation and preprocessing
- Load balancing across worker processes
- Configuration management and updates
- Result aggregation and caching
- Health monitoring of worker processes
**Technology**: Custom socket server with message routing logic.
**Communication**:
- Receives requests from web interface on port 5001
- Communicates with workers on port 5002
- Uses file-based result storage for web polling
- Central message router
- Listens for web requests on port 5001
- Listens for worker connections on port 5002
- Routes requests to appropriate workers based on configuration
- Handles configuration updates
### 3. Worker Processes
- **Analysis Workers** (`vidai/worker_analysis.py`): Handle image/video analysis
- **Training Workers** (`vidai/worker_training.py`): Handle model training
- Each worker type has CUDA and ROCm variants
- Workers register with backend and process assigned tasks
## Communication Protocol
### Message Format
```json
{
"msg_type": "message_type",
"msg_id": "unique_id",
"data": {
// message-specific data
}
}
```
### Message Types
- `analyze_request`: Web to backend for analysis jobs
- `train_request`: Web to backend for training jobs
- `config_update`: Web to backend for configuration changes
- `get_config`: Web to backend to retrieve current config
- `register`: Worker to backend registration
- `analyze_response`: Worker to backend with results
- `train_response`: Worker to backend with results
- `config_response`: Backend to web with config data
## Configuration
Configuration is stored in `~/.config/vidai/config.json`:
```json
{
"analysis_backend": "cuda",
"training_backend": "cuda"
}
```
## Process Management
Use the provided scripts:
- `start.sh [cuda|rocm]`: Launch all processes
- `build.sh [cuda|rocm]`: Build standalone executables
- `setup.sh [cuda|rocm]`: Set up virtual environment
#### Analysis Worker (`vidai/worker_analysis.py`)
**Purpose**: Handles AI-powered media analysis jobs.
**Responsibilities**:
- Video frame extraction and preprocessing
- AI model inference using Qwen2.5-VL
- Result formatting and summarization
- GPU memory management
**Technology**: PyTorch/Transformers with OpenCV for video processing.
#### Training Worker (`vidai/worker_training.py`)
**Purpose**: Handles model training and fine-tuning jobs.
**Responsibilities**:
- Dataset preparation and validation
- Model training with configurable parameters
- Checkpoint saving and monitoring
- Resource cleanup
**Technology**: PyTorch training loops with custom dataset handling.
### 4. Shared Components
#### Communication Module (`vidai/comm.py`)
**Purpose**: Standardized inter-process communication.
**Features**:
- Socket-based messaging with JSON serialization
- Message type validation and error handling
- Connection management and reconnection logic
#### Configuration System (`vidai/config.py`)
**Purpose**: Centralized configuration management.
**Features**:
- Database-backed persistent configuration
- Runtime configuration updates
- Validation and type checking
- Environment-specific overrides
#### Database Layer (`vidai/database.py`)
**Purpose**: Data persistence and user management.
**Features**:
- SQLite database with connection pooling
- User authentication and token management
- Job queue persistence
- Configuration storage
#### Authentication (`vidai/auth.py`)
**Purpose**: User authentication and authorization.
## Data Flow
**Features**:
- Session-based authentication
- API token generation and validation
- Role-based access control
- Password hashing and security
1. User submits request via web interface
2. Web sends message to backend
3. Backend routes to appropriate worker based on config
4. Worker processes request and sends result back
5. Backend forwards result to web via file
6. Web displays result to user
## Data Flow
## Security Considerations
### Analysis Job Flow
1. **User Upload**: User uploads file via web interface
2. **Request Submission**: Web process sends analysis request to backend
3. **Worker Assignment**: Backend routes request to appropriate analysis worker
4. **Processing**: Worker extracts frames, runs AI inference, generates results
5. **Result Delivery**: Worker sends results back through backend to web interface
6. **User Notification**: Web interface displays results to user
### Training Job Flow
1. **Dataset Upload**: User provides training data and parameters
2. **Job Queuing**: Training request added to persistent queue
3. **Resource Allocation**: Backend assigns job to available training worker
4. **Model Training**: Worker executes training loop with monitoring
5. **Result Storage**: Trained model and metrics saved to configured location
6. **Completion Notification**: User notified of training completion
## Scalability Considerations
### Horizontal Scaling
- Multiple worker processes can run on different GPUs
- Backend can distribute load across worker pools
- Database supports concurrent access from multiple processes
### Vertical Scaling
- Individual components can be deployed on separate machines
- Network communication allows distributed deployment
- Configuration system supports cluster setups
### Resource Management
- GPU memory monitoring and cleanup
- Process health checks and automatic restart
- Queue-based job management prevents resource exhaustion
## Security Architecture
### Authentication
- Secure password hashing with SHA-256
- Session-based authentication with configurable timeouts
- API token system for programmatic access
- Email verification for account activation
### Authorization
- Role-based access control (user/admin)
- Resource ownership validation
- API rate limiting and abuse prevention
### Data Protection
- Input validation and sanitization
- Secure file upload handling
- Database query parameterization
- Sensitive data encryption in configuration
## Deployment Options
### Single Machine
- All processes run on one machine
- Shared memory communication via Unix sockets
- SQLite database for simplicity
### Multi-Machine Cluster
- Processes distributed across multiple servers
- TCP socket communication
- Shared database server (PostgreSQL/MySQL)
- Load balancer for web interface scaling
### Cloud Deployment
- Containerized deployment with Docker
- Kubernetes orchestration for scaling
- Cloud storage integration
- Managed database services
## Monitoring and Logging
### Health Checks
- Process status monitoring
- Worker availability tracking
- Queue depth monitoring
- Resource utilization tracking
### Logging
- Structured logging with configurable levels
- Error tracking and alerting
- Performance metrics collection
- Audit logging for security events
## Future Enhancements
### Planned Improvements
- Kubernetes operator for automated scaling
- Advanced load balancing algorithms
- Real-time progress streaming
- Plugin system for custom analysis modules
- Multi-cloud GPU support
### Extensibility Points
- Worker plugin interface
- Custom authentication providers
- Payment processor plugins
- Storage backend abstraction
\ No newline at end of file
- All processes run locally
- No external network exposure by default
- File-based result passing for simplicity
- Consider implementing authentication for production use
\ No newline at end of file
......@@ -43,9 +43,19 @@ def set_training_backend(backend: str) -> None:
set_config('training_backend', backend)
def get_runpod_enabled() -> bool:
"""Check if RunPod integration is enabled."""
return get_config('runpod_enabled', 'false').lower() == 'true'
def set_runpod_enabled(enabled: bool) -> None:
"""Enable or disable RunPod integration."""
set_config('runpod_enabled', enabled)
set_config('runpod_enabled', 'true' if enabled else 'false')
def get_runpod_api_key() -> str:
"""Get RunPod API key."""
return get_config('runpod_api_key', '')
def set_runpod_api_key(api_key: str) -> None:
......@@ -53,11 +63,21 @@ def set_runpod_api_key(api_key: str) -> None:
set_config('runpod_api_key', api_key)
def get_runpod_template_id() -> str:
"""Get RunPod template ID."""
return get_config('runpod_template_id', 'vidai-analysis-latest')
def set_runpod_template_id(template_id: str) -> None:
"""Set RunPod template ID."""
set_config('runpod_template_id', template_id)
def get_runpod_gpu_type() -> str:
"""Get preferred RunPod GPU type."""
return get_config('runpod_gpu_type', 'NVIDIA RTX A4000')
def set_runpod_gpu_type(gpu_type: str) -> None:
"""Set preferred RunPod GPU type."""
set_config('runpod_gpu_type', gpu_type)
......
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment