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

[r0lZ]

Originally Posted by De_Hollander

Alle x264 re-encodes haves 4.1 flag.

That's not true. It is true that most encoding in h264 are in 4.1 (or 4.2) level, because 4.1 is the level of the BDs, and therefore most hardware players are compatible with that level. But most is not all. You can find encodings in level 5.0 or 5.1, but they are less popular, because very few hardware players support them. Level 5.0 is even necessary if you encode in full-SBS or full-T&B.

Originally Posted by De_Hollander

what's it meanss BD compatibility flag in your program anyway ?

The BD standard imposes certain limitations to the encodings, so that the hardware players do not need too large memory buffers or too fast hardware, in order to reduce the cost of the hardware players (and probably because level 4.1 was the current h264 level when the BD standard has been written). If you want to import the movie in a BD authoring tool, you have to encode it with the options that restrict the encoding to the BD level. The BD level is similar to level 4.1, but with a smaller maximum bitrate, and other limitations. Therefore, it is not sufficient to specify level 4.1 to be BD compatible. The flag in BD3D2MK3D sets the --bluray-compat as well as a bunch of other settings to respect the BD standard. If you want to know exactly what it sets, generate a project with the BD compatible option on, and then another one with the flag off, and compare the x264 commands in the _ENCODE.cmd files.

Anyway, if you do not want to build a blu-ray with your SBS, you don't need to set that flag. (Some peoples set it anyway to be sure to be compatible with all TVs and other hardware players, but IMO that's not necessary. Level 4.1 or even level 4.2 are accepted by the vast majority of players.) And anyway, if you set the CRF value to a very low level, it CANNOT be compatible with the BD standard, because the bitrate will be way to high. Therefore, I suggest to do your next encodings without the BD compatible flag, and with level 4,1 or 4.2 alone.

Originally Posted by De_Hollander

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.

13 is not a valid bitrate. You mean CRF 13, right? Anyway, if you specify the CRF (or CQ) mode, you cannot control the bitrate precisely. The encoder will take the decisions for you, according to the complexity of the movie. A very simple CGI animated movie for kids may be encoded with a very low bitrate with CRF 13, but a live film with many details and action scene will probably require a much greater bitrate for the same CRF. In both case, the final quality will be roughly equivalent, because the encoder will have taken the right decisions. In other word, specifying the CRF is roughly equivalent to specify the quality you want, while specifying the bitrate doesn't ensure a constant quality and, as I wrote above, should be used to specify the final file size only.

Originally Posted by De_Hollander

normaly 2 pass re-encoding is in the most re-encodings x264 program's the best option voor quality.

Totally wrong.

I agree that encoding in bitrate mode in 1 pass is the worst thing to do, because since h264 is a variable bitrate codec. Therefore, there is no way to know in advance what will be the ideal bitrate for each part of the movie. For example, if the movie is simple and has not many moving scenes at the beginning, the encoder will have much bitrate to waste. It will assign a bitrate to the easy scenes in order to have a final AVERAGE bitrate equal to the bitrate specified in the command line. But now imagine that the last part of the movie is terribly complex and has many action scenes (like in many action movies). The encoder will have already spent a big part of the bitrate to encode the easy parts, and it will have to encode the final scenes with the remaining bitrate, a too low bitrate for that difficulty. The quality of the end of the movie will be terrible!

Why is 2-pass is better than ABR? During the first pass, the encoder analyses the difficulty to encode each shot and image in the film, with a simplified encoding, and it saves a stats file. During the second pass, it uses the stats file to distribute the bitrate according to the difficulty of the different parts. That way, it can keep the bitrate for the difficult parts, and encode the easy parts with a smaller bitrate. That's a good solution, but note two things:
1) The first pass uses only a faster encode to estimate the difficulty. Therefore, it is not exactly as accurate than the second pass, and small errors in the bitrate distribution are still possible. Therefore, the 2-pass encoding is NOT perfect.
2) Using 2-pass makes sense ONLY if you need a specific file size. If you do NOT specify the file size (or, in other words, the bitrate), the encoder does NOT need to restrict itself to a certain overall bitrate, and therefore it will give EXACTLY what is necessary to obtain the best quality, during the first and only pass. Therefore, encoding in CRF mode gives PERFECT results in only one pass, and it's certainly better that GOOD results in two passes. It's also much faster.
I agree that many encodings are made in 2-pass, and you can read misleading howtos on the net that explain that 2-pass is better. It's simply absurd. Peoples think it must be better, because it's longer, but in fact, it's slightly less good.
Note also that some encoders do NOT have CRF or CQ options and REQUIRE to give a precise bitrate. It's the case, for example, of DVD-Fab. Since in that case, you can only encode in ABR or 2-pass, it is obviously better to use the 2-pass mode. But it's only because that encoder is very limited. With x264, you don't have that limitation.

Originally Posted by De_Hollander

and cpu re-encoding gives the best results than GPU acceleration.

I agree on this.

[De_Hollander]

normaly a good movie x264 encode, haves result to a Bit rate with 10.2 Mbps
That's what i mean with (13) Bit rate: 13.0 Mbps
You can see the results on the info the page before

[r0lZ]

Again, the final bitrate is not an evidence of good or bad quality.

For example, if you encode a totally black clip, a bitrate almost equal to 0 is largely sufficient to obtain a perfect quality. But if you encode a movie where all images are totally different from each other, 13.0 Mbps is certainly not enough to have a decent quality.

Don't trust the guides and other noise found on the internet. There is NO good or bad bitrate. Only good or bad quality. And if you look closely to your movie and you cannot see the difference with the original, that means that the quality is excellent, regardless of the bitrate.

Also, don't forget that the bitrates recommended on many sites are for DVD-Fab or similar bad encoders. If you use x264 (especially with a slow preset) you can certainly divide it by 2 and 3 and still obtain a better quality.

Do not be obsessed by the bitrate. It doesn't means much in term of quality.

BTW, I have also seen that you have enabled the "grain" tuning. IMO, it's a bad idea. It will probably degrade the final quality, unless you give a very high bitrate. IMO, you should only use the "animation" tune when you encode a classic animated movie like an old Disney or Tex Avery, with large flat areas (not modern CGI). Other tune options should be avoided, unless you know exactly what you are doing.

[De_Hollander]

i give the result from de output quality, thats what i mean.
I know bitrate say's noting and more data say's also noting.

I'm just do some test.
I used grain because there is grain in the movie.

13.0 mbps gives a verry good quality result, on mij test.

that is not constant 13.0 mbps, because the bitrate is also much higher at different times

Now iám re-encoding with these settings



I have also re-encoded many blu-ray's with bdrebuilder, with profiles.
And have used different profiles. for animation movies, the profile animation.
for movies with a lot of grain the grain profile.
etcetera

I take the same movie for al the encode test.
there are many grain into the movie. That why i used the profile grain.
There is mean to be that option for it, i think.
These CRF mode encoding test takes a longer time. It is/t faster but the opposite.


why is there no setting for cpu managing?
Preset: Is that binding with cpu encoding script, for giving more quality?
ore cpu using? I assume slower is better

[De_Hollander]

results


General
Unique ID : 245916863071583757788091510176232238669 (0xB901DD73635FAEFE9C859BF38997EE4D)
Complete name : C:\Users\Edwin\Documents\sharks_3d\00000\sharks_3d 3D-SBS 1080p.mkv
Format : Matroska
Format version : Version 3 / Version 2
File size : 10.1 GiB
Duration : 41mn 35s
Overall bit rate : 34.9 Mbps
Movie name : sharks_3d
Encoded date : UTC 2015-07-14 20:48:38
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 : sharks_3d
AUTHOR : BD3D2MK3D 0.66
ENCODER_SETTINGS : --crf 15 --preset slower --tune grain --level 4.1 --vbv-bufsize 78125 --vbv-maxrate 62500 --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 : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 41mn 35s
Bit rate : 32.2 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.648
Stream size : 9.36 GiB (92%)
Title : 3D Half-SBS (x264 high@L4.1 CRF 15 preset slower, tune grain)
Writing library : x264 core 146 r2538 121396c
Encoding settings : cabac=1 / ref=4 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.25 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=6,6 / fast_pskip=1 / chroma_qp_offset=-4 / threads=12 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=15.0 / qcomp=0.80 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=62500 / vbv_bufsize=78125 / crf_max=0.0 / nal_hrd=none / filler=0 / frame-packing=3 / ip_ratio=1.10 / aq=1:0.50
Default : Yes
Forced : No

Audio #1
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Mode : 16
Format settings, Endianness : Big
Codec ID : A_DTS
Duration : 41mn 35s
Bit rate mode : Constant
Bit rate : 1 509 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 449 MiB (4%)
Title : English (DTS 5.1 48KHz)
Language : English
Default : Yes
Forced : No

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 41mn 35s
Bit rate mode : Constant
Bit rate : 448 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 133 MiB (1%)
Title : Nld (AC3 5.1 48KHz)
Language : Dutch
Default : No
Forced : No

Text #1
ID : 4
Format : PGS
Codec ID : S_HDMV/PGS
Codec ID/Info : The same subtitle format used on BDs/HD-DVDs
Title : Nld 3D (BD SUP)
Language : Dutch
Default : No
Forced : No

Text #2
ID : 5
Format : VobSub
Codec ID : S_VOBSUB
Codec ID/Info : The same subtitle format used on DVDs
Title : Nld 3D (VobSub)
Language : Dutch
Default : No
Forced : No

Text #3
ID : 6
Format : PGS
Codec ID : S_HDMV/PGS
Codec ID/Info : The same subtitle format used on BDs/HD-DVDs
Title : Nld forced 3D (BD SUP)
Language : Dutch
Default : No
Forced : Yes

Text #4
ID : 7
Format : VobSub
Codec ID : S_VOBSUB
Codec ID/Info : The same subtitle format used on DVDs
Title : Nld forced 3D (VobSub)
Language : Dutch
Default : No
Forced : Yes

Menu
00:00:00.000 : :1 - 0:00:00
00:05:29.870 : :2 - 0:05:30
00:11:20.096 : :3 - 0:11:20
00:17:36.305 : :4 - 0:17:36
00:22:36.480 : :5 - 0:22:36
00:27:26.769 : :6 - 0:27:27
00:34:31.527 : :7 - 0:34:32
00:38:43.152 : :8 - 0:38:43
00:41:35.659 : :9 - 0:41:36


My first re-encode (x264 BD compatible 2-pass 14000 Kbps preset slow, tune grain) are a lot smaller (dubbel smaller) with the same quality.(with the same blu-ray bitrate) then the Test with CRF mode.
Test with CRF mode: The bitrate are higher than the original blu-ray.
Next test tomorrow CRF mode with 23

[De_Hollander]

Now the results CRF mode with 21 (with no grain "grain" tuning enabled)

info
Format : Matroska
Format version : Version 3 / Version 2
File size : 2.46 GiB
Duration : 41mn 35s
Overall bit rate : 8 483 Kbps
Movie name : Sharks3D
Encoded date : UTC 2015-07-14 23:56:11
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 : --crf 21 --preset slower --level 4.1 --vbv-bufsize 78125 --vbv-maxrate 62500 --frame-packing 3
DATE_ENCODED : 2015-07-15

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 : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 41mn 35s
Bit rate : 6 357 Kbps
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.128
Stream size : 1.85 GiB (75%)
Title : 3D Half-SBS (x264 high@L4.1 CRF 21 preset slower)
Writing library : x264 core 146 r2538 121396c
Encoding settings : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=21.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=62500 / vbv_bufsize=78125 / crf_max=0.0 / nal_hrd=none / filler=0 / frame-packing=3 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No



Disapointed results, mircoblokking. To low bitrate.
I should be enableding graintuning for better results.
What I also previously thought to have to do


2 passes gives the best results.
with give manualy 13.0 mbps

[r0lZ]

Originally Posted by De_Hollander

I used grain because there is grain in the movie.

That may be OK, but don't forget that grain is extremely difficult to compress. The first thing that all encoders do to compress better is removing the grain. If you force the encoder to keep it, it will need to regain some bitrate by other means, and you will probably end up with a poor quality. Or a very large file.
Also, I'm not sure the grain tuning is the best way to preserve the grain. Someone has explained earlier in this thread that it's not a good option. (Sorry, I'm too lazy to search the thread, but you should find the post easily.)

Originally Posted by De_Hollander

why is there no setting for cpu managing?

I can't include all x264 options in the GUI. I want to keep it simple.
But you can add your own options in the Additional options field. For example, you can add --threads 3 to force the encoder to use only 3 CPU cores.

Originally Posted by De_Hollander

Preset: Is that binding with cpu encoding script, for giving more quality?
ore cpu using?

Sorry, I don't understand.
Anyway, the preset is not related at all to the CPU. Selecting a slow or fast preset do not mean that the CPU will be used differently. The presets determine the settings of the most complex options that will be used by the encoder. See the x264 doc for a list of the options that are modified by the presets.

Originally Posted by De_Hollander

I assume slower is better

The presets change many x264 settings. Normally, the slower the best, but take in mind that if you select a slow preset, you may end up with a level greater than 4.1. It's why I have added the "force level" option, to be sure that a specific level will never be exceeded, regardless of the preset used.
Take care also. The Placebo preset is really extremely slow!

Usually, my settings are: CRF (18 to 22 depending of the quality I want for that specific film), Preset slower, Tune none, Force level 4.1, --threads 3, BD compatible not ticked. I have always had excellent results with that settings.

Originally Posted by De_Hollander

My first re-encode (x264 BD compatible 2-pass 14000 Kbps preset slow, tune grain) are a lot smaller (dubbel smaller) with the same quality.(with the same blu-ray bitrate) then the Test with CRF mode.

How can you be sure that it's "the same quality"? If you cannot see a difference, it's great, but if the file size is very different, it's because there is a difference in quality, even if you cannot see it. (It's why it is useless to use very low CRF values. The human eye cannot see subtle differences, and forcing a very high quality has only the effect of enlarging the file size for no good reason.

Originally Posted by De_Hollander

Test with CRF mode: The bitrate are higher than the original blu-ray.

That's what happens when you use a crazy CRF value, way to low.

Originally Posted by De_Hollander

Next test tomorrow CRF mode with 23

CRF 23 is the default (from the x264 team, not BD3D2MK3D), and I think that that value has been very well chosen. It gives excellent compression, while maintaining a reasonable quality. No visible artefacts, but the image is a little bit less sharp than the original. The final MKV file size is usually around 4 GB. That's really less than most encoding you can find on the internet, but if you use a slow preset, it's sufficient. However, personally, I prefer to lower that value a bit, and I use normally a CRF around 20 or 21. For movies with extra sharp and very detailed pictures, such as Sin City 2, I prefer even a lower bitrate, like 18 or 19.

You may think that 2-pass is better, but again, it's not true. The same movie with the same bitrate and the same parameters is encoded exactly the same way. The only real difference is that you cannot predict the exact bitrate in CRF mode, while it is easy to control it in 2-pass.

Also, the CRF mode is intelligent enough to give more bitrate to the parts that are really important (such as slow shots with many details) and less bitrate to the shots with rapid movements, because when you watch the film normally, you cannot see the (relatively) poor quality of these shots. Of course, if you examine closely a single image taken from one of these shots, you can see the problems. You have to watch the movie like a real spectator to evaluate the real quality of the encoding.

Anyway, you are free to do what you want.

[De_Hollander]

i'v tested again with these settings



output

Format : Matroska
Format version : Version 3 / Version 2
File size : 5.82 GiB
Duration : 41mn 35s
Overall bit rate : 20.0 Mbps
Movie name : Sharks3D
Encoded date : UTC 2015-07-15 11:48:30
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 : --crf 18 --preset slower --tune grain --level 4.1 --vbv-bufsize 78125 --vbv-maxrate 62500 --frame-packing 3
DATE_ENCODED : 2015-07-15

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 : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 41mn 35s
Bit rate : 17.7 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.356
Stream size : 5.14 GiB (88%)
Title : 3D Half-SBS (x264 high@L4.1 CRF 18 preset slower, tune grain)
Writing library : x264 core 146 r2538 121396c
Encoding settings : cabac=1 / ref=4 / deblock=1:-2:-2 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.25 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=6,6 / fast_pskip=1 / chroma_qp_offset=-4 / threads=12 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.80 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=62500 / vbv_bufsize=78125 / crf_max=0.0 / nal_hrd=none / filler=0 / frame-packing=3 / ip_ratio=1.10 / aq=1:0.50
Default : Yes
Forced : No


but I have this re-encode compared with to the 2 passes encode
the 2 passes gives a sharper image even though it is smaller

This is the last test for me.

[r0lZ]

This release fixes the (last?) problem with the BDSup2Sub palette in VobSub mode, discussed above.

There are also improvements to some tools, and a new tool to easily remove subtitles from a XML/PNG stream (for example to convert the subtitles for hearing impaired to normal subtitles by removing the descriptive subtitles and leaving only the dialogs).

# v0.67 (July 16, 2015)
# - Tools -> Chapters File Converter: New possibility to grab the chapter names from another chapter file.
# - Tools -> Convert audio file to AC3 or AAC: It is now possible to convert the audio tracks directly from a MKV/MK3D/MKA file without demuxing them first.
# - Added Tools -> Remove selected subtitles from XML/PNG.
# - Workaround for another BDSup2Sub bug: Slightly modified method to generate the palette used when converting 2D SUP to 3D VobSub.
# - Minor cosmetic changes.
# - Updated MkvMerge, MkvPropEdit and MMG to the latest version (v8.0.1)

Download: BD3D2MK3D.7z

[De_Hollander]

Originally Posted by r0lZ

This release fixes the (last?) problem with the BDSup2Sub palette in VobSub mode, discussed above.

There are also improvements to some tools, and a new tool to easily remove subtitles from a XML/PNG stream (for example to convert the subtitles for hearing impaired to normal subtitles by removing the descriptive subtitles and leaving only the dialogs).

Download: BD3D2MK3D.7z

Thank you

[r0lZ]

Thanks for the thanks! ;-)

Originally Posted by De_Hollander

but I have this re-encode compared with to the 2 passes encode
the 2 passes gives a sharper image even though it is smaller

Well, I have just finished some tests to compare the result of the CRF and 2-pass modes.

I have encoded a short clip (about 6 minutes) in CRF 20 two times, with the SSIM option and then with the PSNR. Then, I have noted the bitrate of the generated video stream, and encoded the same clip in 2-pass mode, with that bitrate, to obtain approximately the same file size. Again, I have encoded the clip two times, to obtain the SSIM and PSNR stats.

Of course, in all tests, I have not modified any other parameter. All encodings were made with preset slower and level 4.1. (The tune was set to ssim or psnr, but that settings are necessary to optimise the stats, and should not modify the video. But I cannot use the grain tune at the same time, so you have to consider that the encodings were made with tune "none".)

Here are the results of the tests:

CRF 20, preset slower, force level 4.1:
Encoding speed: 6.16 fps (encoding duration: 0:24:17.5)
SSIM Mean Y:0.9845501 (18.111db)
PSNR Mean Y:46.713 U:48.811 V:48.073 Avg:47.079 Global:46.399 kb/s:2532.32
Resulting video bitrate: 2532.09 kbps

2-pass 2532 kbps, preset slower, force level 4.1:
Encoding speed: 10.23 fps (pass 1) and 6.55 fps (pass 2) (total encoding duration: 0:37:27.5)
SSIM Mean Y:0.9845700 (18.116db)
PSNR Mean Y:46.698 U:48.799 V:48.058 Avg:47.067 Global:46.381 kb/s:2535.43
Resulting video bitrate: 2535.42 kbps

At the end of pass 1, this information was given:
SSIM Mean Y:0.9819845 (17.444db)
PSNR Mean Y:45.226 U:47.875 V:47.216 Avg:45.743 Global:44.857 kb/s:2542.13
Final ratefactor: 21.49

If you don't know how to interpret the SSIM and PSNR values, don't worry, me too I don't know. But I know that in both cases, higher values means better quality (or, more precisely, better similarity with the source video). A SSIM of 1.0 means lossless.

Therefore, as you can see, the encoding in CRF 20 mode is (slightly) better than the 2-pass encoding, for a slightly smaller file size. The CRF more is clearly the winner. These are objective values, not what the human eye sees. That doesn't mean that the encoding is "better" in CRF mode, because an human may prefer a video slightly sharper or softer than the original, and some artefacts that are detected by the SSIM or PSNR procedures may be invisible for the human eye. But at least these values are indisputable facts. The CRF encoding IS closer to the original source than the 2-pass encode.

Also, note the speed of the encoding. In 2 pass mode, the two encodings are shorter than the CRF pass, but pass 2 is almost as slow. And when you add the durations of the 2 passes together, the total duration is MUCH MUCH longer. About 1.5 times slower... for a slightly less good quality.

I have also posted the SSIM and PSNR values displayed after the first pass too, for your information only. Of course, they are less good than CRF or the 2nd pass, but that's normal, because it's the "fast first pass" necessary only to generate the stats. And it's why the first pass is "fast" than the result of the second pass cannot be perfect. If you want a better first pass, there is an option to turn off the fast first pass, and compute everything like in the 2nd pass. That setting may improve slightly the final quality in 2-pass mode, but of course, the total duration of the encoding will be even longer. Probably around 2 times the duration of the CRF pass.

A very interesting information displayed after the first pass in 2-pass mode is the final ratefactor. It's the ratefactor that will be used in pass 2 to obtain the target bitrate. As you can see, in my test, it is 21.49. CRF means "Constant Rate Factor", and in my CRF test I have used 20. The CRF value of the 2-pass encoding is greater, and as you know, a greater CRF means a less good quality. (I don't know if there are other small differences between CRF mode and 2-pass, but anyway a ratefactor greater than 20 is less good than 20.)

In conclusion, my tests confirm that 2-pass is slightly less good, and totally useless when it is not necessary to obtain a very precise final file size. I agree that the difference in quality is minor, but it exists, and I see no reason to waste much encoding time to do 2 passes when an encoding in one pass CRF is much more rapid. In fact, using CRF or 2-pass is approximately equivalent, and the first pass consists mainly (only?) in determining the CRF value to use during the second pass in order to obtain the specified bitrate. Do you really need to spend much time just to know a value that you could have specified directly in the GUI? Imo, it's only a waste of time and CPU power, not good for you and the planet.

I must say that it is possible that the difference with the two methods may vary from movie to movie, and perhaps also if you use some other parameters, such as the "grain" tuning. But in general, the quality of a CRF encoding must be considered as equivalent or slightly better than the quality of 2-pass, only much faster.

And don't forget the other advantage of CRF over 2-pass. It will produce a smaller file when the movie is easy to compress, or a larger file when it is difficult, automatically. In 2-pass, you must know exactly what bitrate you have to give to a certain movie to obtain the quality you want, and without a close analysis (that an human cannot do accurately), it's impossible to determine. CRF does it for you, free of charge.

I don't know what you did to see big quality differences in your tests, but you must have made something wrong, or changed other parameters (like the grain) between the two tests. Anyway, I continue to think that CRF is the better way to encode much (all?) movies, and it will stay the default mode in BD3D2MK3D.

[sneaker_ger]

x264 devs always said that CRF and 2pass are roughly equal and if anything CRF has the slight upper hand. (2pass algo has to do some slight adjustments over the course of the encode to hit target while CRF is "free")

Originally Posted by r0lZ

In 2 pass mode, the second pass is slightly LONGER than the CRF pass.

No, 6.55 fps is faster than 6.16 fps. Some work (frame type decision) is already done in first pass and the whole stats calculations should be negligible compared to that so second pass is supposed to be faster than CRF.

Originally Posted by r0lZ

A very interesting information displayed after the first pass in 2-pass mode is the final ratefactor. It's the ratefactor that will be used in pass 2 to obtain the target bitrate. As you can see, in my test, it is 21.49. CRF means "Constant Rate Factor", and in my CRF test I have used 20. The CRF value of the 2-pass encoding is greater, and as you know, a greater CRF means a less good quality. (I don't know if there are other small differences between CRF mode and 2-pass, but anyway a ratefactor greater than 20 is less good than 20.)

Be careful when interpreting these values.

[r0lZ]

Originally Posted by sneaker_ger

x264 devs always said that CRF and 2pass are roughly equal and if anything CRF has the slight upper hand. (2pass algo has to do some slight adjustments over the course of the encode to hit target while CRF is "free")

It's what I have tried to explain above. Thanks for the confirmation.

Originally Posted by sneaker_ger

No, 6.55 fps is faster than 6.16 fps. Some work (frame type decision) is already done in first pass and the whole stats calculations should be negligible compared to that so second pass is supposed to be faster than CRF.

Yep. I have noticed my error, and modified my previous post while you were replying.

Originally Posted by sneaker_ger

Be careful when interpreting these values.

I agree that it's not easy. But normally, CRF 21.5 is always less good than CRF 20, right?
But I don't know if "Constant" in CRF is important. I wonder if the computed ratefactor during pass 1 is strictly equivalent to the CRF value in CRF mode?

[sneaker_ger]

Originally Posted by r0lZ

But I don't know if "Constant" in CRF is important. I wonder if the computed ratefactor during pass 1 is strictly equivalent to the CRF value in CRF mode?

It's not, not even roughly. That's what I meant by saying "be careful".

[r0lZ]

OK, thanks.

[frank]

Congratulations to r0lZ. The explainations are very properly.

PSNR (in dB) is the mathematical right value describing the difference from the original.
I can remember that (global)

PSNR > 45 dB you cannot see any differences
PSNR > 44 dB very good
PSNR > 43 dB good
PSNR > 41 dB enough for grained sources

Use of CRF < 15 results in larger file sizes than the original.
Then you'd better use your original BD.

And I ask you, people: trust r0lZ. He has enough experience (since MPEG times). This is a thread about a 3D tool and not about basiscs of X264 encoding!

[r0lZ]

Thanks for the confirmation. But I can't totally agree on my supposed experience in x264 encoding. In fact, I don't understand the inside of h264 encoding much and I'm never sure of the correct usage of a specific parameter. But I know for sure that wasting our time in 2-pass encoding when the final file size is not important is absurd. I did some tests to confirm that supposition, and indeed I was right.

Now, I agree that discussion of the "best parameters" to encode a movie should be made in a thread specific to h264/x264, and not here. Thanks for that reminder too.

[De_Hollander]

sorry but my test gives me better results with 2 passes blu-ray compatible with giving manual bitrate of 14mbitps.
I have encoding blu-ray for many years.
Look for the bitrate from the original blu-ray with bdinfo, never give higher bitrate than the blu-ray.
So the blu-ray haves 28 mbps , i' give manualy average 14 mbps, with blu-ray compatibel that's alway's a good bitrate for a 1080p x264
Output :
File size : 4.63 GiB
Duration : 41mn 35s
Bit rate mode : Variable
Bit rate : 14.0 Mbps

You always get a good ratio proportion bitrate and file size.
I have tested many times with CRF with 21 but gives a to small file, and have see microblocking.
So you have see a result Bit rate : 6 357 Kbps (not good) tested with 42 minutes movie blu-ray 12 gig.
encode output was


File size : 2.46 GiB
Duration : 41mn 35s
Bit rate : 6 357 Kbps


r0lZ say's "blu-ray compatible, it's have limit's." No the bitrate beneath 40 is alway's good for a 1080p x264 encode.
higher bitrate than blu-ray is not normal, and gives problems with mediaplayers en streaming.
x264 1080p encode bitrate must be lower, then blu-ray. It's not normal x264 1080p blu-ray encode with higher bitrate then blu-ray, with a smaller file size.


This test
ENCODER_SETTINGS : --crf 18 --preset slower --tune grain --level 4.1

Duration : 41mn 35s
Bit rate : 17.7 Mbps
Width : 1 920 pixels

This encode is bigger in file, but haves not a sharp image like the
2 passes blu-ray compatible with giving manual bitrate of 14 MBps encode.
File size : 4.63 GiB
Duration : 41mn 35s
Bit rate mode : Variable
Bit rate : 14.0 Mbps

[r0lZ]

Please stop this useless discussion. I don't see the point in asking information here if you do not take it into account anyway. And as repeated two times, it's not the right thread to discuss x264 encoding.

[r0lZ]

This release fixes an important bug introduced with v0.67. The program may crash at the end of the processing if it has to convert to 3D a subtitle stream with a few forced subtitles extracted from a larger stream (with the "forced captions only" option in tab 2).

It fixes also a GUI bug during the conversion of an audio stream to AC3 or AAC, but less important because it can happen only when using the Convert Audio tool.

Important: I have also removed mmg.exe (and the "MkvMerge GUI" entry in the Tools menu) because mmg.exe is now obsolete, and has been replaced with mkvtoolnix-gui.exe. I have decided to not include the new MkvToolnix GUI, because I don't think many users need it, and it is difficult to control if the MKV compatibility options (specified with the Settings menu of BD3D2MK3D) are active when the GUI is launched. Having to manage two different sets of options was confusing and dangerous.
Please note that if you overwrite the BD3D2MK3D folder with this version, without deleting it first, mmg.exe will be automatically deleted from the BD3D2MK3D\toolset directory when BD3D2MK3D v0.68 is launched for the first time. I don't want to leave an outdated version of that program in the toolset.
If you want to manually mux your MKV files, download MkvToolnix and install it elsewhere, and use preferably the new MkvToolnix GUI. Don't forget to add the compatibility options you may need in the "Merging" tab of its Preferences window. (mmg.exe is still distributed with the current version of MkvToolnix, but I suppose that it will be removed relatively soon. If you continue to use it, you may also need to add the compatibility options in its preferences.)

# v0.68 (July 20, 2015)
# - Added verification of the disc space before launching the demux process.
# - Fix Tools -> Convert Audio: Cannot convert audio streams with spaces in the file name.
# - Fixed bug when generating the VobSub palette of a subtitle stream with forced captions only.
# - Updated MkvMerge and MkvPropEdit to the latest version (v8.2.0)
# - Removed mmg.exe (MkvMerge GUI), now obsolete. Install MkvToolnix if you need it.

Download: BD3D2MK3D.7z