Support forum for DG Tools

If i understand properly.
You have an m2ts file, you demux audio and video and have, for exemple, an .264 video file, and .ac3 audio file.
You want then to work with the .264 video file instead, and not the .m2ts file anymore.
Am i correct ?
If i am, correct, one possibility, but i don't know if it's easy or not to implement, is to have an option to create a second index file if the video is demuxed.
file is xxxx.mt2s, it creates xxxx.dgi and xxxx_264.dgi.
Maybe it possible to create the DGI informations for the both stream, as while they are demuxed, both are avaible in the memory, so maybe indexing informations can be created for/from the both streams, the one read and the one writen. But, i don't know if this can be done easely or not.

If i'm not correct and didn't properly understood the need, forget what i've said.

If I do understand index structure properly, it writes position (in bytes) to IDR frame and then explains how much data it can decode (in frames) and describes a type/etc. So in case of .264 ES we just need to correct those positions after demuxing step (and fix file extension). Other parts of index file should be the same.

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.

I thought of separate counting for demuxed .264 ES IDR sequences and increasing IDR stamps on it, as diff shows: https://www.diffchecker.com/GYLT5LUh. Or just doing second instance of indexing before writing demuxed video stream onto disk (we should have an option for it in that case).

I have thought of many things. People call me a Thinker.

Sure. No is no, I'll just trust you

If I may put things in perspective
I tested with UHD HDR mpls
If I do an initial index/demux and then delete the index file it only takes about 3 minutes to index the HEVC elementary stream.
All things being equal, this is easy and quick enough

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.

Was just saying that the time savings is really minor in the grand scheme of things
All is good
Quick off topic
What does Rocky and Bullwinkle think of this
https://www.google.com/search?client=fi ... supremacy

All of "quantum information" and its applications is nonsense:

http://www.sciphysicsforums.com/spfbb1/ ... ?f=6&t=407

The informed one Me is here to show non-nonsense (NSFW trigger):

https://www.youtube.com/watch?v=FHSmevQCFoo

Snort. If that is too risque try this:

https://scottlocklin.wordpress.com/2019 ... -bullshit/

DGDemux/DGDemuxNV would be perfect