Encoding & Scaling

[enajeri]

i've got a pal mpeg2 capture in 720x576 @ 25fps (stock standard)
i get the whole lower bitrate will overall mean lower quality
i assume everyone here has figured out what i'm about to ask
i haven't quite out how it works with resolution in the mix as well

the corrected aspect ratio of the mpg is 16:9 so obviously when software/hardware plays it back it stretches the 720 horizontal resolution to 1024
but i've been tossing up on which way to encode:

a) 1024 x 576
b) 720 x 405

the part i'm stuck with is how things go with playback
for fairly decent encode for archiving purposes, would it be better to go with 1024x576 @ 2mbps and get an encoded version of what it looks like, or go 720x405 @ ~2mbps and hope the decoder can make it look just as good if i decide to play it @ 1024x576?
to simplify this further, the question here really is which would look better when upscaled to a resolution of say 1920x1200:

a) 1024 x 576 @ 2mbps
b) 720 x 405 @ 2mbps (or lower)

while 1024 has lower quality per pixel/block, it requires less scaling so less filling in of gaps. while 720 has more quality per pixel/block, it requires more scaling resulting in stretching out that extra quality anyway
i've tried this with xvid and personally found that 1024 seemed moderately better because it mostly blurred things when scaled up, whereas the 720 encode ended up stretching out the compressive noise making the overall image look worse

i'm wondering what other people have found
(not specifically with xvid. more with lower / higher res)

[Dark Shikari]

Why not just keep it the original size and include the appropriate aspect ratio in the output stream?

[pon pon]

enajeri, it seems you have an assumption similar to me, that there is a benefit in encoding at the Display Aspect Ratio. i have a thread here (http://forum.doom9.org/showthread.php?t=130821) with which I am trying to expore the validity of this assumption.

Dark Shikari's response seems to follow the "conventional wisdom", but I do not understand why this approach would yield a better result.

(Sorry to hijack your topic, but the two seem related to me.)

Edit: The link to my other thread does not work now because I deleted it. It was no longer required.

[Dark Shikari]

Dark Shikari's response seems to follow the "conventional wisdom", but I do not understand why this approach would yield a better result.
Simple: Resizing before encoding requires vastly more bitrate (proportional, roughly, to the increase in frame dimensions). Or, better said, at the same bitrate, it decreases quality.

Resizing during playback requires no bitrate at all.

The quality difference between a high quality resize before encoding and a faster resize during playback is lower than the quality difference caused by the higher frame size (and thus fewer bits per pixel).

[pon pon]

Thanks for your response, Dark Shikari. I have thought about your reply quite a bit now and I have completely changed my view on the best way to encode.

enajeri, I believe Dark Shikari's suggestion for your situation is the best course of action. I will give you an explanation in my own words why that is so, based on my understanding, using the two examples you gave.

a) 1024 x 576

If you stretch the frames horizontally in the encode then you are doing the same thing that would be done at playback, but then the result is stored in a lossy format so the quality will not be as good. As well as that, there is the overhead of storing this imperfect data in the file. (I think I was confused here. The encoding is not using all its time working out the re-mapping of the pixels; it is trying to compress the result to minimise loss.) Whereas, as Dark Shikari wrote: "Resizing during playback requires no bitrate at all.", so there is no size overhead for your file if you keep the 720x576 resolution, and the resulting resized images should be more accurate because they are produced from data that has not had this degradation applied to it.

b) 720 x 405

If you shrink the frames vertically then straight away this tells me you have lost image information. At least stretching avoids this, but has its own problems (as mentioned above).

So I think you should use all your bitrate to preserve the original data in its original resolution and define the Display Aspect Ratio as 16:9 in the file you produce, as suggested in Dark Shikari's reply.

enajeri, it may be gratuitous and condescending for me to say this, (but I will anyway, lol) but you should always look for opportunities to stream the video (and audio) sources wherever possible to avoid degradation due to encoding. I don't know if your application provides such an opportunity, but you should do it if you at all possibly can.

[enajeri]

So I think you should use all your bitrate to preserve the original data in its original resolution and define the Display Aspect Ratio as 16:9 in the file you produce, as suggested in Dark Shikari's reply.

enajeri, it may be gratuitous and condescending for me to say this, (but I will anyway, lol) but you should always look for opportunities to stream the video (and audio) sources wherever possible to avoid degradation due to encoding. I don't know if your application provides such an opportunity, but you should do it if you at all possibly can.
i tried this and it seems to work pretty well
will be testing it with some lower bitrates as 1800kpbs is probably a little high

i was testing this with another video in a non-standard ratio (2:1)
i encoded it by specifying the DAR as 2:1
it worked okay but when compared back against the horizontally stretched 1:1 version it was shorted height wise
taking out a ruler the DAR version seems to have reverted to a 2.35:1 format

essentially specifying DAR instead of resolution is perfect
but is there a way to force a non-standard DAR?

(playback tested in wmp10, mpc, & vlc. encoded with xvid)

[Blue_MiSfit]

IMO, it's silly to resize before encoding, unless your playback system doesn't support anamorphic encoding.

I would imagine that if you resize ahead of time, and encode at (for example) CRF - you would get a better image than you would encoding not resized at the same CRF. But it would be a lot bigger.

Yes macroblocks woudl be smaller, but you're probably not going to be too bothered with blocking at 1800kbit.

~MiSfit