Unorthodox use of resizing with rv9

[kastro68]

I'm not really sure when it is appropriate to use resizing since this is all pretty new to me.

For instance is it better to stretch the Width or to stetch the height? Is it bad to shrink the Height...for instance, encode at 720x576 then use producer to resize to 720xHHH, where HHH<576

For interlaced sources you can encode at WWWx288 for Pal source or WWWx240 for NTSC then resize with producer to get the right aspect ratio. This approach would circumvent the need for deinterlacing, which should save some time...I'm not sure on how it would affect quality though. Has anyone tried this yet? How did it turn out?

[Sirber]

Do you want to do anamorphic encodes?

[kastro68]

I know how to resize with producer, I just don't know when it is 'technically' correct to call it 'anamorphic' resizing.

I'm just saying that you can use the resize function for other purposes. It comes in handy especially for tv/video captures, since the source is interlaced.

For PAL, say, you can use avisynth to make the input resolution 640x288 then use producers resize command "-rs 640x480" to resize to 640x480 for a 4:3 source.

Since it only has one field, you don't need to deinterlace.

This is just a hypothetical example. I still have to do more tests to see if the quality is better than just encoding directly to 640x480 or 512x384 or some other 4:3 ratio without resizing.

[Dark-Cracker]

a width stretching is always better than a height strech especially if u have an interlaced material.

[bleo]

I have another 'unorthodox' use of RV9 resizing (for non-interlaced widescreen PAL DVD rips).

Say I want to drop the res to reduce artifacts. Normally I start at 720(->1024)x432, then go down to 720x304, 640x272, 512x216, etc.

Now 640x272=174,080 pixels. But what about 540(->768)x324? =174,960 pixels so it's almost the same but will it look better? I guess this is all on the theory that:
Originally posted by Dark-Cracker
a width stretching is always better than a height strech especially if u have an interlaced material.

I'm about to do some tests, but does anyone have any opinions?

[31 Flavas]

Originally posted by kastro68
I know how to resize with producer, I just don't know when it is 'technically' correct to call it 'anamorphic' resizing. If you ask me, anamorphic means that you resize to the correct AR on playback only. If you downsize first, but preserve the dvd AR (1.50:1 for US NTSC) and then resize to the correct AR. i'd still say that is anamorphic, just not true anamorphic.

[SeeMoreDigital]

Originally posted by 31 Flavas
If you ask me, anamorphic means that you resize to the correct AR on playback only. If you downsize first, but preserve the dvd AR (1.50:1 for US NTSC) and then resize to the correct AR. i'd still say that is anamorphic, just not true anamorphic.
To begin with, the definition of the word anamorphic means: -
'a distorted image which appears normal when viewed'

In the case of an PAL DVD, which contains 720w x 576h pixels. The 'source image area' has an aspect ratio of 1.25:1. So in order for that image to correctly fill a 1.77:1 (16:9) TV/monitor, it must be stretched (distorted) to fit the screen.

In the case of an NTSC DVD, which contains 720w x 480h pixels. The 'source image area' has an aspect ratio of 1.50:1.

This is why on the case/cover of a DVD you sometimes see the expression 'anamorphic widescreen'.

If say, PAL DVD's were manufactured in 'true widescreen' format they would have had an 'source image area' containing 1024w x 576h pixels.

And as Dark-Cracker says. It's always better to stretch the width rather than the height.

[kastro68]

Thanks for the clarification guys.

I looked at one of the links that Karl posted about anamamorphic resizing, there was too much irrelevant information to sort out.

Your explanations are much more succinct and easy to understand.

It is also good reassurance to have different people make the same claims.

And as Dark-Cracker says. It's always better to stretch the width rather than the height.


@bleo: How are your tests coming along? If it does produce better quality, then it might be worthwhile lobbying for resize support in Xvid...I read somewhere that it was possible, at least for linux, I think.

[bleo]

I compared LOTR1 RV9 1 CD rip at 640x268 and 540(->768)x324. Viewed on a 1024x768 LCD. Not much difference! But when looking closely, e.g. at strands of hair!, I see that the 540x324 version pixelates more in the vertical direction so produces more noticeable 'stepping' than the 640x268 version.

Anyway, I got the idea for these anamorphic encodes from SVCD. Since SVCDs are for display on a TV, horizontal stretching is definitely better. However the same theory on a computer monitor or LCD, perhaps not (?)

[unplugged]

Originally posted by SeeMoreDigital
And as Dark-Cracker says. It's always better to stretch the width rather than the height.
From my point of view it's better to resize considering the final viewing ratio, this is fully vaild for progressive source files and with progressive DVDs mastered with interlaced structure, strangely enough there are many of them! (ex.: check Matrix (PAL) with DVD2AVI and see the stream properties on the right panel).

And even more important is if you think to show your files on a TV, where the visible screeen res is absolutely 720x576 for PAL. Because of the lack of TV resolution "weird" ratios like 540x324 (with target 2.35:1) receive vertical compression (downsample to 304) and exaggerated horizontal extension (upsample to 720) to be adapted for viewing.
This step is a further loss, IMHO a drop in image uniformity.
It's not the case with 640x268 (with target 2.35:1 too), at least not that bad.

Instead when compressing from interlaced source (and the image *content* is interlaced, not only the MPEG-2 file structure itself) to an intelaced (too) output, in case of resizing the number of scan lines (height) that we keep has almost double importance in relation with rows (width), because every interlaced frame (field) by nature has half vertial res. compared to that you see during normal viewing.
So when resizing down to XXXxYYY it's better to be more gentle on vertical reduction, to not "compress" even more whitch is compressed too much yet.

Sorry to be too long, I think in italian then write to english, the ideal line would be think (what to be said) in english too.

[kastro68]

I did a test on 'The Pianist' with rv9.
Unfortunately there were some hiccups.

I had trouble getting the correct aspect ratio via tv out. The aspect ratio of the resized output varied depending on which player I used and which container was used. (real or mkv)

Quality wise it looked pretty good to me, considering that it was undersized...got 598 megs when target for video was 630 megs. However, the encoded video had a blurred pastel like effect. I still prefer Xvid for real life movies/clips. For my taste, I'd rather have Xvid's mosquito noise than have that blurred pastel like effect, but that's just me.

Conclusion:
I will continue to use real producer for anime and very low bitrate encodes (without resizing). My opinion is that at very low bitrates Xvid has trouble competing with real media.

[Sirber]

very low for me is 200kbps including sound. Can you write some numbers?

[kastro68]

Originally posted by Sirber
very low for me is 200kbps including sound. Can you write some numbers?

Yep, sure.

I think I put about 3.5 hours of anime into about 630 megs (video only) and still got a really really good result. I can't remember the bitrate, but I think it was approximately 350-400kbps...I'm too lazy to grab a calculator to work it out.

I didn't use 'Drop Duplicate frames' at the time because I only found out about it at a later time, and since the quality looked good to me anyway, I was too lazy to give dropdupe a try. At the time I think I also used undot, convolution3d, Fluxsmooth, deen and awarpsharp.

I also did the same encode with Xvid for comparison. Xvid simply couldn't compete at this bitrate for anime.

[Sirber]

I have nice Futurama, 320x240, 24 FPS from mpeg source, that I encode at 200kbps with 32kbps voice, using DropDupe (recommanded defaults) with 1 frame. Output is about 25 MB, from a ~230MB MPEG1 file, with very nice quality. :D

[RadicalEd]

Sirber, why voice, cook sounds infinitely better than voice, even at 16kbps.

[edit] I lie.. that was cook-0 compared to cook-17 -_-
/me tests

[Sirber]

32kbps cook, mono, voice. :)