Feature Requests

[admin]

Is there a way to automatically note the version? Or could it be saved with either the .dgi file or the .log file?

I'll add it to the DGI file for the next release. Thanks for the suggestion.

[Guest 2]

More than a program feature request, this is a changelog feature request.

Please, please, please tell us when DGI version changes. Sometimes I upgrade versions and have to recreate DGI.

[admin]

I missed the notification of DGI file version NV12 for build 2034. I have added it to the change log in build 2036.

[laserfan]

Is there a way to automatically note the version? Or could it be saved with either the .dgi file or the .log file?

I'll add it to the DGI file for the next release. Thanks for the suggestion.

Thanks for indulging me--I oughta point-out that I haven't had any problems with "beta" versions of DGDecNV (requiring fallback to an earlier rev) since way before the tools' consolidation to DGDecNV! Seems like a very long time ago. But like I said, I'm anal (and a natural worrier) and if I do find any problems with encodings I make I like to keep all the records of what I'd done; "lessee my encoding was made July 10 so I musta used dgdecnv2019 which I'd downloaded on the 6th". Thanks again.

[Karyudo]

Sometimes I upgrade versions and have to recreate DGI.

Maybe it's not quite kosher, but instead of re-indexing, I often (OK, always) [REDACTED].

Seems to work fine...

[admin]

That will always cause *something* to not operate correctly, because I do not change the level when nothing is affected. Whether you notice the thing that is no longer correct depends on the particular change. For example, you may not notice that hints are wrong if you do not use them.

That is really bad advice you are giving and will cause support nightmares for me if generally adopted.

[Karyudo]

Best way to get good advice on the Internet? State loudly and unequivocally your own wrong way of doing it...

I was hoping you'd mention what the risks are -- increased support nightmares is one I'm very sorry I didn't think of. Doing what I suggested worked for the streams I have, but it's clear this is not what one is supposed to do, of course.

(If it's any consolation, if it didn't work I'd immediately re-index, rather than ask for support.)

[admin]

It's OK, I'm going to add a CRC check to the DGI file to thwart you.

[Karyudo]

For a given "non-broken" video stream, will there usually be a material difference between the index files produced by two different versions of DGIndexNV? I would assume not, but I don't *know*.

One of the reasons I avoid re-indexing is because I fear (perhaps irrationally) that any tricky Avisynth editing I've worked out will be borked in some very subtle way by the new version, and I'll have to spend time finding and fixing it. I guess I'm sort of a "better the devil you know..."-type person.

Would there be any way to "freshen" old DGI files with an updated version, faster than re-indexing from scratch? I'm guessing not, but one can always hope...

[admin]

The product is mature enough that at this point the likliehood of a reindexing with a higher version changing the delivered frame locations, trims, etc., is close to zero, and if it did, I would mention it prominently in the change log.

[Karyudo]

One might argue, then, that making a quick fix to the DGI (soon to be thwarted by a CRC check...) should also not introduce errors in delivered frame locations, trims, etc., between versions, and thus should perhaps be unofficially allowed (but not "supported") for those who know what to tweak where??

I'm thinking in particular of my most recent project, where I came across the MKV with compressed headers, and you created a new version to parse such streams. In the interim, I'd remuxed with uncompressed headers and indexed the result, and was editing from that DGI. When the new version came out, I installed it to be current -- but I now had a perfectly-good DGI from the previous version (made just the day before!) that ostensibly I couldn't use. One tiny fix later, and I was fine without having to reindex. But a CRC check would have added some level of annoyance...

I don't suppose you could check the CRC, and pop up a warning along the lines of:

Code: Select all

CRC Check Fail: This DGI was made with a previous version of DGIndexNV, and may not work correctly with the current version. It is recommended that the project be re-indexed with the current version. Proceeding without reindexing is done at the user's risk, and problems arising from ignoring this CRC check will not be supported.

Ignore CRC Check | Cancel and Re-index

But if we have to re-index, we have to re-index. I'm not the one that has to support/fix problems that users may bring upon themselves by not using your product the way it was meant to be used. I really can't get too bent out of shape by a very slight annoyance in an otherwise brilliant and bulletproof piece of software, and you'll hear no further whining/suggesting from me on this topic!

[admin]

One might argue, then, that ...

No, you can't argue that. I told you already that a file format up rev is guaranteed to mean that something will be wrong if you do not re-index to make a properly formatted DGI file that is compatible with the new software.

I'm thinking in particular of my most recent project, where I came across the MKV with compressed headers, and you created a new version to parse such streams. In the interim, I'd remuxed with uncompressed headers and indexed the result, and was editing from that DGI. When the new version came out, I installed it to be current -- but I now had a perfectly-good DGI from the previous version (made just the day before!) that ostensibly I couldn't use.

Who says you couldn't use it? The DGI file version did not go up from 2035 to 2036, and 2036 would not reject it.

One tiny fix later, and I was fine without having to reindex.

There was nothing to fix. Please tell us what your "tiny fix" was. Ha ha, busted!

And BTW, the CRC thing was a joke. There are some valid reasons to edit a DGI file, such as overriding the frame rate (although that can be done in your script too).

Can you imagine how messed up things would be if we didn't have a file format version number, which was designed to save you grief?

Now if you proposed that I add functionality to automatically generate a corrected new format DGI from existing ones, which is something I have thought about, then you might have a case. But that would be pretty low on my priority list, given that only one person has ever found this to be an irritant. It also would not always be possible to create a correct new file without re-scanning the source file(s).

[laserfan]

I don't get why anyone would bother to mess with old dgi files given how wicked-fast the indexing process has become?

[Karyudo]

I've found that indexing some MPEG-2 files is pretty slow, but I'd agree that indexing h264 stuff is quick.

admin, now that I think about it, it's quite likely I started the day with a version older than 2035, indexed a couple of files, then found that it wouldn't index an MKV with compressed headers, upgraded to 2035, and found that 2035 also wouldn't index MKVs with compressed headers. Then when 2036 was introduced and I tried to use a DGI I'd indexed just a day or two earlier, it didn't work. But clearly I'm still in the wrong, because I should have stayed up to date and used 2035 in the first place!

My new rule (eerily similar to your long-standing rule): If old DGI does not work with current version, re-index. No ifs, ands, or buts!

[kypec]

I don't get why anyone would bother to mess with old dgi files given how wicked-fast the indexing process has become?

I've found that indexing some MPEG-2 files is pretty slow, but I'd agree that indexing h264 stuff is quick.

I'm not sure what am I doing wrong but indexing MKV files (untouched stream ripped directly off bluray disc with MakeMKV, VC-1 or H.264) using DGIndex revision 2035 takes more than 40 minutes
for standard 2-hour movie.
MKV is located on external HDD (connected over eSATA), .dgi index is being written on local HDD.
My system: i7-920, 6GB RAM, Windows 7 x64, GeForce 8400GS 512MB
Any ideas?

[admin]

When I did the performance changes I did not do it for the MKV parser code. That still needs to be done. I'll move it up on the priority list.

That code from the MKV guys needs quite a bit of work to run fast.

[kypec]

When I did the performance changes I did not do it for the MKV parser code. That still needs to be done. I'll move it up on the priority list.
That code from the MKV guys needs quite a bit of work to run fast.

Thanks for clarification and even more thanks for moving it higher on your priority list!
What speed improvement (very rough estimation) do you think we can expect of that redone MKV parser?

[admin]

It should become comparable to TS parsing.

[mastrboy]

Feature Request:
- Move crop out of .dgi file to avisynth function parameter
- A simple batch processor/gui-helper, those for loops in cmd is a pain..
I'll try to elaborate a little of what im thinking:
I usually encode anime tv-series which i rip with dvd-decryptor sorted into episode folders, each folder contains the vob file for the episode. Usually i write a cmd file that loops through the folders and use DGIndexNV command-line switches on each vob file to index them and save the .dgi in each directory, i would love to see a simple menu item than just loops through supported files and indexes them while saving the .dgi file with the same filename as source file in the same directory that vob (or other supported) file resides, while being recursive.

(Sorry that my last request caused problems, "cropping in increments of 2x" )

[yesgrey]

Any luck of a DGDecNV DirectShow filter ever come to life?

It would be really great to have AVC and VC-1, both progressive and interlaced, decoded by the GPU...
I know there are already free DXVA filters, but I think they don't work with interlaced sources, and can't be used with madVR...

[admin]

It's an interesting idea.

Regarding the existing filters you mentioned, why don't they work with MadVR?

[yesgrey]

Regarding the existing filters you mentioned, why don't they work with MadVR?

They use DXVA, and only VMR9 (XP) and EVR(Vista/7) support it. The only filter that works is CoreAVC with its CUDA support, but it only supports H.264 progressive, I think it doesn't support interlaced, and no VC-1 and MPEG2 neither.
Furthermore, I'm having some hiccups when using it with madVR. I don't know if it's any problem by having two applications using the GPU at the same time (madVR and COreAVC), or if it might be any problem with CoreAVC's implementation. I've thought that you might be able to make it work flawlessly...

[admin]

Some more questions...

Are you thinking of this primarily for playback purposes, rather than filtering, transcoding, etc? The answer determines how frame accurate it has to be.

Are you wanting an ES decoder with an input pin for compressed video and an output pin for decompressed video? I.e., a decoder filter you could use with existing splitters. Or are you thinking of a full source filter that includes a splitter.

Any further specifications you may be thinking of would also be useful to know. Thank you.

[ZooStation]

+1 for a directshow filter! Having the possibility to repatriate the decoded stream from the gpu to the cpu à la CoreAVC 'cuda' would allow the ffdshow raw filter to jump in. This is currently impossible for 1080p24 VC1 on my 5-year-old Athlon X2. The fastest software decoder is still too slow on this computer forcing me using DXVA for playback and thus, sadly staying away from madVR + postprocessing.
I certainly don't mean to stand in for yesgrey answering questions about madVR, but the thing is madshi's renderer only accepts YV12 for input as to version 0.34. When or even if there will be NV12 support isn't sure yet. I thought it would be worth reminding this detail, since I understand it might make things trickier for hardware deinterlacing. Please correct me if I'm wrong.
Personaly, I would use such a filter solely for playback purposes. Frame accuracy is not a concern as long as seeking in the video remains comfortable. And finally splitter-wise, I think those already available are fine enough.

[yesgrey]

Are you thinking of this primarily for playback purposes?

Yes. For all the other stuff we already have the current DGDecNV, so I think there is no need for accurate frame serving...

Are you wanting an ES decoder with an input pin for compressed video and an output pin for decompressed video? I.e., a decoder filter you could use with existing splitters. Or are you thinking of a full source filter that includes a splitter.

Yes, only a decoder filter to use with existing splitters, unless you feel it would be preferable and easier to create s full source filter, but in that case you would also need to handle other kind of streams, like FLAC and DTS-HD, ect and feed them to their decoders...

Any further specifications you may be thinking of would also be useful to know. Thank you.

Ok. I will think about it and let you know...

Thanks for considering this.