Interlaced HD to DVD AGAIN - some test renders

Back to post

Comments

craftech wrote on 5/31/2011, 4:00 PM
As for what Procoder states, I can't come up with an explanation. Perhaps I just don't understand their terminology. To me, if something renders a 144 minute video in 144 minutes, I would say that it was 100% of realtime. If it took 1,440 minutes, I would say it took 10% of realtime, and so on.
=====
Wrong piece of scrap paper. Actually it was an 82 minute video that took 25-26 hours to render that Procoder was reporting at .05 of realtime or 5%

In terms of the script error, I wonder if Nick has seen your comment on Method 3.

John

Thanks John for the suggestion to change the last line in the script. I am rendering an hour long video using it right now. Then I'll be able to compare. Procoder says it is rendering at 6% of realtime.



NickHope wrote on 5/31/2011, 9:55 PM
John (craftech), if you look back at the script for method 3, it's crucial that the 2nd to last line ( i1 # re-interlaced p2) is not commented out like the 2 above it, so don't delete it. At a glance those 3 lines look like 3 comments but that one isn't, and so return(last) actually returns i1.

The original script was written by Didée, who is used to writing long, complex scripts where lots of variables need assigning and referring back to. For our purposes it's probably easier to rewrite the whole thing just as a series of sequential steps, without assigning p1, p2 or i1 at all. I did actually try that and the result was the same. So that original method 3 script could be written like this:

AviSource("d:\fs.avi")

ColorYUV(levels="TV->PC")

AssumeTFF

TDeint(mode=1)

bicubicresize(1440,960)

bicubicresize(720,960,-.8,.6)

bicubicresize(720,480,-.8,.6)

QTGMC(TR0=1,TR1=1,TR2=2,InputType=1)

blur(0,1)

sharpen(0,.51)

blur(0,1)

sharpen(0,.85)

assumetff()

separatefields()

selectevery(4,0,3)

weave()


(um, check that on a short bit of video to make sure I've got it right)

Or are you suggesting the basic AviSynth 2.6 with the modified 2.5 MT dlls?

This whole issue is very dependent on the individual's system, but it seems that people have had a fair amount of success running QTGMC multi-threaded with this 2.6 build (Version 2009.09.19). Not sure what John M is using with QTGMC now. He was using 2.6 but I have a feeling he reverted to 2.5. John???

One disadvantage of 2.6 is that (John M found) it won't accept frameserved RGB. However a significant advantage since a couple of days ago is that one can use SmoothLevels losslessly in it, unlike in 2.5, because of the the YV16 support. People were finding that mt_masktools-25 was working better in 2.6 than mt_masktools-26, but -Vit-'s modded plugins package may have rectified that.
craftech wrote on 6/1/2011, 5:06 AM
Thanks Nick,

I guess I'll stop the render, change the script, and do it again.

I am thinking that for a future reference (as in a Search) this thread may be more helpful if the scripts are written without all the variables. In other words, written as it was implemented. I realize that the basic stuff like number of threads for MT and the location and name of the source file have to be variable, but unless a person who wants to try the script is an active participant in AVISynth forums much of it can get confusing.

I am finding that I like scripting (as a result of this thread) and am interested in following some of it on the Doom9 forums learning the variables, etc , but I don't think that should be the assumption for anyone wanting to implement the results of this thread. What do you think?

For example. I have to delete one video that took 26 hours to render and also have to stop a 20 hour render that is at 10 hours right now just to try Method 3 on an entire video production. Do I mind? No. But some people might.

Any thoughts?

John
EDIT: I am doing it again with the following script:

Method 3 for Multi-Threading on a Quad Core



SetMTMode(5, 4)

AviSource("c:\fs.avi")

ColorYUV(levels="TV->PC")

AssumeTFF

TDeint(mode=1)

bicubicresize(1440,960)

bicubicresize(720,960,-.8,.6)

bicubicresize(720,480,-.8,.6)

QTGMC(TR0=1,TR1=1,TR2=2,InputType=1)

blur(0,1)

sharpen(0,.51)

blur(0,1)

sharpen(0,.85)

assumetff()

separatefields()

selectevery(4,0,3)

weave()

Distributor()


NOTE: SCRIPT FAILED


craftech wrote on 6/1/2011, 7:25 AM
Follow-up:

The script errors out. Access Violation for Line 5 [TDeint (Mode =1)]
Wouldn't work until I removed the MT and Distributor lines.
In other words, until I used it exactly as Nick just posted.

Estimated render time for the non-MT version is 36 hours for a one hour video. Approximately 3% of real time. Since I may end up deleting it or stopping it after a response here I stopped the render.

Earlier, Multithreading was suggested for Method 3.

But it is obvious simply adding the MT line isn't enough. NOTE: Avisynth MT is properly installed on my system. I am running version 2.5 of Avisynth. Five MT scripts have worked on my system until this one. All of them included TDeint.

So maybe the problem is with Tdeint combined with QTGMC in the Multithreaded version of Avisynth 2.5. Or maybe it's what John Meyer noted in an earlier post above:
============================
Or maybe Not all AVISynth plugins will work with multithreading. In my 2+ years of using the MT version I have run into two problems, although neither has happened often. The first is instability (crashes). I did have this problem with the complex QTGMC script and it was this problem which forced me to change from the 2.5.8 MT version I was using to a 2.6 MT version. The 2.6 version seems both better and faster, but it will not read RGB24 from the Vegas frameserver, so sometimes I switch back to the older 2.5.8 version.
===========================
I then tried adding something John Meyer suggested earlier.

Instead of SetMTMode(5, 4) with 4 being the number of cores, I used SetMTMode(5,0) which tells it to use ALL cores.

I also added SetMTMode(2) after the AVISource = ...line that I had forgotten in my script.
I had been using that line in my other MT scripts and had forgotten to include it. That probably was the main problem not the SetMTMode(5, 4) vs SetMTMode(5, 0) change.



Thus the new Method 3 with Multi-threading is



SetMTMode(5,0)

AviSource("c:\fs.avi")

SetMTMode(2) 

ColorYUV(levels="TV->PC")

AssumeTFF

TDeint(mode=1)

bicubicresize(1440,960)

bicubicresize(720,960,-.8,.6)

bicubicresize(720,480,-.8,.6)

QTGMC(TR0=1,TR1=1,TR2=2,InputType=1)

blur(0,1)

sharpen(0,.51)

blur(0,1)

sharpen(0,.85)

assumetff()

separatefields()

selectevery(4,0,3)

weave()


It didn't error out and it didn't crash. It is also rendering at approximately 5% of realtime or approximately 19 plus hours for an hour video. CPU Utilization is 80-90% which is good.
I haven't tried it with the Distributor() line at the end, but I don't think it will make much difference. Maybe next test.

Thanks,

John


johnmeyer wrote on 6/1/2011, 10:18 AM
For example. I have to delete one video that took 26 hours to render and also have to stop a 20 hour render that is at 10 hours right now just to try Method 3 on an entire video production. Do I mind? No. But some people might.Yes. Test on short clips before you commit to an all-day render. Do LOTS of tests to make sure your script is doing what you think it is doing.

Also, make sure you always look at the "File Information" dialog in VirtualDub. This often reveals flaws in your script. For instance, because you returned "last" in the script I criticized in my earlier post, you actually returned the value of the line:

p1 = bicubicresize(720,480,-.8,.6)

The way AVISynth works, every line after this was assigned to a variable. Therefore this was the "last" line executed before variables were used (the resize command is executed prior to the assignment to "p1" so is it the "last" statement). If you had looked at the File Information dialog, you would have seen that the video was 720x480 (which is what you would expect) but that it was 59.94 fps. This was because QTGMC was never executed, and the variables you used for QTGMC were designed, among other things, to change the double framerate back to normal NTSC 29.97 framerate.

In addition, make sure you are certain that what you are getting is what you were expecting to get. When possible, use a StackVertical or StackHorizontal statement so you can compare the source footage to the final footage.


craftech wrote on 6/1/2011, 1:44 PM
For example. I have to delete one video that took 26 hours to render and also have to stop a 20 hour render that is at 10 hours right now just to try Method 3 on an entire video production. Do I mind? No. But some people might.
===========
Any thoughts?Yes. Test on short clips before you commit to an all-day render. Do LOTS of tests to make sure your script is doing what you think it is doing.
============
I actually have been doing lots of short clip script rendering for myself. But thinking I liked Method 3 better than my other tests and seeing that it had already been tested I thought I would use it for a project. But in terms of the way it was posted, I made some mistakes interpreting it because of a lack of experience in the details of scripting implementation and description. Plus, the original script appears to have a mistake in it from what you pointed out.

Since the HD to SD quest for better results will be here for sometime I feel that this thread will come up in a search for such.
I think that someone looking to try the recommendations might be better served by a more simple script statement instead of making an innocent mistake when they rearrange and un-comment .
So maybe 20 hours later they find out that something was wrong and post back here to find out what they did wrong. This will probably be a bigger problem when this thread is no longer active.

That's what I was suggesting.
=============
Therefore this was the "last" line executed before variables were used (the resize command is executed prior to the assignment to "p1" so is it the "last" statement).
=============
OK. I think I get that now. Really interesting stuff.
=============
When possible, use a StackVertical or StackHorizontal statement so you can compare the source footage to the final footage.

I will check that out.

Thanks as always John

John
NickHope wrote on 6/1/2011, 9:20 PM
Any thoughts?
1. Totally agree with doing a number of short test renders before committing to a long one.
2. QTGMC is probably over the top and unnecessary for this application.
3. That double-stage low pass filtering [i.e. blur(0,1).sharpen(0,.51).blur(0,1).sharpen(0,.85)] is probably inappropriate and unnecessarily lossy for normal footage.
4. Follow -Vit-'s MT instructions (in the QTGMC help file) carefully for best chance of success with MT.
5. Don't worry about future usability of this thread too much. I think everyone apart from us 3 has long since zoned out. I'll probably start a new thread for a version 2 DVD and edit the first post of this thread with a link to it and any conclusions/warnings from this thread.
craftech wrote on 6/3/2011, 4:08 AM
3. That double-stage low pass filtering [i.e. blur(0,1).sharpen(0,.51).blur(0,1).sharpen(0,.85)] is probably inappropriate and unnecessarily lossy for normal footage.
==============
This is why I needed to do some long renders. I definitely noticed it on the hour long video, but did not on the test video you did. That's because it isn't as noticeable in every scene. But overall it definitely is.
==============
5. Don't worry about future usability of this thread too much. I think everyone apart from us 3 has long since zoned out. I'll probably start a new thread for a version 2 DVD and edit the first post of this thread with a link to it and any conclusions/warnings from this thread.
==============
Thanks. That makes sense.

John
craftech wrote on 6/3/2011, 12:06 PM
Continuing the experiments with these HD to SD scripts I have some updates on some new things I tried.

These were full hour plus renders.

I tried the following from a Vegas MXF 1920 x 1080-60i square pixel timeline with full color enhancement and levels adjustments, but NO sharpening:

1. Frameserve YUY2 to Procoder 3 via a Lanczos 3 gradual downsize script.

2. Frameserve YUY2 to Procoder 3 via a Lanczos 4 gradual downsize script.

Light sharpening similar to Unsharp Mask in Vegas with a "light" setting was added in Procoder 3 during the Mpeg 2 render.

The first gave me a soft image with lots of horizontal banding on CRT. Passable on a Plasma.

The second seemed worthy of posting here. My test looked very good on LCD and Plasma and as good as the better ones I've seen on CRT with minimal artifacts. If anyone wants to try it here it is:

NOTE: It is written for the MT version of AviSynth. If you don't have that one remove lines 1, 5, and the last one. Line 1 is for a Quad Core (4). If yours is different change that number or use 0.



SetMTMode(5, 4) 

AviSource("e:\fs.avi")

ColorYUV(levels="TV->PC")

AssumeTFF

SetMTMode(2)

TDeint(mode=1)

Lanczos4Resize(1440,960)

Lanczos4Resize(720,960,-.8,.6)

Lanczos4Resize(720,480,-.8,.6)

blur(0.0,1.0)

sharpen(0.0,0.75)

assumetff()

separatefields()

SelectEvery(4,0,3)

Weave()

Distributor()


John
NickHope wrote on 6/30/2011, 10:52 AM
Can't see me having time to do another full comparison test for some time, so here's the script I have settled on for the time being, for general purpose H1080-60i to NTSC-DVD:

#Frameserve in RGB24 format (or RGB32 if AviSynth will not accept RGB24)



AviSource("d:\fs.avi")

AssumeTFF()

ConvertToYUY2(interlaced=true, matrix="PC.601")



Spline36Resize(720,height)

TDeint(mode=1)

Spline36Resize(width,480)

blur(0.0,1.0)

sharpen(0.0,0.75) #Adjust 2nd value between 0.5 and 1.0 to taste



separatefields()

SelectEvery(4,0,3)

Weave()


Firstly, by frameserving in RGB and then converting to to YUY2 in AviSynth, we can hang on to the full dynamic range. If Frameserver does the conversion to YUY2 it maps to video levels (using Rec601) which need stretching out again with the ColorYUV, and that will be slightly more lossy. Only point I'm not sure on is if some builds of AviSynth won't accept RGB24, or are slow with RGB32. John M had some trouble with that (in SET's MT AviSynth 2.6 I think).

Secondly, on my fairly typical playback gear I am unable to see any difference between any of the resizing methods, including any multi-stage resizing, so I'm content to keep it simple and do it in one go (well actually width first, then height after TDeint bobbing).
craftech wrote on 7/1/2011, 3:06 AM
Nick,

Sorry I didn't notice this until this morning. I wanted to say thanks again for all the work you have done on this. Much appreciated.

Have you tried sharpening in CCE when it creates the Mpeg 2 file instead of or in addition to the sharpening in the AviSynth script?

I am looking forward to trying your new script on my next project.

Thanks again,

John
NickHope wrote on 7/1/2011, 5:20 AM
I haven't tried that. Actually there is no sharpen feature in CCE Basic, as far as I can see. It seems to me it may as well be done in AviSynth if you want more sharpening. Or perhaps Procoder makes a better job of it if it does it concurrently with compressing(?). I don't know. There are fancier AviSynth sharpeners around such as Didee's LimitedSharpen which includes an unsharp mask option. I also wonder whether, if you are sharpening twice, perhaps you should be blurring first each time. Something along the lines of the original script which was doing that to achieve more low pass filtering to deal with amendegw's hula horror clip. All down to experimentation I guess, which I will have to abandon for the time being as I have too much else to get on with and I won't actually need this script myself for a good long time.
NickHope wrote on 7/3/2011, 6:24 AM
John,

Just remembered that I didn't test henryho_hk's suggestion. No time to test at the moment so I'm noting it down here (with some of his comments and some of mine) as a full script before I forget. It's should be faster than the scripts that use TDeint or QTGMC. I have no idea what a Robidoux filter is but it's worth a go. I'm not sure about the 704x480 line and would test it with our usual 720x480 as well, without the added borders. Also I'm not sure if the blur/sharpen is still required after that special bob, but it probably is.

#Frameserve in RGB24 format (or RGB32 if AviSynth will not accept RGB24)



AviSource("d:\fs.avi")

AssumeTFF()

ConvertToYUY2(interlaced=true, matrix="PC.601")



bob(0.3782,0.3109) # Robidoux filter is mathematically optimized for cylindrical resizers (which are painfully slow)

spline36resize(704,480).addborders(8,0,8,0,align=true) # maintain a better NTSC 16:9 aspect ratio



# Not sure if the following are still needed with henryho_hk's bob and resize (above) or not. They probably are. Test first without and then with.

#blur(0.0,1.0)

#sharpen(0.0,0.75) #Adjust 2nd value between 0.5 and 1.0 to taste



SeparateFields()

SelectEvery(4,0,3)

Weave()
craftech wrote on 7/3/2011, 9:40 AM
Nick,

I have never understood why a few people prefer 704 x 480 over 720 x 480. While it is a valid resolution there are instances where it produces a 4:3 result with 16:9 footage. I believe it was originally a format for analog 4:3 televisions. There are also some DVD recorders that produce DVDs with this resolution. The missing 8 pixels from each side I would think could be an issue, but I am not sure. Maybe Henry has an answer for that preference.

I may try the script and post my findings because I just finished my last paid project. Perhaps I'll run an A-B comparison with the one you just posted above it.

Thanks,

John

EDIT: I looked up Robidoux. It's a poster (Nicolas Robidoux) that works with AviSynth who posts on the net.
NickHope wrote on 7/3/2011, 10:27 AM
John, if you test those 2 scripts then don't forget to time them.

I don't understand why 704x480 might be preferable to 720x480 either. If anyone knows then please tell us.
johnmeyer wrote on 7/3/2011, 11:00 AM
I don't understand why 704x480 might be preferable to 720x480 either. If anyone knows then please tell us.A week ago, I received some 704x480 video from a client. I was aware that this was a legal DVD resolution, but had never dealt with it before, and I had to do some research to figure out the proper way to deal with the aspect ratio issues when converting it to 720x480.

What I found -- and I'm not sure this is the whole story -- is that the eight pixels on either size are intended for overscan. Put another way, in 720x480 video, the DVD player and TV set conspire to not actually show the pixels at the edge. I didn't entirely understand everything that I read, but it sounded to me that if you encode 704x480 and put it on a DVD, the DVD player adds black pixels on the edge and puts it out to the TV which then masks out the overscan. So, you end up with exactly the same picture and the same number of pixels on the TV display, regardless of whether you encode 720x480 or 704x480.

I am not 100% confident of that explanation, but I am confident that if you receive 704x480 and need to encode it to 720x480 (to match with other 720x480 footage) the correct way to do that is to add 8 pixels on either side. What you don't want to do is to stretch it.

[edit] I just did some more research, and some sites claim that you should stretch to go between 704x480. I guess I don't know the answer after all.
NickHope wrote on 7/3/2011, 11:39 AM
I bet Bob knows.

I reckon 704x480 played back on a computer without overscan will probably play back with black bars down the sides.
Laurence wrote on 7/3/2011, 1:18 PM
704x480 looks great on a DVD player. I used to use it all the time because it was exactly the same aspect ratio as HD video and you didn't end up having to do either slight pillarboxes on the side or a slight horizontal stretch.

I stopped using it however recently because there is a major problem when you try to play this video back in Windows Media Player. For some reason WMP totally screws up interlaced mpeg video with these dimensions. To say it looks bad is a complete understatement. It looks just horrid. If you are absolutely sure that your video is only going to be played back in a DVD player and NEVER EVER going to be played back on a PC with WMP, it's a nice format. I just can't take that chance however.

Interlaced 704 x 480 video looks fine in VLC. It's just WMP that screws it up.

There was quite a thread about this a while back. I was recommending this format and the poor guy I recommended it to was looking at his final results on a PC and appalled with his results. We were discussing downrezzing HD to SD at the time and I recommended going to 704 instead of 720 because of the better aspect ratio match.

Here is that thread:

http://www.sonycreativesoftware.com/forums/ShowMessage.asp?Forum=4&MessageID=737548
craftech wrote on 7/3/2011, 1:27 PM
I ran the first test of these most recent scripts. You can download and burn the test DVD here.

The FOUR tests are only 9-10 seconds long to keep the file small. If it's too short, I'll do it over.

First one is Nick's most recent simplified Spline 36 resize script:



#Frameserved in RGB24 format 



AviSource("d:\fs.avi")

AssumeTFF()

ConvertToYUY2(interlaced=true, matrix="PC.601")



Spline36Resize(720,height)

TDeint(mode=1)

Spline36Resize(width,480)

blur(0.0,1.0)

sharpen(0.0,0.75) #Adjust 2nd value between 0.5 and 1.0 to taste



separatefields()

SelectEvery(4,0,3)

Weave()


The second one was Henry's script, but I had to modify it. No matter what I tried Procoder would not correctly recognize the AVS file with 704 x 480 in the script. It kept seeing it as 664 x 56 at 24 fps with an AR of 83:7. I had to modify it to 720 x 480. That resulted in the following script:



AviSource("c:\fs.avi")

AssumeTFF()

ConvertToYUY2(interlaced=true, matrix="PC.601")

bob(0.3782,0.3109) 

spline36resize(720,480)

#blur(0.0,1.0)

#sharpen(0.0,0.75)

SeparateFields()

SelectEvery(4,0,3)

Weave()


For the third test I removed the # for blur and sharpen to add those into the script.

For the fourth test I used my Lanczos 4 Gradual Resize script:



SetMTMode(5, 4) 

AviSource("e:\fs.avi")

ColorYUV(levels="TV->PC")

AssumeTFF

SetMTMode(2)

TDeint(mode=1)

Lanczos4Resize(1440,960)

Lanczos4Resize(720,960,-.8,.6)

Lanczos4Resize(720,480,-.8,.6)

blur(0.0,1.0)

sharpen(0.0,0.75)

assumetff()

separatefields()

SelectEvery(4,0,3)

Weave()

Distributor()


The original footage was color corrected and rendered to an MXF intermediate of the same resolution. Project properties with Interpolate Fields. The MXF intermediate file was frameserved to Procoder 3 as specified in the scripts. Procoder rendered the m2p files at a CBR of 8300. DVDA used to create the DVD test folder. I left out the audio.

Check it out when you get a chance.

Henry's script produced an unacceptable strobing effect. If anyone knows why please post here.

Render times were: 46 seconds, 37 seconds, 40 seconds, and 46 seconds respectively. No multithreading was used on scripts 1,2,or 3. It was used on Script 4.

John
NickHope wrote on 7/3/2011, 11:44 PM
Thanks for the feedback and the link to that old thread Laurence. Will do some testing of my own.

Still getting my head around 704x480 vs 720x480 here, and struggling to understand exactly why 704 should give a "better" aspect ratio. Some equations would help, if anyone else understands that.

It's strange how Procoder is reading that file. The output of the henry script should actually be 720x480 because the borders are being added. Try opening the .avs in VirtualDub and see what dimensions it is and whether it's pillarboxed etc..

>> Henry's script produced an unacceptable strobing effect. If anyone knows why please post here. <<

Probably need to activate the blur/sharpen lines by un-commenting them. I commented them out for a first try because I didn't know what that Robidoux filter was doing, but I had the expectation that they would ultimately be required. Downloading your DVD folders now John.
musicvid10 wrote on 7/4/2011, 12:06 AM
Nick, only thing my cobweb-filled brain recalls is that 704x480 was considered correct for DV-AVI NTSC source aspect.

Indeed, 704 x .9091 = 640
craftech wrote on 7/4/2011, 3:50 AM
Probably need to activate the blur/sharpen lines by un-commenting them
==================
Yes. As noted that was what was done for clip 3 to compare with (clip3) and without (clip2) the blur/sharpen effect.

The strobing effect was present in both clip 2 and clip 3. I'll open them up in VD as Henry wrote them (unmodified) and post back.

Let us know what your impressions are of each of the four clips.

John
NickHope wrote on 7/4/2011, 8:54 PM
Ah sorry, I read your post in haste yesterday and missed that.

There is an error in Henry's script. Looks like he has assumed that the "AddBorders" command works the same as "Crop", which has the "align" option. AddBorders doesn't support it, so it looks like your tests have totally bypassed the whole Bob function, and those 2 renders are so bad that I'm sure that's what happened. The "align=true" needs to be deleted.

Really hard to see a significant difference between 1 and 4, so personally #1 remains my choice. I'm going to try some tests with Henry's script. More later...
NickHope wrote on 7/5/2011, 3:05 AM
I worked out that the "strobing" is because of a a field reversal problem. Recently I started dropping the 2nd "AssumeTFF()" line that I used to include ahead of the final reinterlacing, thinking that the "AssumeTFF()" at the start would apply through to that point. I wanted to keep the script concise. But apparently AviSynth keeps a track of whether a field is frame-based or field-based. Because TDeint and QTGMC are external filters, it doesn't know that they were making the clip frame-based (by deinterlacing), but because "Bob" is an internal filter, it knows, and so it's internal flag changes from "field-based" to "frame-based", and then it defaults to BFF when it comes to re-interlace. So the solution is to restore that 2nd "AssumeTFF()" before "SeparateFields()", and then all is OK. Sorry I ever removed it. Actually it's probably a good habit to always keep it in there just in case.

I also got my head around the 704 thing. Actually 704-plus-8-black-pixels-each-side is exactly the same as how Vegas renders by default, using the DVD templates. That is what is required for the picture to display at the correct aspect ratio, because NTSC DVD's A/R of 1.2121 does not actually give 16:9. An A/R of 1.1852 would be required for that. In fact 704-pillarboxed-to-720 will display at the correct aspect ratio, but you'll see black bars down the sides on the computer (I checked in PowerDVD and WMP). On displays with overscan you won't see them. The 720x480 renders we have been doing, actually display video 2.2% wider than it should be, but there will never be any black bars. So really you pays your money and takes your choice. Personally I will probably stick with 720x480 and no pillarboxing, but leave the 704+padding option commented out in my scripts. It does seem a good idea not to render 704x480 without pillarboxing, as that is what was causing Laurence trouble in WMP. If you have time and clear head the Prem Pro lot discussed this.