BD3D2MK3D v1.17: Convert 3D BDs or MKV to 3D SBS, T&B or Frame-sequential MKV

[tebasuna51]

No problem, it was only to show the full info.

[tebasuna51]

Delay MakeMKV test.

I created with tsMuxeR a Bluray folder adding manualy a delay of 200 ms to a DTS-HD track.
The m2ts output have the delay included:
M2TS, 1 video track, 2 audio tracks, 3 subtitle tracks, 0:02:01, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: DTS Master Audio, Spanish, 5.1 channels, 16 bits, 48kHz, 200ms
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
3: DTS Master Audio, English, 5.1 channels, 16 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
4: Subtitle (PGS), Spanish
...

I used MakeMKV with defaults and the mkv generated preseve the delay:
MKV, 1 video track, 2 audio tracks, 3 subtitle tracks, 0:02:01, 24p /1.001
1: h264/MVC (right eye), English, 1080p24 /1.001 (16:9)
2: DTS Master Audio, Spanish, 5.1 channels, 16 bits, 48kHz, 200ms
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
"Surround 5.1"
3: DTS Master Audio, English, 5.1 channels, 16 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
"Surround 5.1"
4: Subtitle (PGS), Spanish
...

Then can exist "custom" BD's with positive delay.

When I try to add a negative delay (-200) in tsMuxeR, seems than work like mkvmerge, cut the first DTS frames (verified decoding the track) and add a positive remaining delay:
M2TS, 1 video track, 2 audio tracks, 3 subtitle tracks, 0:02:01, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: DTS Master Audio, Spanish, 5.1 channels, 16 bits, 48kHz, 2ms
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
...

I don't know if can exist "custom" BD's with negative delay, at least not using tsMuxeR.

[sneaker_ger]

Why do you need to demux the audio tracks in the first place?

[r0lZ]

To include them in the final MKV. ;-)

It is theoretically possible to use the original MKV to grab the streams, but that's not at all the current method used by BD3D2MK3D. It has to demux the audio streams from the BD (in BD mode) because it is too difficult to get them from multiple M2TS files (with seamless branching MPLS), and also to be able to convert them to AC3 if the user wants so. It is way too difficult for me to handle the BD and the MKV input modes totally differently. There are already enough differences to take into account. I can't add new difficulties, just to speed things up.

@tebasuna51:
Thanks for the test!

Can you show me the output of MkvMerge -F verbose-text -i INPUT.mkv ? Does it show the delay ?
And same question for the output shown by tsMuxeR INPUT.mkv

[EDIT] Never mind. I'll do the test myself.

[r0lZ]

AFAIK the only method is extract the timecodes of each audio track:
mkvextract timecodes_v2 INPUT.mkv 1:timecodes_1.txt
and read the second line of the txt:
# timecode format v2
200
210.666667
...
Here the delay of track 1 is 200 ms.
Indeed, the delay is not easy to retrieve. And I would like to avoid mkvextract, because it requires to save a big temp file on disc for each audio stream, and it takes ages to process the whole MKV file. I need only the first occurrence of the audio timecode, but I have no way to stop it to process the whole file. Also, currently, mkvextract is not included in the toolset, and I don't want to add it just for the delay problem.

Luckily, there is another solution. I can use mkvinfo --track-info (or -v) to output a lot of lines to stdout. And when I find a line with the following structure (for all audio tracks), I have found the delay, and I can kill mkvinfo:

| + SimpleBlock (key, track number 2, 8 frame(s), timecode 1.024s = 00:00:01.024)

That will certainly be much more rapid. And mkvinfo is already distributed with the toolset of BD3D2MK3D. :-)

Another solution would be to use the command-line version of MediaInfo, but it is not included in the toolset. However, that solution is so simple that I may be tempted to use it. ;-)

[r0lZ]

Here is a first beta with support for the MKV 3D input.

The source MKV file must have been created by MakeMKV (with the "Mpeg4-MVC-3D" video stream selected). Currently, the TrueHD audio tracks are ignored. I may add later a second demux pass to demux the THD track(s) with eac3to, but it's not yet implemented. Everything else should work as expected (including the audio delays), but remember that it's a beta! (Or should I say alpha?) It may have (and probably has) some bugs.

The program tries to find the info about the stereoscopy and 3D-Planes in the source 3D MKV, and should be ready when a new version of MakeMKV that include these fields/tags will be released, cut currently you will have to fill these values manually (in the first and second tab).

Please note that MkvMerge, MkvInfo and MkvPropEdit have been updated to the latest MkvToolnix version (v9.0.1), but that new version is NOT COMPATIBLE with the previous versions of BD3D2MK3D, because MkvInfo has a new --no-gui command line option that must be specified to use MkvInfo to grab the info from a MKV file. (Other tools, such as gMkvExtractGUI have the same problem.) So, after having tested the new beta, if you want to come back to v0.86, you will have to change the exes in the toolset folder, or restore the whole archive. It is not sufficient to simply overwrite BD3D2MK3D.exe ! (You can still download the latest stable version here: BD3D2MK3D.7z (stable) (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z))

This version fixes also the MKV compatibility option --engage no_simpleblocks. It was misspelled no_simpleblock, without the "s". (Thanks odyssey! And sorry. I forgot to fix this issue in v0.86.)


v0.87b1 (March 30, 2016)
- New possibility to open an interleaved 3D MKV file created by MakeMKV as input.
- Fix: The MKV compatibility option --engage no_simpleblocks was misspelled no_simpleblock
- Updated the MkvToolnix exes to the latest version (v9.0.1)

Download the beta: BD3D2MK3D_v0.87b1.7z [Link removed. Download the latest beta below.]

Please test the beta as far as possible. I have tested it with a few shorts, but I haven't much time to generate big MKV files with MakeMKV and then demux them, so my tests have been very limited. Please comment and report bugs and discrepancies here. Thanks!

[tebasuna51]

Thanks r0lZ.

I have now 2 BD's in my DD, one of them a custom JMBD with a extra audio track with a negative delay.
I'll make test with them.

[r0lZ]

... with a negative delay.How is it possible? My understanding of the delay is that the audio can start after the video, but not the opposite. :confused:

Anyway, the fact that the delay is negative should not be a problem for BD3D2MK3D, but I think that MkvMerge will cut the audio file when it will mux it.

[tebasuna51]

How is it possible?
I asked the authoring tool used to the author.

Anyway, the fact that the delay is negative should not be a problem for BD3D2MK3D, but I think that MkvMerge will cut the audio file when it will mux it.

Yep, is not a problem, I'm still checking some rounding differences but work fine.

--------------

A bug?

I'm pretty sure than I marked 'Left view in AVC stream', but in .avs:

# Current base view: right eye!
# The views are inverted: AVC stream = right view, MVC stream = left view.
right = SelectEven(interleaved)
left = SelectOdd(interleaved)

I attach the log's using the iso and the mkv from MakeMkv:

[r0lZ]

Oops, yes, there is a bug. The data are not correctly updated when the user ticks the option in tab 1, and the value -1 (meaning "undefined so far") is used instead of 0. I'll fix the bug asap...

[r0lZ]

OK, views order bug fixed.

I have also fixed another little bug. When a file from a BD was dropped over the main window (with tab 1 active), the BD was loaded, but without going to the BD input mode.
It is now also possible to drop a 3D MKV file over tab 1 to load it.

Download: [link removed]

[r0lZ]

Another bug fixed. tsMuxeR doesn't support meta files encoded in UTF-8, and crashed when there is a foreign or accented character in the filename of the input 3D MKV. Now, the meta file is saved in the encoding of the system. I hope that works in all cases, but at least that works with Latin European languages. If that doesn't work for you, you will have to rename the input 3D MKV file to remove all foreign characters and retry.

Download: [link removed]

[tebasuna51]

Thanks, downloaded b2.

How do you extract chapters from mkv?

With eac3to from mpls: 25 chapters
With mkvextract from mkv: 25 chapters
With BD3D2MK3D from iso: 26 chapters (one more at end like expected)
With BD3D2MK3D_beta from mkv: 21 chapters
Seems than lose 1 chapter each 5 (the 6, 11, 16, 21 and 26 from iso disappears)

EDIT: I don't see beta 3 but is not a problem for my test.

[tebasuna51]

With beta 2 avs problem solved, log is the same than beta 1.
The chapters problem remain.

[r0lZ]

I retrieve the chapters with tsMuxeR. And you're right. Some chapters were missing. That bug is fixed in beta 4.

Note that the additional chapter at the end of the movie can be removed just like with MakeMKV (if the last chapter is close enough to the end of the movie). See Settings -> Chapters.

Download: BD3D2MK3D_v0.87b4.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D_v0.87b4.7z)

[tebasuna51]

Thanks for the quick changes.

One last question about subtitles.

The .sup's extracted from mkv have little differences in PTS than the extracted from the iso, and always the DTS value to 0.
Is not a problem of tsMuxeR extraction because extracted with mkvextract have the same values.

Also there are differences between calculations converting sup to 3D-sup (like can be see in log's).
I not know if is a problem or not, because is out of my knowledge.
If is ok for you also for me.

I'll make now some test with my second BD.

[r0lZ]

Sorry to reply only now. This morning, I was blind, without internet!

I haven't noticed the PTS differences yet, but anyway, I use the same program (tsMuxeR) to demux the subtitles from the M2TS of the BD and from the 3D MKV, so I suppose it's not tsMuxeR's fault, and BD3D2MK3D is not responsible. I suppose the little differences are introduced by MakeMKV, perhaps because at some point, the PTS are converted to frame number, and then back to PTS? Anyway, when BDSup2Sub converts the subtitles, similar rounding problems happen. As long as the difference is less than one video frame, I don't care.

I know also that BDSup2Sub is totally wrong when it converts the SUP to XML/PNG. IIRC, the XML contains always the timings for 24 fps, regardless of the options you use during the conversion and the frame rate written in the XML. When the XML/PNG stream is converted back to SUP (or DVD SUB), it is necessary to specify that the frame rate must be converted from 23.976 to 23.976, or the timings are completely wrong. That conversions can introduce rounding problems, and finally a difference of one video frame, but IMO, for the subtitles, that doesn't matter much.

I will verify this when I'll have some time to do new tests, with long movies. But that may take some times. I'm currently working on the second demux pass for the TrueHD tracks...

[r0lZ]

Here is the latest beta. It can demux the TrueHD audio with eax3to (during a second demux pass). Of course, it's slow, but it's better than nothing. Again, there are probably some bugs...

Also, the current input mode (BD or MKV 3D) is now saved with the preferences, so that it will be used by default the next time you open BD3D2MK3D.

Download: BD3D2MK3D_v0.87b5.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D_v0.87b5.7z)

(I have not verified the PTS of the subtitles yet. I have to go now, but I should have some time tomorrow...)

[tebasuna51]

Ok, I know than little PTS differences in subs aren't important. We can forget that.

My test with my second BD work fine, all is the same using iso or mkv, with the know differences in sup's and chapters.

I'm check the chapters differences, and qpfile generated, and I see:

Time Time Time I-fra. I-fra I
Chapters Bad from mkv Ok from mpls Dif. mkv QP mpl QP Dif
--------- ------------ ------------ ---- ------ ------ ---
CHAPTER01 00:00:00.000 00:00:00.000 0
CHAPTER02 00:06:08.618 00:06:08.785 -167 8838 8842 - 4
CHAPTER03 00:12:20.406 00:12:20.490 - 84 17752 17754 - 2
CHAPTER04 00:17:30.591 00:17:30.591 0 25189 25189 0
CHAPTER05 00:23:51.054 00:23:51.180 -126 34311 34314 - 3
CHAPTER06 00:31:26.509 00:31:26.676 -167 45231 45235 - 4
CHAPTER07 00:35:54.485 00:35:54.486 - 1 51656 51656 0
CHAPTER08 00:42:29.421 00:42:29.547 -126 61125 61128 - 3
CHAPTER09 00:47:03.362 00:47:03.612 -250 67693 67699 - 6
CHAPTER10 00:53:16.318 00:53:16.318 0 76635 76635 0
CHAPTER11 00:59:12.632 00:59:12.716 - 84 85178 85180 - 2
CHAPTER12 01:04:38.040 01:04:38.041 - 1 92980 92980 0
CHAPTER13 01:08:32.108 01:08:32.108 0 98592 98592 0
CHAPTER14 01:14:22.416 01:14:22.416 0 106991 106991 0
CHAPTER15 01:21:03.483 01:21:03.609 -126 116607 116610 - 3
CHAPTER16 01:25:42.011 01:25:42.012 - 1 123285 123285 0
CHAPTER17 01:36:08.679 01:36:08.680 - 1 138310 138310 0
CHAPTER18 01:41:29.333 01:41:29.625 -292 145998 146005 - 7

Like I can't understand for what the differences I checked the I frames in video (must be the sames in mkv and mpls) and I discover than the I frames calculated with the mpls aren't always I frames in the video, but all calculated with the mkv chapters are I frames in video.

Then seems than MakeMKV correct chapters times to point real I frames in video, and the qpfile is better because point to real scene changes.

[r0lZ]

OK, thanks for the tests.

If I understand correctly, the chapters in the MKV are different than in the original BD, but they are better because they are perfectly aligned with the I-frames. Right?

For me, it's not necessarily a good point, because BD3D2MK3D creates an I-frame at the chapter point anyway (with the qpfile), but indeed, it MakeMKV sets it to a real scene change (which coincides with an I-frame almost always), it's good. It's less good if it chooses the I-frame immediately before or after the scene change.

Anyway, I have no way to modify the chapters myself. I can only trust the chapters in the MKV. I will just verify if the chapter timings are identical with all programs (tsMuxeR, eac3to, MkvMerge, MkvInfo and MediaInfo).

I may release the official v0.87 in a couple of days, if no new bugs are reported...

[tebasuna51]

If I understand correctly, the chapters in the MKV are different than in the original BD, but they are better because they are perfectly aligned with the I-frames. Right?

Correct.

I may release the official v0.87 in a couple of days, if no new bugs are reported...

We can't do more test until a new MakeMKV release, the actual beta key don't work after March 30.

[r0lZ]

I've seen that. And I have just accepted to start the evaluation period. I hope I haven't made a mistake, and that the evaluation period will be renewed with the next key.

I have already compared the output of several programs for the chapter points of the original BD.
It seems that eac3to removes automatically the last dummy chapter (near the end of the movie). tsMuxeR and MediaInfo keep it.
The 3 programs display only 3 decimals. Eac3to rounds the decimal part of the time code to the closest number. For example, it prints 00:16:35.203 for 44784114 ticks (at 45000th of a second), or exactly 995.2025333333333 seconds. tsMuxeR and MediaInfo round to the lower decimal: 00:16:35.202.
That rounding problems are very small and not really important, but I wonder who is right. Currently, when the input is a BD, BD3D2MK3D uses the same method than tsMuxeR and MediaInfo.
With the crazy NTSC frame rate, it is almost never possible to give an exact timing to point just to a specific frame. When the chapter point does not falls exactly on a frame, I don't know if MkvMerge stores the time code of the nearest, previous or next frame, or if it leaves the original chapter point untouched. That's important to select the best rounding method.

I will do other tests with 3D MKV files later. Currently, I must do other things...

[r0lZ]

I confirm that MakeMKV changes the chapter points. I'm not sure it puts them on I-frames, but indeed, most of the times, they are on a scene change. So, I don't worry about that, and anyway I can't restore the original timings.

Here is probably the last beta, unless someone finds a bug or makes an interesting suggestion.

Nothing really important has changed. Only some minor cosmetic changes, and the possibility to use the JPEG included in the MKV (if the original BD has an image in its metadata folder and if you have selected it in the MakeMKV GUI). If the Jpeg is present in the MKV, you can simply click the "From MKV" button in tab 4, and it will be displayed and loaded automatically. The "From MKV" buttons are disabled if there is no portrait or landscape image available.

Download: BD3D2MK3D_v0.87b6.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D_v0.87b6.7z)

[frank]

Originally Posted by r0lZ:
That rounding problems are very small and not really important, but I wonder who is right. Currently, when the input is a BD, BD3D2MK3D uses the same method than tsMuxeR and MediaInfo.
With the crazy NTSC frame rate, it is almost never possible to give an exact timing to point just to a specific frame.
It's very easy. You should round UP chapter points to ms. For years I cut manually to 3 digits after the decimal point and add 1 ms. Only with this chapter points in mkv the players (VLC, Potplayer) seek quick and properly! (catch the I-frame) Editors like TMPGEnc have the same behavior.
Mkvmerge stores time codes, not frames.

[r0lZ]

I know that MkvMerge stores the timecodes. It's the problem. Storing the frame numbers is much more precise, and there is no rounding problems.

If I understand correctly your method, it is equivalent to using ceil() instead of round(), since you add 1 ms. But there is an exception: when the time code falls perfectly on a precise frame. Using ceil() or round() or floor() in that case doesn't change the decimals. But you add 1 ms anyway, and the timecode is therefore 1 ms after the frame. Hence my question: why do you use round() + 1ms? IMO, it is preferable to use ceil().

[r0lZ]

Here is the final release of v0.87. In the last beta, MkvExtract (necessary to extract the JPEG from the 3D-MKV) was missing from the toolset. It is now included. And the MkvToolnix exes have been updated to the latest version. They are the only notable changes with this version.


v0.87 (April 4, 2016)
- New possibility to open an interleaved 3D MKV file created by MakeMKV as input.
- Fix: The MKV compatibility option --engage no_simpleblocks was misspelled no_simpleblock
- Since MkvExtract is needed to retrieve the attachment from the 3D MKV input file, it is now included in the toolset.
- Updated the MkvToolnix exes to the latest version (v9.0.1)

[tebasuna51]

When I decompress your v0.87 final in a empty folder (without BD3D2MK3D.cfg) and I try to change any settings I have a crash:

can't read "::config(initialmkvdir)": no such element in array
while executing
"list $::config(initialmkvdir)"
(procedure "SaveSettings" line 175)
invoked from within...

And don't work 'Save settings now' or 'Save settings on Exit', the file BD3D2MK3D.cfg is never writed to disk.
Even without change anything the .cfg is not created.
The "invoked from" procedures may vary but always crash.

With a BD3D2MK3D.cfg from stable v0.85 the same problem.
But I copied a BD3D2MK3D.cfg from a previous v0.87beta and now work without crash. Seems than beta versions can write new elements in .cfg but stable crash.

[frank]

Originally Posted by r0lZ:Hence my question: why do you use round() + 1ms? IMO, it is preferable to use ceil(). The players read the timecode, converting to frames by division and rounding wrong. It's a game to reach the right chapter point (I-frame). But if you add 1 ms or some more ms the results are good. (The next frame follows 42ms later...). You are right with ceil() but I edit the chapters_ogm.txt manually, and that sucks a lot.

One exception: PAL (25 fps, 50 fps)
No chapter manipulation required, because all time codes are perfectly straight. But 3D with PAL fps is no standard.

[r0lZ]

When I decompress your v0.87 final in a empty folder (without BD3D2MK3D.cfg) and I try to change any settings I have a crash:

can't read "::config(initialmkvdir)": no such element in array
while executing
"list $::config(initialmkvdir)"
(procedure "SaveSettings" line 175)
invoked from within...

And don't work 'Save settings now' or 'Save settings on Exit', the file BD3D2MK3D.cfg is never writed to disk.
Even without change anything the .cfg is not created.
The "invoked from" procedures may vary but always crash.

With a BD3D2MK3D.cfg from stable v0.85 the same problem.
But I copied a BD3D2MK3D.cfg from a previous v0.87beta and now work without crash. Seems than beta versions can write new elements in .cfg but stable crash.
Oops, yes! It's a bug in all beta of v0.87, but if you load a 3D-MKV first, it is possible to save the settings. It's only if you delete the cfg file and do not open a MKV that the settings cannot be saved.

Anyway, here is v0.87.1, that fixes that bug.

v0.87.1 (April 4, 2016)
- Bug fix: Impossible to save the settings due to missing ::config(initialmkvdir)

Download: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

[r0lZ]

The players read the timecode, converting to frames by division and rounding wrong. It's a game to reach the right chapter point (I-frame). But if you add 1 ms or some more ms the results are good. (The next frame follows 42ms later...). You are right with ceil() but I edit the chapters_ogm.txt manually, and that sucks a lot.So, in your experience, most players find and use the I-frame that is just before the timecode of the chapter point. Seems logical, since the player has to decode the I-frame to play the frame (more or less) referenced by the timecode. If the chapter point is not an I-frame, the player must go back to find the previous I-frame, and it should never try to find it right after the timecode.

I will verify my code and change it if necessary for the next version.

One exception: PAL (25 fps, 50 fps)
No chapter manipulation required, because all time codes are perfectly straight. But 3D with PAL fps is no standard.
Yes, and I don't understand why the specs of the blu-ray support the incredibly stupid NTSC-Film timecode. At the time of the invension of the NTSC TV, the synchronisation has been based on the frequency of the AC power. Hence the terrible 29.97 frame rate, and the associated drop/non-drop frames nightmare! But in the 21st century, there is absolutely no good reason to use the AC frequency any more and the NTSC-Video frame rate, except for old videos shots at the time of the NTSC TV. I can understand why 29.97 must still be supported by the modern players, but that should be reserved exclusively to old material, difficult to convert to 24fps.

But why they have invented the terrible NTSC-Film frame rate, and made it the universal standard for the whole world is absolutely incredible. The film rate is 24fps (or 48fps) and nothing else. Now, all modern TVs and BD players are capable of playing any video at that frame rate. Due to the imbecility of the designers, the whole world will still have to support the impossibility to build easily a good time code during a big part of the 21st century. It's probably the most stupid idea of the "experts" who have defined the BD specs. I want to kill them! :angry:

[sneaker_ger]

Exact 24.000 Hz would not solve the problem because 1000ms/24 = 41,666....ms. It would not be exact in mkv either.

[tebasuna51]

Thanks r0lZ.

We can't do more test until a new MakeMKV release, the actual beta key don't work after March 30.

Still without a new MakeMKV release to test, but there are a new beta key (http://www.makemkv.com/forum2/viewtopic.php?f=5&t=1053) than work until end of May 2016.

[r0lZ]

Exact 24.000 Hz would not solve the problem because 1000ms/24 = 41,666....ms. It would not be exact in mkv either.The clock of a modern player runs typically at 90000 or 45000 Hz (it's 45000 for the BD players). But you are right for the time codes. It's why, in all pro studios, edits are always made at 24 or 25fps, with timecodes in the form HH:MM:SS:ff, where ff is a number of frames, not a fraction of a second. The conversion to the NTSC frame rate is always made when all edits are finished, and there is no need to use precise time codes any more... except for the chapter points of the BDs or DVDs.

[r0lZ]

Thanks r0lZ.

Still without a new MakeMKV release to test, but there are a new beta key (http://www.makemkv.com/forum2/viewtopic.php?f=5&t=1053) than work until end of May 2016.
Yep, I've seen that. Anyway, if the suggestions you did to implement the 3D-Plane info in the form of the "3d-plane" tag is implemented, and if they implement also the MKV stereoscopy, there is theoretically nothing to change in BD3D2MK3D. It can already recognise that info, if it is present.

BTW, please let me know when a new version of MakeMKV will be available. Since I don't use it personally, I may miss it.

[Tenker]

@r0lZ

Thank you for your Super Software.

I use them since a long time for my Amazon Fire TV box -> Kodi.

Now I in for the Atmos sound on the Nvidia Shild TV box and unfortunately I have found that the 3D movies I play with the software BD3D2MK3D than 2D.

So all movies run properly as 3D

http://www2.pic-upload.de/thumb/30255439/Alice.jpg (http://www.pic-upload.de/view-30255439/Alice.jpg.html)

My 3D movies that I converted with the software BD3D2MK3D

http://www2.pic-upload.de/thumb/30255438/Avatar.jpg (http://www.pic-upload.de/view-30255438/Avatar.jpg.html)


What should I change the settings so that a 3D mkv is created?
Can I save my "old" 3D movies somehow and change the header MKVs something with MKVExtractGUI2?

Thanks for your help
Tenker

[r0lZ]

Hum, I'm not sure I understand. All files created by BD3D2MK3D are in 3D (unless you launch one of the *_2D_*.cmd files in the project directory).

The first picture in your post is what a 3D-aware player should NEVER show. It's not 3D nor 2D. Just junk. The second picture looks correct, but with a still frame, I cannot see if it is in 3D or 2D.

IMO, your player simply recognises the 3D file extension or the stereoscopy field of the MKV container, or the frame-packing field of the h264 stream. It's normal and expected. Often, the 3D movies downloaded from the internet do not have the correct flags and are played as 2D movies, with the two views side by side or stacked vertically (like in your first image). That's the incorrect behaviour.

Since nVidia knows the 3D, I suppose that it does its job correctly, and shows you the movie in 3D (and you need the glasses), or it detects that the 3D hardware is not present or not ready and shows you the movie in 2D (only one view). If it's not what you want, you should configure it to output exactly what you need. I don't recommend to remove the 3D flags from your movies, since they are correct and useful in most situations. It's the configuration of your hardware that is incorrect.

To reply to your question, you can change the file extension (like 3D-abq or 3D-HSBS) if you have selected the option to use one of them in Settings -> Output File Name -> 3D Format Extension.

If it's not sufficient, you can also change the stereoscopy field of the MKV container with the "header editor" (a part of the MkvToolnix GUI). Select the "Edit Headers" option in the left pane, load the MKV, expand the Video track and change the "Video stereo mode" at the bottom of the list to 0 (or simply tick the "Remove element" option). Finally, use the Header Editor -> Save menu to save the change. There is no need to remux everything.

The third way to flag the movie as 3D is the frame-packing mode of the h264 video stream. Unfortunately, afaik it is impossible to change that field without re-encoding the video. (BTW, it's that flag that is used with the 3D videos on Youtube to identify them as 3D.) If you don't want to include that field in your future conversions with BD3D2MK3D, you should edit __ENCODE_3D.cmd and temove the --frame-packing N argument in the x264 command. (N is a number depending of the Half/Full-SBS/T&B/Frame-Sequential mode).

I repeat that it is absurd to remove the 3D identifiers. A 3D movie must be flagged as 3D, to help the players recognise automatically the right format. It's the player that you must configure correctly. If you remove the 3D flags now, you will probably regret having done it later.

[Tenker]

Thank you for your quick and detailed response.

I must apologize for my English because I translate the German text on GOOGLE in English.


My Amazon Fire TV + Kodi always plays ALL 3D movies / MKVs so on:
- After starting the picture on my Samsung JU7090 is divided, as in the first image = "Alice.jpg"
- Then I have to change the image on the TV to 3D via remote control
- Then 3D glasses on the nose and one can enjoy the 3D image

My nVidia Shild TV Box + Kodi (same settings) shows 30% of my 3D MKVs so as in the picture "Avator.jpg". The picture shows a still image, looks as 2D and is also as sharp as any 2D movie. The 3D switching on TV makes the picture just so twisted, that can be seen only parts of it.

All my 3D MKVs also have the right 3D header as
1: Side by Side (left eye is first)
3: top-bottom (left eye is first)
The Avatar 3D film is also known as 3D about my Amazon Fire TV box, just as I have described above.

Does anyone test an nVidia Shield TV Box + Kodi to that?

[r0lZ]

OK, so the problem is that your nVidia shield interprets the movie as 3D (as it should) and send probably 3D frames to kodi. You want it to ignore the 3D and send a 2D SBS picture, and let kodi switch to 3D. Unfortunately, what you want is very bizare. You have bought a 3D equipment (the nVidia) but you want it to ignore the 3D! It's not the ideal situation! It's why only the 3D movies badly encoded without the 3D flags work as you want.

You should first look in the settings of the nVidia. You will be lucky if there is an option to ignore the 3D and treat the movie as standard 2D. On most TV and hardware players, it is possible to turn the 3D off, but unfortunately, if the TV recognises the movie as 3D due to one of its extension or flags, it will probably switch to a pure 2D mode, and show you only a single view, not the double SBS image. It's what it does now, if I understand correctly. You should explain to the nVidia that it must ignore the 3D nature of the source. It's not the same thing that recognising the 3D but turning it off. If you cannot find a way to do it, you should try to remove the stereoscopy value from the MKV container, as I've explained above. Honestly, I don't think that will be sufficient, because usually the hardware players ignore that flag anyway, and obey only the frame-packing mode in the h264 stream. And that flag cannot be changed.

Perhaps you can also try to configure the nvidia to send frame sequential 3D, just like a 3D BD player does. If that's possible, the nVidia will convert the SBS to full frames, and send them at 47.952 fps to kodi, and you will have to configure kodi to interpret them as frame sequential 3D, like the output of a 3DBD player. I don't know if it's possible.

Unfortunately, I can't help much more, because I don't know your hardware. Good luck!

[kevbo]

Hello, and thanks for this great program! I'm using it to create 3D movies to view on Google Cardboard, and it is awesome.

I'm a bit confused about the "Convert DTS & LPCM audio tracks to..." option on page 2. (I'm using 0.86, I haven't messed around with the 0.87 betas yet.) Actually, the option is clear, and it does exactly what it says it does.

The thing is, for this use case (make the movie 720p and small so it can be moved to a small device), I also want Dolby Digital and/or TrueHD audio to be converted to AAC as well. I want to get the audio as small as possible while still sounding OK.

I understand that maybe part of this is the whole AC3+THD file problem that you've been working on, but is there any way to make that option more of a "convert all audio to AAC/AC3"?

I know how to do it by hand with eac3to and mkvmerge, it would just be handy if it happened within the tool.

Thanks!

[r0lZ]

I understand. In fact, in older versions, it was not possible to convert to AAC. Only to AC3. And therefore, it did not make sense to convert the TrueHD and DD+ to AC3, because ticking the option to use only the 5.1 (pseudo) core had the same effect, without the quality loss of the re-encode operation. I have added the possibility to convert to AAC later, but I haven't changed the logic. You are right. It makes sense to convert any input audio format to AAC, although converting THD and DD+ to AC3 should still be forbidden. I will see if I can easily change my code to allow that. Thanks for the suggestion.

And the problem of the AC3+THD is not related to the conversion. The problem was that tsMuseR is unable to demux the THD tracks (without the AC3 pseudo-core) muxed in 3D-MKV files by MakeMKV. tsMuxeR can demux THD+AC3 tracks from the BD without problem, but not when the core has been stripped out by MakeMKV. Anyway, the problem is solved in v0.87 final. When a THD-only track must be demuxed from a MKV, a second demux pass is done, with eac3to instead of tsMuxeR. (eac3to can demux all audio streams, but has problems when demuxing the subtitles from many 3D BDs, so I have to use the two demuxers, for what they can do.)

I think that it will be possible to convert any stream to AAC with the next version, but be patient. I can't release it rapidly...

[kevbo]

Well, great! I was actually a bit concerned that I just didn't understand something and that I was asking a stupid question. :)

Is there any way for the GUI to remember settings like that? To set those checkboxes to the same setting as you chose last time? (The other one that would be handy is the "720p" option on page 5.)

Thanks again for this fine program! I'm excited about the MKV option, because then I can move the ISO images to MKV files!

Kevin

[r0lZ]

Is there any way for the GUI to remember settings like that? To set those checkboxes to the same setting as you chose last time? (The other one that would be handy is the "720p" option on page 5.)
The settings from the Settings menu are saved immediately, as you change them. The configuration of the pages 2 and 5 (or at least the settings that are not BD dependent), including the audio conversion and the 720p options, are saved with "Save Settings Now", at the bottom of the Settings menu. They are also automatically saved when BD3D2MK3D is closed if you have ticked the option "Save Settings on Exit".

[Triple-M]

First, sorry for my English, if something ist wrong...

I found your App and it it's really great. I have some 3D-MKV Files, made with makeMKV and i want your Tool to convert them into the right 3D-MKV-Format.

Can you or someone else tell me or show me where i can find the Info what i should select "Left View in AVC Stream" or "Right View in AVC Stream" to convert the File correctly? Can i find the Info in tsmuxer GUI when i open die 3D-MKV File made with makeMKV? But where?

Same question with the 3D-Plane Option.

Thanks a lot....

Triple-M

[r0lZ]

Welcome to the Doom9 forums, Triple-M !

Unfortunately, currently, it is not possible to find the information about the views order and the 3D-planes in the 3D-MKV file. If that was possible, BD3D2MK3D would retrieve it for you. We have asked the authors of MakeMKV to add that information in the file, and we hope that the next version of MakeMKV will correctly set the stereoscopy mode in the MKV header and will implement tags for the 3D-planes. When that will be the case, BD3D2MK3D should be able to recognise the info, and you will not see the red warnings any more.

In the meantime, the only way to retrieve the info is by examining the original BD3D, with BD3D2MK3D or with tsMuxeR. When you load a BD in BD3D2MK3D, you can see something like this:

Video : Und AVC, 1080p, 23.976 fps, left-eye
Video : Und MVC, 1080p, 23.976 fps, right-eye (32 3D-Planes)
Audio : Eng TrueHD, Multi-channel, 48/96 Khz
Audio : Fra TrueHD, Multi-channel, 48/96 Khz
Subtitle: Eng PGS, 3D-plane: 1
Subtitle: Fra PGS, 3D-plane: 2
Subtitle: Esp PGS, 3D-plane: 3

Here, the views are in the common order (AVC = left view). Note that most players assume the "Left view in AVC" order, because about 90% of the 3DBDs are authored that way. If you need to swap the views on your TV or with your software player to see the 3D correctly, the views are in the opposite order: Right view in AVC. It is therefore probably easy to find the correct view order with Stereoscopic Player.


Things are very different for the 3D-Planes. In many BDs, the order of the subtitle streams determine the 3D-Planes numbers, like in the example above. But note that the first 3D-Plane is 3D-Plane #0. Here, the plane #0 is not used, and the first subtitle stream is associated with the second 3D-Plane, #1. The rest is logical. Unfortunately, there is no well established rule for the assignment of the 3D-Planes. The 3D-Plane #0 may or may not be used, and the order of the 3D-Planes may or may not be sequential. It is therefore almost impossible to deduce the 3D-Plane to use without examining the BD.

However, it is possible to use a good 3D-Plane without knowing the original assignment. Here is how.

You should try to assign a number that *may* be correct, and let BD3D2MK3D create the project. When the project is finished, you will find the 3D-Planes in the project directory, and the subtitle streams you have converted in XML/PNG format in sub-directories with names similar to this: 00801.track_4610.Fra.3D_2D. Now, use Subtitle Tools -> Verify 3D-Planes Compatibility. In the dialog, select the temp_2D.xml file of the subtitle stream, and the project directory containing the 3D-Planes (such as "...\Movie title\00000"). The tool will create a log file similar to this:

Validity of the 3D-planes from directory "E:\BD3D2MK3D_projects\Test\00801"
with the subtitle file "E:\BD3D2MK3D_projects\Test\00801\00801.track_4610.Fra.3D_2D\temp_2D.xml".
Frame rate used: 23.976023976023978 fps
Processing all subtitles (normal and forced).

Total number of subtitles: 1431

3D-Plane-00.ofs:
0 subtitles with totally undefined depth.
0 subtitles with partially undefined depth.
Subtitle frames with undefined depths: 0
(Depth values for current subtitle stream: Min=16, Max=16, Average=16.0)
*** WARNING: Fixed depth 16! ***

3D-Plane-01.ofs:
0 subtitles with totally undefined depth.
0 subtitles with partially undefined depth.
Subtitle frames with undefined depths: 0
(Depth values for current subtitle stream: Min=16, Max=16, Average=16.0)
*** WARNING: Fixed depth 16! ***

3D-Plane-02.ofs:
8 subtitles with totally undefined depth.
12 subtitles with partially undefined depth.
Subtitle frames with undefined depths: 602
(Depth values for current subtitle stream: Min=-8, Max=70, Average=19.379)

3D-Plane-03.ofs:
3 subtitles with totally undefined depth.
1 subtitles with partially undefined depth.
Subtitle frames with undefined depths: 206
(Depth values for current subtitle stream: Min=-6, Max=72, Average=18.454)

3D-Plane-04.ofs:
2 subtitles with totally undefined depth.
0 subtitles with partially undefined depth.
Subtitle frames with undefined depths: 46
(Depth values for current subtitle stream: Min=-6, Max=72, Average=19.118)

3D-Plane-05.ofs:
3 subtitles with totally undefined depth.
1 subtitles with partially undefined depth.
Subtitle frames with undefined depths: 206
(Depth values for current subtitle stream: Min=-6, Max=72, Average=18.446)

3D-Plane-06.ofs:
3 subtitles with totally undefined depth.
1 subtitles with partially undefined depth.
Subtitle frames with undefined depths: 206
(Depth values for current subtitle stream: Min=-6, Max=72, Average=19.667)

3D-Plane-07.ofs:
1 subtitles with totally undefined depth.
0 subtitles with partially undefined depth.
Subtitle frames with undefined depths: 78
(Depth values for current subtitle stream: Min=-6, Max=72, Average=19.222)

3D-Plane-08.ofs:
4 subtitles with totally undefined depth.
0 subtitles with partially undefined depth.
Subtitle frames with undefined depths: 149
(Depth values for current subtitle stream: Min=-6, Max=72, Average=18.442)

Notes:
The depth of any particular subtitle may be undefined for several reasons.
The 3D-plane may contain undefined depth values for some or all frames of a particular subtitle. When it's the case, BD3D2MK3D ignores the undefined frames, and takes into account only the frames with a valid depth.
The 3D-plane may be too short, and therefore it may not contain sufficient depth values to cover the subtitles appearing near the end of the movie. In that case, BD3D2MK3D uses a depth value of 0.

When a subtitle file is converted to 3D, the temp_2D.xml file is generated and modified to include the <Depth> tags extracted from the selected 3D-plane file. (The Additional Depth value specified in the GUI is NOT added to that value.)
In addition to the <depth> tags, the <UndefinedFrameDepths> tag is added as well when there is at least one frame with an undefined depth for that specific subtitle. The value of that tag is the number of frames without a valid depth for that specific subtitle.
You can search for "UndefinedFrameDepths" in the XML file to easily find all subtitles that may not have a correct depth value.
The depth values that will be used during the conversion of the temp_2D file to the final 3D subtitle file are stored in the <Depth> tags and can be edited manually when necessary.

Terminology used in this log:
* Subtitles with totally undefined depth: When the depth values of ALL frames of a particular subtitle are undefined.
* Subtitles with partially undefined depth: When the depth values of SOME frames of a particular subtitle are undefined.
* Subtitle frames with undefined depths: Total number of all frames where a subtitle must be displayed with an undefined depths.
* Min, Max and Average depth values for current subtitle stream: The smaller, greater and average depth values found in the 3D-plane in the frames during which a subtitle is displayed. The undefined frames are not taken into account. (See the 3D-plane log file generated during the extraction of the 3D-plane files from the MVC stream to see the global min, max and average depths.)
* Fixed depth warning: That warning is added when all frames during which a subtitle is displayed have exactly the same depth value. (Again, the undefined depth are not taken into account.) That means that the 3D-plane is probably fake or badly authored, and is useless anyway.

As you can see, the first 3D-Planes have a fixed depth. You should avoid them.

In the other 3D-Planes, look at the numbers of subtitles with totally undefined depth, subtitles with partially undefined depth, and subtitle frames with undefined depths. The lower the best. Therefore, the 3D-Planes #4 and #7 seem to be the best for the subtitle stream that has been analysed. They are good bets. In fact, with this BD, the French subtitles use the 3D-Plane #4. It has good values. As you can see, there is no perfect way to determine the correct 3D-Plane, but the tool can help you in finding a good one.

Now, if the "good" 3D-Plane is not the one you have selected when you have generated the project, you can simply convert the 2D XML/PNG stream to 3D again with Subtitle tools -> Convert Subtitles to 3D, and of course use the new 3D-Plane. You can overwrite the original 3D SUP (or SUB) file created by BD3D2MK3D, or save the new subtitle under a different name and modify the filename of the streams in the __MUX_3D_OPTIONS.txt file.

Finally, launch the encoding of the final SBS or T&B file, and verify carefully the subtitles. It they look wrong, try with another stream. You don't need to re-encode the video (unless you hardcode the subtitles on the video). Just use the __MUX.3D.cmd to re-create the final MKV with the new 3D subtitles.

Good luck!

[Triple-M]

Thank You.

When i load a BD with BD3D2MK3D i see a list of how you described. In my Case the AVC Stream is also left, now i unsterstand.

But what you've written about the 3D-Planes sounds very complicated. Is all this also important if i only used forced subtitles?

[r0lZ]

Yes, it's important too. The correct depths of the individual subtitles depend of the 3D-Plane, and if you select a wrong 3D-Plane, you may have some subtitles entering within the foreground objects. It's terrible for the brain! Of course, if there are only a few forced subtitles, the risk of bad depths is less important, but that doesn't mean that you can ignore it.

Don't worry. The method to determine a correct 3D-Plane looks complicated, but it is not. The Verify 3D-Planes Compatibility tool can be used to verify if the 3D-Plane you have selected in tab 2 was correct or totally wrong. In the second case, you can find a good one easily with the tool, and convert the 2D stream to 3D manually. That's really not difficult. Try to do it, and you'll see.

[r0lZ]

I'm working on the processing of the audio by BD3D2MK3D (to allow the user to convert the AC3, THD and EAC3 streams to AAC too), and I verify if it works correctly in MKV-3D input mode too. And I have a problem !

I use a short movie with an E-AC3 (DD+) track to do my tests. When I demux the E-AC3 track from the BD with tsMuxeR or eac3to (without the option to keep only the core), I get a file of 19,961 KB. When I retrieve only the core, the file size is 11,406 KB. MediaInfo recognises the files correctly as AC3+ or AC3. So far so good.

But when I convert the movie to 3D-MKV with MakeMKV and I ask to keep the whole AC3+ file and the AC3 core, it creates two streams in the MKV container: the AC3+ and the AC3. That seems correct. But when the AC3+ stream is extracted with tsMuxeR (without the core option), its size is only 8,555 KB. (The size of the AC3 stream is correctly 11,406 KB.) And MediaInfo doesn't recognise the AC3+ stream it at all. It prints only its file size.

Demuxing the same stream from the 3D-MKV with eac3to gives the same result, but it prints an error message:

MKV, 1 video track, 5 audio tracks, 0:03:02, 24p /1.001
1: h264/MVC (right eye), English, 1080p24 /1.001 (16:9)
2: TrueHD, English, 7.1 channels, 48kHz
"Surround 7.1"
3: AC3, English, 5.1 channels, 640kbps, 48kHz
"Surround 5.1"
4: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
"Stereo"
5: EAC3, French, 2/2 channels, 48kHz
"Surround 4.0"
6: AC3, French, 5.1 channels, 512kbps, 48kHz
"Surround 5.1"
Bitstream parsing for track 5 failed.
Demuxing this track may still produce correct results - or not.
a05 Extracting audio track number 5...
a05 Creating file "test.eac3"...
Video track 1 contains 4375 frames.
eac3to processing took 6 seconds.
Done.

Since 11,406 KB + 8,555 KB = 19,961 KB, it seems that MakeMKV extracts the non-core part of the original AC3+ stream and stores it as a full AC3+ stream in the 3D-MKV.

I don't understand why it does that. Does it make sense to store the AC3+ stream without its core? AFAIK, the "+" extension cannot be decoded without the core. Correct?

Is it a known bug of MakeMKV ? If it's the case, should BD3D2MK3D prohibit to use the AC3+ streams from a 3D-MKV container created by MakeMKV ? Or should we report that bug to the MakeMKV staff ?

Thanks in advance if someone can help me understand that mess!

[Triple-M]

I tried my luck and opened a 3D-BD in BD3D2MK3D to see which Stream i must select. The encoding is completed without an error after 3 hours but the merged MKV File is only 5GB large. This can't be right or?
The MKV File from makeMKV is 30GB large. Where ist the mistake?

[sneaker_ger]

MakeMKV only copies the streams from the BluRay. BD3D2MK3D re-compresses the MVC stream to a different format so the file size can change dramatically. You cannot convert from MVC to Side by Side or Top & Bottom without re-encoding. If you think the resulting quality is too low for your taste you can decrease the CRF value. Then the files will come out bigger and with better quality.

[Triple-M]

Ok, i thought thats the encoder option which ist not right but what kind of attitude ist right for the best video quality? CRF 0? Or CQ, 2-pass or ABR?
Like I said I want the best possible quality, equal to the Bitrate of the BD or the 3D-MKV File from makeMKV.