Quote:
Movies shown on TV are mostly progressive. Determining whether something is progressive or interlaced is not that hard, so no need to worry :D |
Quote:
(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 :wink: ). 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. |
Quote:
|
Quote:
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: Code:
addborders(0,0,48,0) Code:
crop(0,16,0,-16) Which in this particular case gave(overscan=1): Code:
LanczosResize(704,560,0,1,720,430) 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 Code:
bicubicresize(720,432) |
Quote:
(can I have your complete script ?) |
Of course, you can have it:
Code:
# 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 :?: http://www.digitalfaq.com/archives/error.gif Addresses change from source to source but remain invariable for different executions on the same source. As per avs version http://www.digitalfaq.com/archives/error.gif 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. |
Quote:
Quote:
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 :roll: |
Quote:
Quote:
Do the exact same tests with this : GripCrop(352, 288, overscan=1, source_anamorphic=false, dest_anamorphic=true) |
Quote:
Code:
GripCrop(544, 576, overscan=1, source_anamorphic=false, dest_anamorphic=true) 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 |
Quote:
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. |
Quote:
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... :idea: :wink: I’ll try it again (i mean to discuss and learn :) ): Quote:
Quote:
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: Quote:
Quote:
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 :!: |
Quote:
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... |
Quote:
|
Quote:
Quote:
Quote:
:arrow: 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 :roll: )
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: Quote:
Hope this makes sense... |
Quote:
|
Quote:
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...) Quote:
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 :!: |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.