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

http://i.imgur.com/ON2kCqD.jpg


3d sup
http://i.imgur.com/EsOgrxT.jpg

3d vobsub
http://i.imgur.com/EwZzUgO.jpg

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
http://i.imgur.com/AOztFyu.jpg

[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]

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]

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.

[r0lZ]

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.
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.
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.
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.
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

http://i.imgur.com/dM0B9jc.png

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]

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.)
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.
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.
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.

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.
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.
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

http://i.imgur.com/JAPVDP5.png

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 (http://forum.doom9.org/showthread.php?p=1727104#post1727104).

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 (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

[De_Hollander]

This release fixes the (last?) problem with the BDSup2Sub palette in VobSub mode, discussed above (http://forum.doom9.org/showthread.php?p=1727104#post1727104).

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 (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)Thank you:goodpost:

[r0lZ]

Thanks for the thanks! ;-)

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")

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.

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]

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.
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.
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]

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 (https://www.bunkus.org/videotools/mkvtoolnix/downloads.html#windows) 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 (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

[De_Hollander]

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 (https://www.bunkus.org/videotools/mkvtoolnix/downloads.html#windows) 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.)

Download: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)Thanks for the post.:thanks:

[r0lZ]

I have just noticed that Tools -> Add Current Album Art to MKV File doesn't work any more. It's not due to a bug in my code, but to a broken mkvpropedit.exe. In the latest version of BD3D2MK3D, I have included mkvmerge and mkvpropedit taken from v8.2.0 of MkvToolnix. Unfortunately, mkvpropedit v8.2 is broken and cannot add attachments to MKV files any more.

I will not release a new version of BD3D2MK3D just for that, but if you want to add cover art attachments to an existing MKV file with BD3D2MK3D, you should replace mkvpropedit.exe in the toolset directory with an older version. I don't know exactly when that bug has been introduced. Perhaps with v8.0? Anyway, I have tried v7.6.0 (because I have it here), and it works perfectly. So, if you can't get a working version of mkvpropedit, you can download mkvpropedit_v7.6.0.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/mkvpropedit_v7.6.0.7z) and extract the exe in your toolset directory.

Of course, I have posted a bug report at the MkvToolnix bugs tracker, and hopefully the next version of mkvpropedit will work fine. I will release an update of BD3D2MK3D at that time.

Note that adding cover art to a BD3D2MK3D project should work fine, because the attachments are added with mkvmerge, at mux time. Mkvpropedit is only necessary to add attachments to an existing MKV file (and is only used by the Cover Art option of the Tools menu).

[EDIT] After a contact with Moritz Bunkus (the author of MkvToolnix), it appears that the bug is in a recent version of a library used by mkvtoolnix. But it is sufficient to copy a magic file in the toolset directory and the latest version of mkvpropedit will work fine. So, you don't need to replace mkvpropedit with an outdated version. Just download the "magic.mgc" file (http://download.videohelp.com/r0lZ/BD3D2AVS/mkvtoolnix%20v8.2.0%20magic%20file.7z), and place it in the sub-directory "data" in the toolset directory. So, you must have this:
BD3D2MK3D_installation_path\toolset\data\magic.mgc
I have checked here and indeed that works fine.
If you have installed the whole MkvToolnix package, you can also simply copy the data directory from your installation of MkvToolnix to the toolset directory.
Of course, the next update will include that magic file directly in the BD3D2MK3D distribution.

[Polar]

Hi,

Just tested your software, but am having some trouble finding how to get the right settings. What I am trying to do is to convert my 3D movie so I can stream it from my Plex media server. The Plex client is a Roku 3 box. the playback is done on a 3D ready DLP projector.

From what I've been reading, DLP projectors only support 2x720p Frame Sequential, not 1080. Is there a way to do this by using BD3D2MKV3D? If not, any suggestions?

By the way, I'm using DLP-Link + glasses that support both120 Hz and 144 Hz

Best regards

[r0lZ]

Welcome to the Doom9 forums, Polar.

Unfortunately, currently BD3D2MK3D doesn't support frame sequential packing. It supports only the Side By Side or Top And Bottom packing methods. However, it is possible to create SBS or T&B files in 720p and full resolution.

I don't own Plex or a DLP projector, and therefore I don't know if Plex can split the two frames and send them as frame sequentail to the projector. You will have to try.

Anyway, all settings related to the resolution of the video are in the last tab. To do full-SBS in 720p, you should select "Side by Side", untick the "Full" option and tick the "Resize video to 720p". That settings are the closest of what you need, but the player or the monitor must be able to split the SBS image to two views.

Also, note that due to a limitation in the VobSub and BD SUP subtitle formats, you cannot have real 3D-subtitles (with the right depth) when using Full-SBS or Full-T&B. You can however hardcode the subtitles on the video stream when you encode the video, and they will be in 3D with the right depth.

Sorry if that doesn't help you much, but I have been unable to find the 3D characteristics of your hardware on the net.

[Polar]

Thank you for swift reply. Plex can do transcoding, but not for what is concerned 3D. I plays the file as-is.

I have been emailing with a forum member "tal.aloni". He has found a solution to recode 3D to 2x720p Frame Sequential for playbak on PS3. I have tested these demo files and the work great on my projector, played over Plex. But is a manual process.

Maybe this could be something interesting for you to have a look at. The thread is here: http://forum.doom9.org/showthread.php?t=170863.

As I wrote in my email to "tal.aloni":

"In this era of Home theaters and DLP 3D ready projectors flooding the marked, I find it a shame that no easy software solution is available for less tech-savvy persons like myself. 3D BDs just won't play on these low budget projectors unless they are in the right format.

As a conclusion it would be nice to find a user friendly solution that offers the flexibility to do just that. Convert 3D BDs to a format that allows one to store it on a media server and play back on the mentioned widely available hardware. Maybe with the help from professionals like you this can become a reality."

In other words, the solution is there, it only needs to be wrapped up in a nice and user friendly package :). Let me know what you think.

[r0lZ]

Well, I have always wanted to add the frame sequential packing, but I did not it yet, because there is no real demand for that packing method.

It should be possible to modify the avs script easily to change the output. It is also very simple to modify the mux option file. If I have some time in the next days, I'll try to implement it. However, there are a few things I need to know.

- Is is a well established standard for the order of the frames? Is it left view first like for SBS and T&B? (Anyway, it will NOT be possible to swap the order from the GUI, and therefore it is important to know the answer.)

- What frame rate should I use? All 3DBDs are encoded in 23.976 fps. I suppose therefore that I need simply to use 47.952 (or, more precisely, 48/1.001 fps). Correct?

Also, note that the encoding may be difficult and produce relatively big files for a relatively low quality, due to the difficulty for x264 to analyse the movement of the objects on screen if they jump back and forth to the left and right views, and compress that different views efficiently. But that's another problem.

I will try to do some tests this evening, and perhaps I'll be able to post tomorrow an explanation of what should be changed in the AVS script and Mux 3D options file to encode the movie in frame sequential mode. Stay tuned.

[Polar]

Left or right eye first? According to this document (http://lists.gnu.org/archive/html/bino-list/2013-03/pdfz6rW7jUrgI.pdf) 3D Input Format Requirements for DLP® Projectors using the new
DDP4421/DDP4422 System Controller ASIC , it is said that:

"The last active line in each stereo pair (left and right frames) shall alternate between two
frames of green (G=255, R=0, B=0) and two frames of magenta (G=0, R=255, B=255).
The left eye frame must always be transmitted first in each stereo pair."

The projector has a setting to set the sequence in reversed order, just in case of, and I found in the manual of my 3D glasses that there is a button that has the same function. I could test this if I had a 2 30 second files, one with left first, the other with right first.

Frame rate? Not sure. When looking at "tal.aloni" his BigBuckBunny-720p-3D.mp4 I see the following information in my player:

Video Resolution 720p
Duration 10:34
Bitrate 6043 kbps
Width 1280
Height 720
Aspect Ratio 1.78
Container MP4
Video Frame Rate 60p
Web Optimized No
Has 64bit Offsets 0

Video

Codec H264
Bitrate 5757 kbps
Language English
Bit Depth 8
CABAC 1
Chroma Subsampling 4:2:0
Color Space yuv
Duration 10:34
Frame Rate 60.000 fps
Frame Rate Mode cfr
Has Scaling Matrix 0
Height 720
Level 4.0
Profile high
Ref Frames 4
Scan Type progressive
Stream Identifier 1
Width 1280
Lyd

Codec AAC
Channels 5.1
Bitrate 279 kbps
Language English
Audio Channel Layout 5.1
Bitrate Mode VBR
Duration 10:34
Profile lc
Sampling Rate 48000 Hz
Stream Identifier 2

As a last note I can tell that my glasses have a refresh rate that supports 96Hz, 100Hz, 120Hz as well as 144Hz . From what I understand 144Hz is the new and better standard. Note sure where this fits in when discussing adding frame sequential packing. But I just give this as additional information for you.

Maybe "tal.aloni" has more usefull information in the thread I referred to?

[r0lZ]

"The last active line in each stereo pair (left and right frames) shall alternate between two
frames of green (G=255, R=0, B=0) and two frames of magenta (G=0, R=255, B=255).
The left eye frame must always be transmitted first in each stereo pair."
Honestly, I don't know why it should be necessary to modify the last active line of each frame. Is it really a standard for frame-sequential? Anyway, I will probably never implement that. Normal frames should be sufficient.

That quote confirms also that it's probably the left-frame first that is the standard for the DLP projectors. Good thing.

[r0lZ]

OK, I did some modifications to a few files and I am currently encoding a little clip. That should work. If you want to try yourself, follow this mini guide.


Use the GUI with the settings to encode in Half-SBS, 720p.
Do NOT use the 3D mode for the subtitles (in tab 2). However, you can hardcode the subtitles over the video (in tab 5).
Do not specify "Add N seconds of black at the beginning of the video" in tab 5.
You can specify "Add N seconds of black at the end of the video", but take in mind that you must specify two times the duration (for example specify 10 to obtain 5 seconds).

When the project is created, modify the following files:

_ENCODE.cmd:

Modify the 2 (or 4 for 2-pass) occurrences of -frames. The number of frames must be doubled.
Change "--frame-packing 3" (or 4) to "--frame-packing 5"
Remove the argument "--qpfile chapters_3D.qpfile" OR modify the chapters_3D.qpfile file (see below).
Not really mandatory: add "--fps 48000/1001" in the x264 command.

_ENCODE_3D_MOVIE.avs
Replace this section:

# Build combined Side-by-Side image
StackHorizontal(Left, Right)
AssumeFPS("ntsc_film")

# Resize to 720p
BicubicResize(2560, 720)

with this:

Interleave(left, right)
AssumeFPS(48000/1001.0)
BicubicResize(1280, 720)

_MUX_3D_OPTIONS.txt

You may want to change the output file name under --output, but you can do it later.
Change SBS in the --track-name of the 3D Video Stream to "frame-sequential" or anything you may prefer. (It's just a label.)
Replace --stereo-mode 0:1 with 0:13 (To be confirmed.)
Replace --aspect-ratio 0:32/9 with 0:16/9
Replace --default-duration 0:24000/1001p with 0:48000/1001p

chapters_3D.qpfile
If you have not removed the --qpfile chapters_3D.qpfile argument in _ENCODE.cmd, you must also edit the chapters_3D.qpfile.
That file contains simply a list of frame numbers followed by I (upper case i).
Each frame number must be doubled. For example, "1770 I" must be changed to "3540 I".
The qpfile is used to force an I frame at the beginning of each chapter, so that it is easier for the players to jump to the beginning of a chapter. It's an improvement but it's not mandatory.

Finally launch _ENCODE.cmd and everything should be automatic. :-)

Note that tal.aloni recommends to mux to MP4 with his own muxer, and to convert the audio streams to AAC. Since his guide is made for very specific hardware and anyway BD3D2MK3D will never mux to MP4, I have not taken that recommendations into account. If your player is recent, it should support the MKV format anyway.

[r0lZ]

OK, it works, or at least I think so. I have no way to test it. If you want to test it with your hardware, you can download the encoded clip (left view first) here: demo 3D frame-sequential 720p.mkv (http://download.videohelp.com/r0lZ/tmp/demo%203D%20frame-sequential%20720p.mkv) (Download it rapidly. I cannot leave it on the site for a long time.)
Please let me know if it works as it should.