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

[HWK]

It would be perfect if you could add MVC and virtual dub procedure ;-) thanks a lot !

Check your PM :D

[r0lZ]

I have made a first test on Ice Age 3 and MVCSource.dll and I've don't seen any artefact at the right of right view.
r0lz could you test also ? Or frencher ?I think that only the Ice Age 3 Panasonic Bundle exhibits the problem. Afaik, the other versions can be successfully encoded. That was the conclusion, posted in this thread a long time ago (http://forum.doom9.org/showthread.php?p=1630715#post1630715).

[Nico8583]

My Ice Age 3 version makes artefacts with DirectShowMVCSource but not with MVCSource

[Nico8583]

Check your PM :D
Thanks again :-)

[r0lZ]

My Ice Age 3 version makes artefacts with DirectShowMVCSource but not with MVCSourceWell, good news. I will test MVCSource soon...

[Thalyn]

Getting the same problem as Frencher while trying to use MVCSource. Both VirtualDub and MeGUI are throwing the same "Can't init decoder session" feedback. Source is just the raw streams that TSMuxer spat out after demuxing a MakeMKV rip of The Croods.

Could this possibly be another "magic path" deal, or is it something simple we've both overlooked?

[Sharc]

r0lZ, I hope you are right with the optimism.
Now I got glitches near the borders after muxing. These glitches were not present in the combinedMVC output of FRIMEncode.... Arrrgh .... Maybe it's only with my system?
(I posted in the tsMuxeR thread)

[Nico8583]

I have no problem with MVCSource, there is no magic path for me, I can launch script from everywhere.
My use of MVCSource :
- Extract stream from BD playlist with eac3to
- Copy 2 files from MVCSource directory where I want
- Create a script like this :

LoadPlugin("MVCsource.dll")

Interleaved = MVCsource("Left.h264", "Right.h264", 132769, 2)

Right = SelectOdd(Interleaved)
Left = SelectEven(interleaved)
return StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right))
Like Sharc indicates, left or right view can be used like this :

LoadPlugin("MVCsource.dll")

Left = MVCsource("Left.h264", "Right.h264", 132769, 0)

return Left
Same thing with Right but 0 must be replaced by 1

Edit : I use Avisynth 2.5.8 32bits, FFDShow 32bits with "All supported" option checked in RAW stream

[r0lZ]

I am currently testing MVCSource, and I can launch it too without problem.
I have extracted the AVC and MVC streams with tsMuxeR.
I have not installed BDtoAVCHD, but I have simply copied MVCsource.dll and libmfxsw32.dll in the same folder. (I guess they can be copied to the avisynth plugins folder, but I haven't tried.)
Maybe MVCSource requires other DLLs or codecs installed in the system? I had a look at the files in the BDtoAVCHD package, but the other files should not be needed.

Currently, I haven't noticed any glitches, but I have only encoded a few minutes of some short movies. The bad point is that it is much slower than the other methods (but much more rapid that the original method based on ldecod!)

I will try with the Ice Age 3 Panasonic bundle now...

[mini-moose]

Well, good news. I will test MVCSource soon...
Does MVCSource uses coreavc too ?

[Nico8583]

Does MVCSource uses coreavc too ?
No it doesn't use CoreAVC.
I don't have installed BDtoAVCHD too, just copied the 2 files and for me it is as fast as DirectShowMVCSource, and faster than BioMVC.

[r0lZ]

Hum, strange. When I encode with DirectShowMVCSource or ssifSource with the medium x264 preset, the speed is around 12 fps. With the tests I am currently doing with MVCSource, ultrafast preset, the speed is between 8 and 9 fps. I guess that encoding a whole movie with the veryslow preset (that I use usually when I'm not testing) will take ages!
Perhaps MVCSource is well optimized for your CPU but not for mine?

[r0lZ]

Just finished a test of a part of Ice Age 3, up to the scene well known to cause a lot of problems (with Diego hunting the gazelle, around 0:06:00), and I have not noticed any problem. So, it seems thet MVCSource could be the solution for us. It has some drawbacks, but the important thing is that it doesn't have the bad MVC decoding problem.

IMO, its main limitations are:
- Impossible to take a BD MPLS or SSIF file as input: requires to demux the two video streams.
- no possibility to encode in anaglyph or other modes
- the number of frames must be known (not a big problem)
- impossible to seek
- perhaps incompatible with some systems or requires some additional files not present on all systems (to be verified)
[EDIT: Not a problem with the system, but the commands of the script have to be processed in a precise order.]
- slow (to be verified) [EDIT: No, it is not slower than ssifSource and DirectShowSource]

Anyway, I will try to use it with a new version of BD3D2MK3D. However, don't expect it soon. I will probably have to rewrite it completely. I will also replace eac3to with tsMuxeR, and add the possibility to convert the subtitles to 3D with the depth extracted from the 3d-planes of the MVC stream. Currently, tsMuxeR is not completely compatible with that, but Roman has promised to add the necessary stuff. I'll wait that new tsMuxeR version before beginning to write the new BD3D2MK3D. Anyway, when it will be ready, it should be simpler to use than the current version, because I will not have to take care of the "multiple SSIF file in the MPLS" problem.

Of course, let me know if you find other problems with MVCSource, or if you discover a 3D BD that cannot be successfully encoded.

[mini-moose]

No it doesn't use CoreAVC.
I don't have installed BDtoAVCHD too, just copied the 2 files and for me it is as fast as DirectShowMVCSource, and faster than BioMVC.

I'm far from being an expert but maybe coreavc causes those decoding issues? I remember early versions of it caused such issues with regular 2d blurays. Maybe I'm stating the obvious, apologies if so :)

[Nico8583]

Hum, strange. When I encode with DirectShowMVCSource or ssifSource with the medium x264 preset, the speed is around 12 fps. With the tests I am currently doing with MVCSource, ultrafast preset, the speed is between 8 and 9 fps. I guess that encoding a whole movie with the veryslow preset (that I use usually when I'm not testing) will take ages!
Perhaps MVCSource is well optimized for your CPU but not for mine?
For me, with DirectShowMVCSource, the speed is between 8 and 10 fps, with MVCSource between 8 and 10 also and with BioMVC is around 6 or 7 fps. I have an AMD Phenom II X6 1090T and 8Go DDDR3.

[Nico8583]

I'm far from being an expert but maybe coreavc causes those decoding issues? I remember early versions of it caused such issues with regular 2d blurays. Maybe I'm stating the obvious, apologies if so :)

CoreAVC may be the problem but we can't replace CoreAVC by another decoder in DirectShowMVCSource :-(

[Nico8583]

r0lz, I'm OK with most of your limitations list :)
Another good thing, BDtoAVCHD is a freeware so perhaps we could contact the author to tell him if we can use his decoder without legal problem ? Or contact him to know if he could add some fonctions of your limitations list (like M2TS, MPLS and/or SSIF support or anaglyph and others modes support) ?

[Nico8583]

I've seen it in features list of BDtoAVCHD :
Do not use external codecs like avisynth or ffdshow or Haali splitter in the process of video conversion.
So it must includes an internal decoder ? :confused:

Edit : How the soft can create and use avs script without avisynth ?

[r0lZ]

I forgot to write that the script necessary to encode with MVCSource posted here (http://forum.doom9.org/showthread.php?p=1658513#post1658513) by Nico8583 assumes base view = right. If you use it, you will probably end up with the left and right views inverted, as most BDs have the left view as the base view.

Also, I wonder why the resize is made before the StackHorizontal command. That means that the script has to do 2 resize operations. If it is made after the Stack command, only a single resize is necessary. I suppose the script could run a little bit faster with a single resize.

I don't know if HorizontalReduceBy2 is more rapid than the BilinearResize that BD3D2MK3D uses by default, but according to the avisynth doc, it doesn't handle the colour exactly in the same way. Maybe that could explain some differences in the rendering with the BD3D2MK3D method and the default script for MVCSource.

Anyway, currently, I do my tests with this script, a slightly modified version of the script posted by Nico, and assuming base view = left:

LoadPlugin("path to\MVCsource\MVCsource.dll")
Interleaved = MVCsource("avc.264", "mvc.264", 132769, 2)
Left = SelectOdd(Interleaved)
Right = SelectEven(interleaved)
StackHorizontal(Left, Right)
HorizontalReduceBy2()

[Thalyn]

Also, I wonder why the resize is made before the StackHorizontal command. That means that the script has to do 2 resize operations. If it is made after the Stack command, only a single resize is necessary. I suppose the script could run a little bit faster with a single resize.
I've found it's better to resize before merging. Reason being that the default resize facilities in AVISynth encourage a bit of "bleed" from one frame into the other where they meet. When the meeting edges of the frame differ significantly (as is almost always the case for Over/Under if you trim the letterboxing like I do) than it gets quite distracting.

Still for the life of me can't get MVCSource to work. Tried installing BDtoAVCHD just in case, running it from the aforementioned's paths, putting the entire contents of its installation into a single folder, adding the folder to the system path, reverting to AVISynth 2.5.8 (normally using 2.6 alpha 5)... even running VirtualDub as admin just in case. Same error every single time!

[r0lZ]

r0lz, I'm OK with most of your limitations list :)
Another good thing, BDtoAVCHD is a freeware so perhaps we could contact the author to tell him if we can use his decoder without legal problem ? Or contact him to know if he could add some fonctions of your limitations list (like M2TS, MPLS and/or SSIF support or anaglyph and others modes support) ?
Oh, well, yes, we can perhaps contact the author, but currently, I don't think the limitations are really problematic.

The SSIF support is not really needed imo. Of course, a good MPLS support would be great, but it must work with MPLS referencing a lot of SSIF files. We have seen that it's a big problem due to the avisynth timout limitations. The current necessity to demux the AVC and MVC streams is a limitation, but at least, we are sure that the encoder will not hang on complex playlists like the current DirectShowMVCSource and ssifSource methods.

Encoding in anaglyph would be great, but it's not the job of the decoder. Anyway, it should be possible to do it with regular avisynth commands. Or perhaps there is already an avisynth filter to encode in anaglyph. Anyway, personally, I'm not really interested in anaglyph. IMO, that 3D method will disappear soon, as most recent TVs support the SBS and T&B modes, and the need for a 3D method suitable for non-3D TVs will be less important in the future. The other 3D modes (like checkerboard or row interleaved) are not popular, and I think we don't need to support them. (The AVC+MVC combined mode could become a great new 3D standard, but currently no TV can show it, and anyway, that mode doesn't require to re-encode the movie.)

I agree that it would be better to have the legal permission to use the decoder. Since it has no protections at all, I suppose the author doesn't care if it is used by free programs.
So it must includes an internal decoder ? :confused:The decoder is MVCSource, no? Do you mean a decoder for 2D (AVC-only) streams?
Edit : How the soft can create and use avs script without avisynth ?Good question!

[r0lZ]

I've found it's better to resize before merging. Reason being that the default resize facilities in AVISynth encourage a bit of "bleed" from one frame into the other where they meet. When the meeting edges of the frame differ significantly (as is almost always the case for Over/Under) than it gets quite distracting.Yes, that's a good reason. However, with the bilinearResize I use usually for my encodings, that problem doesn't happen, or at least it is not really visible. (I encode in SBS though, so it is probably less visible anyway.)

I will do some speed tests with the two methods, and if the speed gain is not obvious, I will probably implement the double-resize method.
Still for the life of me can't get MVCSource to work. Tried installing BDtoAVCHD just in case, running it from the aforementioned's paths, putting the entire contents of its installation into a single folder, adding the folder to the system path, reverting to AVISynth 2.5.8 (normally using 2.6 alpha 5)... even running VirtualDub as admin just in case. Same error every single time!
Damn! We have to find what's wrong, as we need to be sure that the decoder will work everywhere.
Have you searched the BDtoAVCHD thread to see if someone has already reported a similar problem?
I may try the decoder in a Win7 I have installed in a VirtualBox, just to try it without any additional codecs or filters, but currently, my VistualBox doesn't work well any more, and that will take much time.

[Sharc]

Since today MVCSource.dll fails here as well with the same error message as Thalyn. Yesterday it worked. Don't ask me why ... :confused:
I am on Windows 7 / 64bit

[Thalyn]

Well, that rules out one theory I had. Was suspecting it might be OS-based, since 8.1 has some weird problems. If you're getting it under 7 than it's probably not that.

Can't find anything on the BDtoAVCHD thread, either, though I've only been going through with a quick search. If anyone's having the same problem they're using different terminology and not actually mentioning the error by name.

Out of sheer curiosity I've got BDtoAVCHD running a transcode of another movie. Abysmal quality settings but I'm not really concerned by that - I want to see if it works in its "native" environment.

[r0lZ]

Shark, have you tried to encode the same movie/script, or does it fail with another movie?

I'm on Win8 x64 (but I have another partition with win7 x64, that I can still use to do some tests).

[Sharc]

Now it's back to work again (!), like:
- It works nicely with Script + FRIMEncode (which is important for us)
- It fails with the same script put into AvsPmod (don't know why...)

[r0lZ]

Hum, I don't use FRIM, and on my system, I can see the decoded frames in AvsPmod. Really strange.

[Nico8583]

Oh, well, yes, we can perhaps contact the author, but currently, I don't think the limitations are really problematic.

The SSIF support is not really needed imo. Of course, a good MPLS support would be great, but it must work with MPLS referencing a lot of SSIF files. We have seen that it's a big problem due to the avisynth timout limitations. The current necessity to demux the AVC and MVC streams is a limitation, but at least, we are sure that the encoder will not hang on complex playlists like the current DirectShowMVCSource and ssifSource methods.

Encoding in anaglyph would be great, but it's not the job of the decoder. Anyway, it should be possible to do it with regular avisynth commands. Or perhaps there is already an avisynth filter to encode in anaglyph. Anyway, personally, I'm not really interested in anaglyph. IMO, that 3D method will disappear soon, as most recent TVs support the SBS and T&B modes, and the need for a 3D method suitable for non-3D TVs will be less important in the future. The other 3D modes (like checkerboard or row interleaved) are not popular, and I think we don't need to support them. (The AVC+MVC combined mode could become a great new 3D standard, but currently no TV can show it, and anyway, that mode doesn't require to re-encode the movie.)

I agree that it would be better to have the legal permission to use the decoder. Since it has no protections at all, I suppose the author doesn't care if it is used by free programs.
The decoder is MVCSource, no? Do you mean a decoder for 2D (AVC-only) streams?
Good question!
I don't think the limitations are really problematic too, I allways demux my streams and I don't use anaglyph.
When I say decoder, I would like to talk decoder like CoreAVC or FFDShow, perhaps it's not the good term ;)

[Sharc]

r0IZ:
Yes, really strange. It also fails when I open the script in MPC-HC, same as AvsPmod.
(It works however as script for FRIM)

My Script:
LoadPlugin("c:\Program Files Video\MVCSource\MVCsource.dll")
Interleaved = MVCsource("c:\........\00049.track_4113.264", "c:\..........\00050.track_4114.mvc",1000,2)

Right = SelectOdd(Interleaved)
Left = SelectEven(interleaved)
return StackHorizontal(Left,Right)

[Thalyn]

"Native" test is another failure. Tried it with Xue Di Zi (better known as "The Guillotines") just to use a different movie and it gave the same error with its internally created script as I've been getting with mine. Literally fails the instant it hits the line requesting the plugin be used.

[Nico8583]

r0IZ:
Yes, really strange. It also fails when I open the script in MPC-HC, same as AvsPmod.
(It works however as script for FRIM)

My Script:
LoadPlugin("c:\Program Files Video\MVCSource\MVCsource.dll")
Interleaved = MVCsource("c:\........\00049.track_4113.264", "c:\..........\00050.track_4114.mvc",1000,2)

Right = SelectOdd(Interleaved)
Left = SelectEven(interleaved)
return StackHorizontal(Left,Right)
Could you try to rename .264 and .mvc to .h264 ?

[r0lZ]

Could you try to rename .264 and .mvc to .h264 ?That should not be the reason. The .264 and .mvc extensions are the default extensions given by tsMuxeR, and I've used them without problem for my tests.

[r0lZ]

I have finished some speed tests. I have encoded 10000 frames with different methods (and x264's ultrafast preset), and recorded the time taken for the whole process. Here are the results:

MVCSource with HorizontalReduceBy2 used one time: 0:19:42.5
MVCSource with HorizontalReduceBy2 used two times: 0:19:44.0
MVCSource with BilinearResize used one time: 0:19:59.2
ssifSource3 with HorizontalReduceBy2 used one time: 0:19:43.0

The tests are not very accurate, because I was busy doing other things on my PC at the same time, but they seem to confirm that I was wrong. MVCSource is not slower than ssifSource3. Good! :-)
Also, it seems that using HorizontalReduceBy2 one time to resize the double-picture or two times to resize a single picture is approximately equivalent. Good again! :-)

BilinearResize seems slower than HorizontalReduceBy2. It may offer a better quality, I don't know, but I think I'll use only HorizontalReduceBy2 in the next version of BD3D2MK3D, instead of the current avisynth or x264 resize filters. (The current method has the advantage that the user has the choice of the filter and the program to use for the resize, but since the BilinearResize avisynth filter is probably the fastest one with a good quality, using the even faster HorizontalReduceBy2 instead seems to be a good option, unless someone prefer to keep the current resize methods.)

@Sharc: Your script looks correct (except that the left and right views are probably inverted, but that's not something that can make the dll crash.) I don't understand.

[Nico8583]

I've send a message to BDtoAVCHD's author to invit him here ;)

Edit : author is already on this forum, he's "pistacho". Official topic is here : http://forum.doom9.org/showthread.php?t=154957&page=22

[r0lZ]

Thanks for the info.

I have now the problem with MVCSource refusing to work! I have discovered some very strange things.

The decoder worked well with the default script posted ny Nico elsewhere. But, as I have explained earlier, the left and right views are inverted with the vast majority of the 3D movies, so I did finally a test with the Left and Right views in the correct order... and bang! The script crashed! I have tried to reboot, because I suspected a problem with my Win8, but without success.

As soon as I restore the original order and syntax of the commands in the script, it worked fine again! The thing really strange is that the command that calls the MVCSource decoder has not changed!

This script works (but the left and right views are inverted):

LoadPlugin("MVCsource.dll")
Interleaved = MVCsource("00852.track_4113.264", "00852.track_4114.mvc", 135267, 2)
Right = SelectOdd(Interleaved)
Left = SelectEven(interleaved)
return(StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right)))

But this one crashes!

LoadPlugin("MVCsource.dll")
Interleaved = MVCsource("00852.track_4113.264", "00852.track_4114.mvc", 135267, 2)
Left = SelectOdd(Interleaved)
Right = SelectEven(interleaved)
return(StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right)))

Note that I've only swapped the Left and Right assignments.
Of course, the variable names "Left" and "Right" are not responsible of the difference. It seems it's the order of the StackHorizontal command that matters. This script crashes also:

LoadPlugin("MVCsource.dll")
Interleaved = MVCsource("00852.track_4113.264", "00852.track_4114.mvc", 135267, 2)
Right = SelectOdd(Interleaved)
Left = SelectEven(interleaved)
return(StackHorizontal(HorizontalReduceBy2(Right), HorizontalReduceBy2(Left)))

I've found an important thing. It is possible to invert the left and right streams simply bu specifying -2 in the MVCSource command. This script works and the views are in the correct order:

LoadPlugin("MVCsource.dll")
Interleaved = MVCsource("00852.track_4113.264", "00852.track_4114.mvc", 135267, -2)
Right = SelectOdd(Interleaved)
Left = SelectEven(interleaved)
return(StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right)))

This script ie exactly equivalent but more intuitive. It works:

LoadPlugin("MVCsource.dll")
Interleaved = MVCsource("00852.track_4113.264", "00852.track_4114.mvc", 135267, -2)
Left = SelectEven(interleaved)
Right = SelectOdd(Interleaved)
return(StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right)))

It is also possible to decode the two streams in separate commands, like this:

LoadPlugin("MVCsource.dll")
Left = MVCsource("00852.track_4113.264", "00852.track_4114.mvc", 135267, 1)
Right = MVCsource("00852.track_4113.264", "00852.track_4114.mvc", 135267, 0)
return(StackHorizontal(HorizontalReduceBy2(Left), HorizontalReduceBy2(Right)))

Of course, it's a less good solution, because the 2 streams must be decoded twice. But with that syntax, I have not been able to make the script crash.
(It seems that the argument 0 must be used to decode the MVC stream, and 1 for the AVC stream, but I can't confirm that for sure right now.)

Conclusion: The MVCSource command, when used with the parameter 2 or -2, builds an interleaved stream. It seems that the even frames MUST always be the left viw, and the odd frames the right view, but the order of the frames can be inverted by using -2 instead of 2. -2 should be used with most BDs if you want to encode in SBS or T&B with the left view first (the standard that has clearly emerged).

Can you do some tests and confirm that my findings are correct, and that you can decode any BD as long as you use the correct syntax and order of operations? Thanks in advance!

[Nico8583]

Thanks for your report.
I'm going to try how can I determine if 0 is MVC and 1 is AVC or invert. Do you think (I don't thing personnaly) -0 and -1 exists or is only for 2 ?

[r0lZ]

I haven't tried, but again, -0 or -1 doesn't make sense. There is a number for MVC only, one for AVC only and two (2 and -2) for AVC+MVC, as in that case, it is important to know what streams to place in the odd and in the even frames.

I think the possibilities are the following:
0: returns MVC only
1: returns AVC only
2: returns AVC and MVC, with MVC in even frames
-2: returns AVC and MVC, with MVC in odd frames
I still have to verify. Don't trust me blindly!

Usually, AVC = left and MVC = right, but in relatively rare cases, it's the opposite. Use tsMuxeR or the GUI of BD3D2MK3D to see to what eye corresponds the base (AVC) view.

[Nico8583]

So I have made tests and for me it would be :

0 : returns AVC
1 : returns MVC

I've tried with NetBlender 3D Demo disc so Base view is left, I have made several encodes with different scripts and I've compared frame by frame results.

Script 1 :
LoadPlugin("MVCsource.dll")
Left = MVCsource("D:\Rips3D\BD3D-Demo\Left.h264", "D:\Rips3D\BD3D-Demo\Right.h264", 4898, 0)
Return Left

Script 2 :
LoadPlugin("MVCsource.dll")
Right = MVCsource("D:\Rips3D\BD3D-Demo\Left.h264", "D:\Rips3D\BD3D-Demo\Right.h264", 4898, 1)
Return Right

I've encoded with TotalCode Pro :

Test 1 : Left source is script 1, Right source is script 2 -> I've compared original left view and encoded left view : identical
Test 2 : Left source is script 2, Right source is script 1 -> I've compared original left view and encoded left view : encoded left view is not identical, there is an offset between logos -> Right view

Does it seems to be logical ?

Edit : I have also tried to invert Left.264 and Right.h264 in MVCSource(...., xxxx, x) and scripts don't work. But -0 and -1 don't crash, I have made tests and there is no changes between -0 and 0 or -1 and 1.

Edit 2 : I've searched what is "libmfxsw32.dll" and I've found it's a part of Intel Media SDK so this decoder may be based on that ;)

[Sharc]

Has anyone tried viewID 3 and 4?
I wonder how you would interpret the result.

[Nico8583]

No I have not tried this ID. Have you tried ? Does it work ?

[Sharc]

No I have not tried this ID. Have you tried ? Does it work ?
Yes, it works. But I am not sure how to Interpret the result.
Looks like base and dependent pictures are displayed in sequence (?)

[Nico8583]

I'll try later. And what about over 4 ? 5, 6, 7... ?

[r0lZ]

Does it seems to be logical ?Yes. As I wrote, I was not sure of my tests. I have to do some more, similar to what you did. But you are probably right.
Edit 2 : I've searched what is "libmfxsw32.dll" and I've found it's a part of Intel Media SDK so this decoder may be based on that ;)Good. That means that it is probably totally free. :-)
Has anyone tried viewID 3 and 4?
I wonder how you would interpret the result.No. I'll have a look tomorrow. Currently, I am doing a "serious" encode, not a quick test. I'll see tomorrow if Ice Age 3 has no glitches at all...

[pistacho]

Hi!

I am the author of "MVCsource.dll" and I feel good that will be useful, but please, as general rule not re-distribute with other software packages. As much freeware software is free to use but not implicitly free to redistribute.

@r0lZ:
As exception can be bundled with BD3D2MK3D but please include a link to BDtoAVCHD home page in help menu in order to users can update MVCsource to last version or use directly BDtoAVCHD "as-is". Yes! BDtoAVCHD (despite its name) it is also capable of create MKV 3D and does so with the correct left-right views order also. :D


Some time ago I developed this solution precisely because none of the existing fully convinced me.

MVCsource avoids:
- Glitches and "magic paths" of coreavc
- Directshow conflicts, registry misconfigurations of DirectShowSource
- Pipes (I hate them)
- Intermediate steps as MVCcombine.exe
- Bad decoded image (green frames) of H264StereoSource
- Synchronization problems of ssifSource
- sloooow of BioMVC and other ldecod based solutions
- . . .


As I have read in this thread almost know her better than me how to use MVCsource. But I confirm:


0 : base view (AVC)
1 : dependent view (MVC)
2 : interleaved base-dependent (base first)
-2 : interleaved dependent-base (dependent first)


Notes:

Use -2 parameter when base is right (AVC=right) instead of the most common AVC=left
Do not try to change the views order in the script (StackHorizontal line or left/right tags assignation). Not work because Avisynth requests frames in wrong order and the plug-in only supports linear decoding.
Native script generated by BDtoAVCHD is already speed optimized so do not try to find best resize algorithm or include trash as ConvertToYV12 or AsumeFPS
Is best use last Avisynth 2.6 Alpha 5 but is also compatible with 2.5.8

[Nico8583]

Thanks a lot pistacho for all informations and permission to use it (but not redistribute it ;) )

[Nico8583]

pistacho, I have 2 questions please :
- If I have all understand, to use your decoder, only Avisynth is needed ? No need to FFDShow, Haali or other soft ?
- Why Avisynth 2.6 alpha 5 is better than Avisynth 2.5.8 ?
Thanks !

[r0lZ]

Yes, thanks you very much pistacho. Obviously, your decoder is the best one! And I'm glad I can use it with BD3D2MK3D. Of course, I'll add credits to you and a menu with a link to your tool.

Honestly, I didn't know that BDtoAVCHD is also a SBS/T&B MKV builder. I'm not sure any more that BD3D2MK3D is still useful, since you did the same job already. Maybe I'll continue anyway, if BD3D2MK3D does things that your tool doesn't do (such as decoding and hard-printing the 3D subs).

Please stay tuned here. Maybe we'll have other things to ask. Anyway, thanks again.

- Why Avisynth 2.6 alpha 5 is better than Avisynth 2.5.8 ?
I'm also interested by the answer to that question.

[Sharc]

@Thalyn / All:

MVCSource.dll not initiating issues:

I found that the "libmfxsw32.dll" must be put
- either into the same folder as the video application,
- or into a WINDOWS System folder.
In my case of Windows7/64 bit this folder is
c:\windows\SysWOW64\libmfxsw32.dll

The MVCSource.dll can be in any folder. Easiest is the 'plugins' folder of Avisynth because it is then loaded automatically.

I hope this helps.

Thanks pistacho for MVCSource.dll :thanks:

[r0lZ]

Hum, I have libmfxsw32.dll in several locations, but never in a system folder, or in a folder that is in my PATH. IMO, it is sufficient to put it in the same folder than MVCSource.dll.
pistacho, can you confirm?

[Thalyn]

@Thalyn / All:

MVCSource.dll not initiating issues:

I found that the "libmfxsw32.dll" must be put
- either into the same folder as the video application,
- or into a WINDOWS System folder.
In my case of Windows7/64 bit this folder is
c:\windows\SysWOW64\libmfxsw32.dll

The MVCSource.dll can be in any folder. Easiest is the 'plugins' folder of Avisynth because it is then loaded automatically.

I hope this helps.

Thanks pistacho for MVCSource.dll :thanks:

Bingo! Dropped it in with VirtualDub and the script fired up immediately without problem. Previously I only had it in the folder with MVCSource and it refused to work like that. Strange part is I tried previously with adding the folder to my path but either the setting didn't take or it has to be in one of those two folders (ie Application folder or system folder).

*ed: If you're trying to use it with MeGUI, it seems to need it in both the base directory and the x264 subdirectory. One or the other wasn't sufficient. Putting it in a system folder is definitely the easiest solution.

BTW, welcome Pistacho! I'm looking forward to giving this tool a thorough work-out.

*2nd ed: Speed is good on an i7 4770K (@4.2). Just a quick test to make sure I had the AVC and MVC frames in the right order (2000 frames from the start of Croods) showed 15.88fps, against the 16.89fps of ssifSource2. I'll happily take that minor of a speed hit for the increased compatibility.