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

[r0lZ]

Thanks for your kind words. :)

Currently, the MVC decoders are unable to seek, because they do not build an index file. It's a known limitation, and BD3D2MK3D can't directly overcome it. But you wrote "(non 3D)", and therefore I guess that you don't need a MVC decoder. A good AVC decoder should be sufficient. Have you tried FFMpegSource2 (http://avisynth.nl/index.php/FFmpegSource#FFmpegSource2) or a similar Source plugin ? Also, if you really want or need to use DGMVCSource or FRIMSource, you can use the SequentialToSeekable function of the Sub3D avisynth plugin by slavanap (forum.doom9.org/showthread.php?t=173143). It decodes silently all necessary frames to jump to the requested frame and is therefore very slow (especially if you need to seek backward), but it works well. You may also be interested in the main feature of the Sub3D plugin: it detects the right depth for your subtitles without the help of any 3D plane, and can either hardcode your subs or generate a 3D plane! Try it! It is slow and not always accurate, but slavanap did a wonderful job anyway.

[odyssey]

But you wrote "(non 3D)", and therefore I guess that you don't need a MVC decoder.

The title is not in 3D, but it's in translated language, so I'm trying to "patch" it with the 2D title (stacked, separate fields, giving me a 3D-compatible T&B clip).

For the curious one, it's Transcendence, which is only released in 3D in France. Title is spelled "TRANSCENDANCE". Yeah I'm a bit OCD, but since I'm putting a bit of work into the subs anyway... ;)

[r0lZ]

This version includes some minor bug fixes related to the ASS 3D subtitles (reported by konikpolny here (http://forum.doom9.org/showthread.php?p=1783747#post1783747)).

It has also a new feature to display the 2D-only titles of the current BD in a window similar to tab 1. It's only a simple way to find and preview the 2D titles. That may be useful if you want to re-encode them with another tool.

v0.95 (November 20, 2016)
- Added File -> Explore 2D Content of 3DBD to display and preview the 2D MPLS files of the current BD
- SRT to ASS 3D: Fixed: The subtitle of the right view in Half-SBS was sometimes off by 1 pixel
- SRT to ASS 3D: Changed the SecondaryColor from yellow &H0380F0F0 to pure black &H00000000
- SRT to ASS 3D: Changed the font style name "Default" to "3D"
- Updated the Mkvtoolnix exes to the latest version (v9.5.0)
- Updated the x264 exes to the latest version (0.148.2721)
- Updated the x265 exes to the latest version (2.1+36)

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

[konikpolny]

r0lZ,
thanks for the latest version. However, it still doesn't have any automated support for 3D subtitles in full-SBS/TB projects, which I was hoping to come into being.
Most importantly it doesn't generate the 3D-planes and XML/PNG files automatically, which are needed or useful in converting the 2D.SRT to 3D.ASS subtitles.
Also, for the reasons I explained earlier (http://forum.doom9.org/showthread.php?p=1781810#post1781810)it would also be good to have BD3D2MK3D generate the half-3D versions of sups/subs just as it does for half-SBS/TB projects (they can still be useful for full-SBS/TB movies).
Not having these features may add a lot of manual work if one wants to get the 3D subtitles in a full-3D project:
The 3D-planes I can generate manually from the Subtitle tools and this is the easier part, but for XML/PNG there is no tool to generate them directly (you can get xml/png indirectly by converting 2D to 3D). The XML/PNG subs are needed (preferrably before the convertion) if one wants to run the "Verify the 3D-planes compatibility..." tool to make a better guess for the right 3D plane choice (the tool only accepts XML/PNG format).

Currently, as I don't want to do all this manually I am creating the second project for the half- version, only to get these files. This does not make sense.
Please, add the 3D subs support already available to half-SBS/TB projects to full- versions projects as well.

[r0lZ]

r0lZ,
thanks for the latest version. However, it still doesn't have any automated support for 3D subtitles in full-SBS/TB projects, which I was hoping to come into being.
[...]
Please, add the 3D subs support already available to half-SBS/TB projects to full- versions projects as well.
Indeed, I forgot that. Sorry. But see the next post...
[...] but for XML/PNG there is no tool to generate them directly (you can get xml/png indirectly by converting 2D to 3D).It's not correct. You can very easily generate the XML/PNG files with BDSup2Sub. And, BTW, you can even launch BDSup2Sub (the java or ++ version depending on your settings) directly from the Subtitle Tools menu of BD3D2MK3D. Just select the right output format in the BDSup2Sub GUI. But if you do it, take care. BDSup2Sub has a very big bug when loading XML/PNG subtitles. It assumes always (regardless of the content of the XML file) that the frame rate is 25 fps, and, of course, the timings are not correct any more. To avoid that bug, you have to specify that you want to change the frame rate when the stream is loaded, and select 23.976 for both the FPS Source and FPS Target settings. That way, the timings will be correct (for a 3D BD, of course).

Anyway, with the new version of BD3D2MK3D, you should not need to do it manually any more. :-)

[r0lZ]

I've implemented the request of konikpolny. It is now possible to generate the 3D subtitles in Half-SBS or Half-T&B format, even if you encode in Full-SBS or Full-T&B format. (It's still not possible if you encode in Frame Sequential, of course.) See the new option in the Settings menu.

This version includes also a few improvements, and a little bug fix.

v0.96 (November 22, 2016)
- The playlists without audio are not displayed in the GUI any more (unless the "Show all 3D playlists" option is ticked)
- Added the option Generate 3D Subtitles Anyway to force BD3D2MK3D to generate Half-SBS/T&B subtitles even in Full-SBS/T&B format
- Added two context menus in the new Explore 2D Content window
- Fix: Bug when comparing playlists to remove duplicates if a 3D playlist has no 3D-Planes
Download: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

[konikpolny]

r0lZ, Thank you very much for that.
Also, thank you for the info about BDSup2Sub and XML/PNG files.

On this occasion can you please explain what is _ENCODE_2D.cmd used for?

[r0lZ]

_ENCODE_2D.cmd is the command that launches x264 (or x265) with the required parameters to encode the movie in 2D, in case you are interested in the 2D version alone. If I have correctly understood your choice, you don't need it, since you encode in full-SBS so that you can select only an half of the video image to watch the SBS movie in 2D. But others (including me) need half-SBS and having the possibility to encode also in 2D is handy.

[konikpolny]

OK, so it is a way to encode the 2D of the 3D BD, and it is never used in the 3D encode process. But what i didn't understand was that it has hardcoded encode values totally independent of what you specify for your 3D project

[r0lZ]

No, it's not totally independent. Most settings are used for the 2D and 3D versions (like the selected streams, 720p, CRF value or bitrate). Of course, the 3D specific settings (like SBS, 3D subtitles...) are ignored. And some other settings are ignored as well for technical reasons, like the black at the beginning or end of the movie, because the original AVC stream is re-encoded directly and there is no avisynth script and therefore there are less possibilities. But anyway, the overall quality of the 2D version should be identical or very similar to the quality of the 3D version.

[konikpolny]

OK, let's compare, the most outstanding differences...
my 3D encode:
\toolset\x265_8bit_x64.exe
--crf 24 --preset veryslow --tune grain

my 2D encode:
\toolset\x264_8bit_x64.exe (in _MUX_2D_REENCODED_OPTIONS.txt the video track for this is named "x265 baseline CRF 20 preset ultrafast, tune film")
--crf 20 --preset ultrafast --tune film

It doesn't quite look as if the 2D version should be identical or similar to the quality of the 3D version

[r0lZ]

Oh, yes, it's because you encode with x265. I forgot to explain that the 2D encoding is always made with x264, because x265 doesn't accept an AVC stream as input. For that reason, if you encode the 3D movie with x265, the latest settings saved in x264 mode are used for the 2D version. So, to specify other settings for the 2D version, you should switch to x264, modify the settings in the last tab, save the configuration, then return to x265. Your original x265 settings should be automatically restored. The new projects will use the current x265 settings for the 3D version, and the "hidden" x264 settings for the 2D version. (It's somewhat complex, but remember that the 2D stuff is only a bonus, and unfortunately, the x264 and x265 settings are too different to be compatible, so I can't use the x265 settings, even slightly modified, to encode with x264.)

Of course, if you encode the 3D version with x264, both versions use the same encoding parameters, and everything is much more simple. And, in that case, the quality of both versions is equivalent. There are still some slight differences due to the absence of avisynth in the 2D procedure, but they should not introduce noticeable quality differences.

This is roughly explained in the dialogue that pops up when you select the x265 encoder, but I forgot to explain that the 2D version uses always x264 and its settings. I'll add that right now...

[konikpolny]

OK, that explains the differences.
However, please forgive my asking but, could you explain why x265 won't accept an AVC stream as input. And how in this respect 3D encoding is different to 2D one for BD3D2MK3D. I mean Handbrake can encode 3DBD as 2D output video with x265.

[r0lZ]

x265 is still much more basic than x264. It doesn't have the stuff necessary to accept many input formats, and it doesn't have the video filters (resize, crop...) that x264 has. x264 accepts an AVC stream, a MKV video, or an avisynth script among many other input formats. AFAIK, x265 accepts only YUV or Y4M input.

For the 3D, BD3D2MK3D requires to build an avisynth script anyway (to combine the two views, hardcode the subtitles, etc...). The script is read directly by x264 32-bit, or it is converted to YUV with avs2yuv.exe first for x264 64-bit and x264 23 and 64-bit.

For the 2D, BD3D2MK3D doesn't build an avisynth script, and therefore it passes the original AVC stream directly to the encoder. That works fine with x264, but that cannot work with x265. AFAIK, there is no simple way to convert the AVC stream to YUV or Y4M on the fly, and therefore BD3D2MK3D doesn't support x265 for the 2D conversion.

It is certainly possible to build an avisynth script that reads the original AVC stream with a good source plugin, and then use avs2yuv to pass it as YUV to x265. Perhaps it's what hadnbrake does. I don't know, because I don't use it. But since the conversion to 2D is not the main job of BD3D2MK3D and has been implemented only at the request of some users, I kept it very simple, and I don't want to do something more complex. However, if someone knows a simple way to make the AVC stream compatible with x265 (perhaps with something like "avc2yuv.exe" if that exists), then I will probably implement the conversion to 2D HEVC. (The resize to 720p will be impossible, but that's another problem.)

[konikpolny]

thanks for this explanation :thanks:

[audiolord]

Hello.. the issue that I'm having with the application is the encoding quality. I have tried to encode the BFG 3D into a mkv sbs, but the resulting file is less than 8 gig with audio tracks included. I was trying to make a sbs that was at least 12 gig from the original files which are 33+ gigs in size. On any standard 2D bluray, I can manage the quality how I like it, but I'm having issues with your application, as I have tried to manipulate/edi some of the cmd files and others which can have an affect on the encoding rate.. Can anyone give some guidance??

[Nico8583]

What kind of bitrate do you use ? CRF ? VBR ? ABR ? CBR ?

[r0lZ]

Welcome to the Doom9 forums, audiolord !

Why do you want a specific size? Is it not better to target a specific quality? Although somewhat related, size and quality are not identical, and in the case of a movie with very clean images mainly generated with computers (like The BFG), it is possible to compress it very well without much quality loss.

It is totally absurd to pretend that it is necessary to encode at a certain bitrate to obtain a good quality. If you want a good demo, encode a movie made with only black frames at a certain bitrate. Of course, the quality will be perfect. Now, encode a movie made of complex and rapidly changing frames with much noise at the same bitrate. The quality will be terrible! It is therefore impossible to predict the quality of the encoding with a specific bitrate. But if you encode with a reasonable value in CRF mode, the black movie will be perfectly encoded and consume only a few MB, and the complex movie will be equally good but will require much more disc space. Encoding both movies with the same bitrate simply doesn't make sense.

Anyway, it is possible to change the quality of the encoding in the last tab. By default, BD3D2MK3D encodes in CRF mode, and by default I have left the CRF value to the default of the x264 encoder (CRF 23), because IMO that value is an excellent compromise between quality and size. (After all, the programmers of x264 know what they are doing!) Of course, you may prefer to use a lower value if you really think that the quality is not good enough at CRF 23. But do you think that, or do you really see that the quality is bad? IMO, you are victim of a prejudice due to bad information on the internet. Serious tests have proven that the human eye is usually not able to see the difference between a good encoding at CRF 23 and the same encoding at CRF 20 or even lower. Personally, I use values between CRF 18 and CRF 23 depending of the quality of the source image, but IMO it is never useful to encode a movie with lower CRF values. CRF 18 should be reserved to very special cases where the image quality is extremely important. (So far, I have used that value only to encode Sin City 2.)

I've read somewhere that lowering the CRF value by 3 is approximately equivalent to doubling the file size (the bitrate) of the video track. So, if you use CRF 20 instead of 23, the final file size should be around 11 GB, with the audio, but the final file size is difficult to predict because in CRF mode it depends mainly of the difficulty to compress the images. If you really want a specific size, you should use the 2-pass mode, but please DO IT ONLY if you want to put the movie on a media limited in size (like on a DVD). Using 2-pass instead of CRF produces ALWAYS a slightly less good quality, requires much more encoding time and has NO ADVANTAGE at all, except the possibility to define a precise final file size. It is a common mistake to encode in 2-pass, and if it's so frequent, it's probably because peoples recommend absurd encoding settings on the internet.

So to summarise, here are my recommendations: Encode in 2-pass if and only if you really need to control precisely the final file size. Otherwise, encode in CRF and use a CRF value between 18 and 23 depending of your wishes and the quality of the original images. Do not be surprised if your final file size is less than expected, because that means ONLY that the movie was easy to encode, and certainly not that it has been badly encoded. And finally, trust your eyes, and do not trust the bad information on the internet.

[EDIT] Nico has replied before me, but he is right. Your question doesn't make much sense if we don't know what encoding mode you are using.

[audiolord]

Thanks for the replies. All I did was use the program as it was set up and then started encoding. I will try and lower the CRF to see if it will give me what I was asking...

[frank]

You can indeed add --psnr to the command line for quality measurement. Ignore the error warning of x264, it does NOT effect the encoding process. I always use it. Only speed is getting smaller (< -1 fps).

PSNR:
>= 45 dB = very good, your eyes don't see any difference
>= 44 dB = (very) good
>= 43 dB = satisfaying, good for grainy movies

My encoding of Big Friendly Giant:
BFG 3D (hTAB): CRF=20, PSNR=45.3 dB, 5023 kbit/s
EXCELLENT result!

----
There are big issues in the german GUI of Potplayer, especially the 3d-tabs.
So I have corrected my post #1088 (http://forum.doom9.net/showpost.php?p=1782896&postcount=1088).

[frank]

@r0lZ

I use --level 4.0 and additional options like:
--bluray-compat
--vbv-bufsize 15000 --vbv-maxrate 15000
BD compatible is NOT set because of other special options.

BD3D2MK3D adds to the generated commandline the old buffer params (35000...).
Can you change that?
When you set bluray-compat in MEGUI than other params are not inserted.

[r0lZ]

Well, unfortunately, the devs of x264 have taken very bad decisions regarding the --level parameter. When the --level parameter is provided, it should restrict the bufsize and maxrate parameters so that the final result is compatible with the specified level, but it's not what it does. For unbelievable reasons, the --level parameter does nothing except to add the specified level to the header of the h264 stream, WITHOUT actually restricting the real level of the stream. Therefore, the level in the header does NOT reflect the level of the stream! It's obviously a bug, although it has been introduced deliberately. (There are modified versions of the encoder with that bug fixed, but I prefer to use the untouched exes.) It's a pity and that makes selecting the right parameters very difficult, but it's a fact. That means that to obey the level specified by the user and be compatible with the hardware, BD3D2MK3D has to specify the --vbv-* parameters as well, according to the specified level. It's why I can't remove them when you specify the --level with the GUI, as otherwise there will be no guarantee that the specified level is indeed taken into account (and it is too difficult to explain to the casual user that he has to specify the vbv parameter in addition to the level).

If you really want to specify the level with other vbv parameters, you should use "do not force" for the level parameter of x264 in the BD3D2MK3D GUI, and specify it manually in the additional parameters, with the vbv parameters. That way, BD3D2MK3D will not restrict the bufsize and maxrate and you are free to do what you want.

Also, I remember that I did some tests with some parameters specified several times, and it seems that when the same parameter is specified twice with different values, x264 uses always the value of the last occurrence in the command line. BD3D2MK3D adds the additional options near the end of the command line, and therefore if the user specifies a parameter that has also been specified by BD3D2MK3D, the value of the user's option should be used by the encoder. However, I can't guarantee that x264 works always that way, so I prefer to recommend to use the "do not force" trick.

[r0lZ]

You can indeed add --psnr to the command line for quality measurement.
In fact, you can select the psnr for the Tune parameter in the BD3D2MK3D GUI. It does the same thing. Of course, you cannot select another tune at the same time.

BTW, afaik, to use the psnr option, you have to specify it twice. It must be added alone in the command line AND as the tune parameter (--psnr --tune psnr). I may be wrong, but it's what BD3D2MK3D does when the user selects psnr for the Tune parameter in its GUI. Same thing for ssim.

[sneaker_ger]

--psnr will measure psnr. --tune psnr will optimize encoding for best psnr result by disabling AQ and psy. So they do different things. --tune psnr is dangerous and harmful and should not be used for anything but testing. (similar applies to --ssim/--tune ssim)

Psy hurts psnr and ssim but looks better to humans. The x264 developers added the warning because in comparison tests against encoders that don't have any psy feature the results are skewed/unfair.

[r0lZ]

Interesting. But IMO, what BD3D2MK3D does makes sense, because if the user selects psnr as the Tune option in the GUI, then that means that the --psnr parameter must be specified too, because if I understand correctly, disabling psy without enabling psnr (or ssim) doesn't make sense.

In the other hand, it makes sense to specify --psnr without the psnr tune, just to have a feedback about the quality (although it will not be perfectly correct) and without disabling the psy optimisation to keep the encoding for the final MKV. It's what Frank does. To do that with BD3D2MK3D, it is sufficient to add the --psnr argument manually in the additional options field.

Correct?

[sneaker_ger]

Correct.

[frank]

Correct (--psnr argument manually in the additional options field.) :)

Thanks for your info, r0lZ. Yes, the last buffer param overwrites the first, but overwriting user defined params is annoying.
For reencoding I ever use level 4.0 because we REDUCE information to that level, otherwise I would use remux.
The 4.0 bandwidth is comparable with AVCHD, HDTV and very useful for streaming (WLAN!!) or beamers and old TV-players - no stuttering. And I can't see any quality disadvantage, seeking and handling is smooth.

Maybe you can set user defined params in an editable user line (hidden if you want). Like jdobbs in BD-Rebuilder does.
Once defined I want to use my own encoding params (user profile) for every transcode.
That would be a christmas gift for me...
EDIT: Solved by using "do not force" for the level parameter of x264 and using additional options.

[r0lZ]

Maybe you can set user defined params in an editable user line (hidden if you want).I'm not sure I understand. Currently, only the mode (CRF/CQ/2-pass/ABR), the CRF/Quantizer/Bitrate value and the preset must be specified in the GUI. And BD3D2MK3D sets also some parameters depending of the movie, like the number of frames and the colorspace. Everything else can already be specified by the user, in the additional options field. And the content of that field is saved, like almost everything else, when you save the settings (from the Settings menu). I don't think I can do more.

[frank]

Donald published it in March 2016.
Re: Binaries Update Notification Thread
Postby admin » Sat Mar 05, 2016 5:42 pm

I released DGMVCSource b25. It improves performance by 33%. Note that the 'hw' option has been changed to a new string option called 'mode'. Please read the documentation for details.


To find on http://rationalqm.us/mine.html
I can confirm his statement!
On my Dell notebook (CPU 3rd gen) I use HW decoding (sw 12fps -> hw 15fps). The b25 is more stable! Now blockiness (buffer problems?) in some movies is gone away. B3D2MK3D speed goes up to 18...19 fps in hw mode. Tested with Win 10 prof.

The new param is mode = "auto" instead of hw=0

[frank]

Thanks, now user params work for me :)
My problem was:

Originally Posted by r0lZ:
...you should use "do not force" for the level parameter of x264 in the BD3D2MK3D GUI

[videoh]

To find on http://rationalqm.us/mine.html
I can confirm his statement!
On my Dell notebook (CPU 3rd gen) I use HW decoding (sw 12fps -> hw 15fps). The b25 is more stable! Now blockiness (buffer problems?) in some movies is gone away. B3D2MK3D speed goes up to 18...19 fps. Tested with Win 10 prof. Good to hear. Thanks for your test results.

[Nico8583]

b25 improves performance by 33% for HW and/or SW decoding ?

[r0lZ]

I haven't tried b25 yet, but thanks for the reminder. It will be included in the next version of BD3D2MK3D anyway.

[videoh]

b25 improves performance by 33% for HW and/or SW decoding ? Should be substantial for both.

[r0lZ]

EDIT: DO NOT USE THIS VERSION. It has a big bug when using DGMVCSource as the MVC decoder. Use v0.98 or greater!

Just a little bug fix. The exe of the third party programs have also been updated to the latest version.

v0.97 (January 8, 2017)
- Minor cosmetic changes
- Fix: The bitrate in the labels of the stereo audio tracks was wrong
- Updated DGMVCSource to the latest version (1.0.0 b25)
- Updated the Mkvtoolnix exes to the latest version (v9.6.1)
- Updated the x264 exes to the latest version (v0.148.2744)
- Updated the x265 exes to the latest version (2.2+22)

Note that the version number in the Properties -> Details of the DGMVCDecode.dll is still 1.0.0.24, but it's really the b25. I suppose that Donald forgot to change the version number in his source files.

[Humbo]

Hello!
I'm having some problems, and this is the error message I get:

avs [error]: Script error: DGMVCSource does not have a named argument "hw"

Any ideas?
Thanks.

[videoh]

The new version has modified syntax:

DGMVCSource("combined.264","",view=0,frames=2000,mode="auto")
or
DGMVCSource("base.264","dependent.264",view=0,frames=2000,mode="auto")

* single source clip is the combined MVC elementary stream, made with eac3to and mvccombine,
or dual source clips are the base and dependent elementary streams.
* if a single source clip is specified that is a normal AVC file (not a combined MVC file),
then it will be correctly treated as a normal AVC file, and the view parameter is ignored.
* view: 0 = interleaved left and right, 1 = left only, 2 = right only.
* frames: number of frames, if too few the stream is truncated, if too many extra black frames are returned.
The specified frames parameter is internally doubled when delivering interleaved, i.e., when view=0.
* mode chooses mode of decoding: "auto" (default) - use HW acceleration if it is available, otherwise use SW,
"sw" - force SW decoding, "hw" - force HW acceleration, fail if it is not available. If mode is
not specified, then "auto" is assumed.
* multiple instantiation in a single script is supported to the limit of available resources.

I suppose BD3D2MK3D needs to be modified to invoke DGMVCSource correctly for the new parameters.

[r0lZ]

Oops, sorry. No time right now, but I will fix that bug tomorrow.

[r0lZ]

OK, here is the fix. Sorry again. I did a quick test with v0.97 and DGMVCSource b25, and it worked, but I have not noticed that the decoder was FRIMSource! :rolleyes:

v0.98 (January 10, 2017)
- Bug introduced in v0.97: DGMVCSource crashed due to its new syntax of the hw/mode parameter

If you have old projects build with v0.96 or previous versions of BD3D2MK3D, and if DGMVCSource was the selected MVC decoder (the default), you will NOT be able to encode them with v0.98. If you don't want to rebuild the whole project from the 3DBD, you can simply edit the __ENCODE_3D_MOVIE.avs file and change the last parameter of the DGMVCSource() line according to this table:

Old syntax -> New syntax
hw = 0 -> mode = "auto"
hw = 1 -> mode = "sw"
hw = 2 -> mode = "hw"

Similarly, if you want to use projects generated with v0.98 or greater with an old version of DGMVCSource, you should apply the same conversion in the opposite order. For your convenience, v0.98 adds a comment with the old syntax at the end of the DGMVCSource() line. But normally, you should not need to use an old version of DGMVCSource.

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

[Humbo]

Much appreciated!

[macrea]

Can this software be used to output losslessly to ISO?

The problem with makemkv is it doesn't properly support 3D planes for 3D subtitle depth. And I use the Mede8er external player, and it also doesn't seem to properly respect plane settings in mkv files - according to their forums it must be a 3D ISO for the Mede8er player to properly display the 3D subtitles according to the plane data. TSMuxer also seems to not properly read/handle the plane setting. So this software seems to be the only answer for handling the 3D subtitle depth settings properly. But by default it encodes to half-sbs. I'd like to be able to output to frame-packed ISO in order to keep the quality lossless as well as being compliant.

If this is not possible, is there a way to use this software to at least help with the 3D plane issues with TSMuxer? Can I use this software to get the correct plane info, and then use that plane info in TSMuxer? Will TSMuxer handle the plane properly as long as I put the proper plane setting in?

[r0lZ]

Welcome to the Doom9 forums, macrea !

I'm not sure I understand exactly what you want to do. It seems that you want "to output losslessly to ISO". That is easy to do and there are several free or commercial programs able to extract the video, audio and subtitle streams (including the MVC stream with the 3D-Planes) from an original 3DBD and write them unchanged to a new ISO, It's just a copy, and the 3D-Planes should not be lost. You have just to verify thet they are correctly assigned to your subtitle streams during the remux. I think that TsMuxeR can do that perfectly, and you can easily see the original 3D-Planes assignments and assign them to your subtitle streams with its GUI. Is it what you want? If it's the case, you don't need BD3D2MK3D at all, and the copy is really lossless.

You wrote also "I'd like to be able to output to frame-packed ISO in order to keep the quality lossless as well as being compliant." The question is, what frame-packed format do you want? AVC+MVC like in the original BD3D? That's exactly what I have explained in the first paragraph. Or do you want to re-encode to AVC+MVC with the possibility to hardcode the subtitles? In that case, I don't think that there is a complete solution. Or do you just want to output as a single interleaved AVC stream (aka "Frame Sequential") and hardcode the subtitles? In that case, you can use BD3D2NK3D to generate the right frame sequential video stream, and use TsMuxeR to build the ISO. The 3D-Planes cannot be used with that kind of output, but since the subtitles are hardcoded, you don't need them any more. Anyway, only the first case is really lossless.

BD3D2MK3D is not designed to re-encode in MVC, or to output to an ISO. It can only re-encode to SBS, T&B or Frame Sequential, and that 3 formats require only AVC encoding. That means that BD3D2MK3D doesn't have the MVC encoder to encode the right video streams for a 3DBD. So, if you want to re-create a real 3DBD with the AVC and MVC video streams, you need another encoder. And currently, the only free MVC encoder is the Intel encoder, used for example by FRIM (http://forum.doom9.org/showthread.php?t=169651).

I can't help much more without knowing exactly what you want to do.

[macrea]

Welcome to the Doom9 forums, macrea !

I'm not sure I understand exactly what you want to do. It seems that you want "to output losslessly to ISO". That is easy to do and there are several free or commercial programs able to extract the video, audio and subtitle streams (including the MVC stream with the 3D-Planes) from an original 3DBD and write them unchanged to a new ISO, It's just a copy, and the 3D-Planes should not be lost. You have just to verify thet they are correctly assigned to your subtitle streams during the remux. I think that TsMuxeR can do that perfectly, and you can easily see the original 3D-Planes assignments and assign them to your subtitle streams with its GUI. Is it what you want? If it's the case, you don't need BD3D2MK3D at all, and the copy is really lossless.

You wrote also "I'd like to be able to output to frame-packed ISO in order to keep the quality lossless as well as being compliant." The question is, what frame-packed format do you want? AVC+MVC like in the original BD3D? That's exactly what I have explained in the first paragraph. Or do you want to re-encode to AVC+MVC with the possibility to hardcode the subtitles? In that case, I don't think that there is a complete solution. Or do you just want to output as a single interleaved AVC stream (aka "Frame Sequential") and hardcode the subtitles? In that case, you can use BD3D2NK3D to generate the right frame sequential video stream, and use TsMuxeR to build the ISO. The 3D-Planes cannot be used with that kind of output, but since the subtitles are hardcoded, you don't need them any more. Anyway, only the first case is really lossless.

BD3D2MK3D is not designed to re-encode in MVC, or to output to an ISO. It can only re-encode to SBS, T&B or Frame Sequential, and that 3 formats require only AVC encoding. That means that BD3D2MK3D doesn't have the MVC encoder to encode the right video streams for a 3DBD. So, if you want to re-create a real 3DBD with the AVC and MVC video streams, you need another encoder. And currently, the only free MVC encoder is the Intel encoder, used for example by FRIM (http://forum.doom9.org/showthread.php?t=169651).

I can't help much more without knowing exactly what you want to do.

Thanks for the warm welcome!

As was described in your first paragraph, I want to remux to ISO without any re-encoding, keeping only the titles and subtitles I need, while keeping it compliant for burning if I want to.

I have read in a couple places that TSMuxer has bugs/issues with handling planes correctly. From my understanding, TSMuxer won't show you the original planes. It just lets you select the plane you want to use. Is that incorrect? If you use the wrong plane for the subtltle (a different plane than originally on the disc), then the results will not work correctly. This is why I was wondering if BD3D2MK3D would be useful for finding which plane to use in TSMuxer.

I did try using TSMuxer a while back, and it was a foreign animated 3D blu-ray with English subtitles. They must have messed up the planes on the disc because the subs are flat on the screen (plane zero?), cutting through lots of 3D objects and ruing the experience. After using TSMuxer, the subtitles still had the same problem.

I'm new to this 3D planes thing, but am I right that the higher the number in TSMuxer, the farther out of the screen the subtitles are? I'd like to place them far enough out that they won't cut through objects. Any advice would be appreciated.

I also read that some 3D films can have dynamic planes, which place the subs in different planes based on individual dialog, so one line might be on a different plane than another line, depending on the action on-screen. Can anybody suggest a better software solution than TSMuxer for this, or is TSMuxer recommended?

[r0lZ]

From my understanding, TSMuxer won't show you the original planes. It just lets you select the plane you want to use. Is that incorrect?
Well, it's partially incorrect. TSMuxeR shows you the 3D-Plane number, but it is right that it can have some bugs. The problem is related to the structure of the MPLS. A MPLS can reference some subtitle streams but not necessarily all physical streams really present in the M2TS/SSIF. I call the unreferenced streams "phantom streams". They are present, but normally you cannot select them during the playback. (The video, audio and subtitle streams for the PiP video are also additional streams, referenced in an extension of the MPLS but not related to the real movie. They are therefore similar to the phantom streams.) In a 3DBD, the 3D-Planes are assigned only to the streams referenced in the MPLS, in the order of the MPLS. Most of the time, all streams physically present in the M2TS/SSIF files are referenced in the MPLS, in the same order, and in that case the 3D-Planes shown by TSMuxeR should be correct. However, when a phantom stream is present before a referenced stream, or when the streams are not in the same order than in the M2TS, TSMuseR assigns the 3D-Planes sequentially to the wrong streams. That's a bug, and it's one of the major reasons that have motived me to write my own MPLS parser. BD3D2MK3D shows you only the streams really referenced in the MPLS (without the PiP), with the correct 3D-Planes assignments.

So, yes, it is a good idea to use BD3D2MK3D to verify the 3D-Planes assignments shown by TSMuseR, even if most of the times there are no differences.

If you use the wrong plane for the subtltle (a different plane than originally on the disc), then the results will not work correctly.
Correct, although most of the times, all 3D-Planes are similar. It's why BD3D2MK3D has some tools to convert an external 2D subtitle stream to 3D using the most appropriate 3D-Plane, even if no 3D-Plane exist in the BD for that specific stream or language. The results, although not perfect, are usually very good.

I did try using TSMuxer a while back, and it was a foreign animated 3D blu-ray with English subtitles. They must have messed up the planes on the disc because the subs are flat on the screen (plane zero?), cutting through lots of 3D objects and ruing the experience. After using TSMuxer, the subtitles still had the same problem.
Some cheap 3DBDs have no 3D-Planes or they have a constant depth. (It's usually the case of Asian movies, some documentaries, cheap BDs for kids, and so on...) It's also the case of many ISOs badly compressed to fit on a BD25 and found on the internet (because the 3D-Planes information is in the MVC video stream and is lost when you re-encode it.)

Of course TSMuxeR cannot create new 3D-Planes automatically for that bad BDs. If the original subtitles are flat, it cannot fix the problem. (It should be possible to give a constant depth to unstick all subtitles from the surface of the stream, but afaik it's not possible currently.)

Anyway, in your case, since you don't want to re-encode the video, the MVC stream will stay untouched, and if you use the correct 3D-Plane number, you should obtain exactly the same depths than in the original BD.

I'm new to this 3D planes thing, but am I right that the higher the number in TSMuxer, the farther out of the screen the subtitles are? I'd like to place them far enough out that they won't cut through objects. Any advice would be appreciated.
No! TSMuxeR shows you the assignments ONLY! In a single MVC stream, there can be up to 32 different 3D-Planes. In the MPLS, each referenced subtitle stream is defined. The language of the stream, for example, is defined in the MPLS. The number of the 3D-Plane to use is also defined for the subtitle stream (in the 3D extension of the MPLS). The 3D-Plane number is therefore not related at all to the depth of the subtitles (or only very indirectly).

However, the depth values stored in the 3D-Plane itself represent the position along the Z axis of the subtitles. 0 means "on the surface of the screen", < 0 means beneath the screen, and of course, positive values mean toward the spectator. There is normally one depth value per frame in each 3D-Plane, but some depths may be undefined (hex 0x80) if there is no subtitle at that frame. Usually, the depths values range is around -10 to 25. The full range is -127 to 127. (Note also that in BD3D2MK3D, all depth values are multiplied by 2, for technical reasons and because that permits a better precision.)

Unfortunately for you, you cannot create your own 3D-Planes easily, or modify an existing one. They must be attached to the MVC stream before the mux, and afaik there is no tool able to do that. You will therefore have to use a plane present in the original MVC stream, even if it is not perfect.

BD3D2MK3D has some tools to analyse the content of a 3D-Plane and display some statistics (like the min, max and average depths or the number of undefined depths), but unfortunately for you, it can only analyse the 3D-Planes files extracted from the MVC stream, itself demuxed from the SSIF, so using that tools directly on the BD is impossible.

I also read that some 3D films can have dynamic planes, which place the subs in different planes based on individual dialog, so one line might be on a different plane than another line, depending on the action on-screen. Can anybody suggest a better software solution than TSMuxer for this, or is TSMuxer recommended?
Correct. In fact, all "good" 3D-planes are dynamic, because it is very painful to have to adapt constantly the focus of your eyes to see the objects in the movie and to read the subtitles. The subtitles must therefore be as close as possible to the objects that the spectator is supposed to look at.

As you should have understood now, TSMuxeR is not responsible of the quality of the 3D-Planes. It has just to insert the correct 3D-Planes number(s) in the MPLS so that they correspond to the physical subtitle streams. Dot. Therefore, TSMuxeR can perfectly be used to assign the 3D planes (but as explained above, not to be sure of the 3D-Plane number to use). The rest depends of the 3D-Planes present in the MPLS stream. And authoring them yourself is another story, currently impossible or very difficult with free tools and without authoring the 3DBD yourself. (I hope that TSMuxeR doesn't have the same bug when it muxes than when it analyses a MPLS, but I can't be sure because I don't use it for that job. Anyway, since you remux just to regain some space, I suppose that you will not keep the useless phantom streams, and the 3D-Planes assignments should be straightforward.)

Final note: I have adopted the terminology of TSMuxeR when I began to write BD3D2MK3D, but "3D-Plane" is not the official name. It is probably better to use "Offset Sequence" (hence the ".ofs" extension of the 3D-Plane files.)

[macrea]

Thanks very much for all of this information. Very helpful indeed, though a bit confusing. I guess the bottom line is for my current situation, if the subtitles are flat on the screen already (cutting through objects), there's no current way of getting them off the screen and in front of the action, correct? That's unfortunate, but at least I know not to spend hours randomly trying different planes hoping it will work. I guess I'm stuck watching it without subtitles. At least I can enjoy the visuals. The subtitles wreck the enjoyment completely when they are flat on the screen.

[r0lZ]

Yep, it's a good conclusion. Me too, my brain can't support the flat subtitles, and I would like to find a way to replace the bad 3D-Planes in the MVC, but as far as I know, currently it's impossible without re-encoding completely the video streams, and using professional or semi-pro authoring software. But note that I wrote "as far as I know". Personally, I'm not interested in keeping the original streams, and I wrote BD3D2MK3D to do just the opposite: to re-encode the oringnal 3DBD in a totally different and lighter 3D format. For that reason, I don't know exactly the possibilities of the tools used to re-create a BD from M2TS files or elementary streams. Perhaps it is already possible to attach the new or modified 3D-Planes to the MVC stream before re-muxing it, or during the remux process. Perhaps with Scenarist? Honestly, I don't think so, but I'm not sure. If you find a way to do it, please let us know.

Good luck anyway!

[geheim]

If remuxing 3DBDs with Scenarist you could at least set a constant depth to the subtitles. Using a value of -7 worked for me so far, because the subtitles are then displayed way in front of the Screen and I've never seen a movie in which the subtitles cut through objects in this case.
Note that this does only work with original stream files. Reencoding with FRIM or MVCEnc corrupts the sei message inside the mvc stream and therefore makes it impossible to set any depth values...

[r0lZ]

Thanks for the precisions.
Using a value of -7 worked for me so far, because the subtitles are then displayed way in front of the Screen and I've never seen a movie in which the subtitles cut through objects in this case.I'm not familiar with Scenarist, but the -7 value seems strange. It seems that Scenarist has adopted the inverse of what is effectively stored in the offset sequence of the final BD, where a negative value means beneath the screen. And a depth of 7 seems pretty small for many BDs. As I wrote above, some 3D-Planes of commercial BDs have some depth values of 40 or even more. But indeed, 7 may be a good starting point.

I remember I've read somewhere that Scenarist can accept .ofs files (with dynamic depths) as well. It's why I've changed the old BD3D2MK3D 3D-Planes file format from .3dp to .ofs (with just an additional header). I've never tried, but the new .ofs files should be compatible with Scenarist and/or other authoring programs or muxers.
Note that this does only work with original stream files. Reencoding with FRIM or MVCEnc corrupts the sei message inside the mvc stream and therefore makes it impossible to set any depth values...
BTW, I wonder if it is possible to write a little exe that replaces the original values of one or all 3D-Plane(s) in an original MVC stream with modified values. Finding the right SEI messages and replacing the values is certainly possible, but I suppose that some checksums must be modified as well, and that's probably much more difficult. And that doesn't solve the problem of the missing SEI messages in re-encoded streams.

[geheim]

Thanks for the precisions.
I'm not familiar with Scenarist, but the -7 value seems strange. It seems that Scenarist has adopted the inverse of what is effectively stored in the offset sequence of the final BD, where a negative value means beneath the screen. And a depth of 7 seems pretty small for many BDs. As I wrote above, some 3D-Planes of commercial BDs have some depth values of 40 or even more. But indeed, 7 may be a good starting point.


Negative values in Scenarist result in objects appearing closer to you (in front of the Screen), positive values appear farer away (inside the Screen). I don't know if this is the inverse of what is stored inside the final output...

The value of -7 is just my personal experience. I did quite a few remuxes of 3D Blurays with their according subtitles and a value of -7 was never distracting when watching the movies. Also I noticed that higher values result in more Ghosting effects on some TVs, because of the higher discrepancy between left and right... Ghosting appears often if White objects are on black Background, and this is exactly how subtitles are often displayed.
So, I think you could start testing a bit using -7. I wouldn't take less, but of Course a bit more couldn't be that bad either ;)

I remember I've read somewhere that Scenarist can accept .ofs files (with dynamic depths) as well. It's why I've changed the old BD3D2MK3D 3D-Planes file format from .3dp to .ofs (with just an additional header). I've never tried, but the new .ofs files should be compatible with Scenarist and/or other authoring programs or muxers.


Yes Scenarist accepts .ofs files in theory, although I never got it working unfortunately... I don't know why, but if I used an .ofs file for the depth I just got flat Subs all the time, which means not a single depth Setting is applied correctly. I don't know if there is an error in the .ofs from BD3D2MK3D or in Scenarist itself...

BTW, I wonder if it is possible to write a little exe that replaces the original values of one or all 3D-Plane(s) in an original MVC stream with modified values. Finding the right SEI messages and replacing the values is certainly possible, but I suppose that some checksums must be modified as well, and that's probably much more difficult. And that doesn't solve the problem of the missing SEI messages in re-encoded streams.

This would be quite interesting! Do you think it is possible to replace the SEI Messages without reencoding?? I always thought this could only be done with reencoding, and using professional Encoders only.
Of Course, if some checksums are applied it wouldn't work that easily, but it certainly would be worth investigating I assume.
Perhaps if we knew how the SEI message Needs to be inserted inside the stream, we could also just add it to FRIM-encoded streams after encoding?!?

[r0lZ]

Negative values in Scenarist result in objects appearing closer to you (in front of the Screen), positive values appear farer away (inside the Screen). I don't know if this is the inverse of what is stored inside the final output...Yes, it's the inverse of the content of the "real" 3D-Planes and the content of the .OFS files. It's also the inverse of the convention widely used in the 3D infographic world, where the Z axis is always directed toward the spectator.

For the 7 (or -7) value, I fully agree that it's a good starting point. At least if the values in Scenarist are equal to the values in the .ofs files (except the sign). Usually, for a constant depth, I try with something between 6 and 10 depending of the movie, but there are usually at least 10 or 20 subtitles that need manual adjustments. A constant depth of 20, for example, will certainly require less adjustments, but the subtitles are so far from the screen that it's certainly not a value to recommend.

Note also that BD3D2MK3D offers also another way to be sure that the subtitles do not enter in the objects. When a movie is shot in Cinemascope format, it has large horizontal black borders. In the last tab, you can move the picture up in the screen, and if the bottom border is large enough, the subtitles will appear in that border, beneath the picture. That's not perfect, but it's less unpleasant than subtitles entering the objects. Anyway, it's not a solution when the video is not re-encoded.

Yes Scenarist accepts .ofs files in theory, although I never got it working unfortunately... I don't know why, but if I used an .ofs file for the depth I just got flat Subs all the time, which means not a single depth Setting is applied correctly. I don't know if there is an error in the .ofs from BD3D2MK3D or in Scenarist itself...
Hum, strange. Are you sure that the offset sequences are correctly referenced in the MPLS files? It is not sufficient to attach them to the MVC stream. It is also necessary to link the subtitle stream and the OFS together. You can verify if the links are correct with BD3D2MK3D, or with TSMuxeR (at least when it doesn't have the bug described in a previous post (http://forum.doom9.org/showthread.php?p=1793361#post1793361)).

This would be quite interesting! Do you think it is possible to replace the SEI Messages without reencoding?? I always thought this could only be done with reencoding, and using professional Encoders only.
Of Course, if some checksums are applied it wouldn't work that easily, but it certainly would be worth investigating I assume.
Perhaps if we knew how the SEI message Needs to be inserted inside the stream, we could also just add it to FRIM-encoded streams after encoding?!?
Well, currently, BD3D2MK3D can retrieve the 3D-Planes from the previously demuxed MVC stream (with MVCPlanes2OFS.exe, written by Nico8583). Since the 3D-Planes are simply collections of depth values (one byte per frame and per 3D-Plane), it is certainly possible to do the opposite, and overwrite the original depth values with edited or new values. Furthermore, many (but not all) 3DBD have the maximum number of 3D-Planes (32), even if only a couple of them are really used and contain meaningful depth values. That leaves much place for experimenting. Of course, the MVC stream must then be remuxed and the 3D-Planes correctly assigned to the subtitle streams, but that can be done with TSMuxeR.
As I wrote, it might be difficult to do it due to checksums or other difficulties. My knowledge of the structure of the MVC stream is not sufficient to be sure that it's possible, but I can do some little tests. But is it really interesting? What will be the benefit of replacing a 3D-Plane in an original MVC stream (supposed to contain already good 3D-Planes) with a constant depth? Without a full 3D-Subtitles editor, that doesn't make much sense.
Adding totally new SEI messages in the MVC stream is also a big challenge. I don't even know if it's the job of the MVC encoder, of the muxer or even of a dedicated application.

Finally, I'm not sure I'm the right person to develop a program to generate or replace 3D-Planes. BD3D2MK3D is not at all dedicated to do that. It does exactly the opposite and uses the original 3D-Planes only to create "3D Subtitle" streams for SBS or T&B format. I have no intention to write something to modify the existing 3DBD and recreate an ISO. However, I have some free time right now, and I will try to modify manually the 3D-Planes of an original MVC, and see if it is still accepted by the muxer and the players. If it's the case, it might be interesting to investigate further...