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

[r0lZ]

Damn ! Of course. It's due to the bug I have reported previously. When BD3D2MK3D checks your versions of AviSynth, it doesn't understand correctly that no 64-bit version is installed. Although it "thinks" that you have an unsupported 64-bit version installed, it tries to use it anyway, and it loads the 64-bit plugins. Therefore, I was wrong when I wrote that the bug should have no impact on the creation of the project.

I will release a new version as soon as possible...

Thanks for pointing this out, tebasuna51 !

[r0lZ]

Originally Posted by bottom

• First of all sorry, the orginal error I got is:

(...)
      avs [error]: failed to load avisynth
      x264 [error]: could not open input file `__ENCODE_3D_MOVIE.avs'

Yes, sorry for that. As explained above, the problem is that BD3D2MK3D thinks that you have a 64-bit version of AviSynth installed on your computer (although it doesn't recognise AviSynth+ 64-bit). Therefore, it generates the AVS script fo 64-bit, and that produces the error you got.

I will immediately release a new version without that bug. In the meantime, if you want to encode your project without regenerating it with the new version, you can install AviSynth+ 64-bit (and optionally also 32-bit). Then, relaunch __ENVODE_3D_LAUNCHER.cmd, and everything should work fine.

Thanks anyway for the bug report. You have found an important bug !

[r0lZ]

And here is the fix.

v1.14 (September 29, 2019)
- Fixed the bug introduced in v1.12: The AVS script was generated for AviSynth 64-bit when no 64-bit version of AviSynth was installed.

Download: BD3D2MK3D.7z

[bottom]

Thank you for the Quick-Fix!!!

... and it was mainly my fault for posting the wrong error message:
Avisynth was found, but couldn't be started / loaded correctly.

Thus I sent you all in the wrong direction ... sorry, again!

[marsdust]

With AviSynth+ installed can't seem to encode with x265 with v1.14. Selecting from menu still shows x264 options in the GUI? The generated job is x264 regardless also.

[r0lZ]

Damn ! You're right ! I'll fix that tomorrow...

[r0lZ]

OK, here is the fix. As always, that was a stupid bug ! Thanks for pointing it out, marsdust, and welcome to the Doom9 forums.

v1.15 (October 6, 2019)
- Important bug introduced in v1.12 fixed: The option of the Settings -> AVC/HEVC Encoder to encode in HEVC with x265 did not change the encoder.
- Renamed the __CUSTOM_* files generated when the user has defined a custom encoding command to _CUSTOM_* (with only a single leading "_") so that they appear in the directory after the regular files to encode with x264 or x265.

Download: BD3D2MK3D.7z

[marsdust]

That's fantastic. Just tested encoding x265 with Full SBS and working wonderfully. Though had to change the display width manually to 1920x1080 in MakeMKVToolNix but might be my TV not liking 3840x1080. Thanks again!

[frank]

And where you look your encodes? On PC only?
3D stereo is not certified for HEVC / x265.
Is there any TV or beamer that can show 3D SBS/TAB encoded in HEVC?

I only know Google Cardboard V2 apps use HEVC or V8 webm.

[r0lZ]

Originally Posted by marsdust

That's fantastic. Just tested encoding x265 with Full SBS and working wonderfully. Though had to change the display width manually to 1920x1080 in MakeMKVToolNix but might be my TV not liking 3840x1080. Thanks again!

Thanks for your enthusiasm !

You can change the aspect ratio to "16:9 for both" in Settings -> Full-SBS/T&B aspect ratio", so you don't have to modify manually the display width (another way to specify the AR). Some TVs (for example LG) require that value.

[r0lZ]

Originally Posted by frank

And where you look your encodes? On PC only?
3D stereo is not certified for HEVC / x265.
Is there any TV or beamer that can show 3D SBS/TAB encoded in HEVC?

I only know Google Cardboard V2 apps use HEVC or V8 webm.

I think you are partially right. It is true that a 3D movie is supposed to be encoded in AVC (as well as with other constraints like the 16:9 aspect ratio). Also, x265 has no --frame-packing argument, and that means that many TVs will not recognize automatically the 3D format of the movie, and you will have to use the 3D button of your remote when the playback starts. But I think that most UHD TVs support HEVC, for 2D and therefore also for 3D. I don't think they want to prohibit playing a 3D HEVC movie just because it's not the standard.

Of course, for a better compatibility and for the ease of use, x264 is the preferred encoder, and it is and will stay the default in BD3D2MK3D.

Anyway, your remark is interesting. Someone can confirm if his TV supports 3D HEVC, or not ?

[marsdust]

I'm backing up my 3D collection to NAS and save time in the long run not getting out my chair and flipping discs. Many are straight backups via MakeMKV and thus can use Framepacking (preferred) but take up a lot of space.

So just re-encode some of the titles that would not play that much to reduce space, get good compression results with x265 (tolerate 12fps encode times). So since already breaking a spec may as well go full SBS and take advantage of the efficiency of the encoder at 3840x1080 as not constrained by the shiny disc spec.

Plasma TV detects the 3D signal fine and so does the DLP Projector. So although the Framepacked version is better (40GB) on the projector (100ft) the 8GB Full SBS is 95% there. And 3D films are generally clean anyway. Half SBS is not as good on the Projector but appreciate smaller screens would not matter so much and x264 would be fine.

Using a Vero 4K+ (testing the Framepacked beta) and also a $25 x96 mini plays them fine also (the encodes, as x96 does not do Framepacked).

[konikpolny]

Hi r0lZ,
why does BD3D2MK3D create a project with 2 different files eg.
00098.track_4608.Eng.2D.sup and
00098.track_4608.Eng.sup
for the same 2D subtitles? I always thought they are identical but I noticed their filesize is different.

[staina]

With the help of tsMuxer I'm yourself created ISO files with main 3D movie and selected audio and subtitles streams and now I'm found out with the help of BD3D2MK3D that the some that's how created files have assigned other 3D-plane than original 3D Bluray.

I can apply these created ISO files in tsMuxer and set for subtitles streams correct 3D-plane and recreate new ISO files and or I have to for creation apply original 3D Bluray?

For example:

Original Bluray in BD3D2MK3D

1. subtitle stream ENG - 3D-Planes 1
2. subtitle stream JPN - 3D-Planes 6
3. subtitle stream TUR - 3D-Planes 2
4. subtitle stream RUS - 3D-Planes 3
5. subtitle stream POL - 3D-Planes 4

Original Bluray in tsMuxer

1. subtitle stream ENG - 3D-Planes 1
2. subtitle stream JPN - 3D-Planes 2
3. subtitle stream TUR - 3D-Planes 3
4. subtitle stream RUS - 3D-Planes 4
5. subtitle stream POL - 3D-Planes 5

Remux select subtitle stream 1,3,5

1. subtitle stream ENG - 3D-Planes 1
2. subtitle stream TUR - 3D-Planes 3
3. subtitle stream POL - 3D-Planes 5

Correct remux select subtitle stream 1,3,5

1. subtitle stream ENG - 3D-Planes 1
2. subtitle stream TUR - 3D-Planes 2
3. subtitle stream POL - 3D-Planes 4

Thank for answer Staina

[r0lZ]

Originally Posted by konikpolny

Hi r0lZ,
why does BD3D2MK3D create a project with 2 different files eg.
00098.track_4608.Eng.2D.sup and
00098.track_4608.Eng.sup
for the same 2D subtitles? I always thought they are identical but I noticed their filesize is different.

The 2D stream must be converted to XML/PNG by BDSub2Sub before the conversion to 3D. Unfortunately, sometimes, BDSup2Sub creates bad PNG frames for some subtitles. (They are either completely transparent, or their size is 0x0 !). But I have noticed that converting the original subtitle stream from BD SUP to BD SUP has the effect of solving that issue. Therefore, to convert the stream to 3D, BD3D2MK3D begins by a (theoretically unnecessary) conversion to 2D and create the stream with the .2D.sup extension.

Also, sometimes a single subtitle is split in several identical parts in the original stream, and so close together that they appear as a single subtitle to the spectator (known as "multiple ODS"). BDSup2Sub has an option to concatenate these double subtitles together, to form a single subtitle. Therefore, unnecessary subtitles are removed during that first conversion to 2D.

For that reason, previously BD3D2MK3D muxed the converted stream in the final MKV, as it was theoretically free of unnecessary double subtitles and invisible black images. But I have noticed later that sometimes, BDSup2Sub misses some subtitles, and therefore the converted stream can be somewhat incomplete. Therefore, now, BD3D2MK3D muxes the original 2D stream (without the .2D extension) in the MKV, and uses the converted 2D stream for the conversion to 3D only.

It is also correct that the filesize changes when the stream is converted, even if you don't change the format. Of course, it's normal if BDSup2Sub has concatenated some double subtitles, but it seems that there is another bug here, as if you convert again the .2D.sub stream to SUB, you will notice again a filesize change. I'm not sure why, and it it's important, but now, I think that the less you convert is the better. Unfortunately, it is necessary to convert several times the original stream to convert it to 3D.

[r0lZ]

Originally Posted by staina

I can apply these created ISO files in tsMuxer and set for subtitles streams correct 3D-plane and recreate new ISO files and or I have to for creation apply original 3D Bluray?

I'm not sure I understand what you mean, and that question is related to tsMuxer and only indirectly to BD3D2MK3D, so IMO you should have posted your question in the tsMuxer forum. But here is my answer anyway.

I'm sure that you can use BD3D2MK3D to know the exact assignment of the 3D-streams, and I'm also sure that they are often wrong in tsMuxer. I don't know if using the correct assignments from BD3D2MK3D to remux the streams with tsMuxer is sufficient to solve the tsMuxer bug. I hope so, but I use tsMuxer only to demux things, and therefore I don't know its bug when it muxes.

Therefore, I suggest to do a test yourself. Remux a 3D BD that has the wrong 3D-Planes assignments in tsMuxer, but use the correct values from BD3D2MK3D. Then, use tsMuxer and BD3D2MK3D to compare the 3D-Planes list of the newly remuxed BD, and it they are again different, you will know that tsMuxer has the same bug when it muxes.

In that case, you may have to use its (bad) 3D-Planes assignments, and with some luck, the final remuxed BD will be correct. Honestly, I'm not sure, but I think that it may again store the 3D-Plane numbers in the MPLS without paying attention to the order of the streams, and if it does that, the demux bug will be undone by the remux bug ! Of course, if that works, you will have to remux the same number of subtitle streams, in the same order than in the original BD, and with the same 3D-Plane numbers.

[konikpolny]

Originally Posted by r0lZ

... Therefore, now, BD3D2MK3D muxes the original 2D stream (without the .2D extension) in the MKV, and uses the converted 2D stream for the conversion to 3D only.

OK, thanks r0lZ,
so I understand that it's the regular, not the 2D one, is best for OCR conversion to text.

[r0lZ]

Originally Posted by konikpolny

so I understand that it's the regular, not the 2D one, is best for OCR conversion to text.

If you don't care about double subtitles, probably yes.

[staina]

Originally Posted by r0lZ

I'm not sure I understand what you mean, and that question is related to tsMuxer and only indirectly to BD3D2MK3D, so IMO you should have posted your question in the tsMuxer forum. But here is my answer anyway.

I'm sure that you can use BD3D2MK3D to know the exact assignment of the 3D-streams, and I'm also sure that they are often wrong in tsMuxer. I don't know if using the correct assignments from BD3D2MK3D to remux the streams with tsMuxer is sufficient to solve the tsMuxer bug. I hope so, but I use tsMuxer only to demux things, and therefore I don't know its bug when it muxes.

Therefore, I suggest to do a test yourself. Remux a 3D BD that has the wrong 3D-Planes assignments in tsMuxer, but use the correct values from BD3D2MK3D. Then, use tsMuxer and BD3D2MK3D to compare the 3D-Planes list of the newly remuxed BD, and it they are again different, you will know that tsMuxer has the same bug when it muxes.

In that case, you may have to use its (bad) 3D-Planes assignments, and with some luck, the final remuxed BD will be correct. Honestly, I'm not sure, but I think that it may again store the 3D-Plane numbers in the MPLS without paying attention to the order of the streams, and if it does that, the demux bug will be undone by the remux bug ! Of course, if that works, you will have to remux the same number of subtitle streams, in the same order than in the original BD, and with the same 3D-Plane numbers.

Change 3D-plane in tsMuxer does work, Shall I tested.

What I don't know is that a if can use already remuxovaný ISO file with main function in that is only several subtitles streams and me here change 3D-plane to to those that this remux does not contain, but in original him contained. Or I have to always use original Bluray, because after remux with at 3D-plane, that is not used clear all data e.g . about depth display subtitles.

Where there are saved data to single 3D-plane? Is that a video stream, CLPI file or MPLS file.

[r0lZ]

Originally Posted by staina

Where there are saved data to single 3D-plane? Is that a video stream, CLPI file or MPLS file.

Again, it is difficult to understand your English. If I understand correctly, you want to know where are the original 3D-Planes.

The 3D-Planes (officially called Offset Sequences, or OFS) are in the MVC video stream (the "dependent stream" specific to the 3D movies). You can extract the OFS files from the MVC stream with, for example, MVCPlanes2OFS.exe, included with BD3D2MK3D, but as far as I know, there is currently no way to attach new 3D-Planes to the MVC stream, or to edit them easily.

If you remux the video without re-encoding it (for example to simply add a new audio or subtitle stream), the 3D-Planes are preserved, and if their numbers are assigned correctly to the right subtitle streams (in the MPLS) by the remuxer, then everything should be fine. But if you re-encode the video, the 3D-Planes are lost. That means that the reencoded 3D-BD25 usually found on the internet have lost the depth of their subtitles.