Convert Y4M to FLV — Free Online Tool
Convert Y4M (YUV4MPEG2) lossless uncompressed video to FLV using H.264 (libx264) encoding with AAC audio. This tool compresses the massive raw pixel data of Y4M into a compact, streamable Flash Video file — ideal for preparing uncompressed pipeline output for legacy web delivery or RTMP streaming workflows.
to
FFmpeg Command
Copy this command to run the same conversion locally with FFmpeg on your desktop. Download FFmpeg
Drop your Y4M file here
or click to browse
Free — no uploads, no signups. Your files never leave your browser.
Settings
Note: Browser-based encoding uses approximate quality targets. For precise CRF compression, copy the FFmpeg command above and run it on your desktop.
Estimated output:
Conversion Complete!
DownloadHow It Works
Y4M stores every video frame as raw, uncompressed YUV pixel data with no inter-frame compression, making files extremely large but perfectly lossless. During this conversion, FFmpeg reads each raw frame and passes it through the libx264 encoder, which applies H.264 compression using a CRF value of 23 — a perceptually driven quality setting that discards visually redundant data between frames. Since Y4M carries no audio stream, the AAC audio codec flag is included in the command but will produce no audio output unless a separate audio source is muxed in. The resulting FLV container packages the H.264 video in a format historically used for Flash Player delivery and still supported by RTMP-based streaming servers like Nginx-RTMP and older CDN ingest endpoints.
What Each Flag Does
| Flag | What it does |
|---|---|
ffmpeg
|
Invokes the FFmpeg binary. This is the open-source multimedia processing engine running under the hood — in the browser tool, it runs via FFmpeg.wasm compiled to WebAssembly; locally, it refers to your installed FFmpeg executable. |
-i input.y4m
|
Specifies the input file in Y4M (YUV4MPEG2) format. FFmpeg reads the Y4M header to extract frame dimensions, frame rate, and chroma subsampling before decoding the raw uncompressed pixel data frame by frame. |
-c:v libx264
|
Sets the video encoder to libx264, which encodes the raw YUV frames from the Y4M source into H.264 compressed video. H.264 is required for the FLV container in most real-world streaming and playback contexts. |
-c:a aac
|
Sets the audio encoder to AAC (Advanced Audio Coding). Since Y4M contains no audio, this flag will have no effect on the output unless a second audio input is added to the command — the FLV will be produced without an audio stream. |
-crf 23
|
Sets the H.264 Constant Rate Factor to 23, controlling the quality-to-filesize tradeoff for encoding the raw Y4M frames. Lower values (e.g., 15–18) preserve more of the original lossless quality; higher values (28+) produce smaller files with more visible compression artifacts. |
-b:a 128k
|
Sets the AAC audio bitrate to 128 kilobits per second. This is a standard quality level for AAC audio, but since Y4M has no audio track, this flag is effectively dormant for a pure Y4M-to-FLV conversion with no additional audio input. |
output.flv
|
Specifies the output filename and tells FFmpeg to write the result as an FLV (Flash Video) container. The .flv extension causes FFmpeg to use the FLV muxer, which packages the libx264-encoded H.264 video stream into the Flash Video container format. |
Common Use Cases
- Exporting a Y4M intermediate from a compositing or color grading tool (such as Kdenlive or Avisynth) and packaging it into FLV for ingest into a legacy RTMP streaming server
- Archiving the output of a video processing pipeline that outputs Y4M via pipe into a compact, H.264-encoded FLV for long-term storage where Flash-era playback compatibility is required
- Preparing losslessly processed video frames from scientific or broadcast workflows for delivery to older Flash-based video players or kiosk systems that only accept FLV
- Converting Y4M test sequences used in codec benchmarking into FLV to evaluate how H.264 CRF encoding handles specific raw content like gradients, grain, or synthetic patterns
- Reducing the file size of a Y4M output from a video synthesis or render pipeline by encoding it to FLV H.264 before uploading to platforms or tools that accept FLV but not raw video
Frequently Asked Questions
Y4M stores every frame as raw, uncompressed YUV data, so a few seconds of HD video can easily occupy several gigabytes. FLV with H.264 (libx264 at CRF 23) uses temporal and spatial compression to eliminate redundant information between frames, typically achieving compression ratios of 100:1 or more compared to uncompressed Y4M. The tradeoff is that the FLV is lossy — some visual information is permanently discarded, though at CRF 23 this loss is usually imperceptible to the human eye.
Yes. Y4M is a video-only format with no audio stream whatsoever. When FFmpeg processes a Y4M input with the AAC audio flag, it simply finds no audio to encode and produces an FLV with a video-only stream. The output file will be valid and playable, just silent. If you need audio in the FLV, you would need to mux in a separate audio file using an additional '-i' input in the FFmpeg command.
The '-crf 23' flag controls H.264 quality. CRF (Constant Rate Factor) operates on a scale where lower values mean higher quality and larger file sizes — CRF 0 is mathematically lossless, CRF 18 is considered visually near-lossless for most content, and CRF 28+ produces noticeably degraded quality. For a Y4M source that was already lossless, using a CRF between 15 and 18 is recommended if you want to preserve as much of the original visual fidelity as possible in the FLV output.
Yes, you can batch process Y4M files on your desktop using a shell loop. On Linux or macOS, run: for f in *.y4m; do ffmpeg -i "$f" -c:v libx264 -c:a aac -crf 23 -b:a 128k "${f%.y4m}.flv"; done. On Windows Command Prompt, use: for %f in (*.y4m) do ffmpeg -i "%f" -c:v libx264 -c:a aac -crf 23 -b:a 128k "%~nf.flv". The browser-based tool processes one file at a time, so the FFmpeg command is especially useful for batch workflows.
FLV is largely obsolete for modern web delivery — Adobe Flash Player reached end-of-life in December 2020, and all major browsers dropped Flash support. However, FLV remains relevant for RTMP streaming ingest (used by platforms like YouTube Live and Twitch under the hood), legacy kiosk or broadcast systems, and some server-side tools that still consume FLV containers. If your target is a modern browser or device, MP4 with H.264 is a better choice.
Y4M files explicitly signal their YUV color space and chroma subsampling (commonly 4:2:0, 4:2:2, or 4:4:4) in the file header. libx264 reads this information and defaults to encoding in yuv420p for the FLV output, since H.264 in FLV is almost universally expected to use 4:2:0 for broad compatibility. If your Y4M source uses 4:2:2 or 4:4:4 chroma subsampling, that additional color detail will be downsampled during encoding, which is another form of lossy conversion beyond the compression itself.
Technical Notes
Y4M is one of the few formats where every byte of video data is meaningful raw pixel information — there is no codec overhead, no interframe prediction, and no quantization. This makes it ideal as a lossless pipe format between tools like FFmpeg filters, Vapoursynth, or broadcast encoders, but utterly impractical for storage or delivery at scale. Converting to FLV with libx264 changes the fundamental nature of the data: H.264 uses discrete cosine transforms, motion estimation, and entropy coding to represent the video in a fraction of the space, permanently discarding information the encoder judges visually redundant. The FLV container itself imposes some limitations: it does not support subtitles, chapters, or multiple audio tracks, and its metadata capabilities are minimal compared to MKV or MP4. The H.264 profile used by libx264 defaults to 'High' profile, which is widely compatible but worth noting if targeting very old Flash Player versions (which may require Baseline profile — add '-profile:v baseline' to the command if needed). File sizes will vary dramatically depending on the content of the Y4M source: static or low-motion content will compress far more aggressively than high-grain or fast-motion sequences.