Page 6 of 37

Re: DGDemux development

Posted: Mon Dec 02, 2019 1:27 pm
by redbtn
Umm. I don't know how to test it properly yet. But I don't see much difference vs 1.0.0.8. Can you do 500mb RAM buffer for each stream for test?

PS: Minimize bug is fixed now, thank you! Thanks for other improvements too.

Re: DGDemux development

Posted: Mon Dec 02, 2019 1:40 pm
by Bullwinkle
Nothing like that can help. The OS manages physical writes to the disk from the buffers. Many have benchmarked this and found increasing beyond 1MB file buffer brings you nothing; me too. Are you chasing unicorns? What problem do you have?

"Umm. I don't know how to test it properly yet."

Let us know when you figure it out.

Re: DGDemux development

Posted: Mon Dec 02, 2019 1:44 pm
by redbtn
Bullwinkle wrote:
Mon Dec 02, 2019 1:40 pm
Nothing like that can help. The OS manages physical writes to the disk from the buffers. Many have benchmarked this and found increasing beyond 1MB file buffer brings you nothing; me too. Are you chasing unicorns? What problem do you have?
Actually I don't have any issues for now. All looks great. I thought about improving things which works good, you are right, maybe I'm chasing unicorns.

Re: DGDemux development

Posted: Mon Dec 02, 2019 1:48 pm
by Bullwinkle
It's called hoomin error, hoomin paranoia. Try to learn from it.

Now we have to focus on the demuxed streams, checking basic functionality, AV sync, etc.

Waiting on an important upload right now...

Re: DGDemux development

Posted: Mon Dec 02, 2019 3:38 pm
by rack04
Nit pick comment but could you change the try icon? I would like to have both DGDecNV and DGDemux in my taskbar without having to guess which is which. Thanks and great work.

Re: DGDemux development

Posted: Mon Dec 02, 2019 9:45 pm
by zqslzwzw
Rocky wrote:
Sun Dec 01, 2019 8:53 am
zqslzwzw wrote:
Sun Dec 01, 2019 5:26 am
Could you go to that private track to obtain this source? If you do not have its account, I am pleased to invite you as long as you are willing to be and agree with its rule.
We've been looking for DTS HDHR streams so this would help both of us. If I gave you an FTP would you be able to upload it there? We don't do torrents.
The reported BD disk has been uploaded to this FTP. And an explanation of duplication procedure is placed aside.
Thank you for effort!

Re: DGDemux development

Posted: Tue Dec 03, 2019 7:03 am
by redbtn
Another "Browse" bug

Re: DGDemux development

Posted: Tue Dec 03, 2019 8:43 am
by Rocky
Thanks, redbtn, for pointing that out.

I really need to know which MPLS you used for that 10ms thing.

Re: DGDemux development

Posted: Tue Dec 03, 2019 8:44 am
by Rocky
zqslzwzw wrote:
Mon Dec 02, 2019 9:45 pm
The reported BD disk has been uploaded to this FTP. And an explanation of duplication procedure is placed aside.
Thank you for effort!
Thank you. Duplicated and under investigation.

Re: DGDemux development

Posted: Tue Dec 03, 2019 9:20 am
by Rocky
OK, zqslzwzw, I have this fixed. I want to research a few corner cases versus the DTS spec before releasing a fix.

@redbtn

Fixed your new browse bug, too. MPLS for your 10ms thing? Third time asking!

Re: DGDemux development

Posted: Tue Dec 03, 2019 10:30 am
by Rocky
Here is version 1.0.0.10:

* Fixed demuxing of DTS-HDHR streams.

* Fixed GUI corruption after canceling 'browse output' operation.

http://rationalqm.us/dgdemux/DGDemux_1.0.0.10.rar

Re: DGDemux development

Posted: Tue Dec 03, 2019 11:47 am
by redbtn
Rocky wrote:
Tue Dec 03, 2019 8:43 am
Thanks, redbtn, for pointing that out.

I really need to know which MPLS you used for that 10ms thing.
00847.mpls. Sorry for late reply, I was afk

Re: DGDemux development

Posted: Tue Dec 03, 2019 12:18 pm
by Rocky
redbtn wrote:
Tue Dec 03, 2019 11:47 am
00847.mpls. Sorry for late reply, I was afk
Please say disk title, MPLS, and your problem description in one post. There's no time to go searching back across multiple forums to try to piece things together. Thank you for your understanding.

Re: DGDemux development

Posted: Tue Dec 03, 2019 12:19 pm
by Bullwinkle
Even Rocky has limits!

Re: DGDemux development

Posted: Tue Dec 03, 2019 5:32 pm
by redbtn
Rocky wrote:
Tue Dec 03, 2019 12:18 pm
redbtn wrote:
Tue Dec 03, 2019 11:47 am
00847.mpls. Sorry for late reply, I was afk
Please say disk title, MPLS, and your problem description in one post. There's no time to go searching back across multiple forums to try to piece things together. Thank you for your understanding.
Iron man 2, mpls 00847. DTS-MA track.
Before 1.54.34.500 it perfect, after has shift +10ms. I guess there is place where last m2ts starts. Maybe there are 2 identical frames and 1 should be deleted, but for some reason it wasn't.I fail to find duplicate frame, but there starts difference +10ms (vs eac3to), and stream length is +10ms vs BDInfo information. I'm not 100% sure that it's issue, but if you look at it, it will be great.

Re: DGDemux development

Posted: Tue Dec 03, 2019 8:03 pm
by Rocky
Great report, redbtn. Thank you. Now I can get on it tomorrow.

Re: DGDemux development

Posted: Wed Dec 04, 2019 2:41 am
by zqslzwzw
redbtn wrote:
Tue Dec 03, 2019 5:32 pm
Iron man 2, mpls 00847. DTS-MA track.
Before 1.54.34.500 it perfect, after has shift +10ms. I guess there is place where last m2ts starts. Maybe there are 2 identical frames and 1 should be deleted, but for some reason it wasn't.I fail to find duplicate frame, but there starts difference +10ms (vs eac3to), and stream length is +10ms vs BDInfo information. I'm not 100% sure that it's issue, but if you look at it, it will be great.
How to get the duration of a BD disk so precisely by BDInfo or other tools? I also tried BDInfo 0.7.5.5 (GUI), however it reports the duration as hh:mm:ss without the precision of milliseconds.

Re: DGDemux development

Posted: Wed Dec 04, 2019 9:55 am
by Rocky
redbtn wrote:
Tue Dec 03, 2019 5:32 pm
Iron man 2, mpls 00847. DTS-MA track.
Before 1.54.34.500 it perfect, after has shift +10ms. I guess there is place where last m2ts starts. Maybe there are 2 identical frames and 1 should be deleted, but for some reason it wasn't.I fail to find duplicate frame, but there starts difference +10ms (vs eac3to), and stream length is +10ms vs BDInfo information. I'm not 100% sure that it's issue, but if you look at it, it will be great.
1.54.34.500 is the time at which the gap between the last two M2TS files occurs. At each gap, processing is done to see what adjustments are necessary. In this case at that gap, DGDemux sees an accumulated desync that is below the threshold (approx. 5ms for DTS HDMA) for requiring correction. Therefore, no audio frames are deleted or added at this gap. AV sync during the last M2TS appears spot on to me when playing an MKV made from the demuxed files in MPC-HC.

So, it appears that eac3to deletes a frame at this point and DGDemux does not. As I have mentioned several times, DGDemux and eac3to use completely different algorithms to decide when to delete audio frames. The decision at each gap will depend on what has been done at all the previous gaps.

Bottom line is I don't see a problem here.

Re: DGDemux development

Posted: Wed Dec 04, 2019 10:23 am
by redbtn
Rocky wrote:
Wed Dec 04, 2019 9:55 am
1.54.34.500 is the time at which the gap between the last two M2TS files occurs. At each gap, processing is done to see what adjustments are necessary. In this case at that gap, DGDemux sees an accumulated desync that is below the threshold (approx. 5ms for DTS HDMA) for requiring correction. Therefore, no audio frames are deleted or added at this gap. AV sync during the last M2TS appears spot on to me when playing an MKV made from the demuxed files in MPC-HC.

So, it appears that eac3to deletes a frame at this point and DGDemux does not. As I have mentioned several times, DGDemux and eac3to use completely different algorithms to decide when to delete audio frames. The decision at each gap will depend on what has been done at all the previous gaps.

Bottom line is I don't see a problem here.
Thanks for investigating! DGDemux is smarter than eac3to, even on non UHD BDs, it's good! So, it seems I have no issues for now anymore. I'll check UHD seamless disks if I find them. But it will be much harder to find bugs.
Thank you for your hard work!
zqslzwzw wrote:
Wed Dec 04, 2019 2:41 am
How to get the duration of a BD disk so precisely by BDInfo or other tools? I also tried BDInfo 0.7.5.5 (GUI), however it reports the duration as hh:mm:ss without the precision of milliseconds.
Image

Re: DGDemux development

Posted: Wed Dec 04, 2019 10:35 am
by Rocky
Great to hear, redbtn. You've been really helpful in DGDemux development.

Ah, that BDInfo report feature. I never noticed that before. Cool!

Re: DGDemux development

Posted: Wed Dec 04, 2019 11:09 am
by zqslzwzw
redbtn wrote:
Wed Dec 04, 2019 10:23 am
zqslzwzw wrote:
Wed Dec 04, 2019 2:41 am
How to get the duration of a BD disk so precisely by BDInfo or other tools? I also tried BDInfo 0.7.5.5 (GUI), however it reports the duration as hh:mm:ss without the precision of milliseconds.
Image
Thank you very much. I never notice this before.
If I have not scan the whole disk before entering this feature, will the "Length" be detected accurately?
And I have not figure out how to make it on the command line version.

Re: DGDemux development

Posted: Wed Dec 04, 2019 11:18 am
by zqslzwzw
Rocky wrote:
Wed Dec 04, 2019 10:35 am
Great to hear, redbtn. You've been really helpful in DGDemux development.

Ah, that BDInfo report feature. I never noticed that before. Cool!
Today I find another DIY disk with demux problems by DGDemux. The duration of the obtained audio files deviate from that of the video stream.
But none of other softwares such as eac3to, tsmuxer, mkvtoolnix and ffmpeg can demux it correctly. I am not sure whether it is necessary to upload it for your analysis. This disk has only one main m2ts and can be played normally by potplayer.

Re: DGDemux development

Posted: Wed Dec 04, 2019 11:23 am
by Rocky
Sure, go ahead and upload it. Happy to look into it for you. With only one M2TS the gaps processing is not involved, but there may be some other issue that can be fixed.

Re: DGDemux development

Posted: Wed Dec 04, 2019 7:19 pm
by redbtn
Why DGDemux GUI window becomes inactive after clicking "Demux"?

Re: DGDemux development

Posted: Wed Dec 04, 2019 8:18 pm
by Rocky
redbtn wrote:
Wed Dec 04, 2019 7:19 pm
Why DGDemux GUI window becomes inactive after clicking "Demux"?
It doesn't become inactive. I just tested. I'm able to move the window, hit Abort, etc. So... :?: