I just wanted to first of all thank you for this ingenious function. Its is brilliant the way you managed to use existing avisynth commands to produce a very useful function.
I'd like to take advantage of your work in a non-commercial avisynth batch file that I have produced here http://forums.sagetv.com/forums/showthread.php?t=21932
Do I have your permission to modify my batch batch file posted at SageTV using your code? How would you like me to credit your work so that others will see your contribution?
Of course if you find this function useful you're welcome to use it. I've added a credit in the function comment, if you modify it just change to "based on a script by..." or words to that effect.
Guidelines for post content and general behaviour: read announcement here
Max. allowable image sizes in signatures: reminder here
Originally posted by: Zion Time is an enemy that always seems to get the best of me. I could be wrong, but I don't think C++ is much different from Basic.
Well it is a lot different from ZX sinclair or Atari 800 basic, but Visual C++ isn't much harder to learn than Visual Basic.
In virtualdub I the loaded that script to produce an xvid file. I expect that the output avi resolution would have been 720x405 to yield 16:9 AR, however the avi was still 720x480. I am wondering does it automatically get stretched to the proper 16:9 AR whem played back on widescreen? Because on my 4:3 computer monitor the image appears stretched vertically. Whats interesting is when I play the avs script in WMP, the AR appears to be 16:9 on my 4:3 computer monitor (letterboxed). The outputed final xvid avi product however plays back on my 4:3 monitor as being stretched vertically to fill the screens with no letterbox. What am I doing wrong?
I get it. Mpeg2 for DVD by definition MUST be 720 x 480. So it has to do with anamorphic ar on DVD then? If you burn to DVD the panorama converted avi then the resultant mpeg2 will play back in 16:9 resolution suitable for widescreen tv.
In that case given I am producing an Xvid mpeg2 is not applicable and I should add another resize at the end as follows:
lanczos4resize(688,508) crop(0,14,0,-14) addborders(16,0,16,0) panorama(3) lanczos4resize(720,400) [ or lanczos4resize(640,352) ]
Things are not so clear cut if you're making an Xvid AVI file, because there is such a variety of devices that they can be played back on.
I would not recommend adding borders, for an Xivd file it's a waste of bitrate. Make it with a smaller horizontal resolution instead. Similarly, I don't know if you would really want to crop - maybe that will happen when it's played back on a widescreen display.
The way I would do it it to modify the final line in the function:
return clp.lanczos4resize(720,ht)
replacing 720, ht with your desired width and height values. This assumes that if the source is interlaced that you have de-interlaced before Panorama.
Obviously would you need to experiment to your own requirements, but for a start you could try a resolution of 640x384 (1.66:1) with strength 3.
Guidelines for post content and general behaviour: read announcement here
Max. allowable image sizes in signatures: reminder here
Thank you. Actually I don't mind cropping because the same principle applies whether using an xvid or standard mpeg2. That is, I want a compromize between moderate cropping and moderate distortion. If I crop a little off the top and bottom, then maybe I don't need to use a strengh of 3 and hence there is less disortion needed to achieve the same screen coverage.
You have a point about the blackbars being a waste. By expanding the vertical resolution with 640x384, I end up with minor pillar boxes anyway because it will place a 1.66 video on a 1.78 AR screen. So this way I don't waste bitrate whereas by adding blackbars I Xvid ends up allocating cpu cycles for nothing. The only drawback to this is that the center portion of the screen will be distorted vertically a little.
Why does the function expand the horizontal resolution by a factor of 4? What I mean is that if you look at the result of the stack horizontal then you end up with an avi with a resolution of 2880xht (ht= 480 or 576) just prior to the resize to 720xht.
Could'nt we have just calculated rezize horzontal values for each wedge ( a,b....g ) such that the total already is 720xht?
Yes, in fact that's how I did it to begin with - but if you want the function to work on YV12 clips then each chunk has to have a horizontal resolution which is a multiple of 4. Doing all the resizing to 4x supersampling then sizing back down at the end gives you more flexibility.
Guidelines for post content and general behaviour: read announcement here
Max. allowable image sizes in signatures: reminder here
Ahh I Understand now. Is there a picture quality penalty to using the extra resize factor? I suppose you can also execute a ConvertYUY also.
Compared to executing a ConvertYUV() and then using exact resolution versus the 4 factor adjustment, which approach is better for (a) Picture quality (b) encoding speed
I realize colorspace conversions are lossy but aren't resizes also lossy? Please excuse the questions just trying to learn.
