Stuff made for TV is interlaced 99% of the time. The 1% comes from the fact that some TV shows/series are actually progressive, and some have been deinterlaced to create a pseudo-film look from interlaced material. Looks ugly in my eyes though.

Movies shown on TV are mostly progressive.

Determining whether something is progressive or interlaced is not that hard, so no need to worry

Are you sure ? That means that this is the TV that interlaces it ?
(TV can't display progressive stream, except for few new models).

For example Hollywood movies are broadcast progressive, because the original content is progressive. If you see combs, someone has screwed up the NTSC->PAL conversion progress or has used a converter box which creates a fieldblended monster (that can be restored to progressive 23.976fps with Restore24 ). The other option is that it's field shifted, which Telecide will fix easily.

The output is pseudo-interlaced : the two fields are exactly the same, when you separate them, you'll see that the other one is displayed slightly lower than the other. Temporally there is no difference. With truly interlaced material, each field is different (provided there's the slightest amount of motion/noise), temporally and spatially.

Okay, no problem, that is what I imagined also.

No, blindpp seems not to be the culprit here, although it requires mod16 pic dimensions.
Is gripborders thant triggers acces violation.

Take a 720x432 (that's 1.67:1 or 5:3). As both dims. are mod16, blindpp works happyly (whatever it does to the stream).
With this proportion vertical borders are needed in order to get 16:9 A/R anamorphic (because of proportion < 1.78:1). Avisynth crashes with an acces violation.

I performed several tests as first command in the script:

Source is 16:9. This cures the crash but then this border is not removed by gripcrop.

Also helps as it raises proportion to 1.8:1. But then, it just feels better to let fitcd do the job.
Which in this particular case gave(overscan=1):

And seems to crop only 2 pixels hight
At this point I don have a clue if image got a bit distortes as I don't understand what fitcd call "real aspect". It certainly is not width/heigth.
Anyway it loock very good, so I think I remain with fitcd instead of gripcrop/gripsize/gripborders.

alternatively, adding as a firstliner

Will make crash with any source.

This is something I have to test
(can I have your complete script ?)

Of course, you can have it:

As you can see I commented out all non related lines in your script with same result.
bicubicresize(720,432) only used here to force crash on a source not having these dimensions.

New finding: For the former to be true source has not to have borders. If source already has them then you don't get this crash



Addresses change from source to source but remain invariable for different executions on the same source.

As per avs version



Hope this helps

Try the latest Avisynth alpha, http://sf.net/projects/avisynth2 . A lot of bugs have been fixed since January 2004.

And please try to not upscale your video, but yo crop it to 544*576 for instance.

I never used Gripcrop to have a target bigger than the source, and I'm not sure it works with it.

Will try this as soon as I finish my current encoding

It's not related to scaling the video. I just hapent to scale this particular source to have the same diemensions as the one that crashed avs. Otherwise this source precesses without problem.
On the oder hand if you crop the problematic source (originaly 720x432) to be 720x400 it processes well too.

So it's not source related but source video proportion related. Other < 1.75:1 proportions give the very same error. Try cropping any avisource without borders to 360x216 (1.67:1), 320x216 (1.48:1 ) or 344x248 (1.39:1)

Even more, for any source (no previous borders):

- cropping to 360x208 --> 1.73:1 crashes
- cropping to 360x206 --> 1.75:1 works

So gripborders does not appear to manage well any source with less than 1.75:1 proportions except if source allready has borders

I mean in the grip crop line (the target size so, not the source) ! Do not ask him to generate something that is 720*576 but try 544*576 and see if with the same source size, it still crashes.

Because you probably still use Gripcrpo to ENLARGE the picture while it is designed to SCALE DOWN the frame size.

Do the exact same tests with this :
GripCrop(352, 288, overscan=1, source_anamorphic=false, dest_anamorphic=true)

Ok, so you're right, this works

Doesn't work. Dependig on who knows what it gives garbage, access violation o even media player classic crash

But issue remains:

With sources 720x320 (2.25:1) it works flawlesly and that's a lot more upscaling (borders added). As soon as you fall below 1,75:1 thing go south.

Also 720x432 is a near 16:9 proportion that should be posible to adapt to anamorphic without much cropping, nor going all the way down to kvcd resolutions. Just as fitcd does

Anyway, don't mind. I stay with fitcd

For sure, it was just a test.
Gripcrop never gave me any problem whatever the source reso to go downsize (btw you should never upsize a video). But I can't tell you how were the A/R of the source actually.
But as you understood yet, Fitcd gives better control on what is done and it's better to use it.

Now you were just mean... and I don’t quite understand why you act like this every time someone questions something you said.
Anyway, first, I never said that I did MovieStacker from scratch. I always told here (many times) that I took shh’s code (advised by himself) and improved it (mainly, but not only, in the avs script generation; imho) and I’m sure that you were there to here it most of the times.
Second, I can say for sure that I know very little about video encoding, but every little bit of knowledge that I have about this matter I learned here in this forum, and I’m still in a process of constant learning. I believe we all are, aren’t we
I was trying to raise a question, discuss it, and learn something. So please, get down from this kind of gold pedestal you put yourself on and don’t stop my trying for learning...


I’ll try it again (i mean to discuss and learn ):
I think you are wrong saying that!

I have to ask you the same. Read what I said slowly, again.
What you said is the process to get the anamorphic picture, not the anamorphic picture itself.
So, saying it again, an anamorphic picture is an image with X:Y dimension (that does not need to be 4:3) that need to be distorted to 16:9 to be viewed with the correct proportions.
This is exactly what drequena said here:
Yes! You got it right, but there is one thing to be corrected here, and please Phil or anyone else correct me if I’m wrong (bacuse I can't see how).
In your example you have a 4:3 picture dimension (400x300), but it does NOT need to be 4:3! We have anamorphic pictures with many different dimensions. The most used is 720x480... that is NOT 4:3

I believe this is not correct.
Any stuff flagged as 4:3 (that is not 4x3) will be scaled to 4:3 when playback.
Be it 720x576/480, 544x576/480, 480x576/480, etc...

Oh, I totally forgot about those other resolutions. That's exactly what I meant, they are scaled to 720x576/480 then.

That's is your right to think that. The problem is that I'm not wrong and can't explain it more or differently than I already do. So I drop the question there. Sorry.

To follow your way of thinking then my statement has to be changed to "an anamporphic picture is ALWAYS something 16:9". All other proportions are first turned to 16:9 by adding black borders, then anamporphism is applyied on the 16:9 box (to become a 4:3 box).
You are saying here exactly the same thing I am except that, as you said, you are considering how to render an anamorphic picture while I am talking about how to create it.

As an anamporhic picture is a 16:9 distorted into a 4:3 box, then (and of course), to render it you must "undistort' is back to 16:9.

But to take the problem from the start : the avs script that you use to feed the encoder produces a 4:3 picture WHATEVER it is anamorphic or not.

If I may add something (perhaps it will confuse people, perhaps not )

The biggest problem with the whole "AR/anamorphic/resolution"-thing, is that people tend to calculate AR from the resolution. This is, as most of you have noticed now, wrong (tm). PAL and NTSC have a respective resolution of 720x576 and 720x480, neither from which you can calculate the AR, which is in both cases 4:3. While a computer display has 1:1 pixel aspect ratio this is not true for TVs, hence we see the picture still as normal. So ona normal TV 720x576 or 720x480 = 4:3.

Anamorphic means, that this 4:3 frame is used to store a picture which is not 4:3 but 16:9 (anamorphic is always 16:9). A "normal" 4:3 TV will display this image distorted unless black borders are added, which is why it is called anamorphic. On a 16:9 TV there are of course no troubles (not for 16:9 at least ).

So when Dialhot says:
I assume he means anamorphic video uses a resolution/frame size that is natively used for 4:3 images.

Hope this makes sense...

Let say that I do not think in words of resolution because I use to play with anamorphism since years (I used to be operator in a theater), but else, you are correct.

Let me try to put it this way...

1-) I believe we agree that the AR of an anamorphic frame is always 16:9.
2-) We also agree that an anamorphic frame can have various resolutions (with that I mean frame size/dimension).

So if an anamorphic frame is not 4:3 AR and not 4:3 resolution, then where is the 4:3 you are saying
(keep reading...)

That's why I think it's not right calling it 4:3.
We already saw that it can use many different resolution/frame sizes.
And you say that we have to call it 4:3 just because it uses a resolution/frame size that is "natively used" for 4:3 AR
We are not talking about what is natively used. We are talking about anamorphic... and that is not 4:3 but 16:9