Feature Requests
Feature Requests
240 -> 110? That's easy. Even Sherman could do it. He'd use a dropping resistor and burn down the house.
Feature Requests
Today GitHub alerted me that NVenc from rigaya added 3D denoise filter.
I never noticed that NVenc had some functions for video manipolation and, as source is already there, it would be easy peasy to implement the various image switches without having to encode the image at all, just the ones with HW acceleration, of course!
Some new functions for DGSource/Filters would be nice.
What do you think?
I never noticed that NVenc had some functions for video manipolation and, as source is already there, it would be easy peasy to implement the various image switches without having to encode the image at all, just the ones with HW acceleration, of course!
Some new functions for DGSource/Filters would be nice.
What do you think?
Feature Requests
In the latest release: https://github.com/rigaya/NVEnc/blob/ma ... ram2value2Bullwinkle wrote: ↑Sun Apr 17, 2022 8:50 amI went to the github but did not see a 3D denoise filter. Can you point me to it?
- Bullwinkle
- Posts: 338
- Joined: Thu Sep 05, 2019 6:37 pm
Feature Requests
Great, thank you. It's MIT licensed so we can re-use code.
Rocky's not feeling well so I am covering for now. Don't worry, he'll be fine.
Rocky's not feeling well so I am covering for now. Don't worry, he'll be fine.
Feature Requests
Please forward my best wishes.
Proper bitdepth output
Would be possible for DGSource to output the exact color bitdepth?
It's easy to correct by hand with ConvertBits, as they are all zeroes, but on automatic processing, such as with some GUIs, the excess bits can lead to more work for plugins and AVSIs.
Thanks.
It's easy to correct by hand with ConvertBits, as they are all zeroes, but on automatic processing, such as with some GUIs, the excess bits can lead to more work for plugins and AVSIs.
Thanks.
- Bullwinkle
- Posts: 338
- Joined: Thu Sep 05, 2019 6:37 pm
Proper bitdepth output
When indexing a HEVC (10 bits) and I feed AVS+ script with DGSource, I get:
Code: Select all
avs+ [INFO]: AviSynth+ 3.7.2 (r3661, 3.7, x86_64)
avs+ [INFO]: 1920x1080 fps 24000/1001 i420p16 frames 0 - 37767 of 37768
Perhaps I am doing something wrong, anyway.
- Bullwinkle
- Posts: 338
- Joined: Thu Sep 05, 2019 6:37 pm
Feature Requests
Now I get you.
Two thangs:
1. NVDec returns all HBD as 16-bit, so that is what we deliver. We could call ConvertBits internally but...
2. It's actually more efficient to process 16 bit data, as no shifting and masking is needed.
You would need to demonstrate/prove that "the excess bits can lead to more work" if you want anything done.
Two thangs:
1. NVDec returns all HBD as 16-bit, so that is what we deliver. We could call ConvertBits internally but...
2. It's actually more efficient to process 16 bit data, as no shifting and masking is needed.
You would need to demonstrate/prove that "the excess bits can lead to more work" if you want anything done.
Feature Requests
Thought I'd update on things that are on my plate. In no particular order:
* VFR support features.
* Episode and chapter demuxing for DGIndexNV.
* Warn container/ES frame rate mismatch with ability to choose which to use. [COMPLETED]
* DG version of BM3D.
* Adopt NVEncC filters as appropriate.
* Avisynth+ frame properties for pulldown. [COMPLETED for DGMPGDec, still to-do is DGDecNV]
* Support A_MS/ACM as produced by MakeMKV (and others).
* Deliver all quant values via Avisynth+ frame properties (allows for better external deblockers).
* HEVC 4:4:4 support.
Please let me know if I have neglected anything.
* VFR support features.
* Episode and chapter demuxing for DGIndexNV.
* Warn container/ES frame rate mismatch with ability to choose which to use. [COMPLETED]
* DG version of BM3D.
* Adopt NVEncC filters as appropriate.
* Avisynth+ frame properties for pulldown. [COMPLETED for DGMPGDec, still to-do is DGDecNV]
* Support A_MS/ACM as produced by MakeMKV (and others).
* Deliver all quant values via Avisynth+ frame properties (allows for better external deblockers).
* HEVC 4:4:4 support.
Please let me know if I have neglected anything.
Feature Requests
OK, 2 first then. Sherman can help me with it, if I can drag him away from the radio stuff. Silly boy, he bought another 48-461. Trying to corner the global market.
Feature Requests
All good things come in threes, don't cha know?
Feature Requests
You wait, he won't stop at three. I caught him shopping for a fourth one! And there's a chassis only unit that could be the fifth. I guess he really enjoys re-capping.
Feature Requests
You can start with 4, actually.
I can (with some magic powder) make MKVMerge do the dirty job for 2, in the mean while.
Au contraire, we (read I) badly need a good and fast BM3D port
Feature Requests
OK, Sherman is on it.
Feature Requests
Do you have any interest in CUDA Waifu2x and other neural networks?
They are really a fascinating topic to think about... something such as a next gen NEEDI3 resizer...
They are really a fascinating topic to think about... something such as a next gen NEEDI3 resizer...
Feature Requests
Possibly, but one thing at a time.
You can help me and Sherman by telling us of the existing BM3D filters and what you see as their shortcomings.
You can help me and Sherman by telling us of the existing BM3D filters and what you see as their shortcomings.
Feature Requests
I implemented a test version for pulldown flags in DGMPGDec as it was only going to take an hour or so.
http://rationalqm.us/misc/DGDecode_test.zip
It adds the following flags as per the proposed syntax:
_FO
_TFF
_RFF
I also added:
_FieldOrder -- the display field order
Probably going to change _FO to _FieldOperation to avoid confusion with field order.
http://rationalqm.us/misc/DGDecode_test.zip
It adds the following flags as per the proposed syntax:
_FO
_TFF
_RFF
I also added:
_FieldOrder -- the display field order
Probably going to change _FO to _FieldOperation to avoid confusion with field order.
Feature Requests
Late reply but I never get notifications, sorry.
About algorithm, you can easily go and find references on Wikipedia: https://en.wikipedia.org/wiki/Block-mat ... _filtering
AFAIK the first CUDA implementation was https://github.com/DawyD/bm3d-gpu
Then came https://github.com/WolframRhodium/VapourSynth-BM3DCUDA and, marginally, some AVS commits on https://github.com/WolframRhodium/Vapou ... indows.yml
Last release is https://github.com/WolframRhodium/Vapou ... -test8.zip
I have asked your porting because AVS+ one is limited (it supports RGB space only) and it's only marginally developed, as a side dish from the VS repo.
AVS thread is https://forum.doom9.org/showthread.php?t=183066&page=7
Feature Requests
Got it. Thank you for the information. What color spaces are important for you?
Feature Requests
I ain't a color space expert.
Internally it can work whatever you want, enough that precision is preserved, but I'd like that it could accept as input and provide as output the standard color spaces that both decoders and encoders can accept, without having to use external conversion. Mostly I work in 8 up to 16 bit depth but I know that someone uses floating point (32 bits) depth too.
Noticeably, I forgot to tell you the major reason of my request of native CUDA porting, i.e. the required CPU part for the temporal engine. That is where I lose most of the performance when using WolframRhodium version.
Feature Requests
OK, thank you.