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 21st May 2012, 16:11   #1  |  Link
Overdrive80
Anime addict
 
Overdrive80's Avatar
 
Join Date: Feb 2009
Location: Spain
Posts: 621
Croplus 2.21

Function for calculating error aspect ratio, with function crop. Function Aspect_error can be invoked separately.

Download here.

Examples:

Code:
Croplus(4,0,-2,0) # It will show info about source and aspect errors

Subtitle(String(Aspect_Error(4,0,-2,0))) #Show Aspect error resizing for source dimensions.

Subtitle(String(Aspect_Error(4,0,-2,0, 640,480))) #Show Aspect error resizing for certain dimensions. In this case, height= 640, width=480.
Attached Files
File Type: 7z Croplus.2.21.7z (2.8 KB, 14 views)
__________________
Intel i7-6700K + Noctua NH-D15 + Z170A XPower G. Titanium + Kingston HyperX Savage DDR4 2x8GB + Nvidia GTX750 2GB DDR5 + SSD Vertex 4 256 GB + Antec EDG750 80 Plus Gold Mod + Corsair 780T Graphite

Last edited by Overdrive80; 16th January 2013 at 16:12.
Overdrive80 is offline   Reply With Quote
Old 21st May 2012, 16:35   #2  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 5,681
From Docs

Code:
The Subtitle filter adds anti-aliased text to a range of frames. 
If you want more than one subtitle,you have to chain several Subtitle filters together.
If you like, I could quickly knock up a filter that prints out text using a standard Info.h font (not the anti aliased font
of SubTitle), as used in plugin metrics. It would only take a single string arg and optional x,y coords (pixel or character) and the string
could hold layout formatting, eg.

Code:
s = "Hello World, " + String(1.0,"%.3f") + "\nNext line Down\t Tabbed right"

PluginName(s,x=0,y=0,pixel=true)
You interested, maybe a couple of hours to knock it up?

EDIT: and apply to a range of frames.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 21st May 2012 at 17:16.
StainlessS is offline   Reply With Quote
Old 21st May 2012, 16:45   #3  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 5,681
Just spotted this in docs:

Code:
Multi-line text using "\n" is added in v2.57 and it is used if the lsp (line spacing) parameter is set.
It sets the additional line space between two lines in 0.125 pixel units.
This works:

Code:
Subtitle("This is a test\nand so is this",lsp=0) # lsp must be undefined (by default), any value switches it on
EDIT: You could create a string, appending additional messages to the string with a "\n" separator and then
only use subtitle once.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 21st May 2012 at 17:30.
StainlessS is offline   Reply With Quote
Old 21st May 2012, 17:14   #4  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,380
Quote:
Originally Posted by Overdrive80 View Post
However with subtitle function I cant write in differents lines because if I use various instances of subtitle function, only shows the last instance. How I could insert returns???
As StainlessS says, you can get multi-line subtitles using \n with the lsp option.
But multiple instances will also add new subtitles if you use a different alignment (or position (x, y)) for each one.
The reason your code only shows the second one is you have
Code:
...
i.subtitle("Your config is "+Source+" "+Region+" on format "+Ana+".")
...
	i.crop(l_crop, u_crop, r_crop, b_crop).subtitle("The aspect error is: "+string(calc, "%1.16f")+" %",align=9)
where you apply the second subtitle to a different clip instead of to the result of the first, which is thus thrown away.

Note also your function only works if you call it with negative values of r_crop and b_crop - perhaps it should also support positive values (meaning width and height as in Crop() itself).

Quote:
Originally Posted by StainlessS View Post
Code:
Subtitle("This is a test\nand so is this",lsp=0) # lsp must be undefined, any value switches it on
Of course you mean defined.
__________________
GScript and GRunT - complex Avisynth scripting made easier
Gavino is offline   Reply With Quote
Old 21st May 2012, 17:25   #5  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 5,681
Quote:
Of course you mean defined.
Actually no, any value for lsp switches it on, even -1, so I assumed that it was undefined by default.
If wrong, then how exactly does it not work until any value is assigned to lsp?

EDIT: I meant undefined, by default. Dont bother answering, have clarified in orig post.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 21st May 2012 at 17:30.
StainlessS is offline   Reply With Quote
Old 21st May 2012, 18:03   #6  |  Link
Overdrive80
Anime addict
 
Overdrive80's Avatar
 
Join Date: Feb 2009
Location: Spain
Posts: 621
Thanks to both.

Enviado desde mi XT910 usando Tapatalk
__________________
Intel i7-6700K + Noctua NH-D15 + Z170A XPower G. Titanium + Kingston HyperX Savage DDR4 2x8GB + Nvidia GTX750 2GB DDR5 + SSD Vertex 4 256 GB + Antec EDG750 80 Plus Gold Mod + Corsair 780T Graphite
Overdrive80 is offline   Reply With Quote
Old 23rd May 2012, 19:33   #7  |  Link
Overdrive80
Anime addict
 
Overdrive80's Avatar
 
Join Date: Feb 2009
Location: Spain
Posts: 621
Hi, For I can implement suggestions of resizes I want check If following data is correct:

According ITU-R BT.601:

Code:
- DVD NTSC 4:3:

SAR= 720x480
DAR= (720x480)x(4320/4739) = 1.367377...
PAR= 4320/4739

- DVD NTSC 16:9:

SAR= 720x480
DAR= (720x480)x(4320/4739)x(4/3) = 1.823169...
PAR= 4320/4739x(4/3)= 5760/4739

- DVD PAL 4:3:

SAR= 720x576
DAR= (720x576)x(128/117) = 1.367521...
PAR= 128/117

- DVD PAL 16:9:

SAR= 720x576
DAR= (720x576)x(128/117)x(4/3) = 1.823361...
PAR= (128/117)x(4/3)= 512/351

Is it true???

EDIT: I dont understand PAR numbers of Adobe Premiere . Is it right??
__________________
Intel i7-6700K + Noctua NH-D15 + Z170A XPower G. Titanium + Kingston HyperX Savage DDR4 2x8GB + Nvidia GTX750 2GB DDR5 + SSD Vertex 4 256 GB + Antec EDG750 80 Plus Gold Mod + Corsair 780T Graphite

Last edited by Overdrive80; 23rd May 2012 at 19:47.
Overdrive80 is offline   Reply With Quote
Old 24th May 2012, 00:11   #8  |  Link
gyth
Registered User
 
Join Date: Sep 2011
Posts: 86
Quote:
Originally Posted by Overdrive80 View Post
According ITU-R BT.601:
http://www.itu.int/rec/R-REC-BT.601/en

It is a spec for broadcast television, not DVDs.
I'm not sure where your 4320/4739 is coming from.

DVDs don't all follow a single spec.
Some have data for the full 720 width, some only fill the middle 704.
Most give you noisy ill-defined edges more reflective of their analog origins than any digital standard.

In your picture, the 0.9091 is a 10/11 'PAR', which I've heard is correct for NTSC 4:3 DVDs if they only fill 704 out of the 720 width.
Use 8/9 if there is picture data for the full 720.
gyth is offline   Reply With Quote
Old 24th May 2012, 00:36   #9  |  Link
Brother John
(schein)heilig
 
Brother John's Avatar
 
Join Date: Jun 2003
Location: Germany
Posts: 511
Quote:
Originally Posted by Overdrive80
According ITU-R BT.601:
Is it true???
Yes, it is. See here: http://forum.doom9.org/showthread.ph...27#post1058927
There’s even a third possibility to split hairs with the ITU values, but the only meaningful distinction is Generic or ITU-ish. You might even be able to deduce this automatically with autocrop. Assume ITU-ish when the image has at least 8-10 pixels wide black bars left and right, Generic otherwise. For ITU I’d settle for the MPEG-4 values for simplicity’s sake.

Quote:
I dont understand PAR numbers of Adobe Premiere
Yep, those are weird. They use “real” ITU for PAL and MPEG-4 for NTSC. Doesn’t really make sense, but all those variants are too close to each other to make a real difference anyway.
__________________
Brother John

When lost in BeSweet's options, have a look at the Commandline Reference.
DVD nach MPEG-4 klappt nicht? Verzweifelt? Auf zum Encodingwissen!

Last edited by Brother John; 24th May 2012 at 00:38.
Brother John is offline   Reply With Quote
Old 24th May 2012, 10:25   #10  |  Link
Overdrive80
Anime addict
 
Overdrive80's Avatar
 
Join Date: Feb 2009
Location: Spain
Posts: 621
Quote:
Originally Posted by gyth View Post
http://www.itu.int/rec/R-REC-BT.601/en

It is a spec for broadcast television, not DVDs.
I'm not sure where your 4320/4739 is coming from.
I extract info from here

Quote:
In your picture, the 0.9091 is a 10/11 'PAR', which I've heard is correct for NTSC 4:3 DVDs if they only fill 704 out of the 720 width.
Its not is the same the in broadcast??

@Brother John Above, would it be ITU-ish???

Thanks
__________________
Intel i7-6700K + Noctua NH-D15 + Z170A XPower G. Titanium + Kingston HyperX Savage DDR4 2x8GB + Nvidia GTX750 2GB DDR5 + SSD Vertex 4 256 GB + Antec EDG750 80 Plus Gold Mod + Corsair 780T Graphite
Overdrive80 is offline   Reply With Quote
Old 24th May 2012, 11:01   #11  |  Link
TheSkiller
Registered User
 
Join Date: Dec 2007
Location: Germany
Posts: 637
Quote:
Originally Posted by Overdrive80 View Post
Its not is the same the in broadcast??
It's supposed to be the same. But with DVDs there is a greater chance than in broadcast to come across a non-ITU (generic) mastered video (imo).


The numbers you used are the exact values derived from the ITU-R BT.601 - so yes they are fine and "ITU-ish".


Don't get confused with those very exact PARs and the so called MPEG4 ones such as 12/11, 10/11, 16/11 and 40/33. The difference is no more than 2 Pixel. Like Brother John said, for all practical applications it does not matter which of the ITU ones you use, it's more a question of ITU or non-ITU (generic) where the difference is big enough to worry about (at least for me).

The MPEG4 ones are compatible with 16x16 block sizes, i.e. an image of 704 pixel width exactly represents the shape of a 4:3 or 16:9 image.

Last edited by TheSkiller; 24th May 2012 at 11:05.
TheSkiller is offline   Reply With Quote
Old 24th May 2012, 11:04   #12  |  Link
Brother John
(schein)heilig
 
Brother John's Avatar
 
Join Date: Jun 2003
Location: Germany
Posts: 511
Yes, absolutely ITU-ish.

If you love overkill, you could show four different aspect error variants calculated with the respective PAR:
* generic,
* MPEG-4,
* digital ITU (the values from Jukka Ahoís site),
* analog ITU (taking into account that the first and last analog lines are only half lines = half height).
Oh, and a fifth one for NTSC, calculated with a width of 711 pixels instead of 710.85. And if thatís still not enough, letís discuss what ďgeneric PARĒ actually means.
__________________
Brother John

When lost in BeSweet's options, have a look at the Commandline Reference.
DVD nach MPEG-4 klappt nicht? Verzweifelt? Auf zum Encodingwissen!
Brother John is offline   Reply With Quote
Old 24th May 2012, 15:45   #13  |  Link
Overdrive80
Anime addict
 
Overdrive80's Avatar
 
Join Date: Feb 2009
Location: Spain
Posts: 621
Ok, i understand. Thanks to both for you great explanations. I hope to implement it properly.
__________________
Intel i7-6700K + Noctua NH-D15 + Z170A XPower G. Titanium + Kingston HyperX Savage DDR4 2x8GB + Nvidia GTX750 2GB DDR5 + SSD Vertex 4 256 GB + Antec EDG750 80 Plus Gold Mod + Corsair 780T Graphite
Overdrive80 is offline   Reply With Quote
Old 25th May 2012, 12:18   #14  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: Yorkshire, UK
Posts: 1,673
Quote:
Originally Posted by Overdrive80 View Post
I extract info from here
Don't. It's wrong. He converts the half lines into full lines, and you can't do that. That's why he has such strange numbers that no one else has.

If you want perfection, PAL 4x3 is PAR=1150/1053, and more than good enough PAL 4x3 is PAR=12/11. Generic PAL 4x3 PAR is 16/15.

Similarly, perfect NTSC 4x3 PAR is too stupid to use, more than good enough NTSC 4x3 PAR = 10/11, generic NTSC 4x3 PAR = 8/9.

You can calculate the corresponding 16x9 PARs by multiplying these fractions by 4x3 (e.g. more than good enough PAL 16x9 PAR= 16/11).

from here...
http://forum.doom9.org/showthread.ph...19#post1110419

See also...
http://forum.doom9.org/showthread.ph...05#post1525105

Cheers,
David.
2Bdecided is offline   Reply With Quote
Old 25th May 2012, 16:01   #15  |  Link
TheSkiller
Registered User
 
Join Date: Dec 2007
Location: Germany
Posts: 637
I have to admit those halve scanlines still make my head hurt.
What is stated in that table that you linked to in the "error in the DV faq about aspect ratios?" thread seems plausible to me: PAL has 575 scanlines in total and the width is 702 pixels (52Ķs) which gives us a PAR of 1150/1053. I remember I have heard this number before somewhere but unfortunately there are many PARs that are almost the same but come from different scenarios which is what I want to understand.

On Brother Johns (German) website (link) he states that 1150/1053 is an "analog PAR" which (I think) means it is ambigous for any digital image on a computer because those cannot have halve scanlines. However, I don't understand why 128/117 is then stated to be the proper "digital PAR". 128/117 would suggest a proper digital PAL image is 702x576.
I think 703.22 (rounded to 704) x 576 makes more sense...?

Last edited by TheSkiller; 25th May 2012 at 16:04.
TheSkiller is offline   Reply With Quote
Old 25th May 2012, 17:22   #16  |  Link
Brother John
(schein)heilig
 
Brother John's Avatar
 
Join Date: Jun 2003
Location: Germany
Posts: 511
Quote:
Originally Posted by TheSkiller
I don't understand why 128/117 is then stated to be the proper "digital PAR".
Because after the A/D conversion there are no half lines anymore. They get filled up to full lines so itís only reasonable to calculate with full-height lines. In other words: The image gains a tiny bit of height during A/D conversion. Thatís also the reason why I disagree with
Quote:
Originally Posted by 2Bdecided
He converts the half lines into full lines, and you can't do that.
In the analog domain: absolutely you canít. But once youíre digital things change. You absolutely should do that because you do have full-height full-width lines.

Quote:
I think 703.22 (rounded to 704) x 576 makes more sense...?
Nope. In analog you have a height of 574+Ĺ+Ĺ. In digital you have 574+1+1. The width isnít affected.
__________________
Brother John

When lost in BeSweet's options, have a look at the Commandline Reference.
DVD nach MPEG-4 klappt nicht? Verzweifelt? Auf zum Encodingwissen!
Brother John is offline   Reply With Quote
Old 25th May 2012, 22:29   #17  |  Link
TheSkiller
Registered User
 
Join Date: Dec 2007
Location: Germany
Posts: 637
OK, I think I understand it.
So basically one shouldn't calculate with 575 lines because – and that's what helped me understand – we actually have 576 lines but the top most and bottom most lines simply have (or get) half of their content blanked out and that's why PAL actually has "575 lines worth of picture wrapped in 576 lines" and in digital we don't bother blanking the lines to make them halve (although that's possible, have seen it many times).
Makes sense to me now. So that's why the width stays the same (702) although we have 576 lines.
Thanks Brother John.

Last edited by TheSkiller; 25th May 2012 at 22:34.
TheSkiller is offline   Reply With Quote
Old 27th May 2012, 19:51   #18  |  Link
Overdrive80
Anime addict
 
Overdrive80's Avatar
 
Join Date: Feb 2009
Location: Spain
Posts: 621
Quote:
Originally Posted by 2Bdecided View Post
Don't. It's wrong. He converts the half lines into full lines, and you can't do that. That's why he has such strange numbers that no one else has.

If you want perfection, PAL 4x3 is PAR=1150/1053, and more than good enough PAL 4x3 is PAR=12/11. Generic PAL 4x3 PAR is 16/15.

Similarly, perfect NTSC 4x3 PAR is too stupid to use, more than good enough NTSC 4x3 PAR = 10/11, generic NTSC 4x3 PAR = 8/9.

You can calculate the corresponding 16x9 PARs by multiplying these fractions by 4x3 (e.g. more than good enough PAL 16x9 PAR= 16/11).

from here...
http://forum.doom9.org/showthread.ph...19#post1110419

See also...
http://forum.doom9.org/showthread.ph...05#post1525105

Cheers,
David.
Megui uses this values too, is wrong his use in megui??

EDIT: I updated to version 1.0, renamed function to Croplus. With show= true, will show data material and resize suggestions. I hope that you could test results if they are fine.
__________________
Intel i7-6700K + Noctua NH-D15 + Z170A XPower G. Titanium + Kingston HyperX Savage DDR4 2x8GB + Nvidia GTX750 2GB DDR5 + SSD Vertex 4 256 GB + Antec EDG750 80 Plus Gold Mod + Corsair 780T Graphite
Overdrive80 is offline   Reply With Quote
Old 27th May 2012, 20:17   #19  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 5,681
So as not to hijack your thread, previous scipt snippet moved here (DGIndex Batcher):
http://forum.doom9.org/showthread.ph...93#post1576193
Please feel free to us any part of it.

EDITED
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 28th May 2012 at 12:41.
StainlessS is offline   Reply With Quote
Old 28th May 2012, 12:14   #20  |  Link
2Bdecided
Registered User
 
Join Date: Dec 2002
Location: Yorkshire, UK
Posts: 1,673
Quote:
Originally Posted by Brother John View Post
Because after the A/D conversion there are no half lines anymore. They get filled up to full lines so it’s only reasonable to calculate with full-height lines. In other words: The image gains a tiny bit of height during A/D conversion. That’s also the reason why I disagree with
Quote:
Originally Posted by 2Bdecided
2Bdecided
He converts the half lines into full lines, and you can't do that.
In the analog domain: absolutely you can’t. But once you’re digital things change. You absolutely should do that because you do have full-height full-width lines.
First things first. We're talking about differences of less than one pixel. The difference isn't visible without a reference, and is barely visible even with one. Human eyes just aren't that accurate. No one who created this stuff ever cared if the video was this accurate either. In short: this doesn't matter.


However, if we must pick it apart to the sub-pixel level...

This digital video we work with was born in 1982. It is a digitisation of the pre-existing analogue standards. It inherits its parameters from the already very well defined analogue standards.

Therefore the PAL 4x3 PAR is 1150/1053. There is no argument. There is no debate. That is the correct value. It comes from 52us (702 pixels @ 13.5MHz) by 575 lines - the active 4x3 area. The tolerances on these values are huge. Everyone at the time assumed 5% or more overscan would hide the edges anyway. But the "ideal" values are clear.

Digitising 576 lines doesn't add any height, because the two extra half lines just capture some extra black, not active picture. Just like capturing 720 pixels horizontally just digitises some extra black, not active picture. Classic 720x576 sampling still has a PAR of exactly 1150/1053 (matching the 702x575 active picture area). Sampling more black pixels does not make the active picture area any larger. Sampling more black pixels does not change the PAR. Think about that for a second - it's pretty fundamental.

If you're thinking "the half lines are half in terms of length - how does that reduce the picture height at all?" you should see the pictures here... http://www.pembers.freeserve.co.uk/W....html#Vertical ...because that's the world these standards were created to describe.


But now, we work in an all digital world. All the archive PAL content we process will have a PAR of 1150/1053 - there is no use pretending otherwise. However, when creating new digital SD content, it may be convenient to adopt a slightly different PAR. It might even be acceptable when re-purposing archive content. It's not as if half-height half-length lines have any meaning on modern digital displays!

Here are your options:

active 702x575 implies PAR=1150/1053 = no error
active 702x576 implies PAR=128/117 = 0.174% error
active 704x576 implies PAR=12/11 = 0.111% error

It's the last option that gives you the smallest PAR error, the simplest PAR, and lets you light up all the pixels in the MOD16 MPEG acceptable 704x576 resolution.

It's also common sense: if you're going to add height (jumping to 576), you've got to add a little width too - otherwise it's obvious that you're going to change the shape.


Note: while filling the extra half lines is nice on a PC display, it's irrelevant on any real SD output, because the first half of line 23 will almost always contain Wide Screen Switching data (WSS - all European DVD players will add it), so even in underscan mode you'll almost never see real picture data in that top half-line on a TV.

Cheers,
David.

P.S. I did mention that none of this matters, didn't I?

It's just that, given that 704x576 and 704x480 give the closest PARs to the original standards, are both MOD16 MPEG valid resolutions, and yet give really simple PARs, it seems strange to want to add one pixel black borders and use weird PARs to get a more "correct" result when a) the result is further away from the correct PAR, and b) the difference is almost invisible. It's like "damn this simple solution - I want things to be complicated".

Last edited by 2Bdecided; 28th May 2012 at 12:22.
2Bdecided 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 04:27.


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