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 > General > Newbies

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th October 2022, 19:53   #41  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,934
I think MP Pipeline lets you use 32 bit and 64 bit dlls in the same script by running them in different processes.
http://avisynth.nl/index.php/MP_Pipeline
hello_hello is offline   Reply With Quote
Old 27th October 2022, 07:57   #42  |  Link
flossy_cake
Registered User
 
Join Date: Aug 2016
Posts: 786
Quote:
Originally Posted by hello_hello View Post
I'm pretty sure I went with an ITU aspect ratio for the DVD version, and the first thing I noticed when comparing it to the Bluray was the difference in aspect ratio, which looks to be exactly the difference between a generic and ITU aspect ratio for DVDs. Here's a couple of screenshots. Have a look at the clock-face on the left. I'll leave you to decide in which screenshot it looks round, or for that matter, if it's even supposed to be round.

https://i.ibb.co/tJXf43p/DVD-Encode.png
https://i.ibb.co/61qLbTy/Bluray.png

I was looking into this and saw this comment mentioning Fawlty Towers was shot on these EMI 2001 cameras. Their spec sheet can be found here, but it doesn't mention aspect ratio, only that it uses the 625-line CCIR system (page 10). But the CCIR spec says the aspect is 4:3.

So the Blu-ray cover and camera spec are saying 4:3, however active pixel area is about 1.29:1, and this German release of the Bluray mentions 1.29:1 also.

What do you think -- does it look a little wide when stretched to 4:3? On some shots I think it does, but on others it doesn't really. I think the cameras might have some geometry distortion going on stretching it out at the edges, so when actors are in dead center of frame they look skinnier.

Considering the Bluray is a BBC release and BBC made the EMI 2001 camera, you'd think they would know what the aspect should be.
flossy_cake is offline   Reply With Quote
Old 27th October 2022, 19:22   #43  |  Link
flossy_cake
Registered User
 
Join Date: Aug 2016
Posts: 786
Interesting also on page 10 of the CCIR spec it says the display gamma should be 2.8 -- perhaps this explains the more contrasty image of the Blu-ray release.
flossy_cake is offline   Reply With Quote
Old 28th October 2022, 10:06   #44  |  Link
flossy_cake
Registered User
 
Join Date: Aug 2016
Posts: 786
Hybrid bwdif & nnedi3

Code:
BWDIF(field=-2, edeint=nnedi3(field=-2))
The result is interesting, but some interpolated textures are not quite right. For example a pattern of circles becomes more diamond shaped. But lines are much smoother and far less aliased so it's quite nice. And the great news is it's still blazingly fast for realtime use -- 100fps on 1080i.

I still think bwdif is far too quick to interpolate at the slightest bit of camera noise or movement. Perhaps a combination of TDeint & nnedi would do the trick, since TDeint is far better at weaving 1:1.
flossy_cake is offline   Reply With Quote
Old 31st October 2022, 03:31   #45  |  Link
flossy_cake
Registered User
 
Join Date: Aug 2016
Posts: 786
Just for the fun of it I'm trying to manually implement bob deinterlacing with an Avisynth script.

It seems my concept of bob deinterlacing is wrong as I can't reproduce the same quality image as Avisynth's internal Bob() function.

My attempt:

Code:
SeparateFields()  
f1 = SelectEven()   # lines 0,2,4...
f2 = SelectOdd()    # lines 1,3,5...

# I should now have f1=720x288p, f2=720x288p
# but f2's image sits 1px lower, so...

# ...shift f2 1px down 
f2shifted = PointResize(f2, f2.Width, f2.Height, 0.0, -1.0, f2.Width, f2.Height)

# upscale both fields to 720x576p.  Bob() says it uses BicubicResize too.
p1 = BicubicResize(f1, 720, 576)
p2 = BicubicResize(f2shifted, 720, 576)

# display them one after another
Interleave(p1, p2)
Test clip: https://drive.google.com/file/d/1WfW...usp=share_link

I have tried other shift values like 0.5 and 0.25 without getting close to Bob() image quality.

The wiki says that we can use Bob(0.0, 0.1) to preserve original field lines, but even at default values it is still far better image quality than my attempt.


Last edited by flossy_cake; 31st October 2022 at 03:36.
flossy_cake is offline   Reply With Quote
Old 31st October 2022, 04:27   #46  |  Link
flossy_cake
Registered User
 
Join Date: Aug 2016
Posts: 786
Huh, this works:

Code:
p1 = BilinearResize(f1, 720, 576)
p2 = BilinearResize(f2, 720, 576, 0.0, -0.5, 720, 288)
Interleave(p1, p2)
But this doesn't work:

Code:
f2shifted = BilinearResize(f2, 720, 288, 0.0, -0.5, 720, 288)
p1 = BilinearResize(f1, 720, 576)
p2 = BilinearResize(f2shifted, 720, 576)
Interleave(p1, p2)
I thought they would be logically equivalent?

edit: it appears the resize functions first perform the resize, then does the cropping/shifting. That would explain it if true. Somehow the value -0.5 applies to the unresized image dimensions, even though it is performed after the resize. So it is really like doing a -1.0 shift after resize.

edit2: can confirm the result is the same with:

Code:
p1 = BilinearResize(f1, 720, 576)
p2 = BilinearResize(f2, 720, 576)
p2 = BilinearResize(p2, 720, 576, 0.0, -1.0, 720, 576)
Interleave(p1, p2)

Last edited by flossy_cake; 31st October 2022 at 05:58.
flossy_cake is offline   Reply With Quote
Old 31st October 2022, 04:42   #47  |  Link
flossy_cake
Registered User
 
Join Date: Aug 2016
Posts: 786
Hmm, nearest-neighbour bob looks a lot better than I thought:

Code:
p1 = PointResize(f1, 720, 576)
p2 = PointResize(f2, 720, 576, 0.0, -0.5, 720, 288)
Interleave(p1, p2)
The converging lines pattern in the grey circle @ bottom left of frame is surprisingly resolved (I thought it would just be an aliased mess). It is crucial to display at 50hz though otherwise some bobbed frames will get held on screen longer than others and it ruins the field-combining effect.
flossy_cake is offline   Reply With Quote
Old 31st October 2022, 06:57   #48  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,934
Quote:
Originally Posted by flossy_cake View Post
What do you think -- does it look a little wide when stretched to 4:3? On some shots I think it does, but on others it doesn't really. I think the cameras might have some geometry distortion going on stretching it out at the edges, so when actors are in dead center of frame they look skinnier.

Considering the Bluray is a BBC release and BBC made the EMI 2001 camera, you'd think they would know what the aspect should be.
The ambiguity comes from converting the analogue video to digital.
I'm far from an expert on analogue (or digital for that matter) but whether it was from the ITU spec or industry practice or a bit of both, there's a standard for converting analogue to digital which I think involves the frequency at which a scanline is sampled and how much of it is sampled (there's a lot of non picture stuff each end), and that produces 720 pixels per scanline, and from there the pixel aspect ratio can be calculated (for PAL, analogue 4:3 is technically 702 or 703 pixels rather than 704, but that's often ignored).

Assuming the end result is a DAR of 1.3636, the problem arises when the digitised image is used for DVDs that maybe should be exactly 4:3, but without accounting for the difference in aspect ratio, which seems to be what mostly happens. And it would appear, which is disappointing, that even for the Bluray version the 1.3636 DAR was just assumed to be 4:3.

As far as I know, that should be the only discrepancy (1.3636 v 1.3333). Anything else would be some other DAR fudging in the production process, but there's no way to determine what that might be. If you think neither 1.3636 and 1.3333 are correct you are of course free to assume any DAR you like, but that's personal preference, I guess.

Even though the actual picture is only 1.29, I don't think it necessarily means it should be 4:3. I've seen lots of old analogue stuff with a similar DAR, so maybe the 4:3 "picture area" takes over-scan into account. I don't know.

Ah.... while looking to see if BBC had some sort of standard for over-scan, I found this:
BBC Technical Standards for Network Television Delivery

4.1.5 AspectRatio
Active picture width is 52us/702 pixels. All aspect ratio calculations are based on this. Any processes based on 720 pixel width may introduce unwanted geometry or safe area errors.


I may have posted it before, but there's lots of good info here in PARs: https://lurkertech.com/lg/pixelaspect/
And from a discussion at VideoHelp, some info on the 702 pixel width for PAL and an explanation as to why square pixels aren't always square.
https://forum.videohelp.com/threads/...AL#post2646932

Last edited by hello_hello; 31st October 2022 at 07:09.
hello_hello is offline   Reply With Quote
Old 31st October 2022, 09:49   #49  |  Link
flossy_cake
Registered User
 
Join Date: Aug 2016
Posts: 786
Quote:
Originally Posted by hello_hello View Post
The ambiguity comes from converting the analogue video to digital
I was hoping to avoid all that and just look at what aspect the camera captured and target that. As long as no pixels were cropped in the Bluray mastering process, it shouldn't matter if it was distorted as long as all the pixels are there we can stretch it back to whatever aspect the camera captured.

All of this under the assumption the camera really was adhering to the spec and producing a true 4:3 active picture area, which now that I think about it is probably a very bad assumption
flossy_cake is offline   Reply With Quote
Old 31st October 2022, 10:01   #50  |  Link
flossy_cake
Registered User
 
Join Date: Aug 2016
Posts: 786
Quote:
Originally Posted by hello_hello View Post

As far as I know, that should be the only discrepancy (1.3636 v 1.3333). Anything else would be some other DAR fudging in the production process, but there's no way to determine what that might be. If you think neither 1.3636 and 1.3333 are correct you are of course free to assume any DAR you like, but that's personal preference, I guess.
I'm looking at my DVD of Garth Marenghi's Darkplace which has MPEG header flags saying 1.30:1 & 702x576. MadVR obeys this and scales accordingly to produce 1.30 of active pixel area. It doesn't look distorted to me, but I compared it with the Amazon streaming version and that is 640x480 square pixels 1.33:1 and has the same geometry as DVD within the active pixel area, but the active pixel area is 0.03 wider (showing slightly more visible area of the set off to the sides).

Also DVD Mad About You 720x576 1.33:1 in the MPEG headers but active pixel area is 704x576, plus actor's faces look a little stretched! Figure that one out

Last edited by flossy_cake; 31st October 2022 at 10:11.
flossy_cake is offline   Reply With Quote
Old 31st October 2022, 10:31   #51  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,934
Quote:
Originally Posted by flossy_cake View Post
I'm looking at my DVD of Garth Marenghi's Darkplace which has MPEG header flags saying 1.30:1 & 702x576. MadVR obeys this and scales accordingly to produce 1.30 of active pixel area.
I had no idea DVD video ever contained that sort of info. The consensus here has always been they're just 4:3 or 16:9 without any other info, especially something that specific.
hello_hello is offline   Reply With Quote
Old 31st October 2022, 22:03   #52  |  Link
flossy_cake
Registered User
 
Join Date: Aug 2016
Posts: 786
Quote:
Originally Posted by hello_hello View Post
I had no idea DVD video ever contained that sort of info. The consensus here has always been they're just 4:3 or 16:9 without any other info, especially something that specific.
So I'm ripping my DVD's using MakeMKV. This just remuxes the MPEG2 stream into a mkv file without touching the video or transcoding it in any way. LAV Video decoder then reports info like this:



I am not sure if that metadata is coming from the container (mkv) or the MPEG2 stream itself.

The VIDEOINFOHEADER2 structure seems to be part of the windows api: https://learn.microsoft.com/en-us/pr...deoinfoheader2

So I'm not sure where the data actually originates from. My guess is that MakeMKV is probably creating it during the ripping process and then LAV is perhaps reading it out through the Windows API.
flossy_cake is offline   Reply With Quote
Old 1st November 2022, 00:21   #53  |  Link
flossy_cake
Registered User
 
Join Date: Aug 2016
Posts: 786
Quote:
Originally Posted by flossy_cake View Post
I still think bwdif is far too quick to interpolate at the slightest bit of camera noise or movement. Perhaps a combination of TDeint & nnedi would do the trick, since TDeint is far better at weaving 1:1.
Author of BWDIF has kindly added a threshold param: https://github.com/Asd-g/AviSynth-BWDIF/issues/4

Seems to work well with a value of 3-5: the 1px pattern on Public Senat clip is no longer flickering, and static shots in The IT Crowd are now weaving despite the animating camera noise.

Last edited by flossy_cake; 1st November 2022 at 00:30.
flossy_cake is offline   Reply With Quote
Old 6th November 2022, 04:34   #54  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,934
I've no idea where that extra aspect ratio info would be coming from then, given your screenshot only shows 4:3.

I'll check out the new version of BWDIF.
hello_hello is offline   Reply With Quote
Old 6th November 2022, 07:56   #55  |  Link
flossy_cake
Registered User
 
Join Date: Aug 2016
Posts: 786
Quote:
Originally Posted by hello_hello View Post
I've no idea where that extra aspect ratio info would be coming from then, given your screenshot only shows 4:3.
Yeah that DVD is 4:3. Here's the other one ("Garth Marenghi's Darkplace")




Quote:
Originally Posted by hello_hello View Post
I'll check out the new version of BWDIF.
The author has also just added debug param to highlight interpolated pixels.

It's interesting though cause if we set thr to a high value like 95 it seems like bwdif is using DoubleWeave() behind the scenes, so the fps still "looks" double rate even when it's weaving. Whereas when TDeint weaves I'm only seeing 25fps which kind of makes combing artefacts more visible for double rate content.
flossy_cake is offline   Reply With Quote
Old 6th November 2022, 21:27   #56  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,510
Not sure where the dwPixelAspectRatio is from, but for MPEG2 streams (and DVD-video), there can be additional information in the sequence_display_extension . It specifies the portion of the frame that is scaled to 4:3 or 16:9 . You can parse the sequence_display_extension of an mpeg2 elementary stream in gspot
poisondeathray is offline   Reply With Quote
Old 7th November 2022, 01:50   #57  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,934
Quote:
Originally Posted by flossy_cake View Post
Yeah that DVD is 4:3. Here's the other one ("Garth Marenghi's Darkplace")
Interesting. The consensus has always been DVD video doesn't contain that sort of information. I don't think any encoding GUIs look for it. I'll check any DVDs I encode from now on.
hello_hello is offline   Reply With Quote
Old 9th November 2022, 04:23   #58  |  Link
Katie Boundary
Registered User
 
Katie Boundary's Avatar
 
Join Date: Jan 2015
Posts: 1,092
Quote:
Originally Posted by flossy_cake View Post
Just for the fun of it I'm trying to manually implement bob deinterlacing with an Avisynth script.

It seems my concept of bob deinterlacing is wrong as I can't reproduce the same quality image as Avisynth's internal Bob() function.
I raised this idea a long time ago: https://forum.doom9.org/showthread.php?t=174658

However, nowadays I'd use Lanczos4 rather than Spline64. So, my script would look like:

Code:
mpeg2source("whatever.d2v").converttorgb(interlaced=true).separatefields()

A=selecteven().lanczos4resize(720,480,src_left=0,src_top=0.25,src_width=720,src_height=240)
B=selectodd().lanczos4resize(720,480,src_left=0,src_top=-0.25,src_width=720,src_height=240)

interleave(A,B)
__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers.

Last edited by Katie Boundary; 9th November 2022 at 04:29.
Katie Boundary is offline   Reply With Quote
Old 9th November 2022, 08:44   #59  |  Link
flossy_cake
Registered User
 
Join Date: Aug 2016
Posts: 786
Quote:
Originally Posted by Katie Boundary View Post

However, nowadays I'd use Lanczos4 rather than Spline64. So, my script would look like:

Code:
mpeg2source("whatever.d2v").converttorgb(interlaced=true).separatefields()

A=selecteven().lanczos4resize(720,480,src_left=0,src_top=0.25,src_width=720,src_height=240)
B=selectodd().lanczos4resize(720,480,src_left=0,src_top=-0.25,src_width=720,src_height=240)

interleave(A,B)
Why 0.25? Personal preference?

I'm asking as I'm reasonably confident that 0.5 is the amount of shift required if the goal is to preserve the alignment of the original fields (this may not be your goal). In my tests this was the same as upscaling field 2 to double height and then shifting it down 1.0 lines. edit: oops, didn't notice the first one was positive -- does that make any difference image-quality wise vs 0.5?

On a separate note, I just bought The Office on DVD (2020 version) and wow it's a mess. They've added 1:1 cadence intros to every episode (like commentary extras but mandatory) then the theme song intro is proper 2:2 with full 576p res (top field first, doesn't require any deinterlacing), then the show itself looks like it was shot at 1:1 cadence and then had every second field discarded to make 2:2 cadence with only 288p actual res. Then for season 2 it's the same deal except the show itself contains 2:2 576p res but only when the camera is still -- anything that moves drops to 288p (this is baked into the source, as if the DVD authors had needlessly applied a bwdif-style motion compensated deint at some point in the production chain). edit: clip1, clip2. Debating whether it would benefit from some smooth style interpolating of the 2nd field like nnedi3 -- I figure it's better than the junk BBC put in there... but then it would be discarding resolution for the intro.

edit: and for some reason the bottom field is sharper and higher resolution than the top field, so it works better keeping the bottom and interpolating the top. edit: maybe it's a form that interlace filtering thing to reduce flicker on CRTs.

Last edited by flossy_cake; 10th November 2022 at 01:10.
flossy_cake is offline   Reply With Quote
Old 10th November 2022, 02:03   #60  |  Link
Katie Boundary
Registered User
 
Katie Boundary's Avatar
 
Join Date: Jan 2015
Posts: 1,092
Quote:
Originally Posted by flossy_cake View Post
Why 0.25? Personal preference?
Because it's the mathematically correct amount.

Quote:
Originally Posted by flossy_cake View Post
I'm asking as I'm reasonably confident that 0.5 is the amount of shift required if the goal is to preserve the alignment of the original fields (this may not be your goal). In my tests this was the same as upscaling field 2 to double height and then shifting it down 1.0 lines.
If you shift one field up or down and hold the other field right where it is, that results in moving the entire image up or down, as well as destroying all of the original scanlines. My method keeps the image perfectly still and preserves the original scanline data.

Quote:
Originally Posted by flossy_cake View Post
edit: oops, didn't notice the first one was positive -- does that make any difference image-quality wise vs 0.5?.
It makes a difference in terms of shifting the whole image up or down.

Imagine for a moment that you're doing this:

mpeg2source("whatever.d2v").separatefields().selecteven().lanczosresize(720,576)

Do you think that the resulting image will still be exactly in the same place? Or did you cut a row of pixels off the bottom of the image without cutting a row of pixels off the top, thus shifting the whole image downward by a fraction of a pixel?

Your top fields need to be shifted back up a bit and your bottom fields need to be shifted back down a bit if you want to put everything back in its original place.
__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers.
Katie Boundary 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 07:56.


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