Page 15 of 29

Re: Feature Requests

Posted: Sat Nov 02, 2019 11:23 am
by Boulder
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.

Re: Feature Requests

Posted: Sat Nov 02, 2019 11:39 am
by Guest
Yeah, I know
The ConvertBits or vpy equivalent is a simple truncation of the padding zeroes since final output is 10 bit

Re: Feature Requests

Posted: Sat Nov 02, 2019 11:40 am
by Rocky
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?

Re: Feature Requests

Posted: Sat Nov 02, 2019 11:45 am
by Guest
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

Re: Feature Requests

Posted: Sat Nov 02, 2019 12:12 pm
by Rocky
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...?

Re: Feature Requests

Posted: Sat Nov 02, 2019 2:19 pm
by Guest
Would be nice to have the high bit depth from the start, that is all

Re: Feature Requests

Posted: Sat Nov 02, 2019 4:25 pm
by DJATOM
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.

Re: Feature Requests

Posted: Fri Dec 13, 2019 5:28 am
by Xunkar
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.

Re: Feature Requests

Posted: Fri Dec 13, 2019 7:08 am
by Rocky
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.

Re: Feature Requests

Posted: Fri Jan 10, 2020 3:37 am
by DmitryKz
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.

Re: Feature Requests

Posted: Fri Jan 10, 2020 4:53 am
by Boulder
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.

Re: Feature Requests

Posted: Fri Jan 10, 2020 5:49 am
by DmitryKz
Dear Boulder, many many thanks. This is exactly what I need.

Re: Feature Requests

Posted: Fri Jan 10, 2020 7:16 am
by Rocky
Thank you for helping out, Boulder.

Re: Feature Requests

Posted: Sun Mar 29, 2020 4:18 am
by Guest 2
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.

Re: Feature Requests

Posted: Sun Mar 29, 2020 8:10 am
by Rocky
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.

Image

Re: Feature Requests

Posted: Sun Mar 29, 2020 8:28 am
by Guest 2
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
Image
Given average male life expectation of 80, are you 67? :lol:

Re: Feature Requests

Posted: Sun Mar 29, 2020 8:33 am
by Rocky
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.

Re: Feature Requests

Posted: Fri Apr 03, 2020 1:30 pm
by Boulder
Your (sad) progress bar made me realise that I've already "known" you for 18 years :salute: 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.

Re: Feature Requests

Posted: Fri Apr 03, 2020 4:32 pm
by Rocky
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.

Re: Feature Requests

Posted: Sat Apr 04, 2020 7:44 am
by Boulder
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.

Re: Feature Requests

Posted: Sat Apr 04, 2020 10:19 am
by Rocky
Great. Thanks Boulder! May be a while but we'll get it done.

Re: Feature Requests

Posted: Sun Apr 12, 2020 6:50 am
by Rocky
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.

Re: Feature Requests

Posted: Sun Apr 12, 2020 6:57 am
by Boulder
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.

Re: Feature Requests

Posted: Sun Apr 12, 2020 7:00 am
by Rocky
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.

Re: Feature Requests

Posted: Sun Apr 12, 2020 7:11 am
by kebulek
Can you please add command line flag -V or -version?

Code: Select all

DGIndexNV.exe -version
->
DGIndexNV 2053.0.0.206 (64 bit) built on Apr 10 2020
That would be great, thank you! :salute: