Lossless universal video format

Question

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).

Solution 1

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.

Solution 2

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

Comments

[wnrph]

For a comparison, see en.wikipedia.org/wiki/List_of_codecs#Lossless_compression

[slhck]

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?

[Marco]

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.

[Elisa Cha Cha]

Can you clarify, "Container + codec can be played on modern DVD players (supporting other formats than DVD)"?

[Youssef]

@LordNeckbeard Nicke nickname :) By that I mean, that most of the modern DVD players (I mean - physical DVD players) can nowadays play other formats than just DVDs.

[Peter Cordes]

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.

[rogerdpack]

ffmpeg has a few other lossless codecs that might be worth trying [FFv1 comes to mind] as well. GL!

[Jonas]

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.

[Jim DeLaHunt]

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.

[Gyan]

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.

[Jonas]

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.

[Jonas]

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 ) )

[Lissanro Rayen]

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".

[Boris Verkhovskiy]

superuser.com/questions/155305/… says that ffmpeg already chooses the optimal number of threads

[LonnieBest]

A better choice than webm (these days) is perhaps the av1 format.

[Steffen Roller]

AV1 is sooo slow to encode.