DGDemux development
- Bullwinkle
- Posts: 338
- Joined: Thu Sep 05, 2019 6:37 pm
Re: DGDemux development
Maybe that got put in for 1.0.0.11. Is it working good for you?
Re: DGDemux development
The demuxing is working really well for me
I was just wondering about the list shortened names for the M2TS list since I didn't see any difference
I was just wondering about the list shortened names for the M2TS list since I didn't see any difference
- Bullwinkle
- Posts: 338
- Joined: Thu Sep 05, 2019 6:37 pm
Re: DGDemux development
Maybe compare to 1.0.0.10.
Re: DGDemux development
Could not detect frame rate. Skip first doesn't help. If force 23.976 manually it works well. Maybe it's an issue, maybe not.
01281.mpls, files on ftp (4.21gb)
01281.mpls, files on ftp (4.21gb)
Re: DGDemux development
Thank you for your report, redbtn, acute and precise as always. There is a corner case where it can happen (HEVC with no VPS, need to parse the VI). Hope springs eternal in a young man's breast. Need to get rid of that nonsense. Let's see if that's what you've found...
Re: DGDemux development
He he, AVC. OK, have it fixed locally. Will release tomorrow morning. Thank you.
Re: DGDemux development
Here is version 1.0.0.13:
* Fixed problem with FPS detection for some AVC playlists. [redbtn]
http://rationalqm.us/dgdemux/DGDemux_1.0.0.13.rar
* Fixed problem with FPS detection for some AVC playlists. [redbtn]
http://rationalqm.us/dgdemux/DGDemux_1.0.0.13.rar
Re: DGDemux development
Thanks for you hard work on this great tool. I'd like to request a feature. I hope it's alright. Maybe suggest, more then request, you guys be the judge.
Let's take "Odette" as a BD Folder with a standard structure: Odette\BDMV\PLAYLIST
Feature: Making demuxing more flexible.
should give us the list of available playlists from which we can choose which one to demux. This is important because BD may have 20 or 100 different playlists, I need for a demuxing tool to be able to tell me something about them.
Info that eac3to gives is something like this:
Which is kind of a general overview of playlists, their playtimes, which m2ts files they contain and so on.
Then you should be able to choose which one you want to demux.
where -p is playlist number.
The next screen should be numbered list of streams inside that playlist, kinda like how dgdemux lists them.
dgdemux:
eac3to:
I think it's more convenient to have them listed as base10 numbers instead of base16.
After this, 1 version would be to let you demux them.
As a second version, I think it's very important that we are able to name them.
output of which should be:
Also, it'd be great if we were allowed to omit the -o ... option. If not provided, dgdemux should assume that we want to demux into the folder that are at that moment.
In which case, it would just be:
or
Note that for -o ... option, I just included a folder named "output". I think dgdemux should deduce a naming scheme based on something from the -i ... option.
For example, if I'm demuxing -p 1, which is playlist 00000.mpls, sensible automatic naming scheme for the tracks might be:
so basically, playlist_track_number.extension, this only matters of course if user doesn't provide individual track names with -demux.
Sorry about a very long post, none of this is a criticism of your work, I just want this tool to be better, I hope you will consider these suggestions and implement them in time.
Let's take "Odette" as a BD Folder with a standard structure: Odette\BDMV\PLAYLIST
Feature: Making demuxing more flexible.
Code: Select all
DGDemux -i Odette
Info that eac3to gives is something like this:
Code: Select all
1) 00000.mpls, 00000.m2ts, 1:57:30
- Chapters, 12 chapters
- h264/AVC, 1080p24 (16:9)
- RAW/PCM, English, stereo, 48kHz
2) 00007.mpls, 00011.m2ts, 0:27:09
- h264/AVC, 1080p24 (16:9)
- RAW/PCM, English, stereo, 48kHz
3) 00002.mpls, 00003.m2ts, 0:20:43
- h264/AVC, 1080p24 (16:9)
- RAW/PCM, English, stereo, 48kHz
4) 00003.mpls, 00004.m2ts, 0:19:35
- h264/AVC, 1080p24 (16:9)
- RAW/PCM, English, stereo, 48kHz
Then you should be able to choose which one you want to demux.
Code: Select all
DGDemux -i Odette -p 1
The next screen should be numbered list of streams inside that playlist, kinda like how dgdemux lists them.
dgdemux:
Code: Select all
Streams:
1011: Video [AVC]
1100: PCM 48K 24bit 2/0 [eng]
1200: PGS subtitles [eng]
1201: PGS subtitles [eng]
Code: Select all
M2TS, 1 video track, 1 audio track, 2 subtitle tracks, 1:57:30, 24p
1: Chapters, 12 chapters
2: h264/AVC, 1080p24 (16:9)
3: RAW/PCM, English, 2.0 channels, 24 bits, 48kHz
4: Subtitle (PGS), English
5: Subtitle (PGS), English
After this, 1 version would be to let you demux them.
Code: Select all
DGDemux -i Odette -p 1 -o output\
Code: Select all
DGDemux -i Odette -p 1 -demux 1:chapters 2:video 3:audio 4:eng_subtitles_1 5:eng_subtitles_2 -o output\
Code: Select all
chapters.txt video.264 audio.pcm eng_subtitles_1.sup eng_subtitles_2.sup
In which case, it would just be:
Code: Select all
DGDemux -i Odette -p 1
Code: Select all
DGDemux -i Odette -p 1 -demux 1:chapters 2:video 3:audio 4:eng_subtitles_1 5:eng_subtitles_2
For example, if I'm demuxing -p 1, which is playlist 00000.mpls, sensible automatic naming scheme for the tracks might be:
Code: Select all
1: Chapters, 12 chapters : 00000_1.txt
2: h264/AVC, 1080p24 (16:9) : 00000_2.264
3: RAW/PCM, English, 2.0 channels, 24 bits, 48kHz : 00000_3.pcm
4: Subtitle (PGS), English : 00000_4.sup
5: Subtitle (PGS), English : 00000_1.sup
Sorry about a very long post, none of this is a criticism of your work, I just want this tool to be better, I hope you will consider these suggestions and implement them in time.
Re: DGDemux development
Thank you, dragon, and welcome to the forum. Yes, I have that on my to-do list and will surely keep your suggestions in mind when I go to implement that stuff.
Re: DGDemux development
Got the garbage skipping working for CROUPIER. I'd like to ask users whether they think garbage skipping should be optional, i.e., should there be an option to not skip garbage? I always prefer not to have unnecessary options. Can anyone see a use case where it might be desirable to retain content outside the playlist in<-->out times? After this is decided I'll make a release.
BTW, I also enhanced the GUI to do an automatic re-browse when the skip first or skip last boxes are checked/unchecked after an MPLS has been loaded. Much more friendly!
BTW, I also enhanced the GUI to do an automatic re-browse when the skip first or skip last boxes are checked/unchecked after an MPLS has been loaded. Much more friendly!
Re: DGDemux development
By garbage skipping do you mean cases were "skip first" is applicable? Like Kino Lorber discs that have 11.010s m2ts clip at the beginning that causes audio/subtitle out-of-sync issue because intro m2ts just consists of the video stream and not the audio/subtitle streams?Rocky wrote: ↑Sun Dec 15, 2019 11:19 amGot the garbage skipping working for CROUPIER. I'd like to ask users whether they think garbage skipping should be optional, i.e., should there be an option to not skip garbage? I always prefer not to have unnecessary options. Can anyone see a use case where it might be desirable to retain content outside the playlist in<-->out times? After this is decided I'll make a release.
BTW, I also enhanced the GUI to do an automatic re-browse when the skip first or skip last boxes are checked/unchecked after an MPLS has been loaded. Much more friendly!
If that's what you mean, then I'd say that it's not always an issue. Sometimes intro/outro content is useful and skipping them is not a good option.
I do agree with you though, I also prefer for there not to be any unnecessary options. I'm not a huge fan of -sf and -sl options. They kind of bloat the program in my view.
As far as understand, this particular issue arises only when m2ts files that in the playlist don't consist of the same streams. That particular situation raises not only the out-of-sync problem, but other problems such as when some of the m2ts files have 640kbps ac3 audio for example, and some have 448kbps, in the same playlist. What is the output in that case? The way eac3to deals with it is it re-encodes the audio into 640kbps using libAften encoder that it comes with.
Both problems stem from non-consistent list of streams. I think one decent way of dealing with the first problem (out-of-sync issue due to intro) would be for dgdemux to scan m2ts files before demuxing starts, if it discovers that list of streams in all m2ts files of the playlist aren't consistent, then it asks you something like this:
Code: Select all
dgdemux -i MOVIE\BDMV\PLAYLIST\00000.mpls -o output\
Code: Select all
dgdemux
The streams in 00000.mpls [00001.m2ts + 00003.m2ts + 00006.m2ts] aren't consistent:
00001.m2ts 00003.m2ts
1011: Video [AVC] 1011: Video [AVC] ✔
1100: DTS HDMA L+R 48 1536 ✘
1101: PGS subtitles [eng] ✘
Do you want demux 00000.mpls entirely or skip first m2ts? [d] - demux, [sf] - skip first, [sl] - skip last: ...
Especially when sometimes, 00001.m2ts may not cause issues if audio/video tracks in 00003.m2ts have delay added to them, some studios do this, and in cases like that, demuxing the entire mpls even when first m2ts has no audio/subtitle tracks causes no issues as long as dgdemux respects the delay of the playlist on those tracks.
The second issue, where the audio bit rate/type changes between m2ts files is more difficult to solve I think. I haven't tested how dgdemux handles those, I assume it won't re-encode like eac3to does, and it can't "combine" 2 different bit rate audios so I assume it will demux first one, and skip the second one.
for example, if mpls is 00001.m2ts+00002.m2ts+00003.m2ts, and if 00001.m2ts & 00002.m2ts both have AC3@640kbps audio, but 00003.m2ts has AC3@448kbps audio, I assume dgdemux will demux audio just from first two m2ts files and skip the last one, or it will have an error. But again, I haven't tested it so I don't know. There should be a warning in any case, like the above warning when there are inconsistent streams in m2ts files, so that user is aware that demuxed audio is not viable, then he can decide how to handle it. (hopefully in future, there will be a detailed log where all this will be logged.)
Re: DGDemux development
Garbage refers to content in a playlist that is outside the range defined by the IN_time of the first M2TS and the OUT_time of the last M2TS. This is distinct from -sf and -sl. The IN_time of an M2TS need not correspond to the first video access unit of an M2TS. For example, CROUPIER (one M2TS in the playlist) has almost a full minute of colors bars and blackness before the IN_time, and then some more blackness after the OUT_time.
I appreciate your detailed info and requests, dragon. However, I'm not going to revisit things we have already discussed and decided. -sf and -sl are staying. There are too many weird cases and corner cases to try to automate things. Always prefer the human mind. Also I'm not going to do anything based on just your theory and experience. You will need to cite specific disks with links to purchase and say how they are being misprocessed in your view.
I appreciate your detailed info and requests, dragon. However, I'm not going to revisit things we have already discussed and decided. -sf and -sl are staying. There are too many weird cases and corner cases to try to automate things. Always prefer the human mind. Also I'm not going to do anything based on just your theory and experience. You will need to cite specific disks with links to purchase and say how they are being misprocessed in your view.
- Bullwinkle
- Posts: 338
- Joined: Thu Sep 05, 2019 6:37 pm
Re: DGDemux development
"Always prefer the human mind."
Snort! Moose minds work way better. Moose are awesome!
https://www.youtube.com/watch?v=9T27xFSsxxs
https://www.youtube.com/watch?v=JS2MNeUSDa8
Natasha told me she could help me become a moderator. She knows Forum Mr. Big!
Snort! Moose minds work way better. Moose are awesome!
https://www.youtube.com/watch?v=9T27xFSsxxs
https://www.youtube.com/watch?v=JS2MNeUSDa8
Natasha told me she could help me become a moderator. She knows Forum Mr. Big!
Re: DGDemux development
That's great, Bullwinkle, but we really need a GUI concept for the playlist scanning. Let's go!
Re: DGDemux development
Pottsylvanian coders have already solved your problems. Natasha is explaining it to Bullwinkle right now. He is very excited.
Will it be curtains for Bullwinkle, or we all learn to code?
Will it be curtains for Bullwinkle, or we all learn to code?
Re: DGDemux development
Does Bullwinkle already know how to do this?
Re: DGDemux development
Haven't seen him for a while. Hope he's OK!
- Bullwinkle
- Posts: 338
- Joined: Thu Sep 05, 2019 6:37 pm
Re: DGDemux development
Sorry, Rock, here I am. Natasha was going to help me become a moderator, but then she tried to bite me! So I gave her a little stomping and she limped away. Think about it!
The design is all worked out for playlist scanning. You're gonna like it!
The design is all worked out for playlist scanning. You're gonna like it!
Re: DGDemux development
That's great, Bullwinkle! I have to get a DGDemux release out for CROUPIER. Then Xunkar found some weird things in DGIndexNV program stream parsing. Then whee!
Re: DGDemux development
Bullwinkle gave me a nice GUI concept for playlist scanning and I was able to get it working. Here is how it looks. I still have a few little things to do and then I will make a release. Time difference from BDINFO is likely due to accumulated rounding of each playlist item. No big deal for now; I'll fix that later. Playlists shorter than 10 minutes, or ones that have duplicated items are suppressed.
Re: DGDemux development
In future can this be made user selectable?Playlists shorter than 10 minutes
Re: DGDemux development
Sure it can be done. Is there a good reason for it?
Re: DGDemux development
Series discs, by adjusting the time we can filter out most of the extras and leave the actual episodes
Average 1 hr slot episode is 45 to 50 min so one could use 35 minutes
1/2 hr time slot episode is 20 to 25 minutes so we could use 15 minutes
That is the basic idea
Average 1 hr slot episode is 45 to 50 min so one could use 35 minutes
1/2 hr time slot episode is 20 to 25 minutes so we could use 15 minutes
That is the basic idea
Re: DGDemux development
All those times are greater than 10 minutes. BDINFO uses 20 seconds by default. Maybe I should do that?
Re: DGDemux development
The idea is to not show the extras in episodic discs, so making the cut off length closer to the episode time would make it easier to identify the playlists that point to the episodes