You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-color_range tv -colorspace bt709 -color_primaries bt709 -color_trc iec61966-2-1\
65
59
-y outputfile.mp4
66
60
```
67
61
68
62
| --- | --- |
69
63
|**-crf 18**| This is the constant rate factor, controlling the default quality in the range 0-63. By default this is set to 50, which is a little on the low side, using values closer to 18 is recommended, but this does come at the expense of file-size. For more on this see the [CRF comparison](#crf-comparison-for-libsvtav1) below. |
70
-
|**-preset 9**| Help with a trade-off between encoding speed and compression efficiency. Supported preset range in the 0-13. See below for comparisons |
64
+
|**-preset 5**| Help with a trade-off between encoding speed and compression efficiency. Supported preset range in the 0-13. See below for comparisons |
@@ -85,6 +79,14 @@ To help pick appropriate values with the CRF flag, we have run the [Test Framewo
85
79
86
80
### Preset values for libsvtav1
87
81
82
+
| This is showing preset values against encoding time. |
83
+
| This is showing preset values against file size. |
84
+
| This is showing preset values against VMAF harmonic mean |
85
+
| This is showing preset values against PSNR harmonic mean |
86
+
87
+
These graphs are with a CRF of 15 for four different media clips, its showing that the preset values are affecting the amount of compression, but not affecting the quality of the result, at the expense of the encoding time (at least up to preset 9).
88
+
89
+
88
90
See: [SVT-AV1 Common Questions](https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/CommonQuestions.md)
| -cpu-used 6 | This sets how efficient the compression will be. The default is 1, changing this will increase encoding speed at the expense of having some impact on quality and rate control accuracy. Values above 6 are reset to 6 unless real-time encoding is enabled. See below for comparison. |
116
118
| -row-mt 1 | This enables row based multi-threading (see [here](https://trac.ffmpeg.org/wiki/Encode/VP9#rowmt)) which is not enabled by default. |
117
119
| -usage allintra | Encodes for all intra-frames |
120
+
| -arnr-strength | This decreases the amount of noise reduction you get, setting it to 1 helps preserve grain, and some noisy pictures |
121
+
| -aom-params: tune-content=film | There is a tune parameter, but it just seems to make the picture grainy, and is not recommended |
122
+
123
+
Libaom has an aggressive denoiser, which can be pretty good for animated media, but can be a problem for live-action, particularly if there is noisy content, such as water or particles. CRF needs to be lowered to counter this, which does affect encoding speed.
118
124
119
125
### cpu-speed Comparison for libaom-av1
120
126
@@ -129,13 +135,14 @@ To help pick appropriate values with the cpu-speed flag, we have run the [Test F
129
135
130
136
See Also - note these are all guides for AOMENC (the AOM encoder that is part of libaom), but many of the parameters map to ffmpeg:
131
137
*[A 2nd generation guide to aomenc-av1](https://forum.doom9.org/showthread.php?t=183906)
132
-
*[Making aomenc-AV1/libaom-AV1 the best it can be in a sea of uncertainty]((https://old.reddit.com/r/AV1/comments/lfheh9/encoder_tuning_part_2_making_aomencav1libaomav1/)
*[Making aomenc-AV1/libaom-AV1 the best it can be in a sea of uncertainty](https://old.reddit.com/r/AV1/comments/lfheh9/encoder_tuning_part_2_making_aomencav1libaomav1/)
There is no CRF flag, so we are ignoring this for now, but it could be promising down the road.
148
+
There is no CRF flag, so you use the -gp flag, the recommended starting point is about 100. However, we have been unable to get an substantial speed improvement over AOM.
Copy file name to clipboardExpand all lines: EncodeMJPEG.md
+22-6Lines changed: 22 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,12 +7,10 @@ parent: Codec Comparisons
7
7
8
8
# MJPEG - Motion JPEG
9
9
10
-
[Motion JPEG](https://en.wikipedia.org/wiki/Motion_JPEG) has historically been quite common in the VFX industry, and is part of the default quicktime codecs, so is well supported on players, although not typically supported in web browsers.
10
+
[Motion JPEG](https://en.wikipedia.org/wiki/Motion_JPEG) has historically been quite common in the VFX industry, and is part of the default Quicktime codecs, so is well supported on players, although not typically supported in web browsers.
11
11
12
12
While it does compress quickly, and maintains its quality fairly well, we would recommend other codecs at higher bit-depths such as vp9, h264 or h265 (or even Prores or DNxHD), which will also compress better than mjpeg.
|**-qscale:v3**| This is the compression factor, which goes from 2 to 31 where 2 is the best quality. |
44
+
|**-qscale:v2**| This is the compression factor, which goes from 2 to 31 where 2 is the best quality. See alternative approach for better encoding. |
47
45
48
46
49
47
### qscale:v Comparison
@@ -54,3 +52,21 @@ Below is a comparison of different Qscale rates
54
52
| This is showing qscale:v values against file size. |
55
53
| This is showing qscale:v values against VMAF harmonic mean |
56
54
| This is showing qscale:v values against PSNR-Y harmonic mean |
55
+
56
+
## Alternative approach
57
+
58
+
You can generate the individual jpeg files using another tool, and then use ffmpeg to stitch them together. For example, to convert a series of png frames to jpeg, you can use oiiotool:
This gives you more fine grain control over the quality setting, although it gives you less control over the jpeg compression, since it will always be YUV420, where you do get more control with ffmpeg.
68
+
Its actually hard to get an exact mapping between the ffmpeg -qscale setting and the jpeg quality. The highest ffmpeg setting is 2, and that roughly maps to a jpeg quality setting of 86%.
69
+
So if you require higher quality than 86% then use this approach. Settings below 95% do produce artifacts, so this is the recommended approach if you *have* to do this, a 10-bit encoder would be better though.
70
+
71
+
Below shows a comparison of jpeg compression to filesize for a HD sized image sequence of 200 frames.
VP8 is an open-source and royalty free codec developed by the [Alliance for Open Media](https://trac.ffmpeg.org/wiki/Encode/VP8) (AOMedia), a non-profit industry consortium. It will only encode to 8-bit 4:2:0 using the webm container. It is possible to get a similar quality to h264, but not typically at the same compression ratio. It is recommended that you consider [VP9](EncodeVP9.html) which is a considerably better codec. VP8 does support an alpha channel (via the yuva420p pixfmt).
11
+
12
+
General ffmpeg info on VP8 is [here](https://trac.ffmpeg.org/wiki/Encode/VP8), and on the encoder in general [https://www.webmproject.org/docs/encoder-parameters/](https://www.webmproject.org/docs/encoder-parameters/).
13
+
14
+
VP8 has browser support in:
15
+
* Chrome.
16
+
* Edge
17
+
* Firefox
18
+
* Opera
19
+
20
+
VP8 is supported by mkv and webm containers, no support exists for mov or mp4.
-color_range tv -colorspace bt709 -color_primaries bt709 -color_trc iec61966-2-1 \
50
+
-y outputfile.webm
51
+
```
52
+
53
+
54
+
55
+
## Recommended Flags
56
+
57
+
```
58
+
-crf 20 -quality good -b:v 200M -speed 4
59
+
```
60
+
61
+
| --- | --- |
62
+
|**-crf 20**| This is the constant quality rate factor, controlling the default quality, similar to h264. The range is a little different to h264, so you may need to test. |
63
+
|*-quality good*| May require additional testing, but so far switching to *-quality best* increased the duration, but didn't increase the VMAF score (which is already pretty high with these values of crf). |
64
+
| -b:v 200M | Unlike with h264, and vp9 you need to set the bit rate, but you can set it to a high number, and this is the max it would be. |
65
+
| -speed 4 | It sets how efficient the compression will be. Unless you are using -quality best, this doesnt seem to have a setting for |
66
+
67
+
Its possible you might want to change the [GOP](https://aws.amazon.com/blogs/media/part-1-back-to-basics-gops-explained/#:~:text=Simply%20put%2C%20a%20GOP%20is,30%20frames%2C%20or%201%20second.) values (changed with the -g flag), since the default is 240 frames.
68
+
69
+
70
+
### CRF Comparison
71
+
72
+
Below is a comparison of different CRF rates, with -b:v 200M and -quality good
73
+
74
+
75
+
76
+
| This is showing CRF values against encoding time. |
77
+
| This is showing CRF values against file size. |
78
+
| This is showing CRF values against VMAF harmonic mean |
79
+
| This is showing CRF values against psnr y harmonic mean |
80
+
81
+
### Speed Comparison
82
+
83
+
Below is a comparison of different speed rates, -quality good vs. -quality best and with -crf 22, -b:v 200M.
84
+
85
+
This shows that with -quality good the filesize doesnt vary, but with increasing speed settings the encoding time goes down.
86
+
87
+
| This is showing speed against encoding time. |
88
+
| This is showing speed values against file size. |
89
+
| This is showing speed values against VMAF harmonic mean |
90
+
| This is showing speed values against psnr y harmonic mean |
0 commit comments