Direct File input for DGDemux

[Sherman]

+1 for direct M2TS input for DGDemux. Probably even Britney could code that.

[Britney]

I know, right?

[Rocky]

OK guys, I've started looking into this. It's mostly a UI challenge.

[Rocky]

OK, we'll have a new option for DGDemux.exe:

-files file1[,file2,file3...]

If file1 is not a full path, then the current directory is used. For file2, file3, etc., the path for file1 is used and you do not give full paths for them. So we could do:

-files d:\tmp\00000.m2ts,00001.m2ts,00002.m2ts

That way you do not have super long command lines for multiple files. Or, if you are in the directory with the files, you can just do:

-files 00000.m2ts,00001.m2ts,00002.m2ts

Obviously, when -files is used DGDemux knows it is in file mode and does not try to open a disk or MPLS. If only -files is given, a stream list is returned. If -o and -demux are given also, then demuxing occurs.

Does this seem reasonable, guys?

[Bullwinkle]

Go for it, Rocky!

[Rocky]

OK, the first phase is working. With this command:

dgdemux -l "d:\tmp\demux.txt" \
-files "g:\rips\AMERICAN_GANGSTER\BDMV\STREAM\00047.m2ts,00007.m2ts,00048.m2ts"

...the demux.txt file contains:

DGDemux 1.0.0.79 by Donald A. Graft
Copyright (C) 2019-2025 Donald A. Graft, All Rights Reserved [Made in Frostbite Falls, Minnesota]

Files:
00047.m2ts
00007.m2ts
00048.m2ts

Streams:
4113: Video
4352: DTS HDMA 7.1 48 1536
4353: DTS 5.1 48 768
4354: DTS 5.1 48 768
4355: AC3 2.0 48 192
4768: PGS subtitles
4769: PGS subtitles
4770: PGS subtitles
4771: PGS subtitles
4772: PGS subtitles
4773: PGS subtitles

Note that the video details will be added later.

Now, I'll move onto the actual demuxing with the -o and -demux options.

[Rocky]

Forgot to mention that for DGDemuxGUI we will have two GUI main screens, one for disks and one for files, with a button on each to toggle the active mode.

[Rocky]

Demuxing is coded and working. Next I have to implement the DolbyVision stuff (merging, etc.) after demux. Then we will have a test version.

[Rocky]

DV stuff is working. The new code is a bit ugly so I'm gonna refactor a bit before giving y'all a test version.

[Rocky]

Hmm, I have M2TS with 192-byte transport hard-wired in several places, but I want this to work with normal 188-byte transport (e.g., TS) as well. So gonna fix that before giving a test release.

[Rocky]

188 and 204 transport are working. Still got a little bug when the first file is not a full path. Then refactor and give y'all a test version.

I don't think Britney could have done this.

[Rocky]

OK guys, here is a test version.

Example:

dgdemux_test -l d:\tmp\dgdemux.txt -files g:\rips\A_NEW_HOPE\BDMV\STREAM\00901.m2ts,00902.m2ts -o d:\tmp\A_NEW_HOPE -demux 4113,4352

As previously described, the first file may contain a full path but subsequent files use the path of the first file.

Your testing and feedback will be appreciated. Also, for demuxing mono LPCM, the channel mask is now set to Center.

https://rationalqm.us/dgdemux/binaries/DGDemux_test.exe

When this is approved by y'all, I'll move on to DGDemuxGUI.

[Rocky]

Hmm, DGDemuxGUI will not be so easy to support both disk and file mode. That's because the application is a dialog-based application, i.e., the structure is like this:

Code: Select all

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
    DialogBox(hInstance,                       // handle to the application
              MAKEINTRESOURCE(IDD_MAINDIALOG), // name of the dialog resource to use
              NULL,                            // handle to the dialog's parent window
              DialogProc);                     // name of the callback function
    return 0;
}

So I see two ways to go without massive redesign:

1. Just have two applications: DGDemuxGUI_Disk.exe and DGDemuxGUI_Files.exe.

2. Have DGDemuxGUI.exe pop up an initial dialog box just asking if you want disk or file mode, then spawn the appropriate dialog.

I'm tending to go with number 1 due to its simplicity. Your opinions on this would be welcome and appreciated.

[Island]

Could you add an additional small button in DGDemuxGUI_Disk.exe to launch DGDemuxGUI_Files.exe and vice versa? Path to executables could be stored in *.ini files.
Could you make a different icon for DGDemux GUI_Files.exe for better visual differentiation? Any other animal: moose, squirrel

[Rocky]

Great ideas, Island! Thank you so much. I'll do both of those.

Yeah, I'm thinking squirrel too. And change the eagle to a moose.

[jpsdr]

Hello.
For me, number 1 is fine.

[Rocky]

Thanks!

[Rocky]

So far, so good for the streams listing. Moving on to the actual demuxing.

[DelBoy83]

May I ask what the difference is compared to mpls and m2ts files being demuxed? When I add an mpls I get exactly the same m2ts as I would if I just added the m2ts on its own.

[Rocky]

MPLS has access to all the information in the MPLS and CLPI files, while M2TS does not. For example, you can't do strict playlist because that is disk-level information. Also, opening at disk level makes it easy to determine the needed M2TS files based on the playlist, while you're on your own if you don't open at disk level. Finally, the files demuxer can open all types of transport streams while the disk demuxer can demux only M2TS transport.

[Rocky]

I was fixin' to give y'all a test version but ran into a final snafu. Demuxing subs from multiple input files requires knowing the frame rate, because in the disk app the CLPI file is used to get the per-M2TS durations. In DGIndexNV, when opening multiple files the frame rate and frame count are used and that's what I wanted to do in DGDemux files mode. But DGIndexNV gets the frame rate from NVDec, which obviously we cannot do in DGDemux. Another way would be to parse the elementary stream but that would slow down the app and is very complex. Sherman would hate me for ruining his fast-mode architecture. Fear not, we can use avformat from FFMPEG. I already have the code running in a stand-alone app that just gets the frame rate. Now I have to integrate it into DGDemux. But that will have to wait until I get back from the Squirrels United conference. Patience!

[Rocky]

Hehe, I got 'er done. Here is a taste version:

https://rationalqm.us/dgdemux/binaries/ ... 0_test.zip

Of course unzip everything into the same directory so the FFMPEG DLLs can be found. Sorry, they're pretty big. What's a squirrel to do?

See if y'all can figger out how it works. Docs coming later. I decided to use boring icons instead of moose and squirrel. I guess the file list should be stored in the INI file. Feedback will be appreciated.

Off to the conference now.

[jpsdr]

Hello.

Maybe a stupid question, but anyway...
eac3to can demux subtitles.
Is it also using a ffmpeg feature (as if i'm not mistaking eac3to include ffmpeg or use it) or is it using a system of his own ?
If it's the last, maybe the method also can be used for this (or not)...?
Can this be checked by Curly ?

[Rocky]

It uses its own system. I've got things working fine though. DGDemux is very light weight (Sherman's "fast mode") and avoids any ES parsing. Eac3to is heavy-weight and likely provides the same functionality I leveraged from ffmpeg. Let's see how the tasting goes. I have a few UI glitches fixed that I will release when I get back from the conference.

[Rocky]

I'm not happy with the UI as it requires a two-step operation just to open a single file. I'm going to implement a better way that still avoids massive command lines sent to DGDemux.