Support forum for DG Tools

Very good points and very good questions. Thank you. All is possible and everything is on the table.

Hello lovers of all that is rational and correct. Stuck in the handcuffs of Zoom. Randomness is beautiful and arbitrary window size is The Beauty. Throw off the handcuffs! And so confused specifying crop into script via dgindexnv but not resize who pointed that out? Guest 2. A fine collection of pixels he is for one to contemplate. But who are we to speculate?

Whee!

Is synthesis the antithesis of Randomness? You could think about it. Here we have the definitive analysis. cudasynth must be absorbed into the mainline. We all die but try to postpone it. Now watch me.

Not to mention that mainline is avs+ nowadays, as 2.6 being dead for many years.

I think by "mainline" Bullwinkle didn't mean Avisynth but meant the official DGDecodeNV (i.e., not have a separate CUDASynth package). Your point is well taken and further integration into Avisynth+ itself remains under study.

Absorbing Cudasynth into the DGTools mainline would be awesome.
With the template feature creating the scripts, using multiple filters would be quicker.
Might just need an updated avscompat (for vpy) to get closer to perfection, hint, hint

avscompat is it possible to be more brain dead (vs not you gonca)? when pride bursts its britches. Be nice.

I might be a little brain dead/damaged myself
A few good drinks do that

gonca wrote: ↑

Tue Aug 27, 2019 5:02 pm

Seeing as how the option fulldepth= is now gone, would it be possible to have an option to deliver P016 all the time.
Use case
8 bit video is encoded at higher bit rates (10) to avoid banding in final result.
It actually saves only one line in script "ConvertBits(16)" but it would be nice to have, specially since your filters need either 16 or 8 bit inputs.

For 10 bit encode
8 bit input
ConvertBits(16)
Use your filters to preprocess
ConvertBits(10)
Encode

Plus

DGTelecide and DGDecimate working with 16 bit depth would help with the 10 bit encode chain
Just asking, I know that you are busy on DGDemux

By the way, you'll want to ditch the last ConvertBits. Both x264 and x265 will happily accept 16-bit input and convert down to the final bitdepth (x265 has the parameter --dither to enable HQ dithering). If I'm not mistaken, they both work internally in 16 bits anyway.

Yeah, I know
The ConvertBits or vpy equivalent is a simple truncation of the padding zeroes since final output is 10 bit

gonca wrote: ↑

Sat Nov 02, 2019 11:06 am

DGTelecide and DGDecimate working with 16 bit depth would help with the 10 bit encode chain

Have you ever seen a high-bit-depth video that is 3:2 telecined?

No, but if I want an 8 bit file preprocessed and encoded in 10 bit (DVD and some BD, imported) right now the preprocessing must be done in 8 bit and then converted to 10 bit for encoding

gonca wrote: ↑

Sat Nov 02, 2019 11:45 am

No, but if I want an 8 bit file preprocessed and encoded in 10 bit (DVD and some BD, imported) right now the preprocessing must be done in 8 bit and then converted to 10 bit for encoding

And that's a problem because...?

Would be nice to have the high bit depth from the start, that is all

I don't see a use case since DGSource still have to copy back decoded video into RAM, so doing that by extra call in the script might be even faster.

I sometimes have to go back to older rips to extract aduio tracks without reencoding the video. For this particular case I would love a way to demux audio/subs from a video file without having to save the project, would that be possible? I assume it would be much faster to demux the tracks without indexing the video, but maybe there is a another tool I could use for this purpose.

No, that wouldn't gain anything. I have to parse through the files the same way and the overhead of just writing some text to the index file is relatively insignificant.

Hello!
I did not find the answer in the documentation (maybe I was looking badly) - can DGIndexNV make an index file for each downloaded file, and not one common index file (.dgi) for all files in the list (i.e. make multiple *.DGIs)? I want to individually recode each file using AviSint, but I don’t understand how this can be done with DGIndexNV.
I've more than 400 *.ts files and make index files for each tooo long)))
I would be grateful for the answer.

DmitryKz wrote: ↑

Fri Jan 10, 2020 3:37 am

Hello!
I did not find the answer in the documentation (maybe I was looking badly) - can DGIndexNV make an index file for each downloaded file, and not one common index file (.dgi) for all files in the list (i.e. make multiple *.DGIs)? I want to individually recode each file using AviSint, but I don’t understand how this can be done with DGIndexNV.
I've more than 400 *.ts files and make index files for each tooo long)))
I would be grateful for the answer.

You can use the command line client for that.
Open a command prompt, change to the directory where the files to index are and execute a commandline "for %f in (*.ts) do "path\to\your\dgindex.exe" -i "%f" -o "%~nf.dgi" -e -h"

It will create an index file for each .ts file.

Dear Boulder, many many thanks. This is exactly what I need.

Thank you for helping out, Boulder.

Just thinking out about my last indexing:

- add number of progressive, TFF, BFF at the end of dgi, beside FILM;
- scan images while indexing, giving some better parameter approximation for DGHDRtoSDR and other HDR functions (sliding window range?). At this point it could be incorporated into DGSource as it would be reading same DGI, having parameters for different ranges of video.

Your second suggestion is like an earlier one that asked to allow timeline navigation while the Crop dialog is active. I experimented with it but ran into technical difficulties that I did not have the time nor motivation to solve at the time. I keep it as an active request but it's a bit low on the priority list.

Same for your request for additional statistics, low priority I'm afraid. I'm not a spring chicken anymore and I zealously guard the time remaining on my progress bar of life.