encoding to x264 need to resize?

[Daedalus01]

u was just wondering whether the resize function of the mpeg4 guis were needed, and what does it do?

what are the advantages and disadvantages or resizing? i understand by resizing then during playback the decoder doesnt have to do it, so there is less cpu usage and more compability.

however, if playback is to be done in a htpc, is there a point to resizing? and more importantly, does resizing cause quality loss?

thanks

[check]

Output quality from a video is a function of resolution and bitrate. (A few other things affect the quality too, like encoder quality, but those aren't important here). Higher resolutions mean you can keep more detail, but they require a higher bitrate. The balance between bitrate and resolution is one that you'll just have to figure out yourself.

[SealTooGreat]

The balance between bitrate and resolution is one that you'll just have to figure out yourself.
Here's how I do that:

width*height*fps*bpp/1000=kbps

bpp = bits per pixel

...just pick bpp* put it in equation (all others values are known), calculate it and the final output is kbps - which you have to put in encoder's gui or cmd.

or try --CRF


bpp* I usually use 0.16 but you are free to try others values.

[Dark Shikari]

Here's how I do that:

width*height*fps*bpp/1000=kbps

bpp = bits per pixel

...just pick bpp* put it in equation (all others values are known), calculate it and the final output is kbps - which you have to put in encoder's gui or cmd.

or try --CRF


bpp* I usually use 0.16 but you are free to try others values.
That's a bad idea IMO because all videos are different. A very high-motion video, or one with lots of motion that is hard to search for would need a lot more than 0.16 bpp. One example I found that seems to torture x264 pretty well is a rendered video (lossless) of a rotating robot; since nearly every block changes in every single frame in a way that is hard to predict, 0.16 bpp would probably choke it on that video.

On the other hand, I've found videos where 0.03 bpp would probably be enough due to their low noise level.

So I'd recommend CRF instead :cool:

[SealTooGreat]

That's a bad idea IMO because all videos are different. A very high-motion video, or one with lots of motion that is hard to search for would need a lot more than 0.16 bpp. One example I found that seems to torture x264 pretty well is a rendered video (lossless) of a rotating robot; since nearly every block changes in every single frame in a way that is hard to predict, 0.16 bpp would probably choke it on that video.

On the other hand, I've found videos where 0.03 bpp would probably be enough due to their low noise level.

So I'd recommend CRF instead :cool:

I knew that someone would say that, but Yes, you are right, that's why I don't use CRF ;) 'cause I'm limited with hdd space. It's so unpredicted that I can't let CRF to throw out bits as it likes(though I don't say it doesn't do that in proper way ). With low motion scenes I can live with 0.16 bpp instead of 0.003. As high motion scenes I'm limiting encoder to --qpmax 31 so it can't apply higher quantizer. Anyway, as I've said you are free to change/lower/raise bpp values upon quick preview(with your eyes) of movie's complexity.

If you are aiming quality, sure CRF will do the job, but hdd space will suffer.

In short way different needs need different approaches. :)

[Dark Shikari]

I knew that someone would say that, but Yes, you are right, that's why I don't use CRF ;) 'cause I'm limited with hdd space. It's so unpredicted that I can't let CRF to throw out bits as it likes(though I don't say it doesn't do that in proper way ). With low motion scenes I can live with 0.16 bpp instead of 0.003. As high motion scenes I'm limiting encoder to --qpmax 31 so it can't apply higher quantizer. Anyway, as I've said you are free to change/lower/raise bpp values upon quick preview(with your eyes) of movie's complexity.

If you are aiming quality, sure CRF will do the job, but hdd space will suffer.

In short way different needs need different approaches. :)
If you have hard disk issues use a higher CRF... using a high bitrate on videos that don't need it wastes hard disk space, so its exactly contrary to your needs.

[SealTooGreat]

If you have hard disk issues use a higher CRF... using a high bitrate on videos that don't need it wastes hard disk space, so its exactly contrary to your needs.
Once again you are right, but CRF is unpredicted even if you are using higher values. As you have said - all videos are different.

Encoding upon bpp is also unpredictable (i mean you don't choose kbps 'cause of target size) but in less way. You will know that encoder will stick to bitrate (you have calculated using bpp) in 1pass ABR or 2pass encoding.

Really, I do need much more control of output size, while keeping decent quality. CRF can't offer me that, it's strictly quality oriented and absolutely not care about output size.

[akupenguin]

Why exactly do need control over the bitrate? If you want to fit lots of movies on a small hdd, then the unpredictability of any given movie doesn't matter. All you should care about is minimizing the average bitrate over all movies for a given quality.
If your storage only contains one or two movies (e.g. cd or dvd, not hdd), then and only then should you specify a target size for each movie... and you still can't use a constant bpp because you have to calculate exactly what will fit.
And even with such a threshold, you can still get some of the benefits of crf: Encode crf, and then run a 2nd pass only if the crf was too big.

[Daedalus01]

thanks for the replies guys. yes i plan to use CRF (ive done research on that and settled on that) via automkv or staxrip or megui.

however, these programs have an 'auto resize' option, and i was wondering if i should check that

i had a feeling that resizing was simply a slight crop, am i wrong? if it does affect image quality i rather not resize, as i rather more detail with more noise at the same bitrate.