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. |
6th October 2022, 19:53 | #41 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,937
|
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 |
27th October 2022, 07:57 | #42 | Link | |
Registered User
Join Date: Aug 2016
Posts: 787
|
Quote:
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. |
|
28th October 2022, 10:06 | #44 | Link |
Registered User
Join Date: Aug 2016
Posts: 787
|
Hybrid bwdif & nnedi3
Code:
BWDIF(field=-2, edeint=nnedi3(field=-2)) 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. |
31st October 2022, 03:31 | #45 | Link |
Registered User
Join Date: Aug 2016
Posts: 787
|
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) 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. |
31st October 2022, 04:27 | #46 | Link |
Registered User
Join Date: Aug 2016
Posts: 787
|
Huh, this works:
Code:
p1 = BilinearResize(f1, 720, 576) p2 = BilinearResize(f2, 720, 576, 0.0, -0.5, 720, 288) Interleave(p1, p2) 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) 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. |
31st October 2022, 04:42 | #47 | Link |
Registered User
Join Date: Aug 2016
Posts: 787
|
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) |
31st October 2022, 06:57 | #48 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,937
|
Quote:
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. |
|
31st October 2022, 09:49 | #49 | Link | |
Registered User
Join Date: Aug 2016
Posts: 787
|
Quote:
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 |
|
31st October 2022, 10:01 | #50 | Link | |
Registered User
Join Date: Aug 2016
Posts: 787
|
Quote:
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. |
|
31st October 2022, 22:03 | #52 | Link | |
Registered User
Join Date: Aug 2016
Posts: 787
|
Quote:
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. |
|
1st November 2022, 00:21 | #53 | Link | |
Registered User
Join Date: Aug 2016
Posts: 787
|
Quote:
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. |
|
6th November 2022, 07:56 | #55 | Link | |
Registered User
Join Date: Aug 2016
Posts: 787
|
Quote:
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. |
|
6th November 2022, 21:27 | #56 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,544
|
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
|
9th November 2022, 04:23 | #58 | Link | |
Registered User
Join Date: Jan 2015
Posts: 1,093
|
Quote:
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. |
|
9th November 2022, 08:44 | #59 | Link | |
Registered User
Join Date: Aug 2016
Posts: 787
|
Quote:
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. |
|
10th November 2022, 02:03 | #60 | Link | ||
Registered User
Join Date: Jan 2015
Posts: 1,093
|
Because it's the mathematically correct amount.
Quote:
Quote:
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. |
||
Thread Tools | Search this Thread |
Display Modes | |
|
|