Shrinking Videos

[NomadCF]

Reducing the file size can be done in many ways. One way like skittle mentioned is to re-encode the movie to a lower bitrate. Another is to only select OR adjust the audio you select. Meaning if you choose a "lossless" audio track, trying converting it to FLAC or another compressed LOSSLESS format. For just save space always only go with ac3 tracks.


Things to remember about audio tracks.
1. All lossless track can be converted to FLAC and will still be lossless, yet take up less space.
2. FLAC needs to be decoded by the PC before being send to any receiver, that being said you'll be sending PCM to your receiver.
3. All DTS-HD tracks as a core DTS track, taking this over the HD track is simple space saving.
4. All TrueHD tracks as a "core" AC3 track, taking this over the HD track is simple space saving.
5. IMHO +90% of the time, making your own AC3 track from a HD track will give you a higher quality AC3 track. As most AC3 tracks are only 448, VS the 640 you can make from the lossless track.
6. In terms of space saving option your best bet is in this order AC3 => DTS => Lossless. Meaning AC3 be the smallest file, saving you the most VS a DTS or lossless.
7. for your best quality audio always make your "new" audio streams from a Lossless track. Meaning a new AC3 128 from a AC3 256 will not just drop the quality by 50%, but more like over 60%. As your going from Lossy to Lossy (well really the encoder will being doing Lossy => lossless => Lossy, even if it is only it memory).
8. Each stream type has it's own quality settings. For example AC3 comes in settings like 128,192,256,384,448,640 and DTS comes normally only in 768 or 1536.
So choosing a Stream type and a setting that best fits you will also "save" you space. Meaning if you can't tell the difference between a DTS stream at 768 VS 1536. Then choosing the 768 will result in about a 50% space savings over the 1536 track. And if you can't tell the difference between a AC3 640 vs DTS 768 track you *could* save about 30% with the AC3 640 over the DTS 768.



Things to remember about re-encoding.
1. Shrinking or re-encoding to any other lossy format will remove quality.
2. Removing borders for a film will reduce both the final size and require less encoding time, as cropping is faster then processing.
3. When resizing it's easy'est to resize down OR up if you keep the same aspect ratio.
3. To shrink the videos resolution, but "keep" as much of the quality as possible. You'll need to due some basic math + padding. Heres what I mean.

Lets take avatars bluray, It's a 1080p file which means it's 1920x1080p. But let say we wanted to reduce it down to 720P (which would be 1280x720p). Then we would need to figure out are new bitrate is going to need to be. And for this project I feel defining a bitrate over using something like CRF/etc will yelled a closer to "lossless" resize. Now on to finding are new bitrate.

1st we need find the % difference between what we started with and where we are going, so for this example it'll be 1920x1080p->1280x720p.

Code: Select all

1920x1080 = 2073600
1280x720 = 921600
921600/2073600 = 0.44444

Now what we have the new percentage that we are shrinking the film, we can now go back to the original bitrate of the file and reduce that number by are percent (in this case 44.444% (thats 0.4444*100). But because we are going to another lossy format, we need to pad that number a bit to help try and off set the quility loss we going to be by re-encoding to another lossy format. Even if the format is the same as the one you started with, If it's a lossy format your going to lose quality re-encoding.

So to finish this example with are avatar bluray 1080P->720P. Your final bitrate could come out like this.

Code: Select all

Note : 1 Mbps = 1024 kbps
Avatars 1080P bitrate is : 28.8 Mbps = 29491.2 kbps

Now heres where the padding comes in, I tend to pad all non animes with about 5% or in this case I just took the 44.44% up to 50%. The padding will also play a roll in any decimal number, as you'll always need to round UP to the next whole number.

Code: Select all

** Real number
29491.2 / 0.44444 = 13105.88928
roundup(13105.88928) =  13106 
** But with are padding
29491.2 / .50 = 14745.6
roundup(13105.88928) = 14746

So now when you put this file into your favorite resizer/converter you can tell it yo resize your file from 1080P => 720P and use a VBR of 14746 kbps.

[skittle]

...Lets take avatars bluray, It's a 1080p file which means it's 1920x1080p. But let say we wanted to reduce it down to 720P (which would be 1280x720p). Then we would need to figure out are new bitrate is going to need to be. And for this project I feel defining a bitrate over using something like CRF/etc will yelled a closer to "lossless" resize...

This doesnt make sense... --crf and --bitrate use the SAME ratecontrol algorithm,.

[NomadCF]

...Lets take avatars bluray, It's a 1080p file which means it's 1920x1080p. But let say we wanted to reduce it down to 720P (which would be 1280x720p). Then we would need to figure out are new bitrate is going to need to be. And for this project I feel defining a bitrate over using something like CRF/etc will yelled a closer to "lossless" resize...

This doesnt make sense... --crf and --bitrate use the SAME ratecontrol algorithm,.

I never said use --bitrate, please read the whole posting. At the end you see I clearly say the fallowing.

So now when you put this file into your favorite resizer/converter you can tell it yo resize your file from 1080P => 720P and use a VBR of 14746 kbps.

[skittle]

huh?

use a VBR of 14746 kbps.

thats tells x264 to use --bitrate

read x264 --fullhelp before you suggest things to newbies!

[NomadCF]

huh?

use a VBR of 14746 kbps.

thats tells x264 to use --bitrate

read x264 --fullhelp before you suggest things to newbies!

Setting a VBR and not using crf produce or vise versa give anyone completely different results. And using crf for resize makes absolute no sense since you already know 100% what the max bitrate needs to be. If you use crf during a resize you'r going to get an all round unexpected results. And with you already knowing all what all the end results need to be, file size, bitrate ,etc. There is nothing crf can / will give you what will make it usefull in this instance.

I use crf for cross codec conversions like mpeg2 to h264x, as I've never quit sue of a good bitrate to start with. Sure you could go by the recommened 2000-2500 or even the simple h264 is so post to only require 1/2 the bitrate of mpeg2 for the same film. But I find using crf for my 1st give me my desired results.

But for resizing a film I always and only use a VBR setting, regardless of the passes (I use do 3, sure the 3rd pass does really do much for me. But it's only CPU time.)

I mean by means do as you see fit, But spend hours testing and retest, I now have a media center library of 520 SD movies converted to h264 and most have been resized for my families portable players, I've also have 30 Blurays I've converted to 720 and lower. This is all real world experience, not some black board ideals like zeno's paradoxes.

[skittle]

...There is nothing crf can / will give you what will make it usefull in this instance...

Except the insanity that comes from encoding to a specific bitrate.

As I already mentioned, --bitrate and --crf use the SAME rate control algorithm. There is no benefit to using --bitrate unless your are targeting a specific file size, as by definition crf can not target a file size.
try an encode at --crf 18, you will be suprised

[NomadCF]

Except the insanity that comes from encoding to a specific bitrate.

LOL, I agree that a crf of 18 straight from any SD content to h264 would be fine. But where are talking about a quality & resize. The good encoders out there wanting the best quality, 1st run there files though CRF until they get the quality they want. But then they rerun them though a 2+ pass with the bitrate gathered from there CRF. Why do you think that is ?

But, going on to what you've asked me to do. That is run Avatar though CRF 18, I so. The file was smaller and fuss'er or I guess you could say blurry. A Good example of this was on Navi's boday markings. And this resulting bitrate was lower then what I had used, but then again so was the file size. Now had I rerun it with a CRF of oh lets say 16 or less then thing would have cleared up. But thats just the point CRF is designed figure out the needed bitrate, But in are case we know what bitrate we need, there is no guessing or need to have anything try and figure out what is best for are needs. In this above example, we know what we want and what we need to get there. Where are unsolved question that we would need CRF to fill in for us.

CRF is wonderful if you don't know what you need or how to get it. It does all the work for you, But again it's figure thing out for you. Thus the unpredictable files and outcome. You know it should be of X quality, but you need to wait and see.

VBR is wonder if you know what you want and how to get it there. You don't need anything to figure anything out for as you've already got all the answers. And it's a simple math. If you get a file that is smaller then it should be after you already know what bitrate the file needs to be, you've lost quality. If the bitrate is higher or lower then it needs to be, you've lost quality or wasted space.

In the resizing example above, we now all the answers and what the outcome has to be. If It's anything else, we've wasted time,space or quality.

[skittle]

I had a whole page of stuff thats wrong with your logic, but it easier just to say that you have no idea how CRF (or 2 pass for that matter) actually works

Its not worth getting into an argument here, go ask on #x264 on irc.freenode.net if you want a detailed explanation from the devs.

I wont respond to this thread anymore.