Support forum for DG Tools

Question
When I choose Demux Video, is there a way I can have this stream indexed instead of the original file without doing the indexing twice?

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.

Use case
Rip disc to folder (save on HDD for archive purposes)
Would demux video, audio and subtitles to local ssd
If demuxed video is indexed then I can shut down external drive and work from internal drive, so archive drive stays safe.

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

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.

I can always just demux and index, then delete the index file and then index the demuxed video
Thanks for looking at it

Sounds good, gonca. If you have any ideas to accomplish this automatically, without becoming too specialized for any given use case, please let us know.

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

gonca wrote: ↑

Thu Oct 24, 2019 12:27 pm

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 files). You could place your input stream on one disk and then save project to a different disk to get some speedup. I don't see what I can do in DGIndexNV to help you with your use case.

You could place your input stream on one disk and then save project to a different disk

That is what I do now
Thanks for looking into it

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