Resolution vs Bitrate

[Erica90]

I'm fairly new to converting video, but right now I have my standards for 720p set to 5,000,000 bitrate and 1080p at 8,000,000 for 24-30fps which fall under the suggested bitrates vs resolutions shown here for YouTube. I am converting them as a playlist (HLS) so I have to convert the videos no matter what. The purpose is online streaming, though not on YouTube.

I am converting a lot of video with different starting resolutions and bitrates, but I'll use this one as an example. The resolution is 1920x1080 with a bitrate of 4,161,343. Even though my original copy of this video is in 1080p, the bitrate is below my standard for even 720p. Is there any point in making a copy of the video in both 720p and 1080p, both using the same bitrate of 4,161,343? The end result looks the same on my 1080p monitor even though the file size ends up being 57.5mb vs 123mb. I don't have a higher resolution monitor to view them both in full screen on.

As a general rule in this situation, would it be best to always just produce both a 1080p and 720p version? Or if the bitrate is already lower than my standard for 720p, should I just ditch 1080p all together?

Thanks!

[johnmeyer]

Those seem like really low bitrates.

[jagabo]

Is there any point in making a copy of the video in both 720p and 1080p, both using the same bitrate of 4,161,343? The end result looks the same on my 1080p monitor even though the file size ends up being 57.5mb vs 123mb.

If the bitrate is the same the file sizes should be the same too.

[Hoser Rob]

... I'll use this one as an example. The resolution is 1920x1080 with a bitrate of 4,161,343. Even though my original copy of this video is in 1080p, the bitrate is below my standard for even 720p. Is there any point in making a copy of the video in both 720p and 1080p, both using the same bitrate of 4,161,343? The end result looks the same on my 1080p monitor even though the file size ends up being 57.5mb vs 123mb. I don't have a higher resolution monitor to view them both in full screen on....

If you can't tell the difference when watching them though one's half the size you're still ahead IMO. Downsizing the resolution is a very good way to compress and get decent quality.

Does the resolution matter? I don't think there's one answer for this, it depends on the source. Some video doesn't really need that much resolution, it looks as good to me in SD as in 1080p, assuming the same quality encoding in both. Many Sundance type movies are like this for me. But for something like Lord of the Rings, yes, I want 1080p.

For some video, I don't think having 1080p matters as much as the colorspace. For example, I don't think you can see just how good Miyazaki anime is until you see it with 10 bit colour and a decent bit rate. Another example is Annihilation, that's just not the same without good 10 bit colour and bit rate. The difference is like night and day. It doesn't necessarily seem like it would be but it is.

[fornit]

Hi Erica90,

you say "The purpose is online streaming, though not on YouTube". Does this mean, that you want to stream your videos just at another provider than Youtube or do you want to stream by yourself?

If you want to use a provider, then the answer is simple from my point of view: Encode everything with x265, preset "fast" and constant quality at crf 18. That will do the job in every case.

Things will become much more challenging but also much more interesting, if you want to do it by your own.

Regards

[lordsmurf]

... I'll use this one as an example. The resolution is 1920x1080 with a bitrate of 4,161,343. Even though my original copy of this video is in 1080p, the bitrate is below my standard for even 720p. Is there any point in making a copy of the video in both 720p and 1080p, both using the same bitrate of 4,161,343? The end result looks the same on my 1080p monitor even though the file size ends up being 57.5mb vs 123mb. I don't have a higher resolution monitor to view them both in full screen on....

If you can't tell the difference when watching them though one's half the size you're still ahead IMO. Downsizing the resolution is a very good way to compress and get decent quality.

Does the resolution matter? I don't think there's one answer for this, it depends on the source. Some video doesn't really need that much resolution, it looks as good to me in SD as in 1080p, assuming the same quality encoding in both. Many Sundance type movies are like this for me. But for something like Lord of the Rings, yes, I want 1080p.

For some video, I don't think having 1080p matters as much as the colorspace. For example, I don't think you can see just how good Miyazaki anime is until you see it with 10 bit colour and a decent bit rate. Another example is Annihilation, that's just not the same without good 10 bit colour and bit rate. The difference is like night and day. It doesn't necessarily seem like it would be but it is.

For my DLNA server, I never encode more than 720p, using CRF with anywhere from 19 to 24. Animation can sometimes be pushed as hard as 26. When we're talking about H.264, bitrate is not the only aspect. The program can also make a difference, and is why I use Selur's Hybrid.

If the source is 1080p, but lower than another 720p, odds are it already has some of the non-bitrate encoding tweaks. A lot of modern video releasing folks are not too bright beyond using software defaults. But even then, a down-res or a harder CRF can still tweak it down.

Most of my encodes are actually smaller, to about 960x400 or 720x406, never less than x400 vertical size. When you sit 9' away from a screen, even a large 55", it still looks great. Even at 1080p, you'd never almost never see the "detail" from that distance, not unless you stick your nose to the screen. It's about the content, the enjoyment, and a lack of bad video nuisances (artifacts, errors) -- not resolution. The only time detail matters is when watching a baseball game, because the shots are wide, and the on-screen print is small. Even then, its sometimes only broadcast 720.

[Erica90]

Those seem like really low bitrates.

What would you suggest for pre-recorded streaming video?

Is there any point in making a copy of the video in both 720p and 1080p, both using the same bitrate of 4,161,343? The end result looks the same on my 1080p monitor even though the file size ends up being 57.5mb vs 123mb.

If the bitrate is the same the file sizes should be the same too.

You are right. I thought if you don't specify the bitrate, ffmpeg uses the original but in fact it went from 4161 kb/s to 1595 kb/s using:
ffmpeg -i original.mp4 -vf scale=1280:-1 -acodec copy 720p.mp4

I am preparing these videos to be hosted by a new website. I always start off with the highest possible resolution and bitrate. They can vary from as low as 640x480 and usually peak at 1920x1080. The bitrates also vary a lot.

My end goal is to convert them in bulk into an HLS playlist. I already have it automated, going through a directory of the original videos, running one or more ffmpeg commands on the original file, uploading multiple resolutions and saving the info in a database. Where I am having the most difficulty is deciding the best way to handle the resolutions and bitrate.

I figured I'd make lower resolutions available to people on mobile devices or slow connections, but I'm wondering if in 2018 this is really that much of an issue. I'd be willing to just make it simple and do something like, original resolution only if under 1080p and if 1080p or higher, original resolution and a 720p version. So there is always either 1 or 2 versions max.

I saw some different and helpful suggestions on this. Is there maybe a better way to write my ffmpeg command? I build it in a string mixed with PHP variables and then execute it. So far it seems to work well, but knowing very little about ffmpeg I'm sure there are options I should use that I am missing.

$bitrate_string is left empty if the original bitrate is lower than the set one for that resolution. Otherwise it looks something like $bitrate_string = '-b:v 5000000';

ffmpeg -i $source -vf scale=$resolution->width:-1 $bitrate_string -acodec copy -start_number 0 -hls_time 10 -hls_list_size 0 -f hls index.m3u8

I'm also curious how exactly ffmpeg decides what to do as defaults. For example, not giving it a bitrate, it seems to use one close but still smaller to the original. If I specify the bitrate using the one ffprobe gives me from the original, it seems to always make the new file be just slightly larger than the original.

Thanks for all the replies so far!

[jagabo]

ffmpeg uses x264's default CRF value of 23 and the medium preset if you don't specify otherwise.

[fornit]

ffmpeg -i $source -vf scale=$resolution->width:-1 $bitrate_string -acodec copy -start_number 0 -hls_time 10 -hls_list_size 0 -f hls index.m3u8

We've had a similar task as you because we've recently finnished our own (small) tube system (can be found at: https://www.team-andro.com/tube).

In contrast to your decision to use HLS we've built our system on MPEG DASH. That's a technique supporting Google's webm, too, but it's similar enough to HLS to give you some hints.

To be honest, your encoding string still looks a bit simple. I think there are more things to be considered:

• You should specify the video codec: -c:v libx264 -preset fast -profile:v main (use "main" up to 720p and "high" for higher resolutions)
• Don't simply copy the audio codec, convert it: -c:a aac -b:a 128k (128k is the audio bitrate)
• In MPEG DASH you must consider something called "keyframe alignment". And from my understanding that's the same with HLS. Please use Google to get an understanding of what a keyframe is. This means: If you want to create segments of 10 seconds each then your encoding must make sure that there is a keyframe every 10 seconds. So: If your video has a frame rate of 24 fps, then it makes sense to choose a gop size of 240. You can do that by: -keyint_min 240 -g 240 -sc_threshold 0
  But it's not always that easy: Some videos have frame rates like 23.976 fps (= 24000/1001). With MPEG DASH you would then choose another interval, e.g. 10,01 seconds instead of 10. You should google how do deal with that for HLS.
• Note: With x264 width and height must always be dividable by 2 (i.e.: even). If you use a statement like -vf scale=1280:-1 your conversion can fail if the original is e.g. a trailer where the blackbars have been cropped. Better you calculate width and height to make sure both are even.
• Bitrate is usually controlled by a mixture of constant quality setting (-crf) and a buffer (i.e.: setting -maxrate and -bufsize). But that's a topic where one must go in more depth. Our approach has been to provide a Youtube-like quality and file size. I can explain that, but it's more work for me. I'll only do that if I have the impression that you are deep enough in the topic to understand it.

So, up to now, an example conversion string could look as follows:

ffmpeg -i $source -aspect 16:9 -vf scale=1280:720 -r 24 -keyint_min 240 -g 240 -sc_threshold 0 -c:v libx264 -preset fast -profile:v main -crf 23 -maxrate 2200k -bufsize 4400k -c:a aac -b:a 128k -start_number 0 -hls_time 10 -hls_list_size 0 -f hls index.m3u8

Please note: I've not looked deeper at your HLS related statements.

It's not clear whether you want to process arbitrary video material. If so, there are more things to consider. E.g.:

• Videos can be interlaced (e.g.: many DVDs are interlaced). In that case, add the yadif-filter to your vf-statement: -vf yadif,scale=1280:720
• Videos can be anamorphical: E.g.: DVDs usually come along with 720 x 576 px but they are diplayed at a resolution of 1024 x 576 px. I.e.: Storage aspect ratio (SAR) differs from display aspect ratio (DAR). You need a tool like MediaInfo to notice that. Your vf-stament should then reflect that: -vf scale=1024:576

Maybe I could make clear that one statement is probably not enough to make a video streamable. You need to do some analysis with tools like mediainfo and ffprobe first. After that you can do some calculations to create the appropriate encoding string.

[Hoser Rob]

For my DLNA server, I never encode more than 720p, using CRF with anywhere from 19 to 24. Animation can sometimes be pushed as hard as 26. When we're talking about H.264, bitrate is not the only aspect. The program can also make a difference, and is why I use Selur's Hybrid.

If the source is 1080p, but lower than another 720p, odds are it already has some of the non-bitrate encoding tweaks. A lot of modern video releasing folks are not too bright beyond using software defaults. But even then, a down-res or a harder CRF can still tweak it down.

Most of my encodes are actually smaller, to about 960x400 or 720x406, never less than x400 vertical size. When you sit 9' away from a screen, even a large 55", it still looks great. Even at 1080p, you'd never almost never see the "detail" from that distance, not unless you stick your nose to the screen. It's about the content, the enjoyment, and a lack of bad video nuisances (artifacts, errors) -- not resolution. The only time detail matters is when watching a baseball game, because the shots are wide, and the on-screen print is small. Even then, its sometimes only broadcast 720.

Good comment. I've seen reports from studies you seem to allude to ... they found that at the average viewing distance of 9 feet, with 1080p video you'd need something like a 72" screen to be able to actually see that level of detail.

I've seen lots of 720p/1080p video that would have looked a HELL of a lot better if it had been downsampled at the bit rate used. They simply look like a much smaller res video that's been processed with a sharpening filter, and not consistent in quality.

However, there's a limit to how much fiddling I'm willing to do. I'll happily waste some bit rate if the file size comes out IMO reasonable. Like when I convert CDs that aren't that well recorded ... ie. most of them ... to mp3 I just leave the setting at 320K when a smaller bit rate would have been OK.