User1337/File2VideoConverter
1
0
Fork 0
mirror of https://github.com/User1334/File2VideoConverter.git synced 2026-06-15 15:18:54 +02:00
Code Issues Projects Releases 3 Packages Wiki Activity
3 releases 3 tags
  • 0.3.0 c8c36c7c49

    0.3.0 Stable

    User1337 released this 2026-04-18 10:42:14 +02:00 | 5 commits to main since this release

    File2VideoConverter Release

    This release dramatically improves encoding performance through optimized Reed-Solomon encoding, zero-copy GPU rendering, and automatic bitrate calibration for lossy codecs.

    Highlights

    • Reed-Solomon encoding up to 690× faster in Release builds (277s → 0.4s for 13MB with RS-64)
    • GPU renderer now writes directly into CVPixelBuffer memory — no intermediate buffer, no copy
    • Automatic bitrate calibration when selecting H.264 or H.265
    • Per-phase pipeline profiling for performance visibility
    • Render-encoder overlap for better video writing throughput

    Reed-Solomon Encoding

    The RS encoder has been rewritten for maximum throughput. The previous implementation used NSLock-based synchronization and allocated a new array per codeword. The new implementation:

    • Uses UnsafeMutablePointer and UnsafeBufferPointer throughout, bypassing array bounds checking
    • Precomputes log(generator[j]) to eliminate one GF(2^8) table lookup per inner loop iteration
    • Writes parity directly into a flat output buffer at computed offsets — no locks needed
    • Batches codewords per CPU core instead of dispatching one GCD task per codeword, reducing scheduling overhead
    • Reuses a single work buffer per batch instead of allocating per codeword

    The parity layout and RS algorithm remain unchanged. Existing FTV1 containers are fully compatible.

    GPU Renderer

    The Metal renderer no longer allocates two MTLBuffers per frame and copies the result row by row into a CVPixelBuffer. Instead:

    • The CVPixelBuffer memory is wrapped directly as an MTLBuffer via makeBuffer(bytesNoCopy:), so the GPU writes pixels in place with zero copy
    • A reusable source buffer holds the frame bytes and grows as needed without reallocation
    • A new renderFrameDirect Metal shader accounts for bytesPerRow stride, which may differ from width × 4 due to CVPixelBuffer row padding
    • The FrameRenderer protocol now uses mutating func to support buffer reuse in the GPU implementation

    Video Writer Pipeline

    Frame rendering now happens before the encoder readiness check instead of after. This allows the GPU or CPU to render the next frame while the hardware encoder processes the previous one. The encoder poll interval has also been reduced from 10ms to 1ms for faster response.

    Auto Bitrate Calibration

    Switching to H.264 or H.265 now automatically starts bitrate calibration in the background. The calibrated value appears as a dedicated "Calibrated (X.XX bpp)" option in the video quality picker and is auto-selected. Users can override it by choosing a different preset and return to the calibrated value at any time. Changing cell size, resolution, or framerate invalidates the calibration and re-triggers it automatically.

    Pipeline Profiling

    The encode pipeline now measures and reports timing for each phase: file reading, zlib compression, RS encoding, video writing, and finalization. The video writer additionally breaks down time spent waiting for the encoder, rendering frames, appending pixel buffers, and generating preview images. Thread utilization for RS encoding is logged to the console.

    Technical Changes

    • Rewrote ReedSolomonCodec.encodeBlock with unsafe pointers, precomputed log tables, and batched concurrency
    • Added renderFrameDirect Metal kernel with bytesPerRow parameter
    • Refactored GPUFrameRenderer for zero-copy rendering and buffer reuse
    • Changed FrameRenderer.renderFrameBytes to mutating func
    • Swapped render/wait order in FTV1StreamingVideoWriter.appendFrameBytes
    • Added BitratePreset.calibrated case with dynamic picker title
    • Added invalidateCalibration() and auto-calibration triggers on codec and settings changes
    • Added per-phase timing with CFAbsoluteTimeGetCurrent and profiling summary in progress messages

    Compatibility

    This release does not change the FTV1 file format. Existing videos and containers remain readable. The changes are limited to encoding performance, GPU rendering internals, and UI workflow.

    Downloads
  • 0.1.0 9bf7f41cbc

    0.1.0 Stable

    User1337 released this 2026-04-15 20:28:08 +02:00 | 7 commits to main since this release

    File2VideoConverter Release

    This release improves video generation performance in two key areas: frame rendering and Reed-Solomon error correction.

    Highlights

    • New Metal-based GPU renderer
    • Renderer selection in the UI: CPU or GPU (Metal)
    • Existing CPU rendering moved out of the video writer into a dedicated renderer implementation
    • Reed-Solomon parity encoding now runs in parallel across multiple CPU cores
    • FTV1 container format and Reed-Solomon parity ordering remain unchanged and compatible

    GPU Rendering

    Frame rendering now uses a new renderer model. Instead of generating pixels directly inside FTV1StreamingVideoWriter, the app now uses a shared FrameRenderer abstraction with two implementations:

    • CPUFrameRenderer for the existing multi-core CPU rendering path
    • GPUFrameRenderer for Metal-accelerated rendering

    The new Metal compute shader renders serialized frame bytes directly into BGRA pixel data. It handles both data cells and the optional sync border on the GPU. If Metal is unavailable or the GPU pipeline cannot be created, the pipeline automatically falls back to CPU rendering.

    The renderer can now be selected directly in the app. When GPU mode is active, the maximum CPU usage option is disabled because frame rendering is no longer primarily scaled through CPU workers.

    Faster Reed-Solomon Encoding

    Reed-Solomon parity generation has been parallelized. Since individual RS codewords are independent, they are now processed across multiple CPU cores with DispatchQueue.concurrentPerform.

    The computed parity chunks are then appended in codeword order, so the serialized parity layout stays deterministic and unchanged.

    Technical Changes

    • Added RenderMode to pipeline options
    • Updated FTV1StreamingVideoWriter to receive a FrameRenderer
    • Moved CPU rendering logic into CPUFrameRenderer
    • Added GPUFrameRenderer with Metal pipeline, command queue, and pixel buffer copy
    • Added FrameRendererShader.metal
    • Added UI picker for CPU/GPU rendering
    • Parallelized RS encoding in ReedSolomonCodec.encodeBlock

    Compatibility

    This release does not change the FTV1 file format. Existing videos and containers remain readable. The changes are limited to performance and internal rendering/encoding paths.

    Downloads
  • 0.0.2 a5e83b95a9

    0.0.2 Pre-release

    User1337 released this 2026-04-13 19:30:50 +02:00 | 9 commits to main since this release

    Downloads