Great report. I'm pretty sure I know what the problem is. Will report back when I have a slipstream for you to test.

OK, but was profile 244 explicitly requested on the command line?

Netflix Meridian. Sneaker converted a sample to 1920x1080 8bit 4:2:0 from the 300GB file for testing https://mega.nz/#F!BlNDGIgJ!7lBUBs61l1oiIIBScrMyYg Do we know what sneaker used to convert to HD and what was the command line? I am trying to determine how profile 244 came about. Also, the file in ...

Thank you!

You are most welcome, Vraelon!

I should make this explanation a part of every slipstream notification post. I will try to remember to do so.

When a slipstream is released, I simply replace dgdecnv2053.zip in the binaries area with the updated one. So all you need to do is re-download dgdecnv2053.zip. The slipstream number can be seen in DGIndexNV's Help/About dialog. It is also in the file properties for both DGIndexNV.exe and DGDecodeNV...

DGIndexNV was not accepting profile_idc = 244 as valid. I have fixed that and everything works fine after that. Fix will be in the next slipstream. Thank you for pointing this out, Sharc . Probably the other apps that fail with this stream also do not handle profile_idc = 244. 244 stands for High 4:...

The demuxing and indexing are run as two separate uncoordinated threads. That is the main reason that I can't do anything for you about this without a major redesign.

Gents, I appreciate your ideas but I know DGIndexNV architecture and design quite intimately, and I do not see any way to get an extra indexing of the demuxed video on the cheap.

Would a option to just demux, no indexing, be of any value? If the functions run concurrently, and I am writing to a SSD, I have a feeling that no time will be saved The actual indexing is a very small part of things. The disk operations are the killer (reading the source file and writing the demux...

gonca wrote: ↑

Thu Oct 24, 2019 4:59 am

Would changing the path from the video file to the demuxed file, in the dgi, work?

No sir, all the offsets in the DGI file are relative to the indexed stream.

I understand your use case but can't see a way to implement what you ask for in a way that would actually save you any time.

That could be difficult to implement but I suppose not impossible. So may I ask you to please describe the use case in some detail? Thank you.

Thank you, Bullwinkle, I'll take care of it in the next slipstream. Thanks for pointing it out.

It seems so.

Thank you renols very much for your testing and pushing for a solution to this matter, and your warm words of praise and encouragement, which motivate me to further action. My solution may not be perfect. Warts as Bullwinkle would say, but sometimes wartiness is the lesser evil. Long live warts. Whee!

renols wrote: ↑

Sat Oct 19, 2019 7:12 pm

If you want I can test with another one I have bought, which also has tons of playlists.

That would be awesome. We want DGDecNV to be the go-to tool for demuxing.

Never mind. Bullwinkle wants to show us something. Will it be the long-lost rarebit, or a visit from beyond?

Gaps processing for THD embedded AC3 demuxing now released in slipstream 190.

@renols

For me all the audio/subtitle streams in Cars 2 are now demuxed with proper sync to the demuxed video. Can we mark this thread resolved?

DGDecNV slipstream 190:

* TS/M2TS file gaps processing is now implemented for TrueHD embedded AC3 streams. For example, the demuxed embedded AC3 stream from Cars 2 is now in sync with the demuxed video. [renols]

* Updated the DGIndexNV user manual.

Doing gaps correction for THD embedded AC3 was much trickier than hoped. 10 days. But it is now working. The Cars 2 embedded AC3 is now demuxed in good sync. I want to do some regression testing and a bit of refactoring, then give y'all a slipstream.

Good to hear! Thank you for the updated status.

Works fine for me. I just open the script in vdub 2 [DGSource() only] and then do File/Information. It shows P016 color space, which is padded 16-bit as intended.

Thank you, investigating...

For 10-bit or 16-bit DGSource() returns 16-bit. 10-bit streams are padded with 0s to 16-bit.

Should work fine. Can you please give us a sample?

What are you using to determine the bit-depth of the output?

You need to upgrade to slipstream 189. 182 is not compatible with the 436.xx drivers.