I am trying to find the most suitable lossless video format for 1280x720 25fps video. The video has 4 minutes. Sound will be 320 kbps mp3, that is not a big deal. Ideal conditions:

  • Lossless (can be perceptionaly lossless)
  • Container + codec can be played on most platforms
  • Container + codec can be played on modern DVD players (supporting other formats than DVD)
  • Size is less than 700 MB

Is that even possible? Have been struggling three days already, without any satisfying results, even getting 12 GB files (seems a lot - 3 GB/minute).

  • 1
    For a comparison, see en.wikipedia.org/wiki/List_of_codecs#Lossless_compression – wnrph Oct 11 '12 at 11:20
  • 4
    I'm sorry but you practically cannot get a (visually) lossless 720p video of 4 minutes compressed to less than 700 MB (I assumed Megabyte here, not "mb" which would mean "bit"). Why do you have such a constraint? Can't the video be h.264-encoded? – slhck Oct 11 '12 at 11:24
  • yes, MB, sorry about the confusion. I need to fit cca 5 videos x 4 minutes into 4 GB (medium limitations). – mrkva Oct 11 '12 at 11:32
  • 2
    Since you're getting 12GiB files I assume that you use 24Bit colour depth. The uncompressed video data stream is about 4GiB per minute. That's a huge amount of data. What you want is about 170MiB per minute. Regardless of the codec you choose you can only achieve this with a static scene without much movement. I'm afraid you have to relax the contraint to be lossless, reduce the frame rate or tolerate a larger file size. – Marco Oct 11 '12 at 11:57
  • Can you clarify, "Container + codec can be played on modern DVD players (supporting other formats than DVD)"? – llogan Oct 11 '12 at 17:17

The best actual, mathematically lossless format I know of is huffyuv, but that will produce hilariously huge files, and wouldn't be compatible with much. For the record, ffmpeg can do it with:

ffmpeg -i input -c:v huffyuv -c:a libmp3lame -b:a 320k output.avi

X264, the open-source h.264 encoder, has a lossless mode. This can go inside an MP4 container, and should be compatible with most hardware made in the last few years. The first command will give a fast encode speed, but large file; the second command will take a lot longer, but the file should be about half the size of the fast-encoded one (it will still be pretty big though):

ffmpeg -i input -c:v libx264 -crf 0 -preset ultrafast -c:a libmp3lame -b:a 320k output.mp4

ffmpeg -i input -c:v libx264 -crf 0 -preset veryslow -c:a libmp3lame -b:a 320k output.mp4

If that doesn't give you a small enough file, a crf of 18 is generally considered 'visually lossless':

ffmpeg -i input -c:v libx264 -crf 18 -preset veryfast -c:a libmp3lame -b:a 320k output.mp4

I generally recommend the veryfast preset for encoding with x264, in my experience it offers the best speed/size tradeoff (there's a big dropoff in file size between superfast and veryfast, any slower than that and it's more incremental). General advice is to use the slowest preset you can handle, the presets are: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow.

See here for a more in-depth guide to x264 encoding.

| improve this answer | |
  • 2
    Don't suggest veryfast as a good default for lossy x264. medium is a good middle ground, but I usually use veryslow for the final encode of anything. Also huffyuv isn't even very fast, I wouldn't recommend it for anything other than compatibility. – Peter Cordes Jan 15 '15 at 1:09
  • ffmpeg has a few other lossless codecs that might be worth trying [FFv1 comes to mind] as well. GL! – rogerdpack Jan 29 '15 at 19:22
  • Doesn't libx264 downsample the two color channels (in YUV the UV) by half in either direction even if you use a CRF of 0 so it's not truly lossless. Also, with rounding errors, the data isn't guaranteed to be bit-for-bit indentical after a round of x264 compression. – Adisak Jun 26 '15 at 16:23
  • 1
    In my experiments with ffmpeg 3.4.1, libx264 used yuv444 pixel format, where "444" means "don't downsample the U,V part". And, the OP explicitly doesn't mind rounding errors: "can be perceptionaly lossless". So, @Adisak, your concerns are reasonable, but not applicable to this answer. – Jim DeLaHunt Jan 10 '18 at 9:13
  • ffmpeg and libx264 in YUV mode will negotiate a YUV pixel format based on the input. So if the input is YUV 4:2:0 then so is the output pixel format. If the input is YUV 4:4:4 or RGB, then output is YUV 4:4:4. – Gyan Jan 11 '18 at 5:29

These days I like webm:

ffmpeg -i input.avi -c:v libvpx-vp9 -lossless 1 output.webm

To convert faster, with multi-core processors, I've read it is recommended to use one less thread than you have of real cores. So, with an 8 core you could specify 7 threads like this:

ffmpeg -i input.avi -c:v libvpx-vp9 -threads 7 -lossless 1 output.webm
| improve this answer | |
  • 1
    I like to use the environment variable %NUMBER_OF_PROCESSORS% to determine thread count to use. If it the count is 1 or 2, I used all the processors. If the count is 3 or 4, I use all but one processor. And if the count is higher, I use all but two processors for the thread count. – Adisak Feb 6 '18 at 22:22
  • 1
    As a DOS expressions, it looks like this: if "%ADJUSTED_CPUCOUNT%" EQU "" ( if %NUMBER_OF_PROCESSORS% EQU 1 ( set ADJUSTED_CPUCOUNT=1 ) else if %NUMBER_OF_PROCESSORS% EQU 2 ( set ADJUSTED_CPUCOUNT=2 ) else if %NUMBER_OF_PROCESSORS% EQU 3 ( set ADJUSTED_CPUCOUNT=2 ) else if %NUMBER_OF_PROCESSORS% EQU 4 ( set ADJUSTED_CPUCOUNT=3 ) else ( set /A ADJUSTED_CPUCOUNT=%NUMBER_OF_PROCESSORS%-2 ) ) – Adisak Feb 6 '18 at 22:23
  • 1
    superuser.com/questions/155305/… says that ffmpeg already chooses the optimal number of threads – Boris Jul 20 '19 at 6:00
  • A better choice than webm (these days) is perhaps the av1 format. – LonnieBest Oct 19 '19 at 19:51
  • AV1 is sooo slow to encode. – Steffen Roller May 10 at 0:18

to have full compatibility with DVD-players, you'll need to use MPEG-2 format, container, restrictions, codecs. I guess, "modern players" means "mp4" compatibility, which is basically and mostly a mp4-file player - H.264, MPEG-4, AVC => libx264
read more: https://de.wikipedia.org/wiki/H.264


Have a look at https://trac.ffmpeg.org/wiki/Encode/H.264, especially the part where it is about "profile" and "level", for compatibility
Using -profile:v high -level 4.0 should do it


Avoid re-encoding audio-tracks with lossy codecs - any mp3 format is lossy, even 320kbps.
Use -c:a copy instead.

So far, it did a pretty good job for me. no sync problems.
Audio streams are not bound to keyframes. Accurate cuts are possible.
If your audio-track is recorded at 44kHz sampling-rate, use max. 256kbps

Use lossy codecs only for the final encode of your video, if you need to fit certain prerequisites.

I've heard of some audio-sync issues, but it looks like the main issue there was, it was protected material(!).

# Finally

I'd prefer something like this:
ffmpeg -i input -c:v libx264 -crf 5 -preset faster -profile:v high -level 4.0 -c:a copy output.mp4

| improve this answer | |
  • Option "-level 4.0" is not needed. Level in x264 is determined based on resolution and FPS, so usually there is no point to set it manually, this will not improve anything. As far as I know ffmpeg can set correct level automatically, so unless you have very good reason to force it and fully understand how to choose level based on FPS and resolution, you should not use "-level" option. If you care about highest compatibility, use "baseline" profile instead "high". – Lissanro Rayen Nov 9 '18 at 13:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.