Argthtjtr

I created a slideshow on my laptop with the command of

ffmpeg  LOOPS -i "AUDIO_FLAC" -filter_complex "TRANSITION MAP 

concat=n=30:v=1:a=0[v]" -map "[v]" -map 30:a -shortest -q:v 1 -q:a 1 output.mp4

I made the same slideshow on a high-spec desktop and assumed the difference is just the speed. However, the mp4 file generated by the desktop was much smaller without any noticeable loss of quality.

Is it normal that a stronger CPU can produce the video more effectively (by a major degree)? Or there is something different between the machines (e.g., an installed codec). Both machines have Ubuntu 18.04.

UPDATE:

As I checked the files generated by two machines, I somewhat found the difference.

1. The second machine, for a reason I don't know, changed the FLAC input to 12k mp3 despite q:a 1. Then, I had to add -c:a copy -strict -2 to preseve the audio quality.




2. The video codecs were different:

First machine:

Stream #0:0(und): Video: mpeg4 (Simple Profile) (mp4v / 0x7634706D), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 4296 kb/s, 25 fps, 25 tbr, 12800 tbn, 25 tbc (default)

Second machine:

Stream #0:0(und): Video: h264 (High 4:4:4 Predictive) (avc1 / 0x31637661), yuvj444p(pc), 1920x1080 [SAR 1:1 DAR 16:9], 324 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)

I think the huge difference in size (about five times) is due to the fact that the videos were made of fading slideshows. Apparently, these codecs treat fading behaviors quite differently (e.g., repeating the frame; just a guess).

Is it normal that a stronger CPU can produce the video more effectively (by a major degree)?

This depends on what you mean by “effective” and the encoding mode used. There are tradeoffs you have to make while encoding video, and these tradeoffs are:

• speed (in terms of encoding features used)


• file size


• quality

You can fix any two of those points, and there will be tradeoffs for the third. For example, you can have a good-quality file encoded at a small size, but it'll take a long time to encode. Or you fix the quality parameter and choose a fast encoding mode, which will give you a larger file.

Note, however, that this “speed” has nothing to do with time, unless you factor in the speed of the CPU. If you have a stronger CPU and specify a fixed quality for your encode, the file size will still be the same, assuming the same speed settings. The encoding process will just complete faster.

There might also be slight differences in quality and/or file size depending on the CPU capabilities, e.g. once platform-specific optimizations come into play that an encoder may use.

Furthermore, when using multithreading, the output of an encoding process is not guaranteed to be deterministic. You shouldn't see any big file size or quality differences, but frame checksums will not match.

Or there is something different between the machines (e.g., an installed codec)

As you haven't specified any codecs explicitly in your command, ffmpeg may choose the most appropriate one automatically if the default is not available.

For example, if you don't have libx264 (the H.264 encoder) installed, ffmpeg will choose mpeg4 (an MPEG-4 Part II encoder) instead, which is most likely what happened in your case, since MPEG-4 Part II is a much less efficient codec compared to H.264. This again relates to the three bullet points above.

Also, with MP4 output, you cannot use FLAC audio. Your audio will be converted to MP3 or AAC, depending on which encoder your ffmpeg supports.

Tip: Make sure you always explicitly specify which encoder you want with -c:a aac or -c:a libmp3lame, etc. to avoid surprises.

But the only solution would be to compare the encoding logs and look for the differences. If you cannot get those logs, you'd have to check the encoded video for obvious clues like different codecs or average bitrates.

Codecs work (in general terms) deterministically; in other words: the same input with the same codec (version and implementation) and the same settings should provide the same output.

There might be some minor differences based on the codec implementation and the processor instructions used (for example an Intel x86-64 processor could differ on minor points with an ARM implementation; but I would count that as different codec implementations).

I suspect in your case that the underlying codec or codec settings differ.

You can check the codec and codec settings using:

ffprobe -show_streams file.mp4

I suggest you do this for both videos and you’ll see the differences.