anamorphic encode res

[Andrey]

First: Happy New Year to All! :)

So, to subj.
I want to test what is perseptually better - encoding with AR 1:1 or different one, when do widescreen encode.
I 've reading about the subj for a week and still have no idea. :)
I 've created 1:1 1 CD encode of Face/Off with resolution
576x240.
Now I need to select a resoltion to anamorphic encode.
The question is, what resolution to select ? :)
My idea is to test 320x480, which is raher close to
576x240 in pixel count, but have much more vertical lines.
Or it is better to choose 352x440 ? (Practically the same pixels as 320x480)
But will it have enought horizontal pixel to preserve details, when stretched ?
May be somebody have expirience with such an encodes and can give me an advice ?

Thanks in advance !!!
P.S. I've ask before testing, because only machine is powerful enough to do encode for me is at work, my PII 300 at home can process it for infinity :(

[Koepi]

You can test with a few hundred frames, that's even doable with a very slow machine.

Just take a snippet you like and encode it with various aoptions - give the files appropiate names so you can see which samples is what and tadaa - you have your own small cmparison.

Regards
Koepi

[Andrey]

Ok, I 'll give it a try.

P.S. I may be wrong, but I noticed, that encoding a small (less than 3 mins) clip with the same settings as for a whole movie often give a very different result in quality terms. So, IMHO, it is better to test rather long piece...
Anyway, I 'll test it :)

Thanks!

[Andrey]

Ok, after a playing with resolution 336x432 I can tell that for my own eyes the resolution of 576x240 looks better...
I 've tried to encode with different resize methods (lancroz, some bicubic, bilinear) but anyway, seems that horizontal resolution is not enought. The image is definitely sharper, but artifacts (especially, if there is some text at the screen, on monitor or on car as example) are annoying :(
So, now I will try 320x480 :)

[Versa]

Why don't you just leave the resolution at default and make a 2cd encode?

[mikeX]

what exactly do you mean by artifacts?
i'm experimenting with small horizontal resolutions at the time, but i haven't really gone under 480.
from what i notice stretching the horizontal res on playback mostly affects straight diagonal lines (with a stairstepping effect) which has to do with the aspect error really, not the actual encoding (based on the previews of my avs scripts).
a noticeable nuisance though is the slight color distortion i get (the strethed picture appears to have too much green at places)

[Andrey]

>>what exactly do you mean by artifacts?
As I wrote, most sharp details (i.e. texts and so on) have something as I can describe as "muar" or "noise" around them. (sorry, english is not my native)
That also is noticeable around small detailed elements aka faces at the back and so on...

[mikeX]

[:: edited cause i didn't read carefully enough ::] :rolleyes:

my tests usually gave less noise from that of a full horizontal resolution but i guess that can vary depending on the source...

You are probably compressing the horizontal resolution too much, thus stretching back to the correct resolution can't reproduce the original picture accurately enough :(

[Andrey]

>>You are probably compressing the horizontal resolution too much,
>>thus stretching back to the correct resolution can't reproduce the
>>original picture accurately enough
Yep. That is what I was aware of and that is why I asked and advice how to select a resolution :)

[mf]

I would actually try 512x320 then. It'll be a higher pixel count than what you originally had, but reducing the horizontal resolution really disables the higher vertical resolution to do any good. Plus, MPEG artifacts get more and more noticable the lower in resolution you go. An extreme example is a high definition sample that I made (1600x864), which had alot of blocks in high motion which you simply didn't notice because of the excessive resolution. With less extreme resolutions, the same goes for things like ringing and ME trails. Personally I don't go lower than 640 pixels horizontally at any time, but that's just my personal preference.

[symonjfox]

Also, AFAIK, we can use any resolutions we want.

For example I tested 544*544 (16:9), 352*576 (4:3), 720*576 (16:9) and so on, there are infinite (or nearly) combinations.

The only bad thing I noticed is that the 3ivX filter (that is able to use AR settings) doesn't have a nice resize alghoritm, and this is worse than (for example) loading the clip into Vdubmod and resize it with Lanczos or Bicubic resample.

I hope that 3ivx become better, or Ffdshow will automatically parse the AR flag and resizes using Lanczos.

[sysKin]

Originally posted by symonjfox
I hope that 3ivx become better, or Ffdshow will automatically parse the AR flag and resizes using Lanczos. Let me just say that IMHO, resizing down *sucks* and I'm never gonna use it for any reason.
I could have resized down *before* encoding with better results.

Radek

[Audionut]

I like to keep the H resolution as high as possible. With the new xvid codecs and experience I get nice quality encodes to 1 cd even with high (above 600) H resolution.

As for 1:1 encodes or resized 16:9 encodes I would have to say it depends on the movie. But I'm starting to do more in 1:1.

BTW, use your monitor to resise a 1:1 encode. Or any anomorphic video. Simply squeeze the Vertical size down with the monitor controls.

IMO that will = way better quality pitcure compared to removing lines of resolution to display a correct aspect ratio.

[sysKin]

Originally posted by Audionut
BTW, use your monitor to resise a 1:1 encode. Or any anomorphic video. Simply squeeze the Vertical size down with the monitor controls.
Now that's extreme ;) How about just resizing *up* the horizontal resolution, possibly by overlays?

Now about the original topic... are you guys interested in real working aspect ratio in .avi files? I made it. Works. Doesn't work when remuxed to ogm (or matroska, but matroska has its own AR), might stop working when remuxed anywhere.

I sneaked full support to current directshow decoder, but without extra changes to VfW it will not work. So what you need now is proper VfW dll which will save AR info in AVI header (by copying the same info as mpeg-4 has).

I was kinda keeping it secret to avoid any extra confusion, and questions like "how can I change existing avi" for which I have no answer - but I can't live without adding new bugs it seems.

Any good comments?
Radek

[Audionut]

I wouldn't exactly call pushing 3 butons on my monitor extreme.:p

And I can assure you that it is the highest quality way to resize anomorphic movies.;)

Personally I think the avi container should die.:devil:

[mikeX]

@ syskin:

i have to say i didn't understand much on your post :confused:
where can i find the new vfw (compiled)?

[chilledoutuk]

The idea about encoding anamorphic movies is that you retain the same resolution as the orginal source.

for exaample if your source is 16:9 PAL
the source res will be 720 x 576


a sqaure pixel encode will be 720x400

therefore the verticle resolution has been reduced by 30%




the resolution of an anamorphic encode will be 720x576

therefore the orginal resolution has been maintained.

when viewed on a high definition display such as a good computer monitor the anamorphicaly resized picture will seem sharper and more detailed.

if your trying to get a low bitrate then there is not much point in creating anamorphic encodes but if your going for high bitrates the quality improvement is noticable.

syskin im very interested in a xvid playback filter that can anamorphicaly resize.

[Assault]

@ mikeX

AFAIK there's no xvid.dll that saves the AR info in the avi header available for download at the moment. sysKin once made one (I think it was 2 weeks ago) but then decided to not publish it.

@ sysKin

I think adding the AR info to the avi header is a great idea. Then there would already be two container which supported anamorphic encodes. ;)

[shitowax]

3ivx doesn't perform any resizing even when decoding streams with non-square PAR. The AR resizing is usually performed with the graphic card in hardware ... ;)

Originally posted by symonjfox
Also, AFAIK, we can use any resolutions we want.

For example I tested 544*544 (16:9), 352*576 (4:3), 720*576 (16:9) and so on, there are infinite (or nearly) combinations.

The only bad thing I noticed is that the 3ivX filter (that is able to use AR settings) doesn't have a nice resize alghoritm, and this is worse than (for example) loading the clip into Vdubmod and resize it with Lanczos or Bicubic resample.

I hope that 3ivx become better, or Ffdshow will automatically parse the AR flag and resizes using Lanczos.

[mikeX]

oh now i get it, syskin was just talking about planing to publish one that supported writing AR info in an avi header

thanks Assault

btw it's a great idea, but it wouldn't be fair to built it only in the vfw ( linux :cool: geek )

[symonjfox]

Originally posted by shitowax
3ivx doesn't perform any resizing even when decoding streams with non-square PAR. The AR resizing is usually performed with the graphic card in hardware ... ;)
So it's strange! I've a Radeon 8500 with lastest catalyst drivers ...

I didn't know about it. I thought that the decoder (3ivx, ffdshow, divx ...) decodes the stream and adjust it to the right size, not that the graphic card does it. Well, I have so much things to learn :rolleyes:

[sysKin]

Originally posted by Assault
I think adding the AR info to the avi header is a great idea. Then there would already be two container which supported anamorphic encodes. ;) Maybe great idea, but I can't help thinking that:
Originally posted by Audionut
Personally I think the avi container should die.Is so very very correct in my humble opinion, too.]
Originally posted by mikeX
btw it's a great idea, but it wouldn't be fair to built it only in the vfw ( linux geek )But you linux geeks don't need it at all, your mplayer reads mpeg-4 AR and ignores that of an AVI. You've had it all this time ;p
Originally posted by symonjfox
I didn't know about it. I thought that the decoder (3ivx, ffdshow, divx ...) decodes the stream and adjust it to the right size, not that the graphic card does it.Graphic card should do that, definitely. This is why I don't like the Nero's way.

Radek

[mikeX]

But you linux geeks don't need it at all, your mplayer reads mpeg-4 AR and ignores that of an AVI. You've had it all this time ;p
unfortunately i can't use only linux (yet) :(

and 'avi' should die indeed
imo 'mp3' should die too :devil:
long live vorbis & matroska (oh well ogm too)

[Andrey]

Back to the topic :)
(Personally, I completely agree on .avi and .mp3 death :))
Created 480x304 encode with bilinear resize.
Looks definitely greater than 576x240 encode.
All problems I noticed are with slightly blurred sharp text on computer monitors.
That gives me idea, that may be in my previous encode with 432x336 I occasionally select some bicubic resize instead of bilinear, when trying it ? :)
I 'll check it this night :)

[Assault]

Originally posted by sysKin
Maybe great idea, but I can't help thinking that:

Originally posted by Audionut
Personally I think the avi container should die.

Is so very very correct in my humble opinion, too.

I don't like the avi container very much either. But there are still reasons to use it(mainly compatibility issues). I don't think you will change that by not implementing the AR feature for avi.
Furthermore I think XviD should support as many container formats as possible.

One question sysKin: Do you think the XviD decoder will have the ability (any time in the future) to read the AR info from the mpeg4 bitstream? Then this whole discussion would be pointless. ;)

Assault

[Koepi]

It would be possible, but is very ugly:

when a filter gets inserted into the graph it can there request a different DAR. So at that point xvid dsf needs to read from the stream (which data isn't really available at that stage) and decode the first VOL header for fetching the PAR and recalculate DAR accordingly and send it through the graph.

I don't know if we can sort that out, I think this is a task that cries for gabest's (or Nic's) help :) [they're both _the_ dshow experts]

Regards
Koepi

[m0rtal]

Originally posted by Andrey
Created 480x304 encode with bilinear resize.
Looks definitely greater than 576x240 encode.
...
That gives me idea, that may be in my previous encode with 432x336 I occasionally select some bicubic resize instead of bilinear, when trying it ? :)
goddamn!
is this true that bilinear encodes looks better than bicubic when using them for AR? anyone can confirm this?
btw, nobody still didn't make any suggestions about the topic - what AR resolutions are best suitable?

[mf]

Originally posted by Koepi
It would be possible, but is very ugly:

when a filter gets inserted into the graph it can there request a different DAR. So at that point xvid dsf needs to read from the stream (which data isn't really available at that stage) and decode the first VOL header for fetching the PAR and recalculate DAR accordingly and send it through the graph.

I don't know if we can sort that out, I think this is a task that cries for gabest's (or Nic's) help :) [they're both _the_ dshow experts]

Regards
Koepi
Force a reconstruction of the graph?

[Assault]

Ok thanks Koepi for the clarification. :)

Assault

[Andrey]

>>is this true that bilinear encodes looks better than bicubic when
>>using them for AR? anyone can confirm this?
>>btw, nobody still didn't make any suggestions about the topic -
>>what AR resolutions are best suitable?
I think, that bilinear resize may be help in this case, because this is 1 CD encode. And additional artifacts produced by resizing are less noticable, I think...

[m0rtal]

Originally posted by Andrey
And additional artifacts produced by resizing are less noticable, I think...
not in bilinear case! imo, of course.
bilinear resize produses too ugly artifacts, even for 1cd encode...

[symonjfox]

I think it depends on what res you have to change.
For example i think that bilinear is better when downscaling, while bicubic is better when upscaling.

I think that lanczos is still the best resizer around.

[mikeX]

bilinear resize seems to give (quite) better results than lanczos at low bitrates (~680kbps) encoding anamorphically:

source: PAL 16:9 (720x576)
BilinearResize(544,432)
undot()
par @ 24/17 (=768/544) (--edited typo--)

my tests are quite inconsistent at the moment though so don't take them too seriously :rolleyes:

[mikeX]

some more info on my previous encode as well as a new one :)

source: PAL 16:9 (720x576) 2h15m (previous post)
avisynth: BilinearResize(544,432),Undot()
xvid: 2passes with defaults + Q-Pel + Adapt Quant -Packed Bitstream + Chroma Optimizer + PAR 24/17 (+ a small zone @ quant 31 for credits with greyscale) --> 660MB desired size

gspot-2.21:4cc-->XVID/yv12 | Name:XviD | Bitrate:680kb/s | Qf:0.116 bits/pixel

acceptable (that's very subjective offcource) results (much better than similar encodings -at smaller resolutions but with same target size- using 'LanczosResize' without 'Undot()'

source: PAL 16:9 (720x576) 2h15m
avisynth: LanczosResize(544,432),Undot()
xvid: 2passes with defaults + Q-Pel + Adapt Quant :: max B-VOPS 1 + Chroma Optimizer + PAR 24/17 (+ a small zone @quant 31 as before) --> 1100MB desired size

gspot-2.21:Bitrate:1136kb/s | Qf: 0.193 bits/pixel

very good results, you can tell the difference from DVD quality easily though if you are trying to find it (mostly blocks at walls/areas with minor color variations etc), the codec didn't max out (max quants @ 5 --without the credits--) although it came out 5MB undersized

notes: to view the movie in it's correct (anamorphic) AR i use either 'mplayer' (which does not use dshow and reads the PAR info from the MPEG-4 stream (libavcodec for decoding) ) to play the original .avi file or mux my video to matroska (.mkv) with 'mkvmerge' setting the AR flag for the video to 16/9 and view it with either 'media player classic' or 'bsplayer' using libavcodec from ffdshow for decoding

[Soulhunter]

The AR resizing is usually performed with the graphic card in hardware..Doesn't this rely on, how DS intructs the GC... :confused:

Thought that the current DS is not capable to understand AR info in AVI files...

So it cant tell the GC how to change the AR... :confused:

Bye

[Andrey]

>>bilinear resize seems to give (quite) better results than lanczos
>>at low bitrates (~680kbps) encoding anamorphically:
Heh, on two samples that I have now (encodes from rather clear DVD source) it SEEMS, that it is true. I do not know why, anyway.
And statistic based on two samples isn't serios, of course. :)

[mikeX]

http://www.avisynth.org/index.php?page=Resize

Quoting:
If you are magnifying your video, you will get much better-looking results with BicubicResize than with BilinearResize. However, if you are shrinking it, you are probably just as well off, or even better off, with BilinearResize. Although VirtualDub's bicubic filter does produce better-looking images than its bilinear filter, this is mainly because the bicubic filter sharpens the image, not because it samples it better. Sharp images are nice to look at--until you try to compress them, at which point they turn nasty on you very quickly. The BicubicResize default doesn't sharpen nearly as much as VirtualDub's bicubic, but it still sharpens more than the bilinear. If you plan to encode your video at a low bitrate, I wouldn't be at all surprised if BilinearResize yields better quality.

;)

[m0rtal]

ok, bilinear resize is sharper and more compressable, but what about ugly stairsteps effect? anyone notice that on any horizontal objects? it's too ugly for me - that's why I don't use bilinear :(

[mikeX]

hmmm, haven't made many tests with bilinear yet
do you always see such artifacts (regardless the desired res and the source)?

[m0rtal]

Originally posted by mikeX
do you always see such artifacts (regardless the desired res and the source)?
on any horizontal objects - ropes, buildings, cars, even horizon - always :(
that's essence of bilinear resizing, but the good side is that resulting image is simplier and thus easier to encode :)

[bugsan]

here is a sample anamorphic video, 720x416 (Display 720x288, ratio 2.5)
I didnt use the xvid option. i have set AR with MMG (mkv merge).
dont forget to enable "keep aspect ratio" in MPC.

matrix2_anamorph.mkv (http://membres.lycos.fr/xym0x/matrix2_anamorph.mkv) 2min 5.3MB xvid + 2ogg (french/english)

[Andrey]

Ok, just to finalize this thread. :)
My investigation results.
1. It seems that anamorphic encode looks more pleasant to the ... eee ... I would say brain :)
I can not tell it is more pleasant to my eyes, because when I specially investigate a picture, I could see more artifacts comparing to 1:1 encode.(A bit, really. May be it just looks different) But when I watch the movie, it seems to be better...
Compared resolutions are 576x240 and 448x336.
2. It seems, that bilinear resize MUST be used when encoding anamorphically to 1 CD, because I found artifacts produced by lancroz and bicubic resizes VERY annoying in this case... They do not affect the whole picture, but only parts containing small details.

P.S. This is IMHO, of course.

Thanks to all!

[symonjfox]

Originally posted by Andrey
1. It seems that anamorphic encode looks more pleasant to the ... eee ... I would say brain :)
I would add that I made another test that really surprised me:
720*576 (full D1 16:9 encode) Xvid ... + AACHE, total file 700 MB, lenght 100 minutes.

And so, when I watch it from nearby my monitor, I can see hundreds of artifacts and macroblocks (and it's normal since Full D1 res is too much for 1 CD encode). The surprise came when I watch it far away from my monitor ... no comment, the image is superior and artifacts disappear. It looks much better then the other test I made with 1:1 AR and bilinear resize (same filesize).

This is just my opinion, but from now, I will stay with AR 16:9 :)

[mikeX]

here is a sample anamorphic video, 720x416 (Display 720x288, ratio 2.5)

isn't anamorphic encoding all about compressing the horizontal axis more??