Integrating thdmerge into DGDemux with an efficient demux approach is another brilliant stroke.
For a different use case, I have a BD that's already been remuxed to mkv for storage, and now I want to remux back to BDMV for playback. The mkv may contain an ac3 stream, but I’ll never use it for playback, so I don’t care to demux and use it.
I just want to efficiently interleave the thd stream while it's being demuxed from mkv together with a 4hr silent ac3 stream read from disk.
Not wanting to bother you with my specific needs, I modified thdmerge to accept the thd stream from stdin, so thdmerge can be placed at the end of a sequence of piped commands, e.g.,
Code: Select all
eac3to file.mkv 2: stdout.thd | thdmerge -ac3 silence.ac3 -o output.thd+ac3 -t
I have it working, and using file hashes have verified the output of my modified version is identical to thdmerge 1.1 output.
But I have a few concerns.
- You generously shared the source, but the LICENSE file with DGDemux doesn't explicitly cover thdmerge, so I'm not sure what you intended as far as modifications and redistribution.
- I'm sure you have opinions on coding style and approach, and I really don't. I just made changes in a way I thought would be best. Aside from looping to accept a stream as it becomes available on stdin, the biggest change is requiring command-line switches for each parameter, so that the thd file can still optionally be passed as an arg and, especially because of the call to _unlink() that could accidentally delete an input file, so that I could make sure I was reliably handling a variable number of command-line args.
- It’s been 15 years since I last coded in C/C++ so I’m not confident in my approach. Even then, I wrote tools for Unix, so I'm no wiz with Win CRT APIs. If you or anyone is inclined to take a look at the changes the source is here and you can view the diff here.