Page 23 of 37
Re: DGDemux development
Posted: Sat May 09, 2020 8:29 am
by Sherman
Hey Rocky!
I got it working. I had to buffer payload data starting at a packet with payload_unit_start_indicator = 1 up to but excluding the next packet with payload_unit_start_indicator = 1. I learned that trick from you. Then I call a function I made called reorder_pcm() to do the byte swaps on the buffered data. Then that data can be written to disk. I tested it on Ratatouille and the resulting .w64 file is identical to the one produced by sox.exe, it plays fine in MPC-HC, and mkvtoolnix accepts it.
I'm gonna do some code review and testing and then I'll hand it over to you for release. Don't forget we need this in DGIndexNV also. BTW, DGIndexNV has a bug that mangles a few samples at the start of the demuxed PCM file. We can fix that at the same time.
Coding is fun! QM can wait for a while.
Re: DGDemux development
Posted: Sat May 09, 2020 8:34 am
by Rocky
Great work,
Sherman! Waiting for your go-ahead.
Then it is on to various other things (no particular order):
* DGIndexNV zoom = 1/8 for 8K video. "Handcuffs of Zoom."
* Demuxing by episode.
* Port PCM wrapping to DGIndexNV.
You could take the last one since you like coding so much.
Re: DGDemux development
Posted: Sat May 09, 2020 8:47 am
by Sherman
Rocky wrote: ↑Sat May 09, 2020 8:34 am
You could take the last one since you like coding so much.
Your wish is my command.
Re: DGDemux development
Posted: Sat May 09, 2020 8:48 am
by Mr. Peabody
Sherman, I know you're having fun with the coding, but don't forget your homework. And clean your room!
Re: DGDemux development
Posted: Sat May 09, 2020 1:49 pm
by Bullwinkle
Looking closely at your solution, Sherman, I see that it will explode with 20-bit PCM. 20-bit is a legal bluray bit depth. The last 5% of every project determines its success or failure. I learned that from me. The omission is not worth a stomping, but definitely a snort or two. A little tap with the two front hooves to remind you where the real power lies.
Re: DGDemux development
Posted: Sat May 09, 2020 6:18 pm
by Sherman
Bullwinkle, if you can demonstrate a bluray with 20-bit audio I will add support for it.
Rocky, good to go.
Re: DGDemux development
Posted: Sat May 09, 2020 9:02 pm
by Rocky
I'll make a release in the morning with this and the frame rate detection fix for some HEVC streams. Thank you for your contribution.
Love your sense of humor:
Code: Select all
// Set sample size in bytes.
switch ((audio[index].format_m2ts & 0xc0) >> 6)
{
case 1: // 16-bit
size = 2;
break;
// case 2: // 20-bit
// size = puke;
// break;
case 3: // 24-bit
size = 3;
break;
}
Re: DGDemux development
Posted: Sun May 10, 2020 5:17 am
by Guest
DGDemux download link gets a 404 error
Re: DGDemux development
Posted: Sun May 10, 2020 7:00 am
by Rocky
Fixed. Thank you.
Re: DGDemux development
Posted: Sun May 10, 2020 12:17 pm
by Curly
Mr. Peabody wrote: ↑Sat May 09, 2020 8:48 am
And clean your room!
Just curious,
Pea. Are dried lemon peels and empty McDonalds boxes a health hazard? Or are you just throwing your weight around?
Re: DGDemux development
Posted: Sun May 10, 2020 12:20 pm
by Mr. Peabody
Re: DGDemux development
Posted: Sun May 10, 2020 12:25 pm
by Curly
How do we know that
you are a responsible adult, given that you ruined history? Did you know that I too am a highly sought-after speaker?
https://youtu.be/KZSyGCIBDEs
Re: DGDemux development
Posted: Sun May 10, 2020 12:26 pm
by admin
Let's stay on topic, guys. Thank you!
Re: DGDemux development
Posted: Sun May 10, 2020 4:12 pm
by Sherman
Curly, my daddy is stronger than your daddy!
Re: DGDemux development
Posted: Tue May 12, 2020 9:46 am
by Emulgator
Hi DG, many thanks for your continued work on those tools that make ends meet !
Here comes a small thingy for DGDemux 1.0.0.26c:
https://forum.doom9.org/showthread.php? ... ost1911589
(DGDemux 1.0.0.26 reports 30.000fps for an extra video stream (here MPEG-2 NTSC) where it should be 29.970 or 30000/1001)
Re: DGDemux development
Posted: Tue May 12, 2020 10:10 am
by Rocky
Who says it should be 29.97? Can you please cut the first 100MB of the first M2TS in that playlist and upload it somewhere? Also the MPLS file. And please, give me the screenshot! Unapproved attachments at other forums are useless. Thank you.
I can fix it quick if you provide these things.
Re: DGDemux development
Posted: Tue May 12, 2020 11:35 am
by Rocky
Thanks for following up at the other forum. We can continue there.
Re: DGDemux development
Posted: Tue May 12, 2020 12:00 pm
by Rocky
Problem fixed.
Re: DGDemux development
Posted: Wed May 13, 2020 1:59 am
by Emulgator
Success ! 1.0.0.26(d): fps shows 29.970 correctly.
Repeated donation underways, just for all the DG Tools I have used over the years.
P.S. Oh, I just saw it, so I am Moose Approved now !
So no stomping for the next 7 miles...
Re: DGDemux development
Posted: Wed May 13, 2020 4:34 am
by Rocky
Thank you, Emulgator! I think you hold the record now for speed of becoming Moose Approved.
The funny thing is that 30i is not even a legal bluray frame rate. You'd'a thought a diligent squirrel would know that. Derp.
Re: DGDemux development
Posted: Wed May 13, 2020 3:10 pm
by domy
A little status update on my THD prototype:
I've gotten my application to the point where I can give it a list of m2ts files and it gives me a THD file where all the segments are cut in line with the Bresenham algorithm (and it decodes correctly with ffmpeg
). While the sync is now spot on throughout the entire film, the cuts are in the wrong places and it's definitely audible (where you can hear a subtle "pop" that disappears when you do the cut correctly).
Tomorrow I'll dive into matching the decoded audio of the neighboring THD frames at the cut locations to get it just perfect.
Once I'm done with that, I'll clean it up and publish it on my Github
Re: DGDemux development
Posted: Wed May 13, 2020 3:23 pm
by Rocky
Sounds good. I'll be very interested to see what you come up with.
Re: DGDemux development
Posted: Thu May 14, 2020 2:40 pm
by domy
I've had success with extracting the audio data at the ends of a THD stream. It turns out that if two segments overlap by a frame, they match
almost perfectly.
Almost.
Have some samples from Monsters University (signed 32-bit, but really 24-bit, integers):
Last THD frame of 00055 (segment 1), channel 0:
Code: Select all
sample: -295504
sample: -270672
sample: -241760
sample: -212416
sample: -184096
sample: -158032
sample: -133376
sample: -113584
sample: -94656
sample: -72672
sample: -44256
sample: -9104
sample: 27792
sample: 66304
sample: 104480
sample: 136272
sample: 161984
sample: 181840
sample: 194704
sample: 206496
sample: 223856
sample: 247152
sample: 274176
sample: 305600
sample: 342336
sample: 381248
sample: 417872
sample: 451552
sample: 481584
sample: 506080
sample: 523952
sample: 535824
sample: 542512
sample: 541968
sample: 529904
sample: 510112
sample: 485440
sample: 458256
sample: 428976
sample: 399280
First THD frame of 00056 (segment 2), channel 0:
Code: Select all
sample: -295488
sample: -270672
sample: -241744
sample: -212400
sample: -184080
sample: -158048
sample: -133376
sample: -113584
sample: -94672
sample: -72656
sample: -44256
sample: -9088
sample: 27792
sample: 66304
sample: 104480
sample: 136272
sample: 162000
sample: 181824
sample: 194720
sample: 206496
sample: 223872
sample: 247152
sample: 274176
sample: 305600
sample: 342336
sample: 381248
sample: 417888
sample: 451552
sample: 481584
sample: 506080
sample: 523952
sample: 535840
sample: 542528
sample: 541984
sample: 529904
sample: 510112
sample: 485424
sample: 458256
sample: 428976
sample: 399280
The sample sequences match almost identically, being at most 1 unit of resolution off in this case. This makes me happy
. I'll definitely need to test all of my Disney/Pixar discs to see what tolerance I can ultimately get away with when matching, but this is looking very promising.
It also appears that at least on Monsters University, the true bit depth is only 20 bits per sample instead of 24 (due to every sample being a multiple of 16). This is weird and unexpected and I'm not fully convinced yet that I'm not wrongly assuming the sample value data layout, but ffmpeg spits out the same values if I ask it to convert the THD stream to PCM signed 24 bit. Definitely need to make sure I get this right.
Re: DGDemux development
Posted: Thu May 14, 2020 4:55 pm
by Rocky
Always exciting to hear from you,
domy. I've been rebuilding my attic air return system and have to tell you, I am knackered! Will respond tomorrow, if
Sherman doesn't jump in before then. Kids, these days.
Can't salvage the ducts so going with this:
https://www.homedepot.com/p/Master-Flow ... /202562740
Happiness is shiny new ducts and vents.
Start to fix one thing and two things it depends on break. 70s construction was the pits.
:belly-laugh:
Re: DGDemux development
Posted: Thu May 14, 2020 6:20 pm
by Rocky
Blown-in or batts? That is the question.
I'm thinking batts. Blown-in is so messy and think of wading through it for future repairs.
