Hello FFmpeg Team, I am writing to report and clarify several observations related to NVENC compatibility, FFmpeg build differences, and an additional practical concern regarding highly compressed video files versus edit-friendly workflows.
--- 1. NVIDIA GPU support differences (FFmpeg 6.1 vs newer builds) We have tested FFmpeg across multiple Windows systems with the following GPUs: - NVIDIA RTX 3050 (Ampere) - NVIDIA GTX 1660 Super (Turing) - NVIDIA RTX 2050 Observation: - FFmpeg 6.1 reliably detects and uses NVENC on all of the above GPUs with existing drivers. - Newer FFmpeg builds (recent releases / nightlies) often fail to initialize NVENC on the same systems, even though: - The GPU is NVENC-capable - Drivers are installed and functioning - The same systems work correctly with FFmpeg 6.1 In these cases, FFmpeg either falls back to CPU encoding or fails NVENC initialization due to CUDA / driver compatibility requirements. This appears to be a build vs driver vs CUDA dependency mismatch, rather than a hardware limitation. --- 2. Command behavior differences between 6.1 and newer builds We also observed that commands which work reliably in FFmpeg 6.1: - Produce different results, or - Fail validation in newer builds. This makes it difficult to maintain a single, stable encoding pipeline for software intended to support a wide range of consumer GPUs. --- 3. Practical compression concern: delivery quality vs editability We would also like clarification on a real-world workflow concern. Example scenario: - A camera-captured file (6 seconds, ~114 MB) - Compressed using libx264 at CRF 25 - Output size becomes ~2 MB - Resolution, frame rate, and duration remain unchanged - Visual playback quality appears nearly identical Observation: - The compressed file plays smoothly and looks visually similar - It can be opened in editors and rendered successfully - However, it is not ideal for further editing, especially for: - Color grading - Exposure or contrast adjustments - Zoom / crop - Multiple re-exports This highlights a common confusion among users: «Playback quality can appear “the same,” while editing headroom is significantly reduced.» Our understanding is that: - CRF-based H.264/H.265 outputs are delivery-optimized - They are not intended to function as editing masters - Editor-friendly workflows require intra-frame or mezzanine formats (e.g., ProRes, DNxHR, or ALL-I) We would appreciate confirmation that this interpretation aligns with FFmpeg’s intended usage and best practices. --- 4. Practical concern: production stability Our goal is to build a stable, consumer-facing application where: - GPU detection is automatic - NVENC works reliably across GTX and RTX cards - CPU fallback is used only when necessary - Users clearly understand the distinction between: - Editing-friendly files - Final delivery / compressed files At present, FFmpeg 6.1 appears to be the most reliable option for broad NVIDIA GPU compatibility, while newer builds introduce stricter CUDA and driver dependencies that affect stability. --- 5. Questions for the FFmpeg team 1. Is FFmpeg 6.1 currently the recommended stable baseline for maximum NVIDIA GPU compatibility on Windows? 2. Are newer builds intentionally targeting newer CUDA versions that may reduce compatibility with older driver stacks? 3. Is there a documented way to choose or build FFmpeg binaries that maximize backward compatibility with NVENC across GTX and RTX GPUs? 4. Does the FFmpeg team consider CRF-based H.264/H.265 outputs strictly as delivery formats rather than editing masters? 5. Are there any recommended guidelines or documentation references we can point users to regarding edit-friendly versus delivery-optimized encodes? --- 6. Summary - NVENC-capable GPUs (RTX 3050, GTX 1660 Super) work reliably with FFmpeg 6.1 - Newer builds introduce GPU compatibility challenges due to CUDA/driver requirements - Highly compressed CRF outputs can look visually identical but are not suitable for heavy editing - Clear guidance on build selection and workflow intent would be extremely valuable Thank you for your time and for the continued work on FFmpeg. Kind regards, _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
