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

[r0lZ]

You gave me a screenshot of a 3D SUB file, a palette.ini file and a single BMP of a subtitle. They are from DIFFERENT streams !

Obviously, the BMP has no grey shadow. It has a black outline only. Therefore, it is NOT possible to obtain a stream with a grey shadow. Of course, if you use a palette made for a different stream, you cannot obtain good results. How can I explain that better?

Normally, everything is automatic when you convert a BD. If you want to add your own subtitle streams, you have to generate the palette for your subtitle stream, and use it for your conversion. If you use another palette, that CANNOT work!

[De_Hollander]

i try it again i remux it first with 1 sup, than with BD3D2MK3D

[De_Hollander]

Oke i have de mux alle the sup out of the bd
except 1

this is the result
from the reencode with sup and vobsub

original




3d sup


3d vobsub


the shadow color is not black from the vobsub that BD3D2MK3D have made.

now i change de 3d sup to vobsub the palet with BDsup2sub manualy

[r0lZ]

Post the palette.ini file.

[De_Hollander]

#COL - for BDSup2Sub (java version ONLY!) created by BD3D2MK3D v0.66
# Thu Jun 18 21:12:11 CEST 2015
# Generated from all subtitles in original file.
# Note: Colour #0 (black) is not present in the INI file of the java version and cannot be modified.
Color_14=17,187,187
Color_13=51,250,250
Color_12=187,17,187
Color_11=250,51,250
Color_10=187,187,17
Color_9=250,250,51
Color_8=17,187,17
Color_7=51,250,51
Color_6=187,17,17
Color_5=250,51,51
Color_4=17,17,187
Color_3=51,51,250
Color_2=104,104,104
Color_1=204,204,204
Color_0=201,201,201

[r0lZ]

OK, indeed, there is a problem with your SUP file. It is caused by another terrible bug in BDSup2Sub. Unfortunately, I can't do much to fix it, although I have a workaround that may work when converting it to VobSub.

The problem:

When a 2D SUP is converted to 3D, several dirrerent conversions must be made:
1. Convert the original SUB to 2D XML/PNG with BDSup2Sub: No problem.
2. Convert the 2D XML/PNG to 3D with ImageMagick (and BD3D2MK3D): No problem.
3. BD3D2MK3D analyses the PNGs to generate a 16-colours palette (used only when converting to VobSub but generated anyway).
4. Convert the 3D XML/PNG to the final 3D SUP or VobSub file with BDSup2Sub: Bug!

Conversion to 3D BD SUP:

In step 4, BDSup2Sub must convert the 3D PNGs (with white characters, a black background and a black outline) to the output subtitle format. It doesn't use the palette to convert to SUB.

There is no need to change the colours of the original PNGs, since the SUP format supports 16 millions of colours and 256 levels of transparency. In other words, BDSup2Sub should simply copy the content of the PNGs in the subtitle stream, without modifying it. But it's not what it does! For whatever reason (probably due to the semi-transparency of the shadow), it changes the colour of the shadow from pure black to grey! That's a terrible bug!

You can verify that steps 1 and 2 give perfect results by converting your SUP to 3D XML/PNG. Then load the PNG files in an image editor, and you'll see that the outline is black. Totally black. There is no problem in the 3D PNGs. However, if you load the XML/PNG stream in BDSup2Sub, the outline is "converted" to gray, without any reason to do so. That's the bug.

Unfortunately, I have absolutely no way to fix that problem with a workaround. Since there is no way to force BDSup2Sub to change its palette when it converts to SUP format (because it doesn't need a palette), the result is dependent of BDSup2Sub only, and unfortunately, with your precise input SUP stream, it fails to render the colours correctly. We have to live with that bug.

Conversion to 3D VobSub:

When the XML/PNG stream is converted to VobSub format, BDSup2Sub must reduce the 16 millions of colours of the PNGs to the 3 colours of the VobSub format. It uses normally its internal palette, but it is usually not perfect for a specific stream. Therefore, in step 3, BD3D2MK3D analyses the PNGs and tries to generate a palette that contains better colours, and it passes that palette to BDSup2Sub during step 4 to force it to use the right colours. That works usually well, but not in this case.

With this SUP stream, there are only two colours: the white of the characters (in fact a very light grey), and the pure black shared by the outline and the shadow. During its analyse, BD3D2MK3D finds the two colours. It changes the white to force the light grey used really by this SUP file, and it leaves the black alone. (The black cannot be changed anyway.) It doesn't try to change the other colours (notably the dark grey), because there is no reason to suppose that BDSup2Sub will use them. However, due to the bug explained above, it uses the dark grey for the outline instead of the black.

So, I have slightly modified the logic of the palette analysis. Now, if the dark grey is really used in the PNGs, than its colour is modified normally, and we can hope that BDSup2Sub will use it when necessary. In the case of this SUP file, there is no dark grey in the PNGs, and therefore at the end of the analysis, the dark grey colour has not been modified in the original palette. When BD3D2MK3D detects this, it assumes that the bug described above can happen, and it changes the dark grey to black. That forces BDSup2Sub to replace the wrong grey it uses for the shadow with an (almost totally) black shadow.

It seems that this method works well, and I did a few tests with other streams as well. Currently, it seems that the other streams are still well converted to VobSub, and therefore that the modification I did has not broken something.

Conclusion:

The next version of BD3D2MK3D will have a workaround for the BDSup2Sub palette bug, but it works only for the conversions to VobSub. Unfortunately, there is no way to fix the palette bug happening when converting to BD SUP.

In the meantime, it is easy to "fix" the colours of the final 3D VobSub file with BDSup2Sub. Just load the stream, go to Edit -> Edit Default DVD Palette, click on the "dark grey" slot, select black in the palette (in the lower left corner), OK the two dialogues, be sure to select "SUB/IDX" for the Output Format and export the file. (It is also possible to fix the dark grey colour by editing the original IDX file, if you prefer. Simply change the "999999" with "000000" in the line beginning with "palette:".)

Help needed:

Of course, if someone can try to fix the bug in the source code of BDSup2Sub.jar, I would be very grateful. I don't know Java and I don't have the Java programming environment, but I can explain how to fix the bug and test beta versions. Someone is interested?

[De_Hollander]

Thanks for your test and time to investigate it.
In the meantime I change the color palette manual.

BD3D2MK3D is a great programm.
the 2nd reencode gives a great result, with great quality

with settings BD compatible, CRF 15, preset veryslow.
now powerdvd is not crashing.
The reason that the first encode was crashed in powerdvd maybe i'v behold too much audio streams and subtitels in it.

[r0lZ]

Thanks for the confirmation about PowerDVD. But it should not crash, even with a lot of streams. You should try a better player, such as PotPlayer.

And sorry for my rude reply earlier. I was unable to imagine that the grey yellow was created from pure black by BDSup2Sub.

[De_Hollander]

I normally use MPC HC

No problem for your earlier rude reply .

[De_Hollander]

I have a real3d film, with no subs.
Now i want mux the original sup file from the 2D blu-ray.
But tsmuxer set it to plane 0
That good.
But there is no dept /plane in the sup with playing the remux
Can BD3D2MK3D make a fixed dept/plane for real 3D?

[r0lZ]

No. It is easy to create a raw 3D-plane file with fixed depth values, but anyway, as far as I know, there is currently no way to embed it in the MVC stream before remuxing it. You would need a MVC encoder that supports the 3D-planes, and currently, the only free MVC encoder (the Intel) can't do that. In other words, if you re-encode a 3D BD (as AVC+MVC), the depth of the subtitles is irremediably lost. It's one of the big advantages of the SBS or T&B formats: you can keep the depth of the subtitles by including or hardcoding the 3D subtitle stream.

[De_Hollander]

so i can not give a depth to the sup, because the original MVC dont give it to the subtitel
set the plane to 0 in tsmuxer is not work for dat original blu-ray

[r0lZ]

Correct. Assigning a 3D-Plane number to a subtitle stream doesn't work if the 3D-Plane doesn't exist. And it is (currently) impossible to add a new 3D-plane to the video stream.

[r0lZ]

[Reply to a message by De_Hollander that has been deleted.]

Obviously the error message explains that lossless encoding cannot be made with profile high.
You have selected CRF 0, and indeed that means that you want to create a very huge lossless file. But anyway, your settings cannot work. The bluray-compat flag means (probably) that you want to burn a blu-ray disc, but the CRF 0 will produce a file with a bitrate way too high to be compatible with the blu-ray limitations. And anyway, even if the command is accepted, you will never find a blu-ray with a capacity sufficient to store the resulting video file.
Since the profile high is mandatory for the blu-ray compatibility, it is obviously impossible to encode with that parameters, even if you select another profile.
Try to use more coherent parameters, and a decent CRF value.
If you really want a lossless encoding (for what reason?) you should remove most of the other parameters, and certainly the blu-ray compatibility option.

[De_Hollander]

Yes indeed figure it out by myself whats the problem was. That's why i have delete my message.
I turned 0 to 1 and have no errors

[r0lZ]

Anyway, you CANNOT do a real CRF 1 (almost lossless) AND keep the blu-ray compatibility flag enabled at the same time, because the BD standard limits the bitrate to something much smaller than what you would need for CRF 1. It's not because there is no error message that you will obtain a real lossless and BD compatible file. I don't know what will be the winner, but I guess it's the BD compatibility options. Therefore, CRF 1 doesn't make sense. You should use a reasonable CRF value. IMO, below 16, it's completely crazy, unless you want to re-encode the result later, and in that case, it's the BD compatibility option that doesn't make sense.

[De_Hollander]

Originally Posted by r0lZ

Anyway, you CANNOT do a real CRF 1 (almost lossless) AND keep the blu-ray compatibility flag enabled at the same time, because the BD standard limits the bitrate to something much smaller than what you would need for CRF 1. It's not because there is no error message that you will obtain a real lossless and BD compatible file. I don't know what will be the winner, but I guess it's the BD compatibility options. Therefore, CRF 1 doesn't make sense. You should use a reasonable CRF value. IMO, below 16, it's completely crazy, unless you want to re-encode the result later, and in that case, it's the BD compatibility option that doesn't make sense.

??
I am not satisfied with quality with 15 and higher. I thought that how lower the number how better quality but how bigger the file.

What's de best setting?

[De_Hollander]

now i see 2 passes option and set the bitrate options.
How silly of me.
I try that with the 2passes and bitrate settings

[r0lZ]

There are no "best settings". They depends of your needs and the disc space you accept to give to the movie.

The problem is that the BD compatibility flag limits the bitrate. CRF 1 will only produce a huge file (without the BD compatibility flag) and you'll need a big hard disc for each movie you encode! Do you really want that? And if you leave the BD compatibility flag enabled, you will not have a better quality than what the BD standard permits, and therefore CRF 1 is not possible. You cannot have a better quality than the original BD anyway! If you CAN see the difference in CRF 15 or 16 with the original BD, then you're Superman! IMO, only analysis tools can detect the differences with such a low CRF.

You won't get a better quality with 2-pass. 2-pass encoding (and ABR) should be used only if you need to burn the final MKV on a disc with limited space, like a BD or DVD. It is totally useless to do the encoding in a mode that allows you to give the bitrate if the disc space doesn't matter. IMO, CRF mode is much better, as it adapts itself to the complexity of the movie, and you cannot be wrong. Of course if you select a reasonable CRF value.

BTW, many GUIs for x264 limit the CRF value to a reasonable range, like between 18 and 26. I should have made that too, but I prefer to let the user decide. But selecting intentionally a crazy value like CRF 1 doesn't make sense, and I'm beginning to regret my choice.

[De_Hollander]

Originally Posted by r0lZ

There are no "best settings". They depends of your needs and the disc space you accept to give to the movie.

The problem is that the BD compatibility flag limits the bitrate. CRF 1 will only produce a huge file (without the BD compatibility flag) and you'll need a big hard disc for each movie you encode! Do you really want that? And if you leave the BD compatibility flag enabled, you will not have a better quality than what the BD standard permits, and therefore CRF 1 is not possible. You cannot have a better quality than the original BD anyway! If you CAN see the difference in CRF 15 or 16 with the original BD, then you're Superman! IMO, only analysis tools can detect the differences with such a low CRF.

You won't get a better quality with 2-pass. 2-pass encoding (and ABR) should be used only if you need to burn the final MKV on a disc with limited space, like a BD or DVD. It is totally useless to do the encoding in a mode that allows you to give the bitrate if the disc space doesn't matter. IMO, CRF mode is much better, as it adapts itself to the complexity of the movie, and you cannot be wrong. Of course if you select a reasonable CRF value.

BTW, many GUIs for x264 limit the CRF value to a reasonable range, like between 18 and 26. I should have made that too, but I prefer to let the user decide. But selecting intentionally a crazy value like CRF 1 doesn't make sense, and I'm beginning to regret my choice.

Alle x264 re-encodes haves 4.1 flag.
it's confusing
what's it meanss BD compatibility flag in your program anyway ?
I would like to have bitrate of 13
the intention is to have a smaller file than the blu-ray with a bit rate of 13 to save hard disk space.
normaly 2 pass re-encoding is in the most re-encodings x264 program's the best option voor quality.
and cpu re-encoding gives the best results than GPU acceleration.

My re-encode result

General
Unique ID : 209672436581007914956263681669069436738 (0x9DBD7141F063F989B32D2A6D9A5A7742)
Complete name : F:\sharks3d 3D-SBS 1080p.mkv
Format : Matroska
Format version : Version 3 / Version 2
File size : 4.63 GiB
Duration : 41mn 35s
Overall bit rate mode : Variable
Overall bit rate : 15.9 Mbps
Movie name : sharks3d
Encoded date : UTC 2015-07-14 15:19:17
Writing application : mkvmerge v7.9.0 ('Birds') 32bit
Writing library : x264 0.146.2538 121396c / (libswscale 3.1.101) / (libavformat 56.23.106) / (ffmpegsource 2.17.4.0) / built by Komisar on Mar 1 2015, gcc: 4.8.4 (multilib.generic.Komisar) / x264 configuration: --bit-depth=8 --chroma-format=all / libx264 configuration: --bit-depth=8 --chroma-format=all / x264 license: GPL version 2 or later / libswscale/libavformat/ffmpegsource license: GPL version 2 or later / (32bit)
Original source form : Blu-ray 3D
Attachements : _ENCODE_3D_MOVIE.avs / _ENCODE.cmd / 3D-Planes.zip
TITLE : sharks3d
AUTHOR : BD3D2MK3D 0.66
ENCODER_SETTINGS : --bitrate 14000 --pass 1 --stats "00000.stats" --preset slow --tune grain --bluray-compat --profile high --level 4.1 --open-gop --keyint 24 --slices 4 --colormatrix bt709 --colorprim bt709 --transfer bt709 --b-pyramid strict --vbv-bufsize 30000 --vbv-maxrate 40000 --aud --frame-packing 3
DATE_ENCODED : 2015-07-14


Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
MultiView_Count : 2
MultiView_Layout : Side by Side (left eye first)
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 41mn 35s
Bit rate mode : Variable
Bit rate : 14.0 Mbps
Maximum bit rate : 40.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.282
Stream size : 3.97 GiB (86%)
Title : 3D Half-SBS (x264 BD compatible 2-pass 14000 Kbps preset slow, tune grain)
Writing library : x264 core 146 r2538 121396c
Encoding settings : cabac=1 / ref=4 / deblock=1:-2:-2 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.25 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=6,6 / fast_pskip=1 / chroma_qp_offset=-4 / threads=12 / lookahead_threads=2 / sliced_threads=0 / slices=4 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=1 / keyint=24 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=24 / rc=2pass / mbtree=1 / bitrate=14000 / ratetol=1.0 / qcomp=0.80 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=40000 / vbv_bufsize=30000 / nal_hrd=vbr / filler=0 / frame-packing=3 / ip_ratio=1.10 / aq=1:0.50
Default : Yes
Forced : No
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Color range : Limited



very good quality.

Now i'm going re-encode with CRF 15 preset: slower and tune :grain with force level to 4.1
I let you now the results.