PARanoia

[Inc]

http://img218.imageshack.us/img218/7611/030b9rx.jpg (http://imageshack.us)


Also conversions and PAR 1:1 (mpeg4) targets are supported

http://img237.imageshack.us/img237/5714/conversion9np.jpg (http://imageshack.us)


In case of mpeg4 target, do choose the wanted profile (max allowed size)

http://img260.imageshack.us/img260/346/mp44ti.jpg (http://imageshack.us)


Individual Capture Cards/Drivers are supported at Avi-Capture inputs

http://img237.imageshack.us/img237/8472/capture2vq.jpg (http://imageshack.us)


Add common used commands to the resulting script

http://img404.imageshack.us/img404/187/avisynth1xu.jpg (http://imageshack.us)


Do enter/edit and preview the resulted Avisynth script

http://img404.imageshack.us/img404/5913/script7ml.jpg (http://imageshack.us)



You dont have to put the dgdecode.dll or MPEG2Dec3.dll in the Apps folder, it will be recognised (if correctly installed) in the Avisynth/plugins folder (via API).

Although this Appl. supports the string architecture of DVD2AVI generetaed d2v files you should upgrade to the Latest DGMPEGDec stable release from here:
http://www.neuron2.net/dgmpgdec/dgmpgdec.html
(Nice stuff inside! QuantMatrix Logging, mpeg1 support etc.)

Always remember: If downloading a new release of DgIndex, you also have to update the dgdecode.dll!!

Sources will be released when main bugs are fixed, main ideas are implementated and code is cleaned up - and that takes time.

Get it here ...

Version 0.31b
http://sourceforge.net/projects/paranoia-

Changelog
0.30b
- Now Resize- and Crop-Mods are available from 2-16
- Conversion from nonanamorph to anamorph added
- Input-FourCC is shown in the SourceInfo
- Option for Avisource() using Pixel_Type="YUY2" in case of mjpeg input (mjpeg-fix)
- Window enlarged for supporting 768 width inputs

0.20b
- Regular PAR1:1 Avi and Capture-AVI support
- Taking into account the individual Capture Carc/driver active window.
- Doing panscanning/increasingHeight is now possible via the height up'n'down gadget.

0.10b
- Settings will be written into an ini file on exit und loaded when starting again.
- Mpeg4 Resoltion Profiles added in "Settings".
- Appl. got an icon

0.09b
- Fixed:A hughe bug was encountered as NTSC final target sizes didnt match when borders needed to be added.

0.08b
- Fixed: If the avisynthscript window is open then the main appl.window is deaktivated.

0.07b
- Full mpeg4 target resizing support up to big widescreen targets like 1040x576 which is non anamorph out of a 720x576 1.778:1 anamorph source

0.06b
- Resizing core obtained some "check" modes for more userfriendly results
- Generic Par Mode can now be choosen above under "Settings" (more settings will be added and able to be safed as ini soon).

0.05b
- Resizing core rewritten - more accurate.
- Now even more ITU compilancy
- The ITU option button now is functional

0.04b
- A bug in receiving the correct path to the user specific location of the avisynth plugins dir via reading the registry seems to be solved now.

0.03b
- AR Parsing of the d2v source has been fixed, so 4:3 d2vs will now be recognised as 4:3 d2vs and not 16:9.
- Reading the Systems Registry key of avisnth where the plugins path of avisynth is stored. Therefore if the dgdecode.dll or mpeg2dec3.dll wont be found via avisynth's plugins folder, the appl. folder will be used.

0.02b
- A bug was in the resizing core when manually changed the act.px area from 720 to 704 for instance, the result was simply wrong --- fixed



To Do (beside fixing bugs):
- Option for integrating readymade avs fuction templates into resulting scripts
- Histogram preview for checking the correct Luma of the source.

[Peter1234]

@incredible:
Very nice. Thanks for all of the work that went into making this. Small item to fix, on Aviscript menu you have "safe script" which should maybe be "save script". Also on the button in the script window.

[Pookie]

Nice one ! I'm going to try it out today. Thanks, incredible.

[Inc]

Interesting, someone just pointed me to before that "safe" would be ok, I was a bit unshure as the diff. of "to save" and "its safe" before to me seemed clear *g

[movax]

Looks nice, very useful. A Delphi program, or C/C++?

[Inc]

It's written in Pure Basic (http://www.purebasic.com/index.php3).

[Wilbert]

I finally got the time to look at it (v0.20 / didn't know there's a v0.30 :)). Two comments:

1a) chips/drivers:

PAL: ATI's Rage Theater chip twice listed. It should have a capture window of 52.22 µs.
NTSC: ATI's Theater 200 chip - 52.15 µs.
NTSC: ATI's Rage Theater chip - 52.96 µs.

1b) An option to manually enter the capture window would be nice :)

2) scripts:

BicubicResize(472,576,1/3,1/3,0,2,768,572)

should be

BicubicResize(472,576,1./3.,1./3.,0,2,768,572)

since (int 1)/(int 3) is rounded to 0.

[Inc]

Hi Wilbert,

yep, beta increased to v 0.30b including many additions.
Thanks for your hints, beside some bugs you mentioned are already fixed, your other remarks will be implementated.

I updated the first announcing post to the latest infos/links/changelog.

The next version will support mp4,mkv,wmv etc as input too.

PAL: ATI's Rage Theater chip twice listed. It should have a capture window of 52.22 µs.Updatet


NTSC: ATI's Theater 200 chip - 52.15 µs.Did I miss that one in the off. doom9 capt.cards list?


NTSC: ATI's Rage Theater chip - 52.96 µs.0.30 gots that value already ...


Updates will be available in the next version

[IceM]

Verry verry verry welcoming application, tnx allot!
Good GUI, working fast, exactly what i need.

Much tnx man!

[danpos]

@Andrej

THX for the upgrade, Andrej ! I already downloaded it. :)

Cya!

[Richard Berg]

Ok, I'm a dummy, because I can't figure this out :p

Here's what my scripts normally look like:

AviSource("tv-sports-720x480.avi")
# edits, audio adjustments, AssumeTFF/BFF, etc.
Crop(0,2,0,-46, align=true) # mod 8 for filters
# mvbob
# denoising as needed to save bitrate
Crop(0,0,0,-2, align=true)
LimitedSharpen(dest_x = 640, dest_y = 304, ss_x = 1.8, ss_y = 1.7, soft=false)
# histogram, levels, gamma, etc.
return xxx

I then need to calculate the SAR to tell x264. In this example, it would about 8/11...I think...aspect ratios make my head hurt.

As far as I can tell, this program can help find the crops I want without having to load VDub and play with null transform (annoying). Can it also calculate the SAR?

[LocalH]

Very nice. I do have one feature request: would it be too hard to allow the user to input a custom source PAR and DAR? For example, I am working with NES emulator output destined for DVD, and I need to confirm my frame size calculations (I'm using a width of 650 for the image, padded to 720, and I recently learned that the NES PAR is 40:33, so I want to calculate and make sure I get the right width).

[Inc]

AviSource("tv-sports-720x480.avi")
# edits, audio adjustments, AssumeTFF/BFF, etc.
Crop(0,2,0,-46, align=true) # mod 8 for filters
# mvbob
# denoising as needed to save bitrate
Crop(0,0,0,-2, align=true)
This part will be calculated within Paranoia, even a bobbed filtering is possible when checking the "fieldbased Resizing" checkbox.

I then need to calculate the SAR to tell x264. In this example, it would about 8/11
It depends on the Target you choosed! If the Target is mpeg4 then the Appl. calculates a Par 1:1 Output. So SAR also will be 1 or 1:1.

If you wanna keep the full vertical resolution by keeping the incoming PAR for TV Purposes like played back via a HTPC then 720x480 is PAR "4320/4739"! not 8/11

720*(8/11) = 523,6363636364 ... *ough* far away from 640!
720*(4320/4739) = 656,3410002 ok, thats much closer and also correct as it will be cropped to 648px equal width samples on your TV later as 720 gots 711 active px inside at ntsc.

aspect ratios make my head hurtEasy:
Aspectratio is the image proportion result out of the digital imagesize treaten by the width adjust (squeezing/expanding) using the needed PAR.

In case of PAL 702x576 is 4:3 ... 702/576 = 1,21875 isn't 4:3 BUT if doing the calculation by using the needed PAR (used by the TV) the Proportion results right:
(702*PAL_PAR)/576 = (702*(128/117))/576 = 1,3333333333 = 4:3

[Inc]

Very nice. I do have one feature request: would it be too hard to allow the user to input a custom source PAR and DAR? For example, I am working with NES emulator output destined for DVD, and I need to confirm my frame size calculations (I'm using a width of 650 for the image, padded to 720, and I recently learned that the NES PAR is 40:33, so I want to calculate and make sure I get the right width).
Hmmmm...
The correct PAR is calculated beside other things out of the incoming active width used by the Card/Driver when the capture has been digitized.
Standard D1 ITU would be 53,333µs which is exactly 720 for DVD purposes.
If your software expects a diff. PAR then a) it will manipulate the input during mastering or b) it will output a wrong 720 or 704 DVD target active area!

There are MANY popular softwares which do calculate the image size in a wrong way. Adobe for example uses for D1 a "generic" Aspectratio, thats the case in Photoshop and imho in Aftereffects.
So do generate a cricle in Photoshop using the D1 PixelAspectRatio Template and a 720x576 Image, do author a DVD from it and measure the circles proportion finally on the TV, the result will be a circle which will have a wider width using a factor of 720/702.

How to fix that? Do uncheck the ITUcheckbox in paranoia to fix such inputs.

[LocalH]

Well, the video I'm working with is just a raw lossless 256x240 output, and I know for a fact that the PAR of a real NES is 40:33. DAR of this file doesn't matter, but would basically be 4:3 with padding added after resizing for the proper PAR. Yet, when I load it, it treats it as 1:1 PAR, and I have no way to change it. The only line time I care about is the one you listed, standard D1 at 53.333µs, since my material is destined for DVD.

[Richard Berg]

This part will be calculated within Paranoia, even a bobbed filtering is possible when checking the "fieldbased Resizing" checkbox.
So I can have it calculate the mod8 and then the final crop for me? How?

If you wanna keep the full vertical resolution...
I'm discarding some vertical resolution, obviously. When you bob a high-motion clip, much of the vertical rez is interpolated anyway. Thus I think it's a fair compromise to resize 428 lines -> 304 so that I can have a smooth 60fps encode without insane bitrate.

original aspect ratio: 720/428 * 4320/4739 = 1.534

encoded aspect ratio: 640/304 * 8/11 = 1.531

Pretty close. 1:1 would be way off; more importantly, it looks bad.

[Richard Berg]

BTW, a bug: if PARanoia is unable to open the video (e.g. no codec), it gives you 1 message box for every frame in the clip. No way to stop it except kill the process.

[Inc]

Hi Richard,

Which Message is shown if no codec is present? So I can fix that "if" checking routine in the code.

"720/428 * 4320/4739 = 1.534" should be calculated as (720*(4320/4739)) / 428 = 1,5335070098 ... the result is the same, but for understanding the PAR thing it would be better doing it like that ;)

In your Calcs .... what is your target? What did you choose? mpeg4 PAR1:1 ? Which final size?
I assume your import is an AVI file, so did you set the CaptureCard Settings the right one?
Maybe you could host a little sample of your source, so I can do duplicate your approach.

Thanks for reporting the bugs :)

[Richard Berg]

The message is "No avi imagedata could be received!". An easy way to test is install ffdshow, then go to VFW config -> codecs -> set your file's fourcc to Disabled.

I don't have a specific target. I've experimented a lot, trying to find a workable compromise between:
- smooth motion
- sharp picture
- playable on reasonably modern machines
- not too huge

The best combo I've come up with so far is 60fps bob w/ some vertical rez reduction, encoded with x264 @ 2000kbps. I don't know what PARanoia settings that corresponds to since I'm not very familiar with it yet.

My capture card (http://www.comprousa.com/New/en/product/vmtvm800-hardware.html) uses the NEC D64083 (http://www.necel.com/digital_av/english/images/block_d64083.gif) chip. I don't have a standalone DVD player to calibrate it with, so I've just been guessing that it's a 53.333 active window.

I'm uploading a 15sec sample to the temp space in my signature. (compressed @ xvid quant2, ~25MB)

[Inc]

Thanks for naming the error, I just needed it to see at which routine the Appl. "loops" in its errormess. as I gave every procedure an internal check using a sensuful but individual mess. as output if something gets messed up.

Your Link is very useful as I do see they do refer to a y/c separation unit when talking about the NEC D64083 chip.
The most imortant is listed more below in the Link.
Key features

* PHILIPS SSA7133/4HL video and audio broadcast decoder
So I do really guess your card in combination with its driver does output an active window of 52,14815µs which could mean when capping at 720 will result in a wrong AR/PAR.
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.

[Inc]

Richard,

try this (http://home.arcor.de/packshot/PARanoia_0.31b.exe) 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.

[Richard Berg]

Thanks, the new version avoids the endless-message-box issue.

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...

http://richardberg.net/bin/temp/bball-ticker.jpg
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).


http://richardberg.net/bin/temp/bball-noticker.jpg
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.


http://richardberg.net/bin/temp/bball-letterbox.jpg
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 :)

[MacAddict]

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 ;-)

[Richard Berg]

Heh. Of course, you guys won the '98 game in the 3rd picture...

[hanfrunz]

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

[Inc]

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



(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.

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.

[Richard Berg]

Why do you decrease the heigth?
It's the best compromise between file size & quality, nothing more.

[Inc]

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.php?p=685658#post685658
http://forum.doom9.org/showthread.php?p=562532#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?

[Richard Berg]

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.)

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?

[Inc]

The executable and the sources(GPL) are now hosted at sourceforge
http://sourceforge.net/projects/paranoia-/

[buzzqw]

A very big :thanks:

(now go to studing sources !)


BHH

[15081947]

:thanks: this tool has been very helpful in determining AR and using it for resizing