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

[tebasuna51]

Originally Posted by r0lZ

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

[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]

Originally Posted by 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.

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

[r0lZ]

Originally Posted by frank

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.

Originally Posted by frank

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!

[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.

Originally Posted by tebasuna51

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 than work until end of May 2016.

[r0lZ]

Originally Posted by 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.

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]

Originally Posted by tebasuna51

Thanks r0lZ.

Still without a new MakeMKV release to test, but there are a new beta key 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



My 3D movies that I converted with the software BD3D2MK3D




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...