Guide to convert BD 3D to 3D Left+Right Stereoscopic and Anaglyph

[mini-moose]

there is no good way to guess what's the best subtitle 3D depth. The problem is that you cannot easily know the right value for that effect, and if you're wrong, you must change the value and encode the whole movie again.

ouch what a pain :s

Also, BDSup2Sub++ v1.1 should have an option to generate the 3D subs directly in one single stream.

sounds like that would be the ultimate solution.

I'm currently still deliberating with myself over the crop/don't crop thing. I'm used to crop surplus borders and it's hard to change ways even though they don't take much bitrate being all black. It seems players like dune and popcorn are able to display cropped images correctly but something like Oppo fails miserably and stretch it to full 16/9.

[r0lZ]

My TV, and as far as I know, all 3D TVs, need full 16:9 images, or they resize them to full-screen. So, if you plan to buy a 3D TV later, you should leave them.
(I may even add an option to add vertical black borders to 4:3 3D material (1440x1080), just to preserve the aspect ratio when they are played on TV, but I don't think there are many 3D movies in 4:3.)

[mini-moose]

My TV, and as far as I know, all 3D TVs, need full 16:9 images, or they resize them to full-screen. So, if you plan to buy a 3D TV later, you should leave them.
(I may even add an option to add vertical black borders to 4:3 3D material (1440x1080), just to preserve the aspect ratio when they are played on TV, but I don't think there are many 3D movies in 4:3.)

you mean 3d tvs that come with a media port? going through an external player that can read AR flags properly I understand (popcorn and dune tested) works fine from what I'm told.

[r0lZ]

No, I mean from a standard HDD directly connected to the USB port of the TV. I don't know if my TV displays correctly a cropped cinemascope 3D movie fed by a multimedia HDD to the HDMI port, but the manual of the TV says explicitly that 3D must be 16:9. Of course, if the multimedia HDD can add the black borders itself, that should work. Otherwise, probably not.
Software players are usually more flexible, but I hate watching a movie on a computer monitor.
Anyway, IMO, 3D material should always be in 16:9, to avoid the problems. It's not because your current hardware works fine with cropped movies that you will never have to change the TV or HDD. It's a pity to have to re-encode everything.

[mini-moose]

No, I mean from a standard HDD directly connected to the USB port of the TV

ok, that's what I meant, maybe I wasn't clear. I meant that the tv itself has the capability to play media files fed from an hdd/usb device that only stores the files.

Software players are usually more flexible, but I hate watching a movie on a computer monitor.
completely agree. What I do is use a pc that is plugged to the tv just for that purpose but it handles the actual playing via a sw player (xbmc in my case). sort of an htpc I guess. This way I have non of the funny/irritating limitations hw players have.

[mini-moose]

the uncompressed muxed subs didn't work on dune/popcorn/oppo either as expected.

[mini-moose]

I noticed there is a x64 version of ssifSource in the toolset. does it help boostimg the encode speeds in anyway? I assume it needs a 64bit environment to be used, like avisynth x264 and x264 x64.

[r0lZ]

You're right. It is used automatically if you tick the 64-bit option in the GUI, but the encoding process doesn't work without avisynth x64. Anyway, currently, the bottleneck is ldecod, and using the x64 tools doesn't speed things up much.

(BTW, I wonder if I should set the "slow" x264 preset by default, as it is supposed to be better than the medium one, and on my relatively slow machine, x264 spends much time doing nothing, just waiting for ldecod to finish decoding the images. That time could be used to improve the image quality at no cost. But I can't assume that everybody has at least a x64 quad core processor, so I kept the x264 default preset.)

[mini-moose]

(BTW, I wonder if I should set the "slow" x264 preset by default, as it is supposed to be better than the medium one, and on my relatively slow machine, x264 spends much time doing nothing, just waiting for ldecod to finish decoding the images. That time could be used to improve the image quality at no cost. But I can't assume that everybody has at least a x64 quad core processor, so I kept the x264 default preset.)

I'm trying on a relatively old i7 with no oc (9xx series). Tried slow, slower and now trying veryslow. Not full encodes just letting them run to get to a stable speed. The differences seem to be minimal so far but I need to do it again and write down the speed for each. I think it's around 4.5fps for slow, 4.3 for slower and 3.3 for veryslow so far. I will each preset do 3-4% again and let you know the results if you're interested.

the cpu usage seems to be up and down (between 50% and 100%). I assume it's what what happens when it's "waiting for ldecod to finish decoding".

[r0lZ]

Yes exactly. The encoding speed reported by x264 may not be accurate. I think it measures only the time it uses to encode. If it has to wait for the next frame, I'm not sure it will take that wasted time into account. In the other hand, the CPU usage is a global indication. Perhaps it is possible to use 90% or even 100% without slowing down the whole process much. (There has been an interesting discussion on that subject recently here (http://forum.doom9.org/showthread.php?p=1581121#post1581121).)

[mini-moose]

(There has been an interesting discussion on that subject recently here (http://forum.doom9.org/showthread.php?p=1581121#post1581121).)

I didn't see something of real merit there other than to maybe test resize via x264 command line? is that what you mean ?
I didn't know about that app so that was nice to find :)

[frencher]

the uncompressed muxed subs didn't work on dune/popcorn/oppo either as expected.

mkvtoolnix-2.6.0 and < :) Cibox Ready
mkvtoolnix-2.7.0 and > :( Cibox Not Ready

[mini-moose]

mkvtoolnix-2.6.0 :)
mkvtoolnix-2.7.0 :(
what does that mean ?

[frencher]

what does that mean ?

Cibox Cinebox Premium Wireless (HDMi & RJ45)
mkvtoolnix-2.6.0 and < :) Cibox Ready
mkvtoolnix-2.7.0 and > :( Cibox Not Ready
The best is to remux with mkvtoolnix-2.6.0 without compression on all tracks of course
http://s2.static69.com/composant/images/produits/big/CBX-PREMIUM-HDMI.gif
http://www.avcesar.com/source/multi/8/connectique_grand.jpg

[mini-moose]

mkvtoolnix-2.6.0 and < :) Cibox Ready
mkvtoolnix-2.7.0 and > :( Cibox Not Ready

but you can turn off compression on current mkvtoolnix too. 2.60 is real old.

[frencher]

But the last version that works on this box.

[mini-moose]

did another encode using i7 9xxx series pc and --crf 18 --preset slower --tune film

from logfile:
encoded 165282 frames, 3.88 fps, 8109.44 kb/s

from console:
eac3to processing took 11 hours, 49 minutes.
Done.
Video track 2 contains 165210 frames.
Video track 3 contains 165210 frames.
eac3to processing took 11 hours, 50 minutes.
Done.
Completed Decoding frame 330419.

why does it say "eac3to processing"?

oh and I tried a 3d encode with srt muxed to see how it looks (using dune). Quite "amusing"

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

[r0lZ]

I didn't see something of real merit there other than to maybe test resize via x264 command line? is that what you mean ?
I didn't know about that app so that was nice to find :)
The idea to decrease the speed of the encoding (and therefore to increase its quality) comes from that reply:
Given that you haven't screwed up the "--threads" option, if x264 doesn't produce 100% CPU load, this usually has one of the following two reasons: Either you are bottlenecked by slow input (slow decoder, slow pre-processing filters, etc) or you are using very "fast" x264 settings. In the latter case it can happen that the non-parallelizable parts of x264 become more dominant. By using "slower" settings, you may be able to increase the CPU load in that case...
In the case of BD-3D conversion, the decoder process (based on ldecod) is indeed extremely slow. So, I think that the last sentence of that reply applies exactly to our case, and it's why I wonder if I should lower the default value of the preset in my GUI.

[mini-moose]

So, I think that the last sentence of that reply applies exactly to our case, and it's why I wonder if I should lower the default value of the preset in my GUI.

ah I see. It's easy enough to test by encoding short clips (or kill the process after say 5%) with various presets and see what gives you the best balance between cpu and decoder capabilities.
Of Course it may differ from pc to pc but as the speeds seem to be in single figures to begin with I can't see it having huge differences.

[r0lZ]

why does it say "eac3to processing"?
I don't know exactly how ssifSource works, but I know that it uses eac3to and ldecod with named pipes to demux and decode the two video streams. eac3to is called twice, once for each "eye". eac3to prints that message (once for each eye), and my GUI sends it to the console. Obviously, it computes the processing time by comparing the time at the end of the process with the time of the beginning of the process. It doesn't compute it by counting the number of CPU cycles spent in its own process.

oh and I tried a 3d encode with srt muxed to see how it looks (using dune). Quite "amusing"
You mean "hardcoded", right?
I can't see your attachment, as it has not been approved by a moderator yet, so I don't know why you consider it amusing. Does it work as expected?
(BTW, to avoid the delay before approval, you should post your images at an image sharing service such as ImageShack (http://www.imageshack.us/?no_multi=1) and just insert the links here.)

[mini-moose]

I don't know exactly how ssifSource works

ah.

You mean "hardcoded", right?


not hardcoded, soft subbed. Was just curious to see how it looks.
I believe you said your tv almost manages to handle soft srt if it's outside the container but it gets horrible on some scenes, I might be confused though

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

[r0lZ]

Yes, that's exactly what I get if I use my LaCinema to play the 3D movie with an external or internal but not hardcoded subtitle stream. With real-3D SUB/IDX files, it will be possible to use it, and it's why I can't wait for BDSup2Sub++ v1.1.

[mini-moose]

Yes, that's exactly what I get if I use my LaCinemav1.1.

I was hoping it's at least semi useable for cases that require forced subs but I looks like it isn't. I'll join you in the impatient wait :)

[r0lZ]

Well, my TV does a better job: it displays the SRT files correctly (but always "on the surface of the screen") but it cannot show the SUB/IDX format, and having to OCR the original SUP just to let the TV show them more or less correctly is a pain. A tool to create real 3D SUB/IDX files is really necessary.

[frencher]

http://i.imgur.com/vIIKd.jpg
The idea is rather to double the subtitles kind.

1
00:00:02,000 --> 00:00:19,999
This is a test of SRT 3D, This is a test of SRT 3D,
The effect of burst is more difficult to resolve. The effect of burst is more difficult to resolve.

2
00:00:20,000 --> 00:00:25,999
It will seek space for each eye, It will seek space for each eye

3
00:00:26,000 --> 00:00:59,999
Left eye. Right eye.

[r0lZ]

Yes, but that doesn't work with SRT files, as they have no way to specify the exact position of each part of the subtitle. The renderer will simply consider them as a single sentence, and you can only try to put them at the right place by adding a more or less correct number of spaces between the two parts. It's not at all accurate enough, especially when you don't know what font and font size will be used. Furthermore, it is impossible to display them correctly in Top/Bottom mode. Real-3D subtitles must therefore be image based subtitles, not text ones, although it is perhaps possible to use text-based subtitles in a more powerful format (such as SSA that allows you to position the subtitles more precisely, but most TVs cannot show that format).

[mini-moose]

3DBD's Free - v0.0.0.0005 (2012-07-09)
Do you still have the problem with "libflac.dll" or other problem ?

sorry, I missed your post. I will try and let you know. btw what is MMBPlayer?

[frencher]

sorry, I missed your post. I will try and let you know. btw what is MMBPlayer?

Is this a error message?

[mini-moose]

Is this a error message?
no, I have not tried it yet. It's the location that had the dll that gave a false positive the previous time I tried it. C:\Users\admin\AppData\Local\Temp\MMBPlayer

[frencher]

no, I have not tried it yet. It's the location that had the dll that gave a false positive the previous time I tried it. C:\Users\admin\AppData\Local\Temp\MMBPlayer

Ok tell me if there is still this problem.
Normally this is solved.

[mini-moose]

Ok tell me if there is still this problem.
Normally this is solved.
I will. I still would like to know what is that MMBPlayer :)

[frencher]

I will. I still would like to know what is that MMBPlayer :)

This is the folder that stores files embedded (Portable version)
http://www.mmbforums.com/viewtopic.php?f=17&t=2274

[lasa]

is it possible to crop the borders, so that these are not converted? can i resize a movie from 1080p to 720p?

[r0lZ]

Hi lasa, welcome to the Doom9 forums.

With my GUI, you can't crop and resize.

IMO, it's a bad idea to crop the 3D movies, as all 3D TVs need real 16:9, not cropped. (See the discussion about cropping I had with mini-moose above in this thread (http://forum.doom9.org/showthread.php?p=1581600#post1581600).) However, if you really want to do it, you can of course edit the avs script (and a couple of other files) before encoding it.

For the resize, I suggest to use the x264's resize option. Just edit the x264 command in _ENCODE.cmd. You should add something like this: --video-filter resize:1280,720,method=bicubic
(You can select another resize method than the default bicubic: fastbilinear, bilinear, experimental, point, area, bicublin, gauss, sinc, lanczos or spline, but if you change it, I suggest using only lanczos or spline.)
Of course, you can also edit the avs script to do the resize. (You will have to edit also some other parameters in other files, as the resolution is used during the mux process as well.)
Again, I don't think resizing is a good idea, as in 720p SBS, the horizontal resolution will be only 640. Not enough for a good quality 3D video IMO.

If it's just the file size that motivates you to crop and resize, don't worry too much. The black borders consume virtually no disc space, as pure black can be compressed extremely well. Also, x264 is so efficient that usually, it gives an output video between 1 and 3 GB in full 1080p (with the standard CRF value of 23, IMO largely sufficient for a good quality encode).

[qupfer]

Hi, can someone tell me what I am doing wrong :o

Picture (http://qupfer.de/MVC_error.png)

My avs file:
LoadPlugin("D:\Program Files (x86)\megui\tools\dgindexnv\DGDecodeNV.dll")
LoadPlugin("H264StereoSource.dll")
left= DGSource("D:\3DBD\left.dgi",fieldop=0)
right= H264StereoSource("decoder.cfg",189932)
VideoStacked=StackHorizontal(left,right).lanczosresize(1920,1080)
ConvertToYV12(VideoStacked)


Edit1:
Okay, i use a other way.
Create with the "MVC to AVI Converter Demo" and ffdshow-vfw two HuffYUV AVIs ("only" 250GB temp. Data ;) ) and this AVS-Script makes my HalfSBS Video

LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll")
left=FFVideoSource("00800-l.avi").crop(0,120,0,0).AddBorders(0,120,0,0)
right=FFVideoSource("00800-r.avi").crop(0,120,0,0).AddBorders(0,120,0,0)
StackHorizontal(left,right)
Lanczos4Resize(1920,1080)

(i have the luck of large black borders, so I can crop the 3dtv Demo Watermark :p )

Edit 2:
OH....BD3D2AVS with ssifsource looks nice...Thanks r0lZ!

[frencher]

Hi slavanap,

ssifSource does not work in short iso path
Ex:
F:\TEMPRE~1\SS94FB~1\ISO\BDMV\PLAYLIST\00001~1.MPL

Return:
The format of the source file could not be detected.

Works here because manually modified humm :( not iso path
F:\TEMPRE~1\SS94FB~1\ISO\BDMV\PLAYLIST\00001.MPLS

[SpaceNerd]

I've been following this thread closely and have used both H264StereoSource and ssifSource successfully before. The latest BD3D I tried to process, however, gives me an error message. Here's the related info:

AVS script:
LoadPlugin("ssifSource.dll")
LoadPlugin("UnDot.dll")
LoadPlugin("RemoveGrainSSE3.dll")
ssifSource(width = 1920, height = 1080, frame_count = 189932, left_264 = "left.h264", right_264 = "right.h264")
UnDot()
RemoveGrain(mode=2)
AssumeFPS(24000/1001)
Spline64Resize(1920, 1080)


x264 command line:
x264.exe --crf 21 --preset slower --tune film --profile high --level 4.1 --sar 1:1 -o video.h264 video.avs

Error message:
max_dec_frame_buffering larger than MaxDpbSize

The error also occurs, if I use other ssifSource command variants (e.g. using playlist as input). BD3D2AVS (naturally) also produces this error. Can someone tell me what's causing this? Thanks!

[crl2007]

@frencher and r0lZ If you want, you can write a small guide for your applications and provide a download link as well and I'll include both your methods and software as part of the main guide. Thanks.

[frencher]

Yes it's true crl 2007 I soon planned an update and I take this opportunity to make a tutorial.
The download link will also be soon, right on my website http://webfreesoftware.net

[r0lZ]

crl2007, you're welcome. But I have a new version with many improvements. I just need to clean it up and release it here. I think it might be preferable to wait for that version before writing your guide.

[frencher]

@SpaceNerd

max_dec_frame_buffering larger than MaxDpbSize
Here means that the source is corrupt

[SpaceNerd]

Here means that the source is corrupt

Thanks, frencher! It's weird that the BD copy might be corrupt as I was able to rip (and play the ripped video file) without any problems.

Do you by any chance know if the error is on the disc (i.e., the disc has been mastered this way) or if this is caused by a bad rip?

[r0lZ]

I have often noticed that when ssifSource has trouble with a MPLS file, it can successfully process the SSIF of the same title. So, if you use the MPLS as input, try to convert the corresponding SSIF. (Of course, if the MPLS file references several SSIFs, you're unlucky, and you will have to convert all referenced SSIFs and merge them later in some way.)

[SpaceNerd]

Thanks, r0lZ for your tip. Sadly, however, the SSIF input results in the same error. Just as nickolasemp explains in his post (http://forum.doom9.org/showthread.php?p=1575496#post1575496), the H264StereoSource approach fails as well (although I use ffms2 instead of CoreAVC). From the frame count, I guess we both try/tried to backup the John Carter 3D BD. Interestingly though, DVDFab Blu-ray 3D is able to convert the same ISO without problems. If it was possible to tune the x264 encoder options more to my liking, I'd almost consider using that approach. But I'd really like to know what's going (wr)on(g) here...

[pommesmatte]

Hi, at first I want to thank you r0lz for your really nice program!

Just some minor wishes:
- eac3to is capabale of converting audiotracks to other codecs, but BD3D2AVS can only switch the -core Argument at the moment. Well there are also the needed codec files missing for eac3to in the toolset directory, so maybe you had a good reason to omit this features. I don't know.
- Alternatively make an GUI option to include externally generated audiotracks in the muxing script.
- An option for automated start of encoding after the demuxing would also be great.
- It would be cool, if your tool would find its way into meGUI, like many other tools before.
- You should use mkvmerge 5.7.0 for muxing and deactivate header stripping on the tracks, as many media players will struggle on that.
- Maybe you can include a GUI option to deactivate the adding of 3 seconds of black at the end.

Ok, and I'm with the guys having the errors.
Well I'm facing exactly the same issue and yes, also with John Carter 3D.
DVDFab works, as said, but I'm also looking for a more controllable and free solution.

Maybe the problem is related to AnyDVD? Or the discs are poorly pressed, as some other guys on the internet stated.

Other 3D discs worked like a charm.

[r0lZ]

Hi, at first I want to thank you r0lz for your really nice program!Thanks, and welcome to the Doom9 forums!

- eac3to is capabale of converting audiotracks to other codecs, but BD3D2AVS can only switch the -core Argument at the moment. Well there are also the needed codec files missing for eac3to in the toolset directory, so maybe you had a good reason to omit this features. I don't know.Well, I think most users want to keep the original quality, and adding options to re-encode the audio streams is therefore not really necessary. Furthermore, my GUI is not yet another frontend for eac3to. Also, it's more complex that it sounds. I would need to add a lot of options in the GUI, and modify the mux options file accordingly. Anyway, you can easily re-encode any stream from the demuxed stream, and either mux to MKV manually or modify the mux options file yourself.

- Alternatively make an GUI option to include externally generated audiotracks in the muxing script.It's in my ToDo list, but it's also difficult to do. Usually, when an external audio track is added, the frame rate of the video must be modified, and a positive or negative delay is often needed. Since there is no way to check if the external stream will be correctly in sync with the video, I think it's something to do after the main processing. IMO, it is easier to remux the MKV file to add a stream than to have to specify the correct frame rate and exact delay in my GUI. Note also that the GUI is already very complex, and I don't want to add too many options that most users will not use.

- An option for automated start of encoding after the demuxing would also be great.I will try to do it, but I'm not sure it's really possible. Take in mind that the GUI has to verify if an error occurs and show the error message to the user. Will you be happy if you see that an error message during the demux process has blocked the processing during the whole night? IMO, it is safest to wait until the demux completes successfully, and be sure that the encoding has started before going to sleep.

- It would be cool, if your tool would find its way into meGUI, like many other tools before.The goal of the program is to create a MKV file, not to create any kind of file. If you really want that, 3D BD input should be an option in MeGui.

- You should use mkvmerge 5.7.0 for muxingV 5.7.0 is in my personal toolset directory, and will be distributed with the next version. Anyway, you can overwrite the old version with the new one manually.

... and deactivate header stripping on the tracks, as many media players will struggle on that.
Do you mean I should add "--compression none"? It's already done in the new version.

- Maybe you can include a GUI option to deactivate the adding of 3 seconds of black at the end.Not sure it's really necessary, but it's easy to do.

Ok, and I'm with the guys having the errors.
Well I'm facing exactly the same issue and yes, also with John Carter 3D.
DVDFab works, as said, but I'm also looking for a more controllable and free solution.

Maybe the problem is related to AnyDVD? Or the discs are poorly pressed, as some other guys on the internet stated.

Other 3D discs worked like a charm.My program is only a GUI, and if a BD cannot be properly handled, that means that either the BD is guilty, or some of the tools in the toolset (or, as you suggest, AnyDVD). I can't therefore do much here.

Note that the new version demuxes now the SSIF file by default instead of the MPLS. I have noticed, as I wrote above, that some MPLS cannot be handled properly, and that handling the SSIF instead is usually more reliable. (However, the GUI still uses the MPLS if it references several SSIFs.) Unfortunately, it seems that switching to the SSIF is not sufficient for the John Carter BD. (I don't have that BD, so I can't test it myself, but anyway, I don't think I could modify the GUI to fix the issue with that particular BD.)

[mini-moose]

I get that error too..

max_dec_frame_buffering larger than MaxDpbSize

and from log:
Error writing to pipe! | 0x0000006d

if I read correctly I should try pointing the avs to the ssif file instead of mpls?

I used this:

ssifSource("D:\BDMV\STREAM\SSIF\00800.ssif", 1920, 1080, 135526, 2, 3)

gives the same error.

[r0lZ]

OK, I've just added the option to add the 3 seconds of black at the end of the video, and an option to start the encoding immediately after the (successful) demux process. (The second option is in the progress window. Note that if you enable it, BD3D2AVS is also automatically closed.)

IMPORTANT: I have not checked AT ALL the two new options and I have tested only partially some of the other changes. They should work, but I have not enough time to be sure. Consider this release as an alpha version. Please report any problem you may have here.
Note also that the documentation is not fully up to date.


# v0.7 (August 27, 2012)
# - New "Title & tags" tab to define the movie Title (previously in the last tab) and miscellaneous movie tags.
# - Added the possibility to encode in full-SBS and full-T&B.
# - Added the possibility to resize the output video to 720p.
# - Adding 3 seconds of black at the end of the video is now an option.
# - It is now possible to do the final resize operation (if necessary) with x264 rather than with Avisynth.
# - There is now an option to close the GUI and launch the ENCODE batch automatically at the end of the demux operation
(only if successful).
# - Added Tools -> Chapters File Converter to time-stretch an existing chapter file or add or subtract a delay.
# - Takes the new syntax of BDSup2Sub++ into account, so the option to use it instead of the java version should work.
# - Added x264 Profile "auto" to disable the --profile parameter.
# - When there is only a single M2TS in the current MPLS, the M2TS is now selected by default,
# because it is often more reliable to demux the subtitles from the M2TS.
# - The chapters files have now more meaningful file names: chapters_3D_delay.txt and chapters_2D_no_delay.txt.
# - The chapter names are now also added in the 2D version of the chapter file chapters_2D_no_delay.txt.
# - When there is no stream to demux, the xport.exe output is now saved in xport_log.txt.
# - There is now a progress bar (in indeterminate mode) when counting the number of frames with xport.exe.
# - Added "Encoded by" in x264 encoder options of tab 5 to optionally add the encoder's name tag.
# - Moved the "mux to mkv file and do nothing/shutdown options in the Go frame of tab 5.
# - Some operations (such as retrieving the stream descriptions) are now somewhat faster.
# - Minor cosmetic changes, better bindings and undo for text and entry widgets.


[EDIT: Links removed. Download the latest stable version (http://forum.doom9.org/showthread.php?p=1592621#post1592621), please.]

[mini-moose]

hmm I didn't notice there is a new stable version, I'll try that one now.

[r0lZ]

Well, v0.6 is the last version posted here before my previous post. It is stable enough, and has been tested. You should have it already.
The new v0.7 is more subject to bugs, as I haven't had enough time to test it carefully. But since it is ready (and probably usable), and I have not the intention to work on BD3D2AVS for the moment, I prefer to release it as it is.