drop.stream | High-Performance Video Platform

Low-latency, performance-optimized HLS video delivery powered by Rust and Svelte.

Overview

drop.stream is a production-style video streaming service designed for high throughput and near-instant playback readiness. By leveraging a custom Rust-based orchestration layer and HLS (HTTP Live Streaming), the platform eliminates the wait time associated with traditional video processing.

• Speed-to-Stream: Optimized FFmpeg pipelines for 1GB+ files.
• Security-First: Magic-Byte binary sniffing for secure media validation.
• Adaptive Playback: Full HLS VOD seekability from the moment of upload.
• Modern Stack: Reactive Svelte UI with a memory-safe Rust/Axum orchestration backend.

Demo

• Repository: https://github.com/Akash-How/drop_stream
• Reviewer Quick Start: Just run run.bat for a zero-setup local environment (bundled Rust/FFmpeg/Frontend).

Key Capabilities

High-Performance Core

Built in Rust using the Axum framework and the Tokio async runtime. Rust ensures zero memory leaks during heavy 4K/HD video processing, while Tokio handles hundreds of simultaneous segment requests with sub-millisecond overhead.

Professional Media Validation

We don't trust file extensions. The backend performs Magic-Byte sniffing (binary header analysis) to verify legitimate video containers (MP4, MKV, WebM) before the transcoding layer ever touches them, preventing malicious file injections.

"Speed-to-Stream" Orchestration

Videos are transcoded using an optimized 360p profile with the ultrafast preset and zerolatency tuning. This allows large files to begin streaming in under 60 seconds from the start of the upload.

Architecture

At a high level, drop.stream uses a reactive, streaming-first pipeline.

flowchart TD
    subgraph Frontend [Svelte UI]
        Uploader["Upload Zone (Multipart)"]
        Player["HLS.js Stream Player"]
    end

    subgraph Backend [Rust / Axum]
        API["Axum API Handler"]
        Validate["Magic-Byte Validation"]
        Storage["Local Disk Storage"]
        DB["SQLite Metadata"]
    end

    subgraph Processing [FFmpeg Hub]
        FF["Transcoder (360p HLS)"]
        Playlist["VOD Playlist Generator"]
    end

    Uploader --> API
    API --> Validate
    Validate --> Storage
    API --> DB
    Storage --> FF
    FF --> Playlist
    Playlist --> Player

Execution flow:

1. Multipart Upload: The Svelte UI streams the file to the Axum backend.
2. Binary Validation: The backend sniffs the first 4096 bytes for Magic-Byte signatures.
3. Process Orchestration: Rust spawns a managed FFmpeg job for HLS segmentation.
4. VOD Manifest Injection: A localized playlist is generated on-the-fly for immediate seekability.
5. Adaptive Delivery: hls.js fetches segments via standard HTTP requests.

Visual Evidence: UI & Logic

Core Dashboard & Library

The interface utilizes an optically-centered layout for enhanced visual balance and a premium user experience. Every element is designed with a focus on UI/UX precision, using a minimalist aesthetic and localized design cues that reflect high-quality engineering standards.

Security: Magic-Byte Validation

Security is prioritized at the entry point of the pipeline. The backend implements Magic-Byte Sniffing by extracting the initial 4KB of every upload to verify the binary signature against valid video containers. This ensures that only legitimate media files reach the transcoding engine, effectively neutralizing extension-spoofing attacks.

Adaptive HLS Playback

The video player is built on hls.js to deliver a high-fidelity streaming experience. By utilizing VOD-type manifests and independent segment flags, the platform provides a seamless, non-stalling timeline. This approach allows for instantaneous seekability and robust segment buffering even on varying network conditions.

Backend Orchestration

The backend serves as a high-performance supervisor for media transformation. It manages asynchronous FFmpeg jobs via the Tokio runtime, tracking process health and database state concurrently. This orchestration ensures that high-volume transcoding tasks remain isolated from the primary API, maintaining system responsiveness during peak loads.

Terminal Logs (Transcoding & Activity)

Project Structure

.
├── backend/               # Rust (Axum) Backend Orchestration
│   ├── src/               # API, Transcoder, and Security logic
│   └── storage/           # Localized Media & SQLite Storage
├── frontend/              # Svelte UI Layer
│   ├── src/               # Component-based Architecture
│   └── dist/              # Production-optimized builds
├── tools/                 # Bundled FFmpeg & Utilities (Zero-Setup)
├── demo/
│   └── screenshots/       # UI & Logic evidence for documentation
├── README.md              # Project Overview
├── ARCHITECTURE.md        # Deep-dive System Design
└── run.bat                # Portable execution script

Developed with ❤️ by AKASH