Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th November 2005, 21:14   #21  |  Link
Inc
Squeeze it!
 
Inc's Avatar
 
Join Date: Oct 2003
Location: Germany
Posts: 472
Richard,

try this one.
Now all sources except d2v will be imported via a temp.avs generated script.
Means if no decoder is given, then the known avs error screen appears.

Also by this its now possible to import beside avi & d2v ... mp4, mkv and wmv.
In the temp.avs then directshowsource() will serve the Imagedata and size.
But that means a non-anamorph source is assumed at mp4, mkv and wmv inputs.

Also a new script Previewer has been implementated.
Inc is offline   Reply With Quote
Old 22nd November 2005, 21:29   #22  |  Link
Richard Berg
developer wannabe
 
Richard Berg's Avatar
 
Join Date: Nov 2001
Location: Brooklyn, NY
Posts: 1,211
Thanks, the new version avoids the endless-message-box issue.

Quote:
Could it be that THIS is the reason why it "looks bad" as you stated some posts above?

Regarding your better experiences by reducing the vertical pixel information. Thats also possible by entering the Active Pixel Area gadgets (upndown) but you might already know that.
Let me explain another way. I'm doing 2 operations on my clips that are not due to anything related to aspect ratio; I do them only to save bitrate, so I that I can encode @ 59.94fps without requiring 3GB/game & a 3GHz playback machine. Of course, these operations do affect the PAR calculations. I'm wondering if your program can do any of the calcs for me.

(1) I crop from 480->428 lines. The lines I'm cropping are part of the active picture area -- I just don't care about them (stupid ESPN2 stats ticker). This operation doesn't change the PAR, but it affects the formula in #2...

(2) I resize from 428->304 lines. Now I am throwing away information I care about. (Hopefully not much -- a lot of the rez is probably interpolated). I've also changed the PAR. In order to display correctly, on playback the vid needs to be expanded back to the equivalent of 428 (NOT 480) lines before you can correct for the capture card.

Does that make sense?

If so, then wait, because there are more interesting twists when it comes to operation #1:
(a) Some filters require mod8, so if the desired crop is not mod8, I have to split it into two parts as in script above.
(b) The "important" part of the active picture window is always different...


Here's a frame from the clip I posted earlier. On ESPN2, the ticker is always present 24/7, so I crop it off along with the noise @ the top. Desired is (4,2,0,-52), which gets split into (0,2,0,-46) + (4,0,0,-6).



On ESPN, there's live action on the whole frame most of the time. (Twice an half hour they run the ticker for a few minutes, squeezing the action into the upper 430-ish lines, but I don't want to bother with dynamic resizing). Desired crop is (16,2,0,0), which gets split into (16,0,0,0) + (0,2,0,0). Fox Sports acts similarly but with different dimensions.



ESPN Classic never shows a live feed, so they have time to mangle it. Usually they letterbox the source in order to show the ticker, like this pic shows, which yields a different AR than the first case even though the ticker is the same height (~50 pix). Desired crop is (21,2,-19,-50), which turns into (20,2,-20,-46) [compromise, can't have odd horiz crop with YUY2] + (0,0,0,-4).


What's the correct SAR in each case? It's not an easy calc. Now you see why I hope PARanoia can help

Last edited by Richard Berg; 22nd November 2005 at 22:00.
Richard Berg is offline   Reply With Quote
Old 23rd November 2005, 14:09   #23  |  Link
MacAddict
XviD User
 
Join Date: Oct 2004
Location: Ky
Posts: 190
Nice application!

Hmm...seems someone else has the fever for a little 'round ball' action. A shame it's Duke though! Just kidding with you Richard ;-)
__________________
DFI NF4 SLI Expert | Opteron 165 CCBBE 0616 XPMW (9x325HTT=2.9Ghz) | 2x1GB G.Skill HZ (3-4-4-8-12-16-2T) | LG 62L DVD/CD | Geforce 7300GT | All SATA | Antec 650 Trio PSU | XP SP2
MacAddict is offline   Reply With Quote
Old 23rd November 2005, 23:05   #24  |  Link
Richard Berg
developer wannabe
 
Richard Berg's Avatar
 
Join Date: Nov 2001
Location: Brooklyn, NY
Posts: 1,211
Heh. Of course, you guys won the '98 game in the 3rd picture...
Richard Berg is offline   Reply With Quote
Old 25th November 2005, 17:43   #25  |  Link
hanfrunz
Registered User
 
hanfrunz's Avatar
 
Join Date: Feb 2002
Location: Germany
Posts: 537
This is a very cool little program! Are you planning to publish the source code? I am very interested how easy or not easy it is to do something like this in "Purebasic".

thanks,
hanfrunz
hanfrunz is offline   Reply With Quote
Old 25th November 2005, 23:19   #26  |  Link
Inc
Squeeze it!
 
Inc's Avatar
 
Join Date: Oct 2003
Location: Germany
Posts: 472
Quote:
Originally Posted by Richard Berg
Let me explain another way. I'm doing 2 operations on my clips that are not due to anything related to aspect ratio; I do them only to save bitrate, so I that I can encode @ 59.94fps without requiring 3GB/game & a 3GHz playback machine. Of course, these operations do affect the PAR calculations. I'm wondering if your program can do any of the calcs for me.

(1) I crop from 480->428 lines. The lines I'm cropping are part of the active picture area -- I just don't care about them (stupid ESPN2 stats ticker). This operation doesn't change the PAR, but it affects the formula in #2...
ok, I hope I got it



Quote:
(2) I resize from 428->304 lines. Now I am throwing away information I care about. (Hopefully not much -- a lot of the rez is probably interpolated). I've also changed the PAR. In order to display correctly, on playback the vid needs to be expanded back to the equivalent of 428 (NOT 480) lines before you can correct for the capture card.

Does that make sense?
Hmmmm ....
Why do you decrease the heigth? Isn't your 640x480 capture already PAR1:1?
I do understand that you do bob your stream to maintain the smooth playback and cropping away the parts you dont need ... up to here I can follow.

Quote:
If so, then wait, because there are more interesting twists when it comes to operation #1:
(a) Some filters require mod8, so if the desired crop is not mod8, I have to split it into two parts as in script above.
(b) The "important" part of the active picture window is always different...
Again: Hmmmmm

Well if you do bob your stream which causes more effective pix to encode then a non PAR1:1 based encoding incl adding a needed PAR/SAR flag to the bitstream makes sense.
So It would be possible to go for 544x480 and deleting the addborders line afterwards of the avs scriptcontend. Lets say you would end up in 544x428 in effective out of the avs but thats not mod 16.
So do crop manually just a bit more down to 640x416 incl. a targetsize to 544x480 and you will have a video non interpolated in its heigth but squeezed by a given par to 544.
Your PAR would be 640:526 as 526 are the active px out of 544 in case of a 52.000us capturecard/driver combination.
Inc is offline   Reply With Quote
Old 2nd December 2005, 07:03   #27  |  Link
Richard Berg
developer wannabe
 
Richard Berg's Avatar
 
Join Date: Nov 2001
Location: Brooklyn, NY
Posts: 1,211
Quote:
Why do you decrease the heigth?
It's the best compromise between file size & quality, nothing more.
Richard Berg is offline   Reply With Quote
Old 2nd December 2005, 09:50   #28  |  Link
Inc
Squeeze it!
 
Inc's Avatar
 
Join Date: Oct 2003
Location: Germany
Posts: 472
No, I meant that it would be imho better to resize the width to end up in less filesize or better quality in the same filesize As thats also the purpose of a PAR based encoding.

I see your approach very interested!
So I try to reproduce your workout:

a) Input = a 29.97 NTSC Source
b) (MV?)Bobbing it to 59.94 fps --> so making it progressive but still smooth in its playback
c) cropping not needed imagedata and if wanted applying a resizing
d) finally to gain more quality at less filesize you do squeeze the width at a given PAR-Factor before encoding.

Lets say your source is a 640x480 capture. cropping the garbage which lets the image end up in (i.E. MOD16) 624x400 @ 59.94 fps. Now, for saving bits you do resize down the width to 480.
This will give you a video image of 480x400 @ 59.94fps with a PAR of 624:480 (=1.3).
So you could encode that 480x400 using x264, xvid or whatever codec which supports a PAR/SAR flag setting/recognision. You see why I asked about why you dont apply the resizing finally to the width instead of the height for quality-gain purposes, cause the SAR/PAR option of a codec scales the width finally and not the height (imho).

Seems I do mess up SAR and PAR (*grrrr) :
http://forum.doom9.org/showthread.ph...658#post685658
http://forum.doom9.org/showthread.ph...532#post562532

So imho this would mean in this case ...
SAR = DAR * horizontal_size/vertical_size ... (quote Wilbert in the first link)

SAR = (624/400*(PAR1:1))*(480/400) = 1,872

can someone confirm that?

Last edited by Inc; 2nd December 2005 at 10:12.
Inc is offline   Reply With Quote
Old 2nd December 2005, 21:34   #29  |  Link
Richard Berg
developer wannabe
 
Richard Berg's Avatar
 
Join Date: Nov 2001
Location: Brooklyn, NY
Posts: 1,211
Quote:
why you dont apply the resizing finally to the width instead of the height for quality-gain purposes
The video camera is shooting 60 640x240 fields per second. So when you bob to 640x480, the horizontal rez is "real" detail but up to 1/2 of the vertical rez is interpolated by the bob filter. (A good filter can construct the extra 240 lines using "real" vertical detail found in adjacent fields, but it's very hard to do in high-motion sports footage.)

Quote:
the SAR/PAR option of a codec scales the width finally and not the height
I'm not sure what you mean by this. When I go to play my 640x304 video on a 1280x720 projector, why does it matter which axis is scaled first?
Richard Berg is offline   Reply With Quote
Old 11th February 2006, 23:06   #30  |  Link
Inc
Squeeze it!
 
Inc's Avatar
 
Join Date: Oct 2003
Location: Germany
Posts: 472
The executable and the sources(GPL) are now hosted at sourceforge
http://sourceforge.net/projects/paranoia-/
Inc is offline   Reply With Quote
Old 11th February 2006, 23:17   #31  |  Link
buzzqw
HDConvertToX author
 
Join Date: Nov 2003
Location: Cesena,Italy
Posts: 6,552
A very big

(now go to studing sources !)


BHH
__________________
HDConvertToX: your tool for BD backup
MultiX264: The quick gui for x264
AutoMen: The Mencoder GUI
AutoWebM: supporting WebM/VP8
buzzqw is offline   Reply With Quote
Old 12th February 2006, 17:45   #32  |  Link
15081947
Rate Distorted
 
15081947's Avatar
 
Join Date: Jan 2006
Location: FI33720
Posts: 7
this tool has been very helpful in determining AR and using it for resizing
__________________
Sometimes it is the dust on the display, not the noise in your encode
15081947 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 21:44.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.