DGDemux development

[Rocky]

Sweet!

[Emulgator]

1.0.0.29 looks nice !
2001 shows the 2 video streams with PIDs 1011 (HEVC) and 1015 (DV).

3D: yes I am constantly looking for such stuff and buy the few that give a good impression.
TRON Legacy in 2D was already spectacular, but in 3D it is even moaaar.

Can't understand the reason for 3D demise... could it be that nausea claims made the film industry shiver ?

[Emulgator]

Just running AnyDVD HD 7.6.9.1 on TRON Legacy 3D in folder mode:
When mounted by AnyDVD HD Explorer shows the .ssifs in full size.
Before ripping Any warns about folder mode for 3D, suggests image mode for 3D,
I insisted on folder mode and at the moment Any indeed rips one of these (00131.ssif) to 23.784.564 KB.

[Guest]

When you rip 3D to folder, with AnyDVD, the final size is roughly 2X the size of the ISO

[Emulgator]

Yes, IIRC ssif just was to be seen as the mounted m2ts pairs, now I let these be materialized for research.
(In the case of TRON_LEGACY_3D 00131.m2ts seemed to be base view.
00132.m2ts seemed to be the dependent "Sub TS for a sub-path of Stereoscopic Movie" (BDEdit v0.49b).
Going to bed now.

[hydra3333]

Just checking if y'all are paying attention. Thank you, gonca, for pointing that out.

Just a leetle note, the binaries page viewtopic.php?f=5&p=11684#p11684 still has the funny link.
Cheers !

[Emulgator]

Yes, that download link was still dead yesterday, I just went folder up to download.

Continuing with TRON_LEGACY_3D:
(This is a 3D-only disc, EU only, wasn' t for individual retail, I guess bundleware with 3D players.
No playback on 2D players, possibly locked out by player/display chain check.
If you try to play that disc on partly 2D equipment anway you get a warning screen:
"The disc has recognised that your player and/or display does not support 3D playback)

Playing the main movie with MPC-HC32 1.9.3
mediainfo if started from within lists the playlist 00070.mpls pointing to 00131.mts + 00132.mts for first half of the movie
and 00133.m2ts + 00134.m2ts for the second half of the movie.

DGDemux 1.0.0.29 was happy with Makemkv's folder, and with AnyDVD HD's folder
(tested only pointing and mountig, no demuxing for now)
For now from playlist 00070.mpls it saw only the base view (odd) 00131.m2ts and 00133.m2ts
and offered these for demuxing.
(2 more playlists 00082.mpls and 00083.mpls exist and are shown, these just mount the two halves of the film separately.)

mediainfo standalone fired upon the even (dependent) 00132.m2ts and 00134.m2ts:
PID for the dependent views 00132.m2ts and 00134.m2ts was indeed 0x1012 (dec 4114)
MVC Codec ID: 0x20 (dec 32)
Format Profile: Stereo High@L4.1
MultiView_Count: 2
This might help in parsing.

In these connected .m2ts the second (even).m2ts seem to contain the dependent view, and only that stream.
(these .m2ts were not playable with MPC-HC32 1.9.3 nor MPC-BE32 4969).
Maybe straightforward from there to demux that elementary.
What do do with such stream later, user has to decide...
While examining MakeMKVs .ssif.smap it looks to me as if these store the interleaving pattern of both base view/dependent view.m2ts.
This might help in later reusing of the demuxed MVC ES.

Just as a hint for the ones who want to dive in:
https://forum.videohelp.com/threads/323 ... ssif-files
but y'all may know more already...

[Rocky]

Thank you gentlemen. Thought I had fixed the link. Fixed it again and double-checked.

So AnyDVD is the only way to directly get the SSIF files. I will write a simple SSIF.SMAP -> SSIF utility to convert for MakeMKV.

All we need to do is demux the dependent stream from the SSIF files. Shouldn't be that difficult. Of course, DGMVCSource() and FRIMSource() can already serve the base and dependent streams via Avisynth(+).

[Guest]

Should be getting the movie Sanctum 3D real soon to help with testing (it is actually easier for me this way due to archiving system, or lack thereof)

[Rocky]

Great to hear.

Just found that the dependent stream can have its own subtitle stream. Complicates things. Where is Sherman?

[Guest]

Movie arrived a few minutes ago
If you need info/comparisons between original, MakeMKV and AnyDVD please let me know

[Guest]

Great to hear.

Just found that the dependent stream can have its own subtitle stream. Complicates things. Where is Sherman?

Would it be its own or the same subtitle with a depth offset for the 3D effect?
I guess that either way it would be its own subtitle

[Rocky]

Movie arrived a few minutes ago
If you need info/comparisons between original, MakeMKV and AnyDVD please let me know

Just need to know if AnyDVD creates full SSIF files on windows. Thank you.

[Guest]

Yes
Full sized ssif files

[Rocky]

Jolly good. Thank you.

[Emulgator]

In my case of TRON_LEGACY_3D the concerning even numbered m2ts contain only 1 stream, the .mvc stream.
Will check Rataouille 3D, Cars 3D, Men in Black 3D, time permitting.

[Rocky]

Not sure I follow your point there, Emulgator. Can you please elaborate? Is it about no extra subtitles in the the MVC M2TS? Well, sometimes there are, and sometimes there are not.

I'm moving towards using just the M2TS files rather than the SSIF. The playlist gives us the matching M2TS MVC file(s) so all we have to do is demux the MVC stream from the matched M2TS file(s). It is all one-to-one so no need to maintain separate file lists, etc.

Using just the M2TS files means that all rippers will be compatible.

[Emulgator]

Yes, I mentioned that only for that case of TRON_LEGACY_3D, I didn't mean to challenge your previous statement.
P.P.S.: Just contributing those cases, no doubt that it could be different with other discs:
TRON_LEGACY_3D: One of the 3D pairs primary 00131.m2ts/secondary 00132.m2ts:
mediainfo shows for 00132.m2ts: MVC stream only, no subs. CABAC, 4 RefFrames, 162Gbps VBR (garbage data), 20.4Mbps max.
MIB_3_3D: One of the 3D pairs primary 00342.m2ts/secondary 00343.m2ts:
mediainfo shows for 00343.m2ts: MVC stream only, no subs. CABAC, 3 RefFrames, 8.6Mbps VBR, 20Mbps max.
RATATOUILLE_3D: One of the 3D pairs primary 01214.m2ts/secondary 01255.m2ts:
mediainfo shows for 01255.m2ts: MVC stream only, no subs. CABAC, 3 RefFrames, 8.4Mbps VBR, 18Mbps max.
CARS_3D: One of the 3D pairs primary 01393.m2ts/secondary 01429.m2ts:
mediainfo shows for 01429.m2ts: MVC stream only, no subs. CABAC, 3 RefFrames, 6.5Mbps VBR, 16Mbps max.

Demuxing the secondary.m2ts directly: yes, this is what I hoped to suggest in my post a page earlier.

In these connected .m2ts the second (even).m2ts seem to contain the dependent view, and only that stream.
(these .m2ts were not playable with MPC-HC32 1.9.3 nor MPC-BE32 4969).
Maybe straightforward from there to demux that elementary.

Just in case somebody wants to go on reconstructing .ssif from main/dependant.m2ts pairs and Makemkv's .ssif.smap:
Looks as if ixceuh already wrote a parser script and a ssif rebuilder:
https://www.makemkv.com/forum/viewtopic ... hilit=ssif
P.S. well, found the links to be dead now, but in this thread mhelin, KurianOfBorg, mike_admin tell a bit about their findings..
Makemkv's .ssif.smap structure seems to tell how to concatenate .ssif from the two main/dependant .m2ts source files:
per line calling the appropriate sourcefile, start offset, length of chunk.
But for the reason of demuxing this seems obsolete now, mounting as ssif should only be needed by the playing application.
Maybe useful for counterchecking only, and to go from .ssif files if anybody has them (as tsmuxeR offers IIRC, although I never used that feature).

[Emulgator]

Just for completeness' sake and maybe it helps:
Some conclusions from 4 ssif.smap tables (still soft, 2020 06 19 CN):

Unit length = 2KiB = 2048B (dec)

Base view chunk length seems to vary around 0x2000 (+0x400 / -0x1000)
Last 2..3 base view chunks can be shorter.
Base view chunk length granularity seems to be 0x20 (=32dec = 64KiB),
except for the last chunk, there it seems to be 0x2 (= 4KiB).
P.S.: CARS_3_3D has 0x1 granularity.

Dependent View chunks come first.
3 of 4 3D-BDs have fixed dependent view chunk length.

Last 2..3 dependent view chunks can be shorter.
Dependent view chunk length granularity seems to be 0x20 (=32dec = 64KiB),
except for the last chunk, there it seems to be 0x2 (= 4KiB).
Last dependent chunk length granularity seems to be 0x2 (=4KiB)
P.S.: CARS_3_3D has 0x1 granularity.
---------------------------

Unknown Disc (see above)
Largest Stereoscopic Pair example Base 00005.m2ts + Dependent 00006.m2ts

Base View 00005.m2ts has variable chunk length range 0x1A40..0x2040 (6720..8256dec)
Dependent View 00006.m2ts has fixed chunk length 0xC60 (=3168dec)
-----------------------------

MIB_3_3D
Largest Stereoscopic Pair example Base 00342.m2ts + Dependent 00343.m2ts

Base View 00342.m2ts has variable chunk length range 0x1140..0x1920
Last 2 base view chunks can be shorter, here 0xE40, 0x13B6

Dependent View 00343.m2ts has fixed chunk length 0xC60 (=3168dec)
Last 2 dependent view chunks can be shorter, here 0x780, 0xA4A
------------------------------

RATATOUILLE_3D:
Largest Stereoscopic Pair example Base 01214.m2ts + Dependent 01255.m2ts

Base View 01214.m2ts has variable chunk length range 0x23A0..0x24C0
Last 2 base view chunks can be shorter, here 0x480, 0x9A8

Dependent View 01255.m2ts has fixed chunk length 0xA80
Last 2 dependent view chunks can be shorter, here 0x480, 0x9A8
-----------------------------

CARS_3_3D:
Largest Stereoscopic Pair example Base 01393.m2ts + Dependent 01429.m2ts

Base View 01393.m2ts has variable chunk length range 0x23A0..0x24C0
Last 3 base view chunks can be shorter, here 0x0F00, 0x1080, 0x24F3 -> Granularity 0x1

Dependent View 01429.m2ts has variable chunk length 0x780..0x900
Last 3 dependent view chunks can be shorter, here 0x320, 0x420, 0x7FE -> Granularity 0x1

[Rocky]

Thank you, Emulgator, for your data. It seems then that subs in the dependent stream are rare or maybe even practically nonexistent. So we'll ignore that for now.

[Sherman]

Hey Rocky! After I got back from 1935 last night (talking to Einstein of course and also Podolsky to ask why he misrepresented Einstein's argument in the famous EPR paper -- his answer is shocking!) I whipped up a function called DemuxMVC(filename, pid) to demux from a dependent M2TS file. It does not use any existing data structures so it could be launched as a thread and run simultaneously to the existing video demuxing. I tested it succesfully on the first M2TS in TOY_STORY_4_3D. That means I was able to serve the 3D with DGMVCDecode. The output is the same as from EAC3TO with the exception that I do not remove filler NALUs as EAC3TO does. It's not a big deal as the extra data is not that big. I did not want to have to parse at the video ES level, but just at the transport packet level. And hey, we should demux everything, not start arbitrarily deleting stuff that exists in the source. It's a demuxer, OK?

Still to do is to parse the playlist to detect 3D and get the names of the dependent M2TS files to pair with the main file list. It doesn't have to be a separate list but just another field of the existing file list. Then add code to launch the demux for each file while writing to one output file.

[Rocky]

Cool! Sounds like you have a good handle on things. Why don't you go ahead and finish off the rest?

[Sherman]

I'm on it! Will try to finish it off before heading back to meet Honoré de Balzac. Maybe a stop to meet Houdini as well.

[Sherman]

Hey Rocky! I got it all done and successfully demuxed TOY_STORY_4_3D and tested the resulting streams with DGMVCDecode(). Maybe you should give a test build before slipstreaming it.

[Rocky]

That's awesome Sherman. I'll release a test build as you suggest but first I want to have a peek at your code. You know what they say: Trust but verify!

What do you think Bullwinkle, has this kid earned his spurs?