## Feature Requests

Support forum for DGDecNV
Boulder
Moose Approved
Posts: 54
Joined: Fri Jul 29, 2011 7:22 am

### Re: Feature Requests

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.
gonca
Curly Approved/Moose Approved
Posts: 952
Joined: Sun Apr 08, 2012 6:12 pm

### Re: Feature Requests

Yeah, I know
The ConvertBits or vpy equivalent is a simple truncation of the padding zeroes since final output is 10 bit
Rocky
Moose Approved
Posts: 1162
Joined: Fri Sep 06, 2019 12:57 pm

### Re: Feature Requests

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?
gonca
Curly Approved/Moose Approved
Posts: 952
Joined: Sun Apr 08, 2012 6:12 pm

### Re: Feature Requests

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
Rocky
Moose Approved
Posts: 1162
Joined: Fri Sep 06, 2019 12:57 pm

### Re: Feature Requests

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...?
gonca
Curly Approved/Moose Approved
Posts: 952
Joined: Sun Apr 08, 2012 6:12 pm

### Re: Feature Requests

Would be nice to have the high bit depth from the start, that is all
DJATOM
Moose Approved
Posts: 72
Joined: Fri Oct 16, 2015 6:14 pm

### Re: Feature Requests

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.
RTX 2070 | Ryzen R9 3900X (no OC) | 64 GB RAM
Xunkar
Moose Approved
Posts: 36
Joined: Sun Aug 18, 2019 5:17 am

### Re: Feature Requests

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.
Rocky
Moose Approved
Posts: 1162
Joined: Fri Sep 06, 2019 12:57 pm

### Re: Feature Requests

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.
DmitryKz
Posts: 10
Joined: Tue Nov 05, 2013 12:52 pm

### Re: Feature Requests

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.
Boulder
Moose Approved
Posts: 54
Joined: Fri Jul 29, 2011 7:22 am

### Re: Feature Requests

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.
DmitryKz
Posts: 10
Joined: Tue Nov 05, 2013 12:52 pm

### Re: Feature Requests

Dear Boulder, many many thanks. This is exactly what I need.
Rocky
Moose Approved
Posts: 1162
Joined: Fri Sep 06, 2019 12:57 pm

### Re: Feature Requests

Thank you for helping out, Boulder.
tormento
Moose Approved
Posts: 342
Joined: Mon Sep 20, 2010 2:18 pm

### Re: Feature Requests

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.
Rocky
Moose Approved
Posts: 1162
Joined: Fri Sep 06, 2019 12:57 pm

### Re: Feature Requests

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.

tormento
Moose Approved
Posts: 342
Joined: Mon Sep 20, 2010 2:18 pm

### Re: Feature Requests

Rocky wrote:
Sun Mar 29, 2020 8:10 am
Your second suggestion is like an earlier one that asked to allow timeline navigation while the Crop dialog is active.
Sorry, I was not clear enough. My idea was, while indexing to dgi, mark the brightest and lowest of video (on range or frame base) and then feed HDR to SDR conversion with that results to have better parameters, dinamically.
Rocky wrote:
Sun Mar 29, 2020 8:10 am
Given average male life expectation of 80, are you 67?
Rocky
Moose Approved
Posts: 1162
Joined: Fri Sep 06, 2019 12:57 pm

### Re: Feature Requests

67.314... as you can see at the bottom left.

Sure, I understand your request. Again, it's a reasonable thing to ask for, but it's low priority.
Boulder
Moose Approved
Posts: 54
Joined: Fri Jul 29, 2011 7:22 am

### Re: Feature Requests

Your (sad) progress bar made me realise that I've already "known" you for 18 years Where did the years go? Well, they took the colour of my beard with them but I look good in grey or white anyway.

To celebrate these years, I have a simple feature request:
Would it be possible to have the HDR-specific colorimetry and mastering information written in the template in x265 style with a macro? I don't know if you already determine the chroma location but that would be useful too. All these would then be easy to drop in the x265 commandline.
Rocky
Moose Approved
Posts: 1162
Joined: Fri Sep 06, 2019 12:57 pm

### Re: Feature Requests

Time flies when you're having fun! Thank you for your enduring friendship.

I can do what you ask. Just give me the exact specifications as I am not familiar with x265 HDR syntax, etc.
Boulder
Moose Approved
Posts: 54
Joined: Fri Jul 29, 2011 7:22 am

### Re: Feature Requests

Rocky wrote:
Fri Apr 03, 2020 4:32 pm
Time flies when you're having fun! Thank you for your enduring friendship.

I can do what you ask. Just give me the exact specifications as I am not familiar with x265 HDR syntax, etc.
Thank you as well

Let's see..

COLORIMETRY 9 16 9 is transcoded directly as --colorprim 9 --transfer 16 --colormatrix 9.
There are the tables and respective values here: https://x265.readthedocs.io/en/default/ ... -colorprim but I think that they are the same what you already use.

MASTERING 13250 34500 7500 3000 34000 16000 15635 16450 40000000 50
would be
--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)"

If the CLL info is there, for example LIGHT 552 190, it would be --max-cll "552,190" in x265. If the info is not there, it can be left out.

Chroma location is something I'm not sure of. If MediaInfo shows 4:2:0 (Type 2) for Chroma subsampling, you should use --chromaloc 2. All the UHD sources I've seen, had this set like that. Non-UHDs don't seem to have it so it can be left out.
Rocky
Moose Approved
Posts: 1162
Joined: Fri Sep 06, 2019 12:57 pm

### Re: Feature Requests

Great. Thanks Boulder! May be a while but we'll get it done.
Rocky
Moose Approved
Posts: 1162
Joined: Fri Sep 06, 2019 12:57 pm

### Re: Feature Requests

Boulder wrote:
Fri Apr 03, 2020 1:30 pm
All these would then be easy to drop in the x265 commandline.
I don't understand that. How would that work, i.e., how would script contents get into a command line? You want to put it just as a comment and then you could cut and paste from that? If so, it may be easier to put another line in the DGI with the existing HDR lines.
Boulder
Moose Approved
Posts: 54
Joined: Fri Jul 29, 2011 7:22 am

### Re: Feature Requests

Rocky wrote:
Sun Apr 12, 2020 6:50 am
Boulder wrote:
Fri Apr 03, 2020 1:30 pm
All these would then be easy to drop in the x265 commandline.
I don't understand that. How would that work, i.e., how would script contents get into a command line? You want to put it just as a comment and then you could cut and paste from that?
Exactly that. It's so much easier and error proof to copy-paste a string of text to my basic commandline skeleton than opening the dgi file (or using MediaInfo) and copying values from there one by one.
Rocky
Moose Approved
Posts: 1162
Joined: Fri Sep 06, 2019 12:57 pm

### Re: Feature Requests

OK, how about adding a formatted command line to the DGI file right there with the existing HDR lines? You could copy and paste from that and it would be easier to implement. Or I could just replace the existing lines with the formatted version.
kebulek
Moose Approved
Posts: 13
Joined: Thu Oct 14, 2010 10:16 am

### Re: Feature Requests

DGIndexNV.exe -version
DGIndexNV 2053.0.0.206 (64 bit) built on Apr 10 2020