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. |
20th October 2022, 19:33 | #1581 | Link | |
Registered User
Join Date: Aug 2016
Posts: 609
|
Quote:
On a perfect source it's kind of tolerable but if I get a dodgy source with chroma alignment issue like TV channel 44 (you may have noticed it in the clip that chroma is shifted to the right) then it results in 2 generations of chroma mishandling and that is too much to tolerate. edit: animated png Last edited by flossy_cake; 20th October 2022 at 19:45. |
|
20th October 2022, 19:52 | #1582 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
Mode 1 = Exactly like mode 0, except instead of decimating the M most similar frames, frames are decimated from the longest remaining strings of duplicates. The defaults are fine because for normal 3:2 pulldown, for every eight fields that go in, ten come out, or referring to frames instead of fields, for every four that go in five come out, so ideally you only want to reverse that. If you give TDecimate more wiggle room, for example Cycle=50 and CycleR=10, it'll still remove the same number of frames over-all, but not necessarily the same frames. I assume, in theory at least, TDecimate could decide to keep the first 40 frames in the group and remove the last ten as duplicates. Adjusting dupThresh would change the number of frames considered to be legit duplicates, and therefore the number of legit duplicates in succession for any given cycle. For very large cycles it's possible to effect the A/V sync if the duplicates aren't distributed/decimated evenly throughout. Therefore you could look at the beginning of each cycle as also being a reset for the A/V sync. |
|
20th October 2022, 21:42 | #1583 | Link | ||
Registered User
Join Date: Aug 2016
Posts: 609
|
Quote:
Quote:
Code:
ConditionalFilter(last, bwdif(field=-2), TFM().TDecimate(), "IsCombedTIVTC", "=", "true") |
||
21st October 2022, 12:38 | #1584 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
If it'll de-interlace RGB, maybe convert to RGB before anything else. Or if you're using filters that don't work with RGB, you could try full chroma YUV instead. For HD ConvertToRGB32(interlaced=true, matrix="Rec709") or ConvertToYV24(interlaced=true) There's a ChromaShift plugin, but for YV12 it's 2 pixel increments, or 4 if it's interlaced, or if you're really keen and know the exact shift you can use a resizer to compensate. To shift the chroma of a 1080p video 7.3 pixels to the left (it'd be -7.3 to shift it right). A = last MergeChroma(A, A.Spline36Resize(1920,1080, 7.3,0,1920,1080)) Quote:
I'd have to experiment myself to see if I could get the de-interlacing to work as you've described with ConditionalFilter. I don't use conditional filtering much. It'd probably also slow things down even more. Last edited by hello_hello; 21st October 2022 at 12:45. |
||
22nd October 2022, 08:02 | #1585 | Link | ||
Registered User
Join Date: Aug 2016
Posts: 609
|
Quote:
1. TV channel error 2. DXVA deint error 3. My Samsung TV downsampling to 4:2:2 internally But you can see 1 vs 2 on that animated png and it still looks bad on a 4:4:4 monitor. Quote:
I've tried to achieve a better result with TDeint(mode=1, full=false, tryWeave=true, slow=1) but after testing with some more clips eg. The IT Crowd DVD, its combing detection just isn't good enough either. Basically the intro sequence to the show is 2:2 then the show proper is all 1:1. The intro gets weaved nicely, but the show proper has issues on scenes where actors are sitting very still and the only thing moving is their mouth. In this case their mouth movement gets combed cause it's not above the combing detection threshold. There are myriad settings to play with: cthresh, blockx, blocky, MI etc. but despite playing with these for hours I could not achieve a good balance where the intro would get weaved and no mouth combing. The best I could get was with cthresh=3 and those other parameters left alone. I guess I will try with just TFM() which should weave the intro sequence but I don't know how it's going to handle those problematic 1:1 scenes. In the end I suspect I will have to use an override file to handle the intro sequence separately. It's kind of cool that we can even do such a thing, but at the same time I feel like we're annoyingly close to having a "set it and forget it" option. edit: Actually now that I think about it, I don't think it needs to be called from Avisynth. I will give your suggestion a try -- thanks. Last edited by flossy_cake; 22nd October 2022 at 08:29. |
||
22nd October 2022, 12:32 | #1586 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
I thought you were opening scripts in MPC-HC and using MadVR to de-interlace or something like that. Maybe I misunderstood. I almost never watch interlaced video as I always de-interlace with QTGMC and re-encode, so I haven't had much experience with "player" de-interlacing issues.
Try Metric=1 for TDeint (and TFM). It often does better on small amounts of fine combing than the default metric. Failing that, try following TDeint with VInverse. http://avisynth.nl/index.php/Vinverse |
22nd October 2022, 14:49 | #1587 | Link | |
Registered User
Join Date: Aug 2016
Posts: 609
|
Quote:
I tried metric=1 and saw a slight improvement allowing me to increase cthresh by 1 to achieve the same result. Ultimately still visible artefacting though and I'd still prefer bwdif which doesn't have the issue at all, but of course bwdif doesn't weave 2:2 moving sections. Tried VInverse() which does seem to work but it's only half framerate so I can still see actor's mouths moving at 25fps compared to the rest of their face animating at 50fps. I guess human vision is very critical when it comes to facial recognition -- if something is even slightly off it will be noticed. VInverse also seems to soften the image slightly? bwdif is slightly softer than TDeint as well though so I shouldn't complain. I guess that tight weave threshold of TDeint is contributing to its slightly sharper output. I'm applying avs scripts by simply opening them with MPC-HC so they get applied in realtime. This realtime functionality is essential to me as I want to avoid transcoding and have the flexibility of making per-season or even sometimes per-episode adjustments. Another issue I'm dealing with is the Avisynth source filter isn't passing interlaced flags which breaks DXVA deint which for some reason requires them in order to work. There is something unique about the interlacing in this particular show The IT Crowd. Even DXVA struggles with it and sometimes weaves pixels when it shouldn't be, leaving 1 pixel wide combing artefacts in certain patterns. Which is weird because DXVA deint looks quite clean on that 576i SDI Public Senat clip in the other thread. |
|
22nd October 2022, 15:34 | #1588 | Link | |
Registered User
Join Date: Aug 2016
Posts: 609
|
Quote:
edit: aaaand it looks like there are all kinds of audio sync issues , so it seems I need to pass it through LAV to avoid that. edit2: using a different audio renderer seems to solve that. Last edited by flossy_cake; 22nd October 2022 at 15:55. |
|
22nd October 2022, 17:50 | #1589 | Link | |
Registered User
Join Date: Aug 2016
Posts: 609
|
Quote:
I couldn't get any improvement with converting to 444/RGB -- whatever NVidia is doing to the chroma is some kind of permanent damaging processing regardless of what pixel format I send it. However with MergeChroma I am able to get a "better" result, but chroma is still blurred around edges, even though it is aligned. I think NVidia's DXVA implementation might be downsampling the chroma internally as part of its deint process. Last edited by flossy_cake; 22nd October 2022 at 17:53. |
|
23rd October 2022, 00:07 | #1590 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,061
|
In typical endusers motion pictures distribution formats chroma is downsampled so can not have naturally same sharpness as luma. With conversions to RGB and any 4:4:4 chroma is upsampled by some process (filter/interpolator) that can give different sharpness. Current digital subsampled formats have build-in bugs and they are not still removed and also industry do not have any standards on YUV<->RGB spatial conversions. So every hardware/software developer uses its own ideas how it can be. Also there is 2 different processings in converting subsampled->full sampled: intermediate and final (display/monitor). Intermediate is designed to keep sharpness in many sub<-> full conversions (production chain) and final is for viewing (end-user consumption). So only final conversion to display RGB have anti-gibbs conditioning filter that looks like some blurring of chroma. Intermediate production converters do not have anti-gibbs filtering so looks sharper (but can/must produce chroma/RGB ringing in some processings like scaling - so it is up to upscaler designer to keep track what is feed to its input).
Typical production workflow (1 iteration): YUV 4:2:0 storage/delivering -> 4:4:4 RGB -> RGB adjust/blend/tuning/mix/artistic -> YUV 4:2:0 storage/delivering. Do not change digital sample count of luma (format). It uses intermediate unfiltered chroma processing to keep chroma sharpness in many iterations. Typical end user consumption process: YUV 4:2:0 distribution -> 4:4:4 RGB for display -> display scaling (or DAC for analog that is equal to infitine samples upscale) -> optical image for viewing. It should use final (end of chain) anti-gibbs filtered chroma upscale in 4:2:0->4:4:4 conversion. NVIDIA for home (video playback) and DXVA are endusers processing for typical motion pictures consumption so typically should be designed with not as sharp (unfiltered) prof conversions for intermediate processing. AVS currently do not separate intermediate/final chroma upscale so may look sharper in compare with DVXA/NVIDIA upscale for displaying. Last edited by DTL; 23rd October 2022 at 00:21. |
23rd October 2022, 10:30 | #1591 | Link |
Registered User
Join Date: Aug 2016
Posts: 609
|
The problem with DXVA chroma handling is that it also shifts the chroma position down and to the right by 0.5 pixels according to my tests with a 4:2:0 chroma pattern.
Also if I feed DXVA deint a true 4:4:4 test pattern and/or 4:4:4 pixel format, it STILL downsamples it to 4:2:0. Disabling DXVA deint passes full chroma. Here is my best guess at what might be happening with DXVA deint for a 4:2:0 source: LAV decoder outputs 4:2:0 -> MadVR upscales to 4:4:4 -> DXVA deint downscales to 4:2:0 & shift chroma location 0.5 -> final output is upscale to 4:4:4 again. I am not sure who is doing the final output upscale to 4:4:4, it might be DXVA or it might be some other part of the GPU driver matching it to whatever chroma is set in NVCP. In any case the extra redundant step of downscaling to 4:2:0 and back up to 4:4:4 seems to be imbuing the chroma with a bit of softness, plus the 0.5 shift makes the end result noticeably poor. Then on top of this the TV network has its own chroma shift issue, plus my TV is downsampling to 4:2:2 internally and the end result is starting to look a bit shabby. Take those last 2 steps out and I might not be able to tell anything is wrong in a double blind test on typical content. But on a test pattern I would for sure. I'm not really a stickler for chroma -- I see people in the MadVR thread fussing over various chroma upscaling algorithms, spending a lot of GPU cycles to do NGU chroma upscaling. But honestly I can't see much difference on anything but test patterns or sources that have chroma problems baked into the source. As long as the alignment is right, I'm satisfied with the typical filters like Bicubic, Lanczos, Spline etc. The sharper algorithms tend to do worse on sources with chroma issues baked into the source. Last edited by flossy_cake; 23rd October 2022 at 10:33. |
23rd October 2022, 11:21 | #1592 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,061
|
DXVA2 support chroma placement signalling - https://learn.microsoft.com/en-us/wi...omasubsampling .
Code:
typedef enum _DXVA2_VideoChromaSubSampling { DXVA2_VideoChromaSubsamplingMask = 0xf, DXVA2_VideoChromaSubsampling_Unknown = 0, DXVA2_VideoChromaSubsampling_ProgressiveChroma = 0x8, DXVA2_VideoChromaSubsampling_Horizontally_Cosited = 0x4, DXVA2_VideoChromaSubsampling_Vertically_Cosited = 0x2, DXVA2_VideoChromaSubsampling_Vertically_AlignedChromaPlanes = 0x1, DXVA2_VideoChromaSubsampling_MPEG2, DXVA2_VideoChromaSubsampling_MPEG1, DXVA2_VideoChromaSubsampling_DV_PAL, DXVA2_VideoChromaSubsampling_Cosited } DXVA2_VideoChromaSubSampling; So your workflow need detect (or other ways found) correct chroma placement in your source of 4:2:0 subsampled and pass this data to the DXVA. So it is expected the DXVA processing result will be more correct. If not - you may also report issues to Microsoft support and may be NVIDIA support if you use DXVA and NVIDIA hardware - may be somewhere this chroma placement processing is broken in some Microsoft or NVIDIA layer (DirectX or NVIDIA driver or hardware). If you use DXVA via MadVR may be you need to consult its developer or try manual set DXVA chroma placement flags to see if your execution layers of DXVA (DirectX + NVIDIA driver + NVIDIA hardware) correctly process it. May be we need additional accept/detect/pass and manual override of chroma placement signalling to DXVA in MadVR if it still not have this interface and functions. Same as with interlacing in the old days. Last edited by DTL; 23rd October 2022 at 12:09. |
23rd October 2022, 13:03 | #1593 | Link |
Registered User
Join Date: Aug 2016
Posts: 609
|
You could be right, however I have tested on GTX 1070 vs R9 380 and the latter has no chroma shift with DXVA deint. So it looks to be an NVidia driver issue perhaps not honouring or misinterpreting the meaning of the chroma positioning value. But I need to update my driver to see if Nvidia fixed it.
|
23rd October 2022, 14:45 | #1594 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Quote:
__________________
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; 23rd October 2022 at 14:49. |
|
23rd October 2022, 16:14 | #1595 | Link | |
Registered User
Join Date: Jul 2018
Posts: 1,061
|
Quote:
Do you get confirmation that calling software (madVR ?) really sends required chroma placement signalling to DXVA ? In both madVR and LAV decoder controls I do not see any settings for chroma placement signalling (auto/passthrow/manual or others). Last edited by DTL; 23rd October 2022 at 16:22. |
|
23rd October 2022, 17:25 | #1596 | Link | |||
Registered User
Join Date: Aug 2016
Posts: 609
|
Quote:
Quote:
Although maybe it is LAV Video Decoder (ffmpeg) which is providing the incorrect chroma placement and MadVR is just passing that incorrect info on? But in that case AMD shouldn't get it right either. Quote:
i.e BWDIF(field=-2) vs TDeint(mode=1, mtnmode=1, slow=2) But, TDeint produces some junk interpolated pixels around the edges of raster so I have to zoom in 2px to make sure there is no underscan. But really the texture detail preservation on TDeint is a lot better on static shots -- the slightest bit of video noise or camera movement triggers BWDIF into interpolation so in practice I am very rarely actually achieving true 576p resolution with BWDIF. TDeint does seem to use about double the amount of CPU though, but fmpeg says 170fps for 720x576i @ 15% CPU usage so that is plenty of headroom still. |
|||
23rd October 2022, 18:26 | #1597 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,061
|
Correct metadata signalling from demuxer-decoder-renderer is expected only in prof level developed environment like microsoft windows and its multimedia extensions like DirectX or other. So may be try to play your content by DirectShow if possible and check the correct chroma decoding and RGB dematrix.
Example: Take standard prof authored DVD interlaced and try to playback using DirectShow. The microsoft MPEG2 decoder should provide correct chroma placement flags to renderer. May be your content do not have metadata encoded into and decoder can not provide anything for unknown source. Only the author of content may be know what is the correct chroma placement and need to found way how to to put this to content or pass to decoding and playback environment by other ways. So in good playback devices for pixel-peepers the manual control for chroma placement is expected to support playback from unknown sources with better result. Last edited by DTL; 23rd October 2022 at 18:43. |
23rd October 2022, 20:15 | #1598 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Quote:
Advanced:- https://www.nvidia.com/Download/Find.aspx?lang=en-uk# Advanced can also select "Windows Driver Type", ie Standard / DCH. Just a bit better selection control [Advanced can also select Beta]. Advanced Driver Search, is NVidia's [not mine] description on that page. EDIT: There are also more choices under Product Type, eg NVS, Data Center/Tesla, GRID, Perhaps additional diffs. EDIT: + More OS selections, I'm not gonna look for more, you look if you like
__________________
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; 23rd October 2022 at 20:29. |
|
24th October 2022, 14:28 | #1599 | Link | ||
Registered User
Join Date: Aug 2016
Posts: 609
|
Quote:
BWDIF does actually have an edeint param but it does something else: Quote:
I'm sure there's got to be some way to "diff" it with the original clip. I'm asking because although I subjectively prefer the sharper look of TDeint, it does have a tendency to corrupt fine details, eg. text becomes a bit distorted. Only noticeable on test patterns though, but I'm still curious to see whether BWDIF is really so sensitive to motion that it will interpolating almost the whole time and only weaving under rare perfectly still conditions i.e test patterns or static computer generated overlays. |
||
24th October 2022, 15:06 | #1600 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,374
|
Quote:
subtract, or overlay with difference mode . You can use levels to amplify the differences eg. Code:
. . . a = last b = a.bwdif(some settings) Subtract(a,b) #Levels(127, 1, 129, 0, 255) # for 8bit #Levels(511, 1, 513, 0, 1023) # for 10bit If the distortions in text, fine patterns from tdeint (or bwdif) are due to the interpolation algorithm, you can specify a different deinterlacer or interpolation algorithm with edeint (for tdeint, or bwdif) . QTGMC is a commonly used one, or NNEDI3 if you want faster |
|
Tags |
tdeint, tivtc |
Thread Tools | Search this Thread |
Display Modes | |
|
|