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

[von Suppé]

Thanks so much about the MPLS handling info. This is good to know.

Originally Posted by r0lZ

...No, they are stored in "[project folder]\[movie title]\[MPLS number]"... ...are extracted only when they are needed to convert the subtitles to 3D

Then I think to know why I don't have these files/folders. I was doing a "Frame Sequential" mkv. If my understanding & memory serves me right, in that case only 3D subs can be done if you hardcode a subtitle on both left- and right-eye streams. Eventhough the "Subtitles type" in tab 2 was set to "3D only", I left the option in "Hardcode subs on video" on tab 5 to "None".
I do wonder however, why the created "**.2D.sup" files aren't an exact match of the demuxed (2D) sups. They don't have to be altered, my guess?


As for the 3D-planes extraction tool:

Originally Posted by r0lZ

...the tool to extract them works only on the elementary MVC stream. You must therefore demux the MVC stream from...

Can't help myself for trying out, but in the 3D-planes extraction tool's browser window it is however possible to select the ssif file as input (setting the "filetype" box to "All files (*.*)". And it will output. I compared this output to the result of demuxed mvc file as input.
Both show 6 same-named *.ofs files that are the same size, but not bit-equal (checked with hash-checker). Both "3D-Planes.log" files do show same summary data for the first 5 planes, but Plane 6 is very different indeed.
Of course, from now on I will always run the 3D Planes extractor with the firstly demuxed mvc as source.


Edit:

Originally Posted by r0lZ

...Generating a whole project with BD3D2MK3D just to have its full 3D-Planes log may be overkill...

Maybe, but once a project is finished, to me it proved very educational to look at the project folder.
Seeing all these files created and used, specially when you choose the windows explorer column "Date created", you can almost chronologically step-by-step follow what steps were taken. Very informative.


Of course I'll do a lot more testing and will certainly use the enormously handy subtitle tools.

For now, cheers

[r0lZ]

I have noticed several times some problems with the original (2D) subtitle streams, especially in Asian films. They contain often bad or empty subtitles, that can and should be removed. Also, BDSup2Sub merges identical subtitles if the gap between them is very short. So, I've decided to load and save the 2D subtitles anyway, just to clean them up. It's also during that first conversion that BD3D2MK3D analyses the stream, determines if there are forced subtitles, and see if the stream can be directly converted to 3D.

However, using the 2D version saved by BDSup2Sub may be a bad thing in some precise circumstances, notably when two (or more) different subtitles are displayed at the same time. It seems that the standard version of BDSup2Sub cannot properly handle them, as it removes the two subtitles. If you want to avoid this, you can try to replace BDSup2Sub.jar with the fork developed by Scorpius666 and available here. Or, if you are confident enough, just use the demuxed stream as it is. (It's the stream without the 2D or 3D extension in the BD3D2MK3D project directory.) Since you don't need to convert them to 3D, the original stream should be OK if it is displayed without problems when you play the original BD.

I haven't written MVCPlanes2OFS.exe myself, but I helped its author. The problem is that the detection of the SEI messages is fairly basic, and I cannot assume that the extraction works correctly when used on a complex file with a lot of multiplexed streams. So, IMO, extracting the 3D-Planes from the SSIF or dependent M2TS may work fine, but it may also fail, depending of the mux and the situation. It is at least safer to extract them from the demuxed MVC elementary stream, so it is a good idea to do it.

[von Suppé]

Originally Posted by r0lZ

...you can try to replace BDSup2Sub.jar with the fork developed by Scorpius666 and available here

I'm sorry, something is not clear. I downloaded the latest version here: https://github.com/mjuhasz/BDSup2Sub/wiki/Download
but it's the same version you have already in your toolset folder.
Can you please confirm this is the proper, latest "fork"?
I have always been using this version as latest download from Videohelp site.

[r0lZ]

Oops, sorry, the link I gave you points two posts too far. It should have pointed here. [Previous post fixed] And the fork (called officially BDSup2Sub "enhanced") can be downloaded here.

BD3D2MK3D distributes v5.1.2 by Mjuhasz, the latest "official" version (because I want to be sure that there are no new bugs in the fork before distributing it).

[von Suppé]

Thank you, r0lZ.

So, reading this, I think it would be proper custom to always load a demuxed SUP in BDSup2Sub or its fork and export again, just to make sure that errors are cleared out.
I was surprised to see how many warnings there were with SUP from Avatar, for instance.

[Tenker]

@rOIZ
@ll

I have not had any problems with your SUPER software.
Unfortunately, I can not convert the 3D movie "Wonder Woman".
My PC is an i7-4710HQ with Windows 10 64bit.

+ all files were unpacked without problems
00098.track_4113.264 = 21.428.288 KB
00098.track_4114.mvc 0 11,350,934 KB
00098.track_4353.Deu.dtsma = 2.415.318 KB
- after starting the "__ENCODE_3D.cmd"

@echo off
set path=D:\!_Video\BD3D2MK3D\toolset;%path%
echo Encoding movie in 3D
echo Movie: Wonder.Woman.2017.3D

echo Encoding started %date% %time%
@echo on

"D:\!_Video\BD3D2MK3D\toolset\avs2yuv.exe" ^
"__ENCODE_3D_MOVIE.avs" -frames 203220 -o - ^
| "D:\!_Video\BD3D2MK3D\toolset\x264_8bit_x64.exe" ^
--bitrate 15000 --pass 1 --stats "00098_3D.stats" ^
--preset medium ^
--sar 1:1 --range tv --colormatrix bt709 ^
--frame-packing 3 --qpfile chapters_3D.qpfile --frames 203220 --fps 24000/1001 ^
--output "00098_3D.264" --demuxer y4m --stdin y4m -
@echo Pass 1 finished %date% %time%
"D:\!_Video\BD3D2MK3D\toolset\avs2yuv.exe" ^
"__ENCODE_3D_MOVIE.avs" -frames 203220 -o - ^
| "D:\!_Video\BD3D2MK3D\toolset\x264_8bit_x64.exe" ^
--bitrate 15000 --pass 2 --stats "00098_3D.stats" ^
--preset medium ^
--sar 1:1 --range tv --colormatrix bt709 ^
--frame-packing 3 --qpfile chapters_3D.qpfile --frames 203220 --fps 24000/1001 ^
--output "00098_3D.264" --demuxer y4m --stdin y4m -
@echo off
echo Encoding finished %date% %time%

REM Optionnaly mux the video and demuxed streams to MKV.
REM Note: The mux is disabled if no streams are demuxed.
if exist "__MUX_3D.cmd" cmd /c "__MUX_3D.cmd"

REM Everything done: do the post-processing (Shutdown computer...)
if exist "__POSTPROCESS_3D.cmd" cmd /c "__POSTPROCESS_3D.cmd"
exit /B

the video was buckled = about 110 fps







Normal value is always about 25 fps

- The video file 00098_3D.264 is only 15.078 KB large

Can you please help me?

Many thanks and many greetings
Tenker


EDIT; I have tried both versions 1.0 and 1.1 without success

[tebasuna51]

The fps than you show are the encode speed: 110 encoded frames per second.
Not related with fps to play than is a correct 24000/1001

The problem is when the first pass finish with a bitrate of 14 Kb/s instead something like the 15 Mb/s selected.
I don't know for what, the command line to encode seems fine.
Put the __ENCODE_3D_MOVIE.avs to see anything wrong.

[r0lZ]

I don't understand. Indeed, even with a powerful i7 CPU, an encoding speed of 115fps is very fast! And the final file size is also abnormal.

IMO, there is something wrong with the decoding of the video. Have you played the final MKV? Does it contain video, or just black frames? Verify if the end of the movie contains real images too.

I have already noticed that sometimes, x264 encodes the beginning of the movie correctly, but suddenly all encoded frames are totally black, without reason, and up to the end of the movie. I have never understood what is causing that (rare) problem, but that seems related to an x264 bug. Anyway, when that happens, relaunching the encoding is sufficient, and the second time the movie is encoded successfully.

I suspect a problem with the PC going in Sleep mode during the encoding, or something like that. There is a well known x264 bug that makes it fail to encode properly when it wakes up from sleep mode. Do you encode with a portable computer? Are you sure you have launched __ENCODE_3D_LAUNCHER.cmd and NOT directly __ENCODE_3D.cmd ? __ENCODE_3D_LAUNCHER.cmd ensures that the computer will not go to sleep mode during the encoding.

Also, I suggest to use only the CRF encoding mode. It produces ALWAYS a slightly better quality than 2-pass for the same overall bitrate, so 2-pass should be used ONLY when the final file size must be precisely controlled (for example to burn the MKV on a DVD). Since the CRF mode requires only a single pass, it has less chances to encounter a problem, and it works very well.

Also, are you sure that the original BD has been properly decrypted? You cannot encode directly the original protected BD.

Anyway, I did Wonder Woman without problem myself, so it should not be a problem to encode it.

[Tenker]

Thank you very much for your quick and detailed reply.

What is NKV?

The 00098_3D.264 video is only black.

Yes, the decode has run on a notebook.

I have started the process automatically (then "__ENCODE_3D_LAUNCHER.cmd" started) and the file "__ENCODE_3D.cmd" was started without success.

DVDFab has converted the 3D ISO without problems, abe I ALWAYS use your software.

I start to test CRF encoding mode with automatic "__ENCODE_3D_LAUNCHER.cmd" start and reports.

What file and how do I have to change it so I can encode CRF instead of 2-pass?

Thank you rOIZ

[r0lZ]

Originally Posted by Tenker

What is NKV?

A typo! It's MKV. Sorry. (I've fixed it in my previous post.)

Originally Posted by Tenker

The 00098_3D.264 video is only black.

Yes, the decode has run on a notebook.

I have started the process automatically (then "__ENCODE_3D_LAUNCHER.cmd" started) and the file "__ENCODE_3D.cmd" was started without success.

DVDFab has converted the 3D ISO without problems, abe I ALWAYS use your software.

I start to test CRF encoding mode with automatic "__ENCODE_3D_LAUNCHER.cmd" start and reports.

OK, so it seems that you have encountered the rare "black frames" bug. As I wrote, I don't know its cause, so I can't help you more.

Just retry.

Originally Posted by Tenker

What file and how do I have to change it so I can encode CRF instead of 2-pass?

There are a lot of files to modify slightly. It is better to start over. But before doing so, just relaunch __ENCODE_3D_LAUNCHER.cmd, and let it run for a couple of minutes. Then, have a look at the encoding process. If it's again above 100fps, then the bug happens again. Kill the encode and redo the whole project, this time in CRF mode. Verify also when the second pass is running. The first pass may be OK, and the bug may happen only during the second pass.

Otherwise, if the encoding speed is normal, let the encoding run, and carefully verify if the final MKV is OK, especially near the end of the movie. As far as I know, the black frames bug can occur at any point in the movie, but it continues always up to the end of the movie. Therefore, if the end of the credits is OK, the rest should be OK too.

Sorry for the wasted time. Unfortunately, I have no way to reproduce the bug, and I cannot understand exactly why it happens and how to implement a workaround to fix it. Anyway. I'm sure it's not a bug in BD3D2MK3D itself, and therefore I am probably unable to fix it myself, even if I could understand it.

[Tenker]

Thank you rOIZ ,

__ENCODE_3D_LAUNCHER.cmd started unsuccessfully



I start to test CRF encoding mode with automatic "__ENCODE_3D_LAUNCHER.cmd" start and reports.


EDIT 15:48

unfortunately the same result
The file 00098_3D.264 is only 13.368 KB large and black content.

[r0lZ]

Damn! That's strange. Are you sure the BD has been correctly decrypted?

[frank]

The same error with Wonder Woman here on my Dell XPS 9560. dgMVCSource (deleted: and FRIMSource) decode black frames in HW-mode (Intel CPU).
Use software mode, that works. (You have to edit __ENCODE_3D_MOVIE.avs to force SW mode. Standard is auto -> selects HW mode on Intel machines -> error)
AFAIK I also had this issue with The Martian 3D.

[Tenker]

@frank

I changed the "__ENCODE_3D_MOVIE.avs" accordingly, unfortunately also without success.

...
LoadPlugin("D:\!_Video\BD3D2MK3D\toolset\LoadHelper.dll")
LoadPlugin("DGMVCDecode.dll")
#LoadPlugin("FRIMSource.dll")

#LoadPlugin("VSFilter.dll")
##LoadPlugin("SupTitle.dll")

# Load the two video streams (203220 frames per stream)
interleaved = DGMVCSource("00098.track_4113.264", "00098.track_4114.mvc", view = 0, frames = 203220, mode = "hw") # Old syntax for mode: hw = 0
#interleaved = FRIMSource("mvc", "00098.track_4113.264", "00098.track_4114.mvc", num_frames = 203220, cache = 2, platform = "")
# Current base view: left eye.
# The views are in the common order: AVC stream = left view, MVC stream = right view.
left = SelectEven(interleaved)
right = SelectOdd(interleaved)

# Build Side-by-Side stream
StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))
AssumeFPS("ntsc_film")

# Hardcode subtitles
#VobSub(".sub")
##SupTitle(".sup")

# Return the 3D clip.
Return(last)#.Info()

@rOIZ
I have sent the one PN ...

[frank]

Oh, man

mode="sw"

is the SW mode!!

[frank]

After new tests with Wonder Woman I have managed to start the encoding with FRIMSource decoder in HW mode. (platform = "hw")

But I needed several attempts to start. Something goes wrong with Intel drivers...
After successfully start of encoding the speed increased by 6 fps to 36 fps and the results are ok.

___________________
Win 10 Pro 64 bit v1703

[von Suppé]

Originally Posted by r0lZ

...you can try to replace BDSup2Sub.jar with the fork developed by...

I haven't replaced the .jar file but just used the enhanced fork manually. Damn. Thinking I'd be sure enough.
When exporting SUP to XML_PNG, BDSup2Sub Enhanced 0.0.9 changes timecodes. My subs got out of sync. I found out that clicking the "Reset" button (FPS Target going to 23.976) was not enough to do it right (in BDSup2Sub 5.1.2 it always worked).

I reminded a way (like ages ago) to solve easySUP's 24fps bug with BDSup2Sub. After a quick test I realized that you have to tick "Change frame rate" and then set both FPS Source and FPS Target to 23.976. It somehow forces the right timecodes then and output will be in sync with input.

Strange to experience that I have to do the same now in the enhanced fork. It's absolutely tricky and something to keep a sharp eye on.

[Tenker]

@frank

Thanks, with FRIMSource decoder runs also without platform = "hw"

[r0lZ]

So, it seems that FRIMSource is definitively better than DGMVCDecode. Should I set FRIM as the default MVC decoder in BD3D2MK3D?

[r0lZ]

Originally Posted by von Suppé

I haven't replaced the .jar file but just used the enhanced fork manually. Damn. Thinking I'd be sure enough.
When exporting SUP to XML_PNG, BDSup2Sub Enhanced 0.0.9 changes timecodes. My subs got out of sync. I found out that clicking the "Reset" button (FPS Target going to 23.976) was not enough to do it right (in BDSup2Sub 5.1.2 it always worked).

I reminded a way (like ages ago) to solve easySUP's 24fps bug with BDSup2Sub. After a quick test I realized that you have to tick "Change frame rate" and then set both FPS Source and FPS Target to 23.976. It somehow forces the right timecodes then and output will be in sync with input.

Strange to experience that I have to do the same now in the enhanced fork. It's absolutely tricky and something to keep a sharp eye on.

It's a well known bug of BDSup2Sub (old, new and ++ versions). I have reported it to the author of the recent fork, but he don't understand that it's really a bug, and he has rejected my request to fix it. Perhaps you will have more chance to convince him that there is indeed something totally abnormal? See this post and the following in the BDSup2Sub thread for more info.