How can I reduce a video's size with ffmpeg?
How can I use ffmpeg
to reduce the size of a video by lowering the quality (as minimally as possible, naturally, but I need it to run on a mobile device that doesn't have much available space)?
I forgot to write one thing yet. When the video can use subtitles (*.srt or *.sub) I'd like to convert them too to fit the parameters of converted video file.
video ffmpeg compression
|
show 3 more comments
How can I use ffmpeg
to reduce the size of a video by lowering the quality (as minimally as possible, naturally, but I need it to run on a mobile device that doesn't have much available space)?
I forgot to write one thing yet. When the video can use subtitles (*.srt or *.sub) I'd like to convert them too to fit the parameters of converted video file.
video ffmpeg compression
4
I haven't used it but theffmpeg
man page shows a-fs
option to limit the output size, does something likeffmpeg -i in.avi -fs 100M out.avi
work?
– Kevin
Jan 10 '12 at 23:41
1
I will not redirect you to the man page:man ffmpeg | wc -l --> 5254
– user13742
Jan 11 '12 at 0:11
3
The.avi
is not the main issue..avi
is just a container. The main issue is which codecs you use.. Many (most?).avi
vids use older style codecs (eg XviD) which are fine, but are larger for the same quality when compared to the later generation of codecs .. You can typically get a tight encoding by using theH.264
video compression standard (eg. codecx264
) andaac
compression for audio.. The container and codecs you use is up to you and your phone... The.mp4
container is well accepted.. (but can your phone handle it: see this link
– Peter.O
Jan 11 '12 at 1:16
@Kevin This wants more parameters for conversion.
– xralf
Jan 11 '12 at 8:34
@hesse What does it mean?
– xralf
Jan 11 '12 at 8:36
|
show 3 more comments
How can I use ffmpeg
to reduce the size of a video by lowering the quality (as minimally as possible, naturally, but I need it to run on a mobile device that doesn't have much available space)?
I forgot to write one thing yet. When the video can use subtitles (*.srt or *.sub) I'd like to convert them too to fit the parameters of converted video file.
video ffmpeg compression
How can I use ffmpeg
to reduce the size of a video by lowering the quality (as minimally as possible, naturally, but I need it to run on a mobile device that doesn't have much available space)?
I forgot to write one thing yet. When the video can use subtitles (*.srt or *.sub) I'd like to convert them too to fit the parameters of converted video file.
video ffmpeg compression
video ffmpeg compression
edited Jan 11 '12 at 8:38
xralf
asked Jan 10 '12 at 21:45
xralfxralf
2,2431971119
2,2431971119
4
I haven't used it but theffmpeg
man page shows a-fs
option to limit the output size, does something likeffmpeg -i in.avi -fs 100M out.avi
work?
– Kevin
Jan 10 '12 at 23:41
1
I will not redirect you to the man page:man ffmpeg | wc -l --> 5254
– user13742
Jan 11 '12 at 0:11
3
The.avi
is not the main issue..avi
is just a container. The main issue is which codecs you use.. Many (most?).avi
vids use older style codecs (eg XviD) which are fine, but are larger for the same quality when compared to the later generation of codecs .. You can typically get a tight encoding by using theH.264
video compression standard (eg. codecx264
) andaac
compression for audio.. The container and codecs you use is up to you and your phone... The.mp4
container is well accepted.. (but can your phone handle it: see this link
– Peter.O
Jan 11 '12 at 1:16
@Kevin This wants more parameters for conversion.
– xralf
Jan 11 '12 at 8:34
@hesse What does it mean?
– xralf
Jan 11 '12 at 8:36
|
show 3 more comments
4
I haven't used it but theffmpeg
man page shows a-fs
option to limit the output size, does something likeffmpeg -i in.avi -fs 100M out.avi
work?
– Kevin
Jan 10 '12 at 23:41
1
I will not redirect you to the man page:man ffmpeg | wc -l --> 5254
– user13742
Jan 11 '12 at 0:11
3
The.avi
is not the main issue..avi
is just a container. The main issue is which codecs you use.. Many (most?).avi
vids use older style codecs (eg XviD) which are fine, but are larger for the same quality when compared to the later generation of codecs .. You can typically get a tight encoding by using theH.264
video compression standard (eg. codecx264
) andaac
compression for audio.. The container and codecs you use is up to you and your phone... The.mp4
container is well accepted.. (but can your phone handle it: see this link
– Peter.O
Jan 11 '12 at 1:16
@Kevin This wants more parameters for conversion.
– xralf
Jan 11 '12 at 8:34
@hesse What does it mean?
– xralf
Jan 11 '12 at 8:36
4
4
I haven't used it but the
ffmpeg
man page shows a -fs
option to limit the output size, does something like ffmpeg -i in.avi -fs 100M out.avi
work?– Kevin
Jan 10 '12 at 23:41
I haven't used it but the
ffmpeg
man page shows a -fs
option to limit the output size, does something like ffmpeg -i in.avi -fs 100M out.avi
work?– Kevin
Jan 10 '12 at 23:41
1
1
I will not redirect you to the man page:
man ffmpeg | wc -l --> 5254
– user13742
Jan 11 '12 at 0:11
I will not redirect you to the man page:
man ffmpeg | wc -l --> 5254
– user13742
Jan 11 '12 at 0:11
3
3
The
.avi
is not the main issue.. avi
is just a container. The main issue is which codecs you use.. Many (most?) .avi
vids use older style codecs (eg XviD) which are fine, but are larger for the same quality when compared to the later generation of codecs .. You can typically get a tight encoding by using the H.264
video compression standard (eg. codecx264
) and aac
compression for audio.. The container and codecs you use is up to you and your phone... The .mp4
container is well accepted.. (but can your phone handle it: see this link– Peter.O
Jan 11 '12 at 1:16
The
.avi
is not the main issue.. avi
is just a container. The main issue is which codecs you use.. Many (most?) .avi
vids use older style codecs (eg XviD) which are fine, but are larger for the same quality when compared to the later generation of codecs .. You can typically get a tight encoding by using the H.264
video compression standard (eg. codecx264
) and aac
compression for audio.. The container and codecs you use is up to you and your phone... The .mp4
container is well accepted.. (but can your phone handle it: see this link– Peter.O
Jan 11 '12 at 1:16
@Kevin This wants more parameters for conversion.
– xralf
Jan 11 '12 at 8:34
@Kevin This wants more parameters for conversion.
– xralf
Jan 11 '12 at 8:34
@hesse What does it mean?
– xralf
Jan 11 '12 at 8:36
@hesse What does it mean?
– xralf
Jan 11 '12 at 8:36
|
show 3 more comments
7 Answers
7
active
oldest
votes
See this answer. Quoted below for convenience:
Calculate the bitrate you need by dividing 1 GB by the video length in seconds. So, for a video of length 16:40 (1000 seconds), use a bitrate of 1000000 bytes/sec:
ffmpeg -i input.mp4 -b 1000000 output.mp4
Additional options that might be worth considering is setting the Constant Rate Factor, which lowers the average bit rate, but retains better quality. Vary the CRF between around 18 and 24 — the lower, the higher the bitrate.
ffmpeg -i input.mp4 -vcodec libx264 -crf 20 output.mp4
5
This is a four year some time. 😂
– wener
Mar 28 '16 at 14:59
6
Second command, using-crf 24
took a 255.3MB video I had and reduced it to 72.7MB without lowering the quality noticeably. Have an upvote!
– Patrick Roberts
Mar 25 '17 at 18:14
1
Impressively reduced a ~2G video to 14MB, still looks good, this was the first search result and it's exactly what I was looking for, thanks!
– sinisterstuf
Mar 30 '18 at 12:20
3
Might be good to note that you can now uselibx265
for even more size reduction.
– ZN13
Apr 13 '18 at 19:55
5
Usedffmpeg -i input.avi -vcodec libx264 -crf 24 output.avi
. It reduced a 100mb video to 9mb.. Very little change in video quality. Thank you!
– alpha_989
May 23 '18 at 22:02
|
show 9 more comments
Unless you're looking for a specific bitrate, I'd recommend the -crf
option. This is the most commonly used for x264
encoding: http://slhck.info/articles/crf
In short: a CRF of 23 would make "DVD" quality movie (~700MB-1GB) and lower CRF values would be higher quality (larger files).
Please give examples of the full command instead of linking to an external website (which could break someday:)
– Jake Berger
Aug 25 '18 at 17:17
1
@Vicky Chijwani provides the code in the example above. This is better suited to a comment but it was my first activity on this site. The link has more explanation on the crf option but isn’t necessary to get the code to work.
– Tom Kelly
Aug 27 '18 at 12:05
add a comment |
You mentioned wanting to reduce filesize to fit more videos on a mobile device, which is my usecase as well. All the answers here are for reducing the compression quality but nobody has mentioned reducing video frame size. It's a lot quicker, from about 3 to 5 times quicker than recompressing in my experience. See the ffmpeg docs on scaling for more info.
ffmpeg -i input.mkv -vf "scale=iw/2:ih/2" half_the_frame_size.mkv
ffmpeg -i input.mkv -vf "scale=iw/3:ih/3" a_third_the_frame_size.mkv
ffmpeg -i input.mkv -vf "scale=iw/4:ih/4" a_fourth_the_frame_size.mkv
add a comment |
I tested most of the other proposed answers to this question. The test data conclusions are below. These are the proposed answers that I tested:
(BR) Modify the bitrate, using:
ffmpeg -i $infile -b $bitrate $newoutfile
(CR) Vary the Constant Rate Factor, using:
ffmpeg -i $infile -vcodec libx264 -crf 23 $outfile
(SZ) Change the video size (for example to half size), using:
ffmpeg -i $infile -vf "scale=iw/2:ih/2" $outfile
(BL) Change the H.264 profile to "baseline", using:
ffmpeg -i $infile -profile:v baseline $outfile
(DF) Use the default ffmpeg processing, using:
ffmpeg -i $infile $outfile
DATA
- "size" - percent size of the converted video in relation to the original.
- "bitrate" - bitrates of original and converted videos.
- "definition" - pixel size of videos.
- "convert" - time to convert the video in seconds.
I calculated the target bitrate for (BL)using the proposed method.
=== File A - How Node Is Helping To Propel Angular-Fnbixa7Ts6M.mkv ===
original BR CR SZ BL DF
-------- --- -- -- -- --
size 64152 kb 214% 76% 40% 83% 76%
bitrate 411 kb/s 883 313 165 342 313
definition 1920x1080 1920x1080 1920x1080 960x540 1920x1080 1920x1080
convert -- 648 509 225 427 510
=== File B - Using GraphQL with Angular _ By - Lee Costello-OGyFxqt5INw.mkv ===
original BR CR SZ BL DF
-------- --- -- -- -- --
size 410301 kb 33% 109% 28% 143% 109%
bitrate 2687 kb/s 880 2920 764 3843 2920
definition 3840x2160 3840x2160 3840x2160 1920x1080 3840x2160 3840x2160
convert -- 2307 3188 1116 2646 3278
CONCLUSIONS
The (SZ) method is definitely the quickest method. It was 2X to 4X faster. This can be very much an issue on high-def videos, since all of the other methods took longer to convert than the actual length of the video! For example, The (CR) method took 53 minutes to convert the 21 minute video.
The (SZ) method is definitely the best method if the definition of the video is larger than the definition of the screen that will be displaying it. For example, if your phone can only display a 1080p picture, sending it a 3840x2160 video is just wasteful. It would be best to half its size to 1080p.
Some of the proposed answers actually INCREASED the size of some videos. For example, the (BR) method more than doubled the size of the 1080p sample. It did however make the 2160p size one-third. For the high-def sample, the (CR), (BL) and (DF) methods all INCREASED the size of the video.
Correct (or best) Answer
It is always best to first lower the resolution to the maximum supported by your target display.
If you want to reduce file size further, it will depend on personal choices. You can either reduce information content or increase compression.
You can lower the resolution more if that is not something that concerns you.
If the video doesn't include fast action scenes, you may want to lower the frame rate.
If you have a powerful processor and space is the only issue, you can increase the compression rate.
Bit rate is a combination of multiple factors. So just telling ffmpeg to lower the bit rate may not give you the results you want.
Another way of lower information content is to lower the color depth. How to do this was not yet discussed.
add a comment |
Note that it seems that ffmpeg
already performs some optimization when ran without options, so before trying to use settings you don't understand or deciding to explicitly lose information, give a try to a default conversion :
ffmpeg -i input.mp4 output.mp4
In my case it reduced the bitrate of both the video and audio (you can check and compare the input and output file by running ffprobe
on them), transforming a 700 Mb video into a 60 Mb one of seemingly similar quality.
add a comment |
You'll need to use 2-pass encoding to "fit" a video within a designated file size (bitrate), without reducing the quality too drastically. This is quite a detailed topic: http://www.mpabo.com/2014/12/14/ffmpeg-and-x264-encoding-guide/
add a comment |
I have a recipe I originally forged for myself in order to convert the Motion JPEG videos my old camera generates (they are very large videos, since each frame is an entire JPEG image) to h264. Here's an adaptation for other kinds of videos (courses, etc).
I'm not using ffmpeg, but mplayer and mencoder. First, We have to demux the audio with mplayer:
mplayer -vo null -ao pcm:fast:file=<audio_pcm.wav> <video>
- The
-vo null
and-ao null
parameters tells mplayer to not extract video.
In the next steps, we'll do a 3-pass compression with mencoder. At the first pass we'll choose a suitable Constant Quality Mode compression (crf parameter) as a start point:
mencoder <video> -ovc x264
-x264encopts ratetol=100:preset=veryslow:crf=<value>:pass=1
-nosound -o video1.h264
You can add slow_firstpass parameter to the -x264encopts if you are paranoid with the final quality of the video. Mencoder manual says that this option disable some parameters that “significantly improve encoding speed while having little or no impact on the quality of the final pass”. So, use it only at the last step.
You should try several values for crf —
try starting from 25 and goes on increasing it until you note artifacts at the resulting video (higher values compresses more). Remember subsequent encoding passes will improve the quality you have choosed for crf.Alternatives for the veryslow preset are slower, slow, medium etc. See mencoder manual for the complete list.
ratetol controls the bitrate variation — I'm not sure if I'm doing the right thing here, but I set it to the maximum value in order to let total freedom to mencoder to choose the right bitrate for each scene.
After the first pass, you'll note that the last line gives you the average bitrate you will use at the next steps:
(...)
x264 [info]: kb/s:526.43
Change the crf parameter, recommended at the first pass, to bitrate, required at the subsequent passes:
mencoder <video> -ovc x264
-x264encopts slow_firstpass:ratetol=100:preset=veryslow:bitrate=526:pass=3
-nosound -o video2.h264
This second pass encoding will read the statistics generated at the first pass (divx2pass.log
and divx2pass.log.mbtree
) in order to optimize the compression.
Note you'll use the same video input, not the generated by the first pass — first pass' output video is only useful to check the initial quality.
Note also that the
pass=3
(notpass=2
) will generate a new statistics file, so you can repeat the last step as many times you want. I usually dopass=3
twice, always paying attention to the result bitrate.
Meanwhile, you can compress the audio too, using lame
or oggenc
:
oggenc -q<n> <audio_pcm.wav>
Finally, we'll remux audio and video
mencoder -audiofile <audio>.ogg video2.h264 -oac copy -ovc copy
-of lavf -lavfopts format=mp4 -o <video>.mp4
- The
-of lavf -lavfopts format=mp4
generatesmp4
file format using the lavopts muxers.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f28803%2fhow-can-i-reduce-a-videos-size-with-ffmpeg%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
See this answer. Quoted below for convenience:
Calculate the bitrate you need by dividing 1 GB by the video length in seconds. So, for a video of length 16:40 (1000 seconds), use a bitrate of 1000000 bytes/sec:
ffmpeg -i input.mp4 -b 1000000 output.mp4
Additional options that might be worth considering is setting the Constant Rate Factor, which lowers the average bit rate, but retains better quality. Vary the CRF between around 18 and 24 — the lower, the higher the bitrate.
ffmpeg -i input.mp4 -vcodec libx264 -crf 20 output.mp4
5
This is a four year some time. 😂
– wener
Mar 28 '16 at 14:59
6
Second command, using-crf 24
took a 255.3MB video I had and reduced it to 72.7MB without lowering the quality noticeably. Have an upvote!
– Patrick Roberts
Mar 25 '17 at 18:14
1
Impressively reduced a ~2G video to 14MB, still looks good, this was the first search result and it's exactly what I was looking for, thanks!
– sinisterstuf
Mar 30 '18 at 12:20
3
Might be good to note that you can now uselibx265
for even more size reduction.
– ZN13
Apr 13 '18 at 19:55
5
Usedffmpeg -i input.avi -vcodec libx264 -crf 24 output.avi
. It reduced a 100mb video to 9mb.. Very little change in video quality. Thank you!
– alpha_989
May 23 '18 at 22:02
|
show 9 more comments
See this answer. Quoted below for convenience:
Calculate the bitrate you need by dividing 1 GB by the video length in seconds. So, for a video of length 16:40 (1000 seconds), use a bitrate of 1000000 bytes/sec:
ffmpeg -i input.mp4 -b 1000000 output.mp4
Additional options that might be worth considering is setting the Constant Rate Factor, which lowers the average bit rate, but retains better quality. Vary the CRF between around 18 and 24 — the lower, the higher the bitrate.
ffmpeg -i input.mp4 -vcodec libx264 -crf 20 output.mp4
5
This is a four year some time. 😂
– wener
Mar 28 '16 at 14:59
6
Second command, using-crf 24
took a 255.3MB video I had and reduced it to 72.7MB without lowering the quality noticeably. Have an upvote!
– Patrick Roberts
Mar 25 '17 at 18:14
1
Impressively reduced a ~2G video to 14MB, still looks good, this was the first search result and it's exactly what I was looking for, thanks!
– sinisterstuf
Mar 30 '18 at 12:20
3
Might be good to note that you can now uselibx265
for even more size reduction.
– ZN13
Apr 13 '18 at 19:55
5
Usedffmpeg -i input.avi -vcodec libx264 -crf 24 output.avi
. It reduced a 100mb video to 9mb.. Very little change in video quality. Thank you!
– alpha_989
May 23 '18 at 22:02
|
show 9 more comments
See this answer. Quoted below for convenience:
Calculate the bitrate you need by dividing 1 GB by the video length in seconds. So, for a video of length 16:40 (1000 seconds), use a bitrate of 1000000 bytes/sec:
ffmpeg -i input.mp4 -b 1000000 output.mp4
Additional options that might be worth considering is setting the Constant Rate Factor, which lowers the average bit rate, but retains better quality. Vary the CRF between around 18 and 24 — the lower, the higher the bitrate.
ffmpeg -i input.mp4 -vcodec libx264 -crf 20 output.mp4
See this answer. Quoted below for convenience:
Calculate the bitrate you need by dividing 1 GB by the video length in seconds. So, for a video of length 16:40 (1000 seconds), use a bitrate of 1000000 bytes/sec:
ffmpeg -i input.mp4 -b 1000000 output.mp4
Additional options that might be worth considering is setting the Constant Rate Factor, which lowers the average bit rate, but retains better quality. Vary the CRF between around 18 and 24 — the lower, the higher the bitrate.
ffmpeg -i input.mp4 -vcodec libx264 -crf 20 output.mp4
edited Mar 26 '17 at 13:44
answered May 11 '12 at 5:36
Vicky ChijwaniVicky Chijwani
2,21211313
2,21211313
5
This is a four year some time. 😂
– wener
Mar 28 '16 at 14:59
6
Second command, using-crf 24
took a 255.3MB video I had and reduced it to 72.7MB without lowering the quality noticeably. Have an upvote!
– Patrick Roberts
Mar 25 '17 at 18:14
1
Impressively reduced a ~2G video to 14MB, still looks good, this was the first search result and it's exactly what I was looking for, thanks!
– sinisterstuf
Mar 30 '18 at 12:20
3
Might be good to note that you can now uselibx265
for even more size reduction.
– ZN13
Apr 13 '18 at 19:55
5
Usedffmpeg -i input.avi -vcodec libx264 -crf 24 output.avi
. It reduced a 100mb video to 9mb.. Very little change in video quality. Thank you!
– alpha_989
May 23 '18 at 22:02
|
show 9 more comments
5
This is a four year some time. 😂
– wener
Mar 28 '16 at 14:59
6
Second command, using-crf 24
took a 255.3MB video I had and reduced it to 72.7MB without lowering the quality noticeably. Have an upvote!
– Patrick Roberts
Mar 25 '17 at 18:14
1
Impressively reduced a ~2G video to 14MB, still looks good, this was the first search result and it's exactly what I was looking for, thanks!
– sinisterstuf
Mar 30 '18 at 12:20
3
Might be good to note that you can now uselibx265
for even more size reduction.
– ZN13
Apr 13 '18 at 19:55
5
Usedffmpeg -i input.avi -vcodec libx264 -crf 24 output.avi
. It reduced a 100mb video to 9mb.. Very little change in video quality. Thank you!
– alpha_989
May 23 '18 at 22:02
5
5
This is a four year some time. 😂
– wener
Mar 28 '16 at 14:59
This is a four year some time. 😂
– wener
Mar 28 '16 at 14:59
6
6
Second command, using
-crf 24
took a 255.3MB video I had and reduced it to 72.7MB without lowering the quality noticeably. Have an upvote!– Patrick Roberts
Mar 25 '17 at 18:14
Second command, using
-crf 24
took a 255.3MB video I had and reduced it to 72.7MB without lowering the quality noticeably. Have an upvote!– Patrick Roberts
Mar 25 '17 at 18:14
1
1
Impressively reduced a ~2G video to 14MB, still looks good, this was the first search result and it's exactly what I was looking for, thanks!
– sinisterstuf
Mar 30 '18 at 12:20
Impressively reduced a ~2G video to 14MB, still looks good, this was the first search result and it's exactly what I was looking for, thanks!
– sinisterstuf
Mar 30 '18 at 12:20
3
3
Might be good to note that you can now use
libx265
for even more size reduction.– ZN13
Apr 13 '18 at 19:55
Might be good to note that you can now use
libx265
for even more size reduction.– ZN13
Apr 13 '18 at 19:55
5
5
Used
ffmpeg -i input.avi -vcodec libx264 -crf 24 output.avi
. It reduced a 100mb video to 9mb.. Very little change in video quality. Thank you!– alpha_989
May 23 '18 at 22:02
Used
ffmpeg -i input.avi -vcodec libx264 -crf 24 output.avi
. It reduced a 100mb video to 9mb.. Very little change in video quality. Thank you!– alpha_989
May 23 '18 at 22:02
|
show 9 more comments
Unless you're looking for a specific bitrate, I'd recommend the -crf
option. This is the most commonly used for x264
encoding: http://slhck.info/articles/crf
In short: a CRF of 23 would make "DVD" quality movie (~700MB-1GB) and lower CRF values would be higher quality (larger files).
Please give examples of the full command instead of linking to an external website (which could break someday:)
– Jake Berger
Aug 25 '18 at 17:17
1
@Vicky Chijwani provides the code in the example above. This is better suited to a comment but it was my first activity on this site. The link has more explanation on the crf option but isn’t necessary to get the code to work.
– Tom Kelly
Aug 27 '18 at 12:05
add a comment |
Unless you're looking for a specific bitrate, I'd recommend the -crf
option. This is the most commonly used for x264
encoding: http://slhck.info/articles/crf
In short: a CRF of 23 would make "DVD" quality movie (~700MB-1GB) and lower CRF values would be higher quality (larger files).
Please give examples of the full command instead of linking to an external website (which could break someday:)
– Jake Berger
Aug 25 '18 at 17:17
1
@Vicky Chijwani provides the code in the example above. This is better suited to a comment but it was my first activity on this site. The link has more explanation on the crf option but isn’t necessary to get the code to work.
– Tom Kelly
Aug 27 '18 at 12:05
add a comment |
Unless you're looking for a specific bitrate, I'd recommend the -crf
option. This is the most commonly used for x264
encoding: http://slhck.info/articles/crf
In short: a CRF of 23 would make "DVD" quality movie (~700MB-1GB) and lower CRF values would be higher quality (larger files).
Unless you're looking for a specific bitrate, I'd recommend the -crf
option. This is the most commonly used for x264
encoding: http://slhck.info/articles/crf
In short: a CRF of 23 would make "DVD" quality movie (~700MB-1GB) and lower CRF values would be higher quality (larger files).
answered Jan 14 '17 at 13:50
Tom KellyTom Kelly
34726
34726
Please give examples of the full command instead of linking to an external website (which could break someday:)
– Jake Berger
Aug 25 '18 at 17:17
1
@Vicky Chijwani provides the code in the example above. This is better suited to a comment but it was my first activity on this site. The link has more explanation on the crf option but isn’t necessary to get the code to work.
– Tom Kelly
Aug 27 '18 at 12:05
add a comment |
Please give examples of the full command instead of linking to an external website (which could break someday:)
– Jake Berger
Aug 25 '18 at 17:17
1
@Vicky Chijwani provides the code in the example above. This is better suited to a comment but it was my first activity on this site. The link has more explanation on the crf option but isn’t necessary to get the code to work.
– Tom Kelly
Aug 27 '18 at 12:05
Please give examples of the full command instead of linking to an external website (which could break someday:)
– Jake Berger
Aug 25 '18 at 17:17
Please give examples of the full command instead of linking to an external website (which could break someday:)
– Jake Berger
Aug 25 '18 at 17:17
1
1
@Vicky Chijwani provides the code in the example above. This is better suited to a comment but it was my first activity on this site. The link has more explanation on the crf option but isn’t necessary to get the code to work.
– Tom Kelly
Aug 27 '18 at 12:05
@Vicky Chijwani provides the code in the example above. This is better suited to a comment but it was my first activity on this site. The link has more explanation on the crf option but isn’t necessary to get the code to work.
– Tom Kelly
Aug 27 '18 at 12:05
add a comment |
You mentioned wanting to reduce filesize to fit more videos on a mobile device, which is my usecase as well. All the answers here are for reducing the compression quality but nobody has mentioned reducing video frame size. It's a lot quicker, from about 3 to 5 times quicker than recompressing in my experience. See the ffmpeg docs on scaling for more info.
ffmpeg -i input.mkv -vf "scale=iw/2:ih/2" half_the_frame_size.mkv
ffmpeg -i input.mkv -vf "scale=iw/3:ih/3" a_third_the_frame_size.mkv
ffmpeg -i input.mkv -vf "scale=iw/4:ih/4" a_fourth_the_frame_size.mkv
add a comment |
You mentioned wanting to reduce filesize to fit more videos on a mobile device, which is my usecase as well. All the answers here are for reducing the compression quality but nobody has mentioned reducing video frame size. It's a lot quicker, from about 3 to 5 times quicker than recompressing in my experience. See the ffmpeg docs on scaling for more info.
ffmpeg -i input.mkv -vf "scale=iw/2:ih/2" half_the_frame_size.mkv
ffmpeg -i input.mkv -vf "scale=iw/3:ih/3" a_third_the_frame_size.mkv
ffmpeg -i input.mkv -vf "scale=iw/4:ih/4" a_fourth_the_frame_size.mkv
add a comment |
You mentioned wanting to reduce filesize to fit more videos on a mobile device, which is my usecase as well. All the answers here are for reducing the compression quality but nobody has mentioned reducing video frame size. It's a lot quicker, from about 3 to 5 times quicker than recompressing in my experience. See the ffmpeg docs on scaling for more info.
ffmpeg -i input.mkv -vf "scale=iw/2:ih/2" half_the_frame_size.mkv
ffmpeg -i input.mkv -vf "scale=iw/3:ih/3" a_third_the_frame_size.mkv
ffmpeg -i input.mkv -vf "scale=iw/4:ih/4" a_fourth_the_frame_size.mkv
You mentioned wanting to reduce filesize to fit more videos on a mobile device, which is my usecase as well. All the answers here are for reducing the compression quality but nobody has mentioned reducing video frame size. It's a lot quicker, from about 3 to 5 times quicker than recompressing in my experience. See the ffmpeg docs on scaling for more info.
ffmpeg -i input.mkv -vf "scale=iw/2:ih/2" half_the_frame_size.mkv
ffmpeg -i input.mkv -vf "scale=iw/3:ih/3" a_third_the_frame_size.mkv
ffmpeg -i input.mkv -vf "scale=iw/4:ih/4" a_fourth_the_frame_size.mkv
answered Jun 2 '18 at 19:07
georgiecaseygeorgiecasey
24123
24123
add a comment |
add a comment |
I tested most of the other proposed answers to this question. The test data conclusions are below. These are the proposed answers that I tested:
(BR) Modify the bitrate, using:
ffmpeg -i $infile -b $bitrate $newoutfile
(CR) Vary the Constant Rate Factor, using:
ffmpeg -i $infile -vcodec libx264 -crf 23 $outfile
(SZ) Change the video size (for example to half size), using:
ffmpeg -i $infile -vf "scale=iw/2:ih/2" $outfile
(BL) Change the H.264 profile to "baseline", using:
ffmpeg -i $infile -profile:v baseline $outfile
(DF) Use the default ffmpeg processing, using:
ffmpeg -i $infile $outfile
DATA
- "size" - percent size of the converted video in relation to the original.
- "bitrate" - bitrates of original and converted videos.
- "definition" - pixel size of videos.
- "convert" - time to convert the video in seconds.
I calculated the target bitrate for (BL)using the proposed method.
=== File A - How Node Is Helping To Propel Angular-Fnbixa7Ts6M.mkv ===
original BR CR SZ BL DF
-------- --- -- -- -- --
size 64152 kb 214% 76% 40% 83% 76%
bitrate 411 kb/s 883 313 165 342 313
definition 1920x1080 1920x1080 1920x1080 960x540 1920x1080 1920x1080
convert -- 648 509 225 427 510
=== File B - Using GraphQL with Angular _ By - Lee Costello-OGyFxqt5INw.mkv ===
original BR CR SZ BL DF
-------- --- -- -- -- --
size 410301 kb 33% 109% 28% 143% 109%
bitrate 2687 kb/s 880 2920 764 3843 2920
definition 3840x2160 3840x2160 3840x2160 1920x1080 3840x2160 3840x2160
convert -- 2307 3188 1116 2646 3278
CONCLUSIONS
The (SZ) method is definitely the quickest method. It was 2X to 4X faster. This can be very much an issue on high-def videos, since all of the other methods took longer to convert than the actual length of the video! For example, The (CR) method took 53 minutes to convert the 21 minute video.
The (SZ) method is definitely the best method if the definition of the video is larger than the definition of the screen that will be displaying it. For example, if your phone can only display a 1080p picture, sending it a 3840x2160 video is just wasteful. It would be best to half its size to 1080p.
Some of the proposed answers actually INCREASED the size of some videos. For example, the (BR) method more than doubled the size of the 1080p sample. It did however make the 2160p size one-third. For the high-def sample, the (CR), (BL) and (DF) methods all INCREASED the size of the video.
Correct (or best) Answer
It is always best to first lower the resolution to the maximum supported by your target display.
If you want to reduce file size further, it will depend on personal choices. You can either reduce information content or increase compression.
You can lower the resolution more if that is not something that concerns you.
If the video doesn't include fast action scenes, you may want to lower the frame rate.
If you have a powerful processor and space is the only issue, you can increase the compression rate.
Bit rate is a combination of multiple factors. So just telling ffmpeg to lower the bit rate may not give you the results you want.
Another way of lower information content is to lower the color depth. How to do this was not yet discussed.
add a comment |
I tested most of the other proposed answers to this question. The test data conclusions are below. These are the proposed answers that I tested:
(BR) Modify the bitrate, using:
ffmpeg -i $infile -b $bitrate $newoutfile
(CR) Vary the Constant Rate Factor, using:
ffmpeg -i $infile -vcodec libx264 -crf 23 $outfile
(SZ) Change the video size (for example to half size), using:
ffmpeg -i $infile -vf "scale=iw/2:ih/2" $outfile
(BL) Change the H.264 profile to "baseline", using:
ffmpeg -i $infile -profile:v baseline $outfile
(DF) Use the default ffmpeg processing, using:
ffmpeg -i $infile $outfile
DATA
- "size" - percent size of the converted video in relation to the original.
- "bitrate" - bitrates of original and converted videos.
- "definition" - pixel size of videos.
- "convert" - time to convert the video in seconds.
I calculated the target bitrate for (BL)using the proposed method.
=== File A - How Node Is Helping To Propel Angular-Fnbixa7Ts6M.mkv ===
original BR CR SZ BL DF
-------- --- -- -- -- --
size 64152 kb 214% 76% 40% 83% 76%
bitrate 411 kb/s 883 313 165 342 313
definition 1920x1080 1920x1080 1920x1080 960x540 1920x1080 1920x1080
convert -- 648 509 225 427 510
=== File B - Using GraphQL with Angular _ By - Lee Costello-OGyFxqt5INw.mkv ===
original BR CR SZ BL DF
-------- --- -- -- -- --
size 410301 kb 33% 109% 28% 143% 109%
bitrate 2687 kb/s 880 2920 764 3843 2920
definition 3840x2160 3840x2160 3840x2160 1920x1080 3840x2160 3840x2160
convert -- 2307 3188 1116 2646 3278
CONCLUSIONS
The (SZ) method is definitely the quickest method. It was 2X to 4X faster. This can be very much an issue on high-def videos, since all of the other methods took longer to convert than the actual length of the video! For example, The (CR) method took 53 minutes to convert the 21 minute video.
The (SZ) method is definitely the best method if the definition of the video is larger than the definition of the screen that will be displaying it. For example, if your phone can only display a 1080p picture, sending it a 3840x2160 video is just wasteful. It would be best to half its size to 1080p.
Some of the proposed answers actually INCREASED the size of some videos. For example, the (BR) method more than doubled the size of the 1080p sample. It did however make the 2160p size one-third. For the high-def sample, the (CR), (BL) and (DF) methods all INCREASED the size of the video.
Correct (or best) Answer
It is always best to first lower the resolution to the maximum supported by your target display.
If you want to reduce file size further, it will depend on personal choices. You can either reduce information content or increase compression.
You can lower the resolution more if that is not something that concerns you.
If the video doesn't include fast action scenes, you may want to lower the frame rate.
If you have a powerful processor and space is the only issue, you can increase the compression rate.
Bit rate is a combination of multiple factors. So just telling ffmpeg to lower the bit rate may not give you the results you want.
Another way of lower information content is to lower the color depth. How to do this was not yet discussed.
add a comment |
I tested most of the other proposed answers to this question. The test data conclusions are below. These are the proposed answers that I tested:
(BR) Modify the bitrate, using:
ffmpeg -i $infile -b $bitrate $newoutfile
(CR) Vary the Constant Rate Factor, using:
ffmpeg -i $infile -vcodec libx264 -crf 23 $outfile
(SZ) Change the video size (for example to half size), using:
ffmpeg -i $infile -vf "scale=iw/2:ih/2" $outfile
(BL) Change the H.264 profile to "baseline", using:
ffmpeg -i $infile -profile:v baseline $outfile
(DF) Use the default ffmpeg processing, using:
ffmpeg -i $infile $outfile
DATA
- "size" - percent size of the converted video in relation to the original.
- "bitrate" - bitrates of original and converted videos.
- "definition" - pixel size of videos.
- "convert" - time to convert the video in seconds.
I calculated the target bitrate for (BL)using the proposed method.
=== File A - How Node Is Helping To Propel Angular-Fnbixa7Ts6M.mkv ===
original BR CR SZ BL DF
-------- --- -- -- -- --
size 64152 kb 214% 76% 40% 83% 76%
bitrate 411 kb/s 883 313 165 342 313
definition 1920x1080 1920x1080 1920x1080 960x540 1920x1080 1920x1080
convert -- 648 509 225 427 510
=== File B - Using GraphQL with Angular _ By - Lee Costello-OGyFxqt5INw.mkv ===
original BR CR SZ BL DF
-------- --- -- -- -- --
size 410301 kb 33% 109% 28% 143% 109%
bitrate 2687 kb/s 880 2920 764 3843 2920
definition 3840x2160 3840x2160 3840x2160 1920x1080 3840x2160 3840x2160
convert -- 2307 3188 1116 2646 3278
CONCLUSIONS
The (SZ) method is definitely the quickest method. It was 2X to 4X faster. This can be very much an issue on high-def videos, since all of the other methods took longer to convert than the actual length of the video! For example, The (CR) method took 53 minutes to convert the 21 minute video.
The (SZ) method is definitely the best method if the definition of the video is larger than the definition of the screen that will be displaying it. For example, if your phone can only display a 1080p picture, sending it a 3840x2160 video is just wasteful. It would be best to half its size to 1080p.
Some of the proposed answers actually INCREASED the size of some videos. For example, the (BR) method more than doubled the size of the 1080p sample. It did however make the 2160p size one-third. For the high-def sample, the (CR), (BL) and (DF) methods all INCREASED the size of the video.
Correct (or best) Answer
It is always best to first lower the resolution to the maximum supported by your target display.
If you want to reduce file size further, it will depend on personal choices. You can either reduce information content or increase compression.
You can lower the resolution more if that is not something that concerns you.
If the video doesn't include fast action scenes, you may want to lower the frame rate.
If you have a powerful processor and space is the only issue, you can increase the compression rate.
Bit rate is a combination of multiple factors. So just telling ffmpeg to lower the bit rate may not give you the results you want.
Another way of lower information content is to lower the color depth. How to do this was not yet discussed.
I tested most of the other proposed answers to this question. The test data conclusions are below. These are the proposed answers that I tested:
(BR) Modify the bitrate, using:
ffmpeg -i $infile -b $bitrate $newoutfile
(CR) Vary the Constant Rate Factor, using:
ffmpeg -i $infile -vcodec libx264 -crf 23 $outfile
(SZ) Change the video size (for example to half size), using:
ffmpeg -i $infile -vf "scale=iw/2:ih/2" $outfile
(BL) Change the H.264 profile to "baseline", using:
ffmpeg -i $infile -profile:v baseline $outfile
(DF) Use the default ffmpeg processing, using:
ffmpeg -i $infile $outfile
DATA
- "size" - percent size of the converted video in relation to the original.
- "bitrate" - bitrates of original and converted videos.
- "definition" - pixel size of videos.
- "convert" - time to convert the video in seconds.
I calculated the target bitrate for (BL)using the proposed method.
=== File A - How Node Is Helping To Propel Angular-Fnbixa7Ts6M.mkv ===
original BR CR SZ BL DF
-------- --- -- -- -- --
size 64152 kb 214% 76% 40% 83% 76%
bitrate 411 kb/s 883 313 165 342 313
definition 1920x1080 1920x1080 1920x1080 960x540 1920x1080 1920x1080
convert -- 648 509 225 427 510
=== File B - Using GraphQL with Angular _ By - Lee Costello-OGyFxqt5INw.mkv ===
original BR CR SZ BL DF
-------- --- -- -- -- --
size 410301 kb 33% 109% 28% 143% 109%
bitrate 2687 kb/s 880 2920 764 3843 2920
definition 3840x2160 3840x2160 3840x2160 1920x1080 3840x2160 3840x2160
convert -- 2307 3188 1116 2646 3278
CONCLUSIONS
The (SZ) method is definitely the quickest method. It was 2X to 4X faster. This can be very much an issue on high-def videos, since all of the other methods took longer to convert than the actual length of the video! For example, The (CR) method took 53 minutes to convert the 21 minute video.
The (SZ) method is definitely the best method if the definition of the video is larger than the definition of the screen that will be displaying it. For example, if your phone can only display a 1080p picture, sending it a 3840x2160 video is just wasteful. It would be best to half its size to 1080p.
Some of the proposed answers actually INCREASED the size of some videos. For example, the (BR) method more than doubled the size of the 1080p sample. It did however make the 2160p size one-third. For the high-def sample, the (CR), (BL) and (DF) methods all INCREASED the size of the video.
Correct (or best) Answer
It is always best to first lower the resolution to the maximum supported by your target display.
If you want to reduce file size further, it will depend on personal choices. You can either reduce information content or increase compression.
You can lower the resolution more if that is not something that concerns you.
If the video doesn't include fast action scenes, you may want to lower the frame rate.
If you have a powerful processor and space is the only issue, you can increase the compression rate.
Bit rate is a combination of multiple factors. So just telling ffmpeg to lower the bit rate may not give you the results you want.
Another way of lower information content is to lower the color depth. How to do this was not yet discussed.
edited Feb 5 at 23:49
answered Feb 4 at 17:55
John PankowiczJohn Pankowicz
1413
1413
add a comment |
add a comment |
Note that it seems that ffmpeg
already performs some optimization when ran without options, so before trying to use settings you don't understand or deciding to explicitly lose information, give a try to a default conversion :
ffmpeg -i input.mp4 output.mp4
In my case it reduced the bitrate of both the video and audio (you can check and compare the input and output file by running ffprobe
on them), transforming a 700 Mb video into a 60 Mb one of seemingly similar quality.
add a comment |
Note that it seems that ffmpeg
already performs some optimization when ran without options, so before trying to use settings you don't understand or deciding to explicitly lose information, give a try to a default conversion :
ffmpeg -i input.mp4 output.mp4
In my case it reduced the bitrate of both the video and audio (you can check and compare the input and output file by running ffprobe
on them), transforming a 700 Mb video into a 60 Mb one of seemingly similar quality.
add a comment |
Note that it seems that ffmpeg
already performs some optimization when ran without options, so before trying to use settings you don't understand or deciding to explicitly lose information, give a try to a default conversion :
ffmpeg -i input.mp4 output.mp4
In my case it reduced the bitrate of both the video and audio (you can check and compare the input and output file by running ffprobe
on them), transforming a 700 Mb video into a 60 Mb one of seemingly similar quality.
Note that it seems that ffmpeg
already performs some optimization when ran without options, so before trying to use settings you don't understand or deciding to explicitly lose information, give a try to a default conversion :
ffmpeg -i input.mp4 output.mp4
In my case it reduced the bitrate of both the video and audio (you can check and compare the input and output file by running ffprobe
on them), transforming a 700 Mb video into a 60 Mb one of seemingly similar quality.
answered Jan 1 at 21:04
Skippy le Grand GourouSkippy le Grand Gourou
1,0721122
1,0721122
add a comment |
add a comment |
You'll need to use 2-pass encoding to "fit" a video within a designated file size (bitrate), without reducing the quality too drastically. This is quite a detailed topic: http://www.mpabo.com/2014/12/14/ffmpeg-and-x264-encoding-guide/
add a comment |
You'll need to use 2-pass encoding to "fit" a video within a designated file size (bitrate), without reducing the quality too drastically. This is quite a detailed topic: http://www.mpabo.com/2014/12/14/ffmpeg-and-x264-encoding-guide/
add a comment |
You'll need to use 2-pass encoding to "fit" a video within a designated file size (bitrate), without reducing the quality too drastically. This is quite a detailed topic: http://www.mpabo.com/2014/12/14/ffmpeg-and-x264-encoding-guide/
You'll need to use 2-pass encoding to "fit" a video within a designated file size (bitrate), without reducing the quality too drastically. This is quite a detailed topic: http://www.mpabo.com/2014/12/14/ffmpeg-and-x264-encoding-guide/
answered Jun 12 '16 at 18:20
SaltySub2SaltySub2
1112
1112
add a comment |
add a comment |
I have a recipe I originally forged for myself in order to convert the Motion JPEG videos my old camera generates (they are very large videos, since each frame is an entire JPEG image) to h264. Here's an adaptation for other kinds of videos (courses, etc).
I'm not using ffmpeg, but mplayer and mencoder. First, We have to demux the audio with mplayer:
mplayer -vo null -ao pcm:fast:file=<audio_pcm.wav> <video>
- The
-vo null
and-ao null
parameters tells mplayer to not extract video.
In the next steps, we'll do a 3-pass compression with mencoder. At the first pass we'll choose a suitable Constant Quality Mode compression (crf parameter) as a start point:
mencoder <video> -ovc x264
-x264encopts ratetol=100:preset=veryslow:crf=<value>:pass=1
-nosound -o video1.h264
You can add slow_firstpass parameter to the -x264encopts if you are paranoid with the final quality of the video. Mencoder manual says that this option disable some parameters that “significantly improve encoding speed while having little or no impact on the quality of the final pass”. So, use it only at the last step.
You should try several values for crf —
try starting from 25 and goes on increasing it until you note artifacts at the resulting video (higher values compresses more). Remember subsequent encoding passes will improve the quality you have choosed for crf.Alternatives for the veryslow preset are slower, slow, medium etc. See mencoder manual for the complete list.
ratetol controls the bitrate variation — I'm not sure if I'm doing the right thing here, but I set it to the maximum value in order to let total freedom to mencoder to choose the right bitrate for each scene.
After the first pass, you'll note that the last line gives you the average bitrate you will use at the next steps:
(...)
x264 [info]: kb/s:526.43
Change the crf parameter, recommended at the first pass, to bitrate, required at the subsequent passes:
mencoder <video> -ovc x264
-x264encopts slow_firstpass:ratetol=100:preset=veryslow:bitrate=526:pass=3
-nosound -o video2.h264
This second pass encoding will read the statistics generated at the first pass (divx2pass.log
and divx2pass.log.mbtree
) in order to optimize the compression.
Note you'll use the same video input, not the generated by the first pass — first pass' output video is only useful to check the initial quality.
Note also that the
pass=3
(notpass=2
) will generate a new statistics file, so you can repeat the last step as many times you want. I usually dopass=3
twice, always paying attention to the result bitrate.
Meanwhile, you can compress the audio too, using lame
or oggenc
:
oggenc -q<n> <audio_pcm.wav>
Finally, we'll remux audio and video
mencoder -audiofile <audio>.ogg video2.h264 -oac copy -ovc copy
-of lavf -lavfopts format=mp4 -o <video>.mp4
- The
-of lavf -lavfopts format=mp4
generatesmp4
file format using the lavopts muxers.
add a comment |
I have a recipe I originally forged for myself in order to convert the Motion JPEG videos my old camera generates (they are very large videos, since each frame is an entire JPEG image) to h264. Here's an adaptation for other kinds of videos (courses, etc).
I'm not using ffmpeg, but mplayer and mencoder. First, We have to demux the audio with mplayer:
mplayer -vo null -ao pcm:fast:file=<audio_pcm.wav> <video>
- The
-vo null
and-ao null
parameters tells mplayer to not extract video.
In the next steps, we'll do a 3-pass compression with mencoder. At the first pass we'll choose a suitable Constant Quality Mode compression (crf parameter) as a start point:
mencoder <video> -ovc x264
-x264encopts ratetol=100:preset=veryslow:crf=<value>:pass=1
-nosound -o video1.h264
You can add slow_firstpass parameter to the -x264encopts if you are paranoid with the final quality of the video. Mencoder manual says that this option disable some parameters that “significantly improve encoding speed while having little or no impact on the quality of the final pass”. So, use it only at the last step.
You should try several values for crf —
try starting from 25 and goes on increasing it until you note artifacts at the resulting video (higher values compresses more). Remember subsequent encoding passes will improve the quality you have choosed for crf.Alternatives for the veryslow preset are slower, slow, medium etc. See mencoder manual for the complete list.
ratetol controls the bitrate variation — I'm not sure if I'm doing the right thing here, but I set it to the maximum value in order to let total freedom to mencoder to choose the right bitrate for each scene.
After the first pass, you'll note that the last line gives you the average bitrate you will use at the next steps:
(...)
x264 [info]: kb/s:526.43
Change the crf parameter, recommended at the first pass, to bitrate, required at the subsequent passes:
mencoder <video> -ovc x264
-x264encopts slow_firstpass:ratetol=100:preset=veryslow:bitrate=526:pass=3
-nosound -o video2.h264
This second pass encoding will read the statistics generated at the first pass (divx2pass.log
and divx2pass.log.mbtree
) in order to optimize the compression.
Note you'll use the same video input, not the generated by the first pass — first pass' output video is only useful to check the initial quality.
Note also that the
pass=3
(notpass=2
) will generate a new statistics file, so you can repeat the last step as many times you want. I usually dopass=3
twice, always paying attention to the result bitrate.
Meanwhile, you can compress the audio too, using lame
or oggenc
:
oggenc -q<n> <audio_pcm.wav>
Finally, we'll remux audio and video
mencoder -audiofile <audio>.ogg video2.h264 -oac copy -ovc copy
-of lavf -lavfopts format=mp4 -o <video>.mp4
- The
-of lavf -lavfopts format=mp4
generatesmp4
file format using the lavopts muxers.
add a comment |
I have a recipe I originally forged for myself in order to convert the Motion JPEG videos my old camera generates (they are very large videos, since each frame is an entire JPEG image) to h264. Here's an adaptation for other kinds of videos (courses, etc).
I'm not using ffmpeg, but mplayer and mencoder. First, We have to demux the audio with mplayer:
mplayer -vo null -ao pcm:fast:file=<audio_pcm.wav> <video>
- The
-vo null
and-ao null
parameters tells mplayer to not extract video.
In the next steps, we'll do a 3-pass compression with mencoder. At the first pass we'll choose a suitable Constant Quality Mode compression (crf parameter) as a start point:
mencoder <video> -ovc x264
-x264encopts ratetol=100:preset=veryslow:crf=<value>:pass=1
-nosound -o video1.h264
You can add slow_firstpass parameter to the -x264encopts if you are paranoid with the final quality of the video. Mencoder manual says that this option disable some parameters that “significantly improve encoding speed while having little or no impact on the quality of the final pass”. So, use it only at the last step.
You should try several values for crf —
try starting from 25 and goes on increasing it until you note artifacts at the resulting video (higher values compresses more). Remember subsequent encoding passes will improve the quality you have choosed for crf.Alternatives for the veryslow preset are slower, slow, medium etc. See mencoder manual for the complete list.
ratetol controls the bitrate variation — I'm not sure if I'm doing the right thing here, but I set it to the maximum value in order to let total freedom to mencoder to choose the right bitrate for each scene.
After the first pass, you'll note that the last line gives you the average bitrate you will use at the next steps:
(...)
x264 [info]: kb/s:526.43
Change the crf parameter, recommended at the first pass, to bitrate, required at the subsequent passes:
mencoder <video> -ovc x264
-x264encopts slow_firstpass:ratetol=100:preset=veryslow:bitrate=526:pass=3
-nosound -o video2.h264
This second pass encoding will read the statistics generated at the first pass (divx2pass.log
and divx2pass.log.mbtree
) in order to optimize the compression.
Note you'll use the same video input, not the generated by the first pass — first pass' output video is only useful to check the initial quality.
Note also that the
pass=3
(notpass=2
) will generate a new statistics file, so you can repeat the last step as many times you want. I usually dopass=3
twice, always paying attention to the result bitrate.
Meanwhile, you can compress the audio too, using lame
or oggenc
:
oggenc -q<n> <audio_pcm.wav>
Finally, we'll remux audio and video
mencoder -audiofile <audio>.ogg video2.h264 -oac copy -ovc copy
-of lavf -lavfopts format=mp4 -o <video>.mp4
- The
-of lavf -lavfopts format=mp4
generatesmp4
file format using the lavopts muxers.
I have a recipe I originally forged for myself in order to convert the Motion JPEG videos my old camera generates (they are very large videos, since each frame is an entire JPEG image) to h264. Here's an adaptation for other kinds of videos (courses, etc).
I'm not using ffmpeg, but mplayer and mencoder. First, We have to demux the audio with mplayer:
mplayer -vo null -ao pcm:fast:file=<audio_pcm.wav> <video>
- The
-vo null
and-ao null
parameters tells mplayer to not extract video.
In the next steps, we'll do a 3-pass compression with mencoder. At the first pass we'll choose a suitable Constant Quality Mode compression (crf parameter) as a start point:
mencoder <video> -ovc x264
-x264encopts ratetol=100:preset=veryslow:crf=<value>:pass=1
-nosound -o video1.h264
You can add slow_firstpass parameter to the -x264encopts if you are paranoid with the final quality of the video. Mencoder manual says that this option disable some parameters that “significantly improve encoding speed while having little or no impact on the quality of the final pass”. So, use it only at the last step.
You should try several values for crf —
try starting from 25 and goes on increasing it until you note artifacts at the resulting video (higher values compresses more). Remember subsequent encoding passes will improve the quality you have choosed for crf.Alternatives for the veryslow preset are slower, slow, medium etc. See mencoder manual for the complete list.
ratetol controls the bitrate variation — I'm not sure if I'm doing the right thing here, but I set it to the maximum value in order to let total freedom to mencoder to choose the right bitrate for each scene.
After the first pass, you'll note that the last line gives you the average bitrate you will use at the next steps:
(...)
x264 [info]: kb/s:526.43
Change the crf parameter, recommended at the first pass, to bitrate, required at the subsequent passes:
mencoder <video> -ovc x264
-x264encopts slow_firstpass:ratetol=100:preset=veryslow:bitrate=526:pass=3
-nosound -o video2.h264
This second pass encoding will read the statistics generated at the first pass (divx2pass.log
and divx2pass.log.mbtree
) in order to optimize the compression.
Note you'll use the same video input, not the generated by the first pass — first pass' output video is only useful to check the initial quality.
Note also that the
pass=3
(notpass=2
) will generate a new statistics file, so you can repeat the last step as many times you want. I usually dopass=3
twice, always paying attention to the result bitrate.
Meanwhile, you can compress the audio too, using lame
or oggenc
:
oggenc -q<n> <audio_pcm.wav>
Finally, we'll remux audio and video
mencoder -audiofile <audio>.ogg video2.h264 -oac copy -ovc copy
-of lavf -lavfopts format=mp4 -o <video>.mp4
- The
-of lavf -lavfopts format=mp4
generatesmp4
file format using the lavopts muxers.
edited Oct 31 '17 at 4:21
agc
4,70111137
4,70111137
answered Dec 20 '16 at 1:36
Juliano B. NequiritoJuliano B. Nequirito
112
112
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f28803%2fhow-can-i-reduce-a-videos-size-with-ffmpeg%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
4
I haven't used it but the
ffmpeg
man page shows a-fs
option to limit the output size, does something likeffmpeg -i in.avi -fs 100M out.avi
work?– Kevin
Jan 10 '12 at 23:41
1
I will not redirect you to the man page:
man ffmpeg | wc -l --> 5254
– user13742
Jan 11 '12 at 0:11
3
The
.avi
is not the main issue..avi
is just a container. The main issue is which codecs you use.. Many (most?).avi
vids use older style codecs (eg XviD) which are fine, but are larger for the same quality when compared to the later generation of codecs .. You can typically get a tight encoding by using theH.264
video compression standard (eg. codecx264
) andaac
compression for audio.. The container and codecs you use is up to you and your phone... The.mp4
container is well accepted.. (but can your phone handle it: see this link– Peter.O
Jan 11 '12 at 1:16
@Kevin This wants more parameters for conversion.
– xralf
Jan 11 '12 at 8:34
@hesse What does it mean?
– xralf
Jan 11 '12 at 8:36