resize for archive

[fatxy]

what i do: i stream dvb related things with resoultions from 480x576 to 720x576

what i want: archive them using xvid, without any black borders

so i have a few resizing/cropping questions:

whats the best iyo for 720x576 sources:

a, crop and resize with gknot to ie. 704x528
b, crop and resize to 720x576 (do you look if its divisible by 16/32?)
c, crop and resize to 768x576 (do you look if its divisible by 16/32?)

720x576 anamorph sounds good to me but i dont get it displayed properly in mediaplayers. do i have to use the xvid ar tab or is it enough to change it afterwards with mpeg4 modifier?

and what do you suggest fpr 480x576 sources?

[unmei]

Is there a reason not to encode at 480x576 / 720x576 ?
Because if there is not, i would not resize at all. Encoding at source resolution is a good thing :). I almost never resize, i really don't see why i should. And if you want to archive you would want to avoid this processing step that alters your image if it is not absolutely necessary ..no?

[minolta]

-using mpeg4modifier or xvid ar tab has same effect
-next release of xvid decoder will support anamorphic
-preview of next decoder can be found here (works with standard players like wmp):
http://forum.doom9.org/showthread.php?s=&threadid=79350

[fatxy]

ok thanks for your answers, ill stick to anamorph encodes then

[lordadmira]

Originally posted by unmei
Is there a reason not to encode at 480x576 / 720x576 ?
Because if there is not, i would not resize at all. Encoding at source resolution is a good thing :). I almost never resize, i really don't see why i should. And if you want to archive you would want to avoid this processing step that alters your image if it is not absolutely necessary ..no? It depends on what u trust more to do a good aspect ratio correction. The player app? Or ur good pre-encode filter. The player will probably use a fuzzy bilinear, if it can do it at all. Fixing it beforehand is just easier and will give a better encode as far as I'm concerned.

LA

[unmei]

You certainly have a point there. And i could even add, the increased CPU demand for correction-on-playback, especially for better resizers.

But still i prefer to have the encoding mapping one source pixel to one encoded pixel if possible. This way it is left for playback to find an acceptable way to squeeze the picture, not "omitting resolution" already at the encoding stage.

I mostly use MPC, it sqeezes to the AR set in the matroska atomatically. It might not be the best algo, but im pretty sure it is not pixel resize. If you want to use a specific resizer on playback you could always use FFDShow's where you have a nice selection of methods to choose from, maybe everything you ever want, except the lanczos 4 (ATM:)).

Another thing to think about when you resize ..you can use the hi quality resizer you want, but unless you actually encode in your current screen resolution, you will still use the ("crappy") player resizer in fullscreen playback. So unless you don't watch in fullscreen, or your screen res = your encode res, you gain nothing in this respect from the resized encode. You "save pixel" of course, but that is exactly the point why i avoid resizing before encode..

[lordadmira]

Originally posted by unmei
This way it is left for playback to find an acceptable way to squeeze the picture, not "omitting resolution" already at the encoding stage. Eh, ur not really losing anything for as small a change as AR correction. All the shape information is preserved completely. All that's lost is redundant texture info. (I don't mean ME texture)

but unless you actually encode in your current screen resolution, you will still use the ("crappy") player resizer in fullscreen playback. Heh I thought of that a little later. ;) When is ATI gonna have in-overlay hardware lanczos??

LA