Log in

View Full Version : Guide to convert BD 3D to 3D Left+Right Stereoscopic and Anaglyph


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 [36] 37 38 39 40 41 42 43 44 45 46

HWK
22nd December 2013, 06:17
In my case I lost lot of speed, went from 86.92fps average to 20.32 fps average.

Thalyn
22nd December 2013, 09:05
86.92fps?!:scared:

Even with a 2D encode I'm happy just to get to the mid-teens with my usual settings, usually only just reaching the teens at all. I have a new set I'm playing with that is a little faster (and a lot more consistent) but even they don't give results with a leading 2.

Incidentally, The Croods finished - in 3D, without audio, it's only slightly slower for me than a 2D from Handbrake with audio (audio being transcoded, whole thing being muxed to MP4 as it goes). 10,447 seconds (3D) vs 10,376 seconds (2D). I could probably squeeze a little more out of the 3D with a less flexible script, too (I think I have at least three "try" commands at present that I could just comment out instead).

frencher
22nd December 2013, 12:08
Does MVCSource uses coreavc too ?

No based on Intel SDK
http://i41.tinypic.com/2rc2zbt.png

pistacho
22nd December 2013, 21:24
- Why Avisynth 2.6 alpha 5 is better than Avisynth 2.5.8 ?
Thanks !

There are some speed improvements using Avisynth 2.6 alpha 5 but nothing bad occurs if 2.5.8 is used.


- If I have all understand, to use your decoder, only Avisynth is needed ? No need to FFDShow, Haali or other soft ?

Depends... if is used in a command line environment (together with x264.exe e.g.) only Avisynth is used but if you want preview or play .avs with MPC-HC or other player may be necessary FFDShow (not for decoder itself, but for player in order to render uncompressed raw video that Avisynth outputs). Standard players normally not support uncompressed raw video directly.

To avoid this VirtualDub can be used to play/preview Avisynth scripts.


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?

No, not is sufficient. Is sufficient to put in the same folder that calling application... and calling application is not MVCsource.dll is .exe that calls AVS script (player, VirtualDub, x264.exe, etc.)
Due this, is safer adding folder that contains libmfxsw32.dll to a system path (or put the dll in a system folder).


Some additional info:

Apart of decode separate AVC / MVC streams utilizing .avs scripts already posted here, MVCsource can be used to decode combinedAVC+MVC streams (as generated by MVCCombine.exe). Simply putting the file in the first parameter and leave second with empty string:


LoadPlugin("C:\Program Files (x86)\BDtoAVCHD\MVCsource\MVCsource.dll")

Interleaved = MVCsource("Combined_AVC+MVC.264", "", 135518, 2)

Right = SelectOdd(Interleaved)
Left = SelectEven(interleaved)

return StackVertical(VerticalReduceBy2(Left), VerticalReduceBy2(Right))


This mode is not used currently in BDtoAVCHD software but may be utility for someone here. ;)

Nico8583
22nd December 2013, 21:42
There are some speed improvements using Avisynth 2.6 alpha 5 but nothing bad occurs if 2.5.8 is used.

Depends... if is used in a command line environment (together with x264.exe e.g.) only Avisynth is used but if you want preview or play .avs with MPC-HC or other player may be necessary FFDShow (not for decoder itself, but for player in order to render uncompressed raw video that Avisynth outputs). Standard players normally not support uncompressed raw video directly.

To avoid this VirtualDub can be used to play/preview Avisynth scripts.
Thanks for your response. Is there a big difference speed between 2 versions ? Or very few fps ?

No, not is sufficient. Is sufficient to put in the same folder that calling application... and calling application is not MVCsource.dll is .exe that calls AVS script (player, VirtualDub, x264.exe, etc.)
Due this, is safer adding folder that contains libmfxsw32.dll to a system path (or put the dll in a system folder).
For me, I put both dll and avs in the same directory, I don't have libmfxsw32.dll in .exe directory or system directory and it seems to work without problem :confused:

pistacho
22nd December 2013, 21:57
Is there a big difference speed between 2 versions ? Or very few fps ?

I do not remember exactly but expect few or very few difference. Test in your system and you tell us :)

For me, I put both dll and avs in the same directory, I don't have libmfxsw32.dll in .exe directory or system directory and it seems to work without problem :confused:

Best. But in other systems probably not.

Nico8583
22nd December 2013, 22:05
I do not remember exactly but expect few or very few difference. Test in your system and you tell us :)
Thanks, I'll try later but I've also BDRebuilder on my PC and Avisynth 2.5.8 only must be present :rolleyes:

Best. But in other systems probably not.
I'll check again if this dll is not present on my system folder but I don't believe.

Cedvano
22nd December 2013, 22:16
is MVCsource work with SSIF ?

r0lZ
22nd December 2013, 23:15
Thanks for the precisions, pistacho.

Can you consider to modify MVCSource to load libmfxsw32.dll from the same directory? Currently, having to copy it in a system folder, or to change the user's PATH is an important limitation. BD3D2MK3D is a standalone (almost portable) program that does not require to be installed, and I would like to keep that philosophy. (I can certainly add the folder to the PATH in the shell script that launches the encoding with x264, as it will not be permanent, but that will not work to preview the script.) If it's impossible or too difficult, don't worry. I'll find a solution. After all, it's simpler to handle than the 'magic path' of the previous versions!

Thalyn
23rd December 2013, 07:56
is MVCsource work with SSIF ?
At present, it appears to only work with elementary streams - not containers. You'd have to use TSMuxer, eac3to or similar to demux the SSIF first.

It does appear to work fine using the multiview stream as extracted from the output of MakeMKV, too, though that's fairly moot as the newer MVC-aware TSMuxers can split those to AVC and MVC while extracting anyway.

Wolfy59
23rd December 2013, 10:16
Hi I just try the new method on the croods 3D.
And the right eye works fine now when i test it to wirtual dub.
No glitche nor artefact.
Thanks for the good work you do here.
You re Kings.
Have a nice year s end

Wolfy59
23rd December 2013, 11:21
http://img189.imageshack.us/img189/6792/b98h.jpg

Does someone can explain these error ?
thanks for answers
mvcsource: error only linear decoding is allowed (current frame index=14, request frame=0)

Sharc
23rd December 2013, 11:33
@wolfy59:
MVCSource.dll does not support seeking. Which means you cannot move back and forth with the slider of your player.
You can only start from frame 0 and move forward frame by frame (=linear).
I am not aware of any other (free) 3D- .dll which would support seeking. All I know are linear.

r0lZ
23rd December 2013, 11:53
OK, since my tests with MVCDecode are satisfactory, I will use it with the next version of BD3D2MK3D. However, that version will not be ready soon. I have many things to modify, and I will probably also use tsMuxeR instead of eac3to to demux the streams, and the java version of BDSup2Sub instead of BDSup2Sub++ to convert the SUP files to SUB/IDX (because I have discovered some important bugs in BDSup2Sub++ and its development has ceased). That means that the next version of my GUI will be very different. And I will need some time to write and debug it.

In the meantime, I have compiled this version, still using DirectShowSource or ssifSource3. It has a few bug fixes and some little ameliorations, and I have updated the third party programs to the latest versions. Download it, and keep it if you want to be able to use the old method later.


# v0.23 (December 23, 2013)
# - Default output file name slightly modified.
# - Added a menu to download the LavFilters DirectX codecs in the Help menu.
# - The option "Use SsifSource3 for SBS/T&B" is not the default any more.
# (However, it is not modified if the settings have been saved to disc.)
# - Several GUI bugs fixed in Tools -> Convert Subtitle to 3D.
# - Updated tsMuxeR and mkvmerge to the latest versions.


Download v0.23 (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D_v0.23.7z) (Latest version using ssifSource3 or DirectShowMVCSource and eac3to and BDSup2Sub++)

Cedvano
23rd December 2013, 12:01
Fine, I test it immediately.

pistacho
23rd December 2013, 20:36
Can you consider to modify MVCSource to load libmfxsw32.dll from the same directory? Currently, having to copy it in a system folder, or to change the user's PATH is an important limitation. BD3D2MK3D is a standalone (almost portable) program that does not require to be installed, and I would like to keep that philosophy. (I can certainly add the folder to the PATH in the shell script that launches the encoding with x264, as it will not be permanent, but that will not work to preview the script.) If it's impossible or too difficult, don't worry. I'll find a solution. After all, it's simpler to handle than the 'magic path' of the previous versions!

This is not an MVCsource limitation it’s an Intel Media SDK limitation: MVCsource.dll not loads libmfxsw32.dll, only is statically linked to an Intel "dispatcher" and is this that finds the appropriated version of Intel Media SDK core DLL utilizing a predefined method and I cannot change this.

r0lZ
23rd December 2013, 20:52
OK, understood.

Another thing. Is it possible to remove the number of frames from the avisynth command, or is it another limitation of the Intel SDK? It is not always easy to know the exact number of frames.

pistacho
23rd December 2013, 21:00
H264 strems not self contains the number of frames inside but Avisynth needs to know it... any better ideas? :)

r0lZ
23rd December 2013, 21:13
No. But it's OK for my GUI. It's just more difficult when I'm doing tests manually. For example, I have closed the tsMuxer window too early, and I forgot to note the number of frames. I have had to demux the streams again, just to know it! That was long! But luckilly, it's not a problem for my GUI. It has to demux the video streams with tsMuxeR anyway, and tsMuxeR prints the number of frames. It is easy to retrieve it.

I know that it is theoretically possible to get the number of frames by analysing the time codes of the video streams, but it's not the job of the encoder. I was just wondering why that number is needed. The decoder can probably decode all frames, up to the end of file. But I don't know how it works internally, and I may be wrong. Anyway, forget my question. It's OK.

Sharc
23rd December 2013, 21:30
Good for my ego that you guys also do not know an easy and quick way to determine the number of frames ;)

r0lZ
23rd December 2013, 23:36
There are several ways, but none are quick. My preferred one is xtract.exe, that can count the frames without demuxing. But it has to read the whole stream anyway. tsMuxeR and eac3to print the number of frames in the log after a demux.
Also, as I wrote above, the number of frames can be deduced from the time codes and the frame rate, but that requires to write a little program to retrieve the time codes.
I'm not sure, but perhaps the number of frames (or the clip duration) is also present in the MPLS file.

Cedvano
23rd December 2013, 23:39
To see the number of frame, I play video with Media Player Classic and go to the end. I press CTRL+G and see the number of frames.

Sharc
23rd December 2013, 23:51
But this method works only when seeking is supported, right?

Cedvano
23rd December 2013, 23:53
I think not! At me it has always worked.

Sharc
24th December 2013, 00:00
I'm not sure, but perhaps the number of frames (or the clip duration) is also present in the MPLS file.
Good proposal. BDedit (seems to be abandoned though) indicates Clip Durations as "length" from the selected playlist, like 01:56:01.728

Or:
When opening a script in AvsPmod and starting the internal player the total number of frames is shown in the status bar (bottom left), together with the frame number of the actual frame.

frencher
24th December 2013, 06:58
Hi pistacho,

Can i use "MVCsource.dll" in my soft's ;)

You are welcome

Nico8583
24th December 2013, 13:19
Hi pistacho,

Can i use "MVCsource.dll" in my soft's ;)

You are welcome
I'm agree ;) we don't have a free player for our files, so MVC Player Free must continue :D

Wolfy59
24th December 2013, 19:28
@wolfy59:
MVCSource.dll does not support seeking. Which means you cannot move back and forth with the slider of your player.
You can only start from frame 0 and move forward frame by frame (=linear).
I am not aware of any other (free) 3D- .dll which would support seeking. All I know are linear.

Strange i just remove ffdshow and it works fine now

pistacho
25th December 2013, 10:15
frencher:

Umm... if your software is a video player, no seek capability and force to extract elementary streams of container is not the best option. :confused:

r0lZ
25th December 2013, 10:26
His program is not just a 3D player. It is also an encoder. Anyway, I agree that MVCSource should be available to all of us having worked in this thread. My GUI is only one of the programs offered here, and I see no reason to give the permission to use MVCSource to me only.

Nico8583
25th December 2013, 10:53
Also perhaps you could :
- Share source code of MVCsource (for developpers++) ?
- Modifiy inputs of your avisynth plugin to accept M2TS and/or MPLS and/or SSIF ?
It's just ideas ;)

pistacho
25th December 2013, 11:45
His program is not just a 3D player. It is also an encoder. Anyway, I agree that MVCSource should be available to all of us having worked in this thread. My GUI is only one of the programs offered here, and I see no reason to give the permission to use MVCSource to me only.


OK can be used by free applications but must follow these "best practices":


Do not redistribute "MVCsource.dll" in your application. (then you will understand why)

Do not copy versions of "libmfxsw32.dll" in windows/system directories or add other folders to a system path. (can be obsolete, replace newer versions or break other software)

Create Avisynth script with this LoaderPlugin call:LoadPlugin("MVCsource.dll")Without full path. Since at installation BDtoAVCHD configure properly MVCsource will work fine.

Instruct to users that needs install BDtoAVCHD from official source and/or provide link to BDtoAVCHD homepage (http://www.connecta2000.com/BDtoAVCHD/) at your application.


As BDtoAVCHD is frequently updated I think this is the best option. So avoid configuration problems and conflicts due to having multiple installed applications using MVCsource on the same computer.

jdobbs
25th December 2013, 21:35
OK can be used by free applications but must follow these "best practices":


Do not redistribute "MVCsource.dll" in your application. (then you will understand why)

Do not copy versions of "libmfxsw32.dll" in windows/system directories or add other folders to a system path. (can be obsolete, replace newer versions or break other software)

Create Avisynth script with this LoaderPlugin call:LoadPlugin("MVCsource.dll")Without full path. Since at installation BDtoAVCHD configure properly MVCsource will work fine.

Instruct to users that needs install BDtoAVCHD from official source and/or provide link to BDtoAVCHD homepage (http://www.connecta2000.com/BDtoAVCHD/) at your application.


As BDtoAVCHD is frequently updated I think this is the best option. So avoid configuration problems and conflicts due to having multiple installed applications using MVCsource on the same computer.How do you use it in an app without redistributing "MVCsource.dll" with the app? That just make its use convoluted.

pistacho
25th December 2013, 23:06
How do you use it in an app without redistributing "MVCsource.dll" with the app? That just make its use convoluted.

The same way that app that use .NET Framework but does not include .NET framework in the installation.

Or

The same way that BDRebuilder use Avisynth // FFDShow but does not include it.

Or

The same way that BDRebuilder can use DirectShowMVCSource.dll / CoreAVCDecoder.dll but does NOT redistribute it. :)

jdobbs
26th December 2013, 06:29
The same way that app that use .NET Framework but does not include .NET framework in the installation.

Or

The same way that BDRebuilder use Avisynth // FFDShow but does not include it.

Or

The same way that BDRebuilder can use DirectShowMVCSource.dll / CoreAVCDecoder.dll but does NOT redistribute it. :)
I'm sorry, but an AVISYNTH plugin is nothing like the .NET framework. And a plugin that is based on freely distributed code like the Intel SDK is nothing like one that requires a copyrighted independently developed package like CoreAVCDecoder (that has to be purchased).

AVISYNTH and FFDSHOW can be freely distributed -- and have no restrictions, and I will include them in the installation package when I decide to build one (like I did with DVD Rebuilder).

But, hey, it's your plugin and you can do whatever you want. I'll just stick with FRIMDecoder, as it has no restrictions and works fine.

r0lZ
26th December 2013, 08:25
Pistacho, I agree with jdobbs. It is not fair to keep your plugin just for you or force us to install your program to be able to use it. Obviously, according to your update history, you have used several tools developed by peoples in this thread (without the explicit consent of their authors) and you have grabbed most information from us, but you have never shared any info with us. It's not a problem per se, but now, you can contribute to the collective efforts here, and imo you should share your plugin with us. Especially because it is based on a free and open source library.

I agree that installing several versions of the plugin or the Intel DLL on the same system may be dangerous or confusing, but there are certainly ways to avoid that problem. For example, my GUI could check if MVCSource has already been installed, and install it only if it's not the case. It could also install it exactly the same way as your program, so that your program will be able to use it too, or to update it to a newer version. Or, even a better solution, my GUI can keep the 2 DLLs in its own private folder, and add that folder to the system path only in its own process. The global path will therefore never be changed. Your program, if it is installed on the same machine, will not even know that the plugin of the Intel dll is present elsewhere, and will continue to work with the DLLs it has installed itself. That's certainly sufficient to avoid all conflicts.

Also, note that currently, your program installs some DirectShow filters (for example the Haali Media Splitter), even if they are already installed on the machine. That can also cause conflicts, and I don't want to force the users of my GUI to install a program that can cause incompatibility issues with other players or tools.

So please, accept what you have proposed originally. Let us distribute your DLLs, and we will add a link to your program, and we will keep the DLLs in a specific folder, independent of the rest of the system. You will be rewarded for your help, and there will be no conflict with your app. But please, don't ask us more.

frencher
26th December 2013, 18:25
@ pistacho
I regret to use this topic for your personal use without having participated once.
Block the use of "MVCsource.dll" to those who helped indirectly and unknowingly helped develop BDtoAVCHD is a can as if you were withdrawing the right to use the source of this topic.
No change on your part I will also use FRIMDecoder it is free and even much faster, although it has some bugs.
Thank you anyway for your personal interests in this topic.

pistacho
26th December 2013, 18:33
I'm sorry but is already decided: the next version of MVCsource.dll (already developed) only runs if the complete BDtoAVCHD software is installed but will be free to use by third-part applications.

Also will have several improvements as HW acceleration and some bug fixes.

Remember that MVCsource.dll is part of BDtoAVCHD software and never wanted to be a standalone application. If I wanted this I would have uploaded to Videohelp, etc. and is not the case.

You're asking me to use part of BDtoAVCHD for other applications and I'm just going to put certain conditions. That’s all.

---

Some test of upcoming BDtoAVCHD version with HW acceleration on i7-3770k CPU:

http://imageshack.us/a/img28/7461/m400.png


EDIT: Sorry for posting at same time as frencher

jdobbs
26th December 2013, 19:23
I saw that coming days ago...

Sharc
26th December 2013, 19:33
BDtoAVCHD is Adware, right?

Nico8583
26th December 2013, 20:53
Where is the interest to force users to install a free software that they will never use ?
Personally, if I must install your soft to use MVCSource, I'll never launch it and perhaps I will block BDtoAVCHD.exe with my firewall in order to be sure to stop all network traffic from/to the soft (to block Google Adsense for example)...
I don't understand your point of view, sorry. I think you should stop your work on BDtoAVCHD but continue only to update your good Avisynth plugin MVCsource ;) ;)

HWK
26th December 2013, 21:11
Frankly, I fail to comprehend logic of this altogether. I mean why force users to install program and more important according r0lz, take away from community and not give back. I would have shared mine but unfortunately it is property to MVC Encoder I use and can't be separated and distributed.

r0lZ
26th December 2013, 22:15
Perhaps someone here can do what pistacho did. Putting the MVC decoder in an avisynth plugin should not be extremely difficult. It should be sufficient to grab the source of any *Source avisynth plugin, and modify it to include the Intel decoder, as unmodified as possible. I don't know avisynth enough, and I don't have the right tools to do it myself, but I'm sure D9 is full of programmers that can do it. Someone is interested, or knows someone that could do it for us?

jdobbs, what trick do you use with FRIM to avoid to write large files to HDD?

HWK
26th December 2013, 22:34
jdobbs, what trick do you use with FRIM to avoid to write large files to HDD?

Couple of days back Jdobbs mentioned his main focus will be on doing proper 3d, rather than SBS or OU and based on light of this I think he uses pipe between two process, but of course I could be wrong as well.

frencher
27th December 2013, 06:50
Couple of days back Jdobbs mentioned his main focus will be on doing proper 3d, rather than SBS or OU and based on light of this I think he uses pipe between two process, but of course I could be wrong as well.

Intel Media SDK provides framework for MPEG2, H.264 AVC and H.264 MVC-3D encoding and decoding.
SDK is supported on Windows 7, Windows 8.x, and it can be freely distributed and used.

FRIM Encoder and FRIM Decoder are free command-line tools based on modification of examples from this SDK.


FRIM Encoder converts planar-yuv file, named pipe, uncompressed avi or Avisynth script into elementary MPEG2, H.264 AVC or MVC-3D streams.

HWK
27th December 2013, 06:56
Yes, I am aware of it. r0lz asked about intermediate files and for that I said Jdobbs will most likely use FRIM Encoder and FRIM Decoder with connection of pipe.

About avisynth script unless things have changed recently I was told 2.5.8 has issue with it and 26.0 is required. On that account jdobbs was not prepared to use beta of avisynth with BD-RB beta

frencher
27th December 2013, 06:58
Where is the interest to force users to install a free software that they will never use ?
Personally, if I must install your soft to use MVCSource, I'll never launch it and perhaps I will block BDtoAVCHD.exe with my firewall in order to be sure to stop all network traffic from/to the soft (to block Google Adsense for example)...
I don't understand your point of view, sorry. I think you should stop your work on BDtoAVCHD but continue only to update your good Avisynth plugin MVCsource ;) ;)

Same sorry no work now pay

BDtoAVCHD Topic on doom9 (http://forum.doom9.org/showthread.php?t=154957)

r0lZ
27th December 2013, 11:02
Frencher, I'm not interested in the Intel Encoder. Just the decoder. But afaik, currently, it can only write to uncompressed YUV. I need a way to grab its output from within an avisynth script, to compose the SBS or T&B images directly from the source, without having to write huge files on disc. It's what MVCSource does. Pity we can't use it in acceptable conditions.

You wrote earlier that FRIM has some bugs. Can you be more explicit? If, like MVCSource, it uses the Intel decoder, it should decode equally well. Or did you speak of the FRIM encoder?

mini-moose
27th December 2013, 11:23
BDtoAVCHD is Adware, right?

It appears like it is. Trying it now and it has a nasty ads window on the bottom.

Sadly, it doesn't allow a lot of flexibility in some cases. For example, the 2D option has a crop option but no preview or option to select exact crop values, just resolution defaults 1920x1040, 1920x800 etc).

r0lZ
27th December 2013, 11:37
It appears like it is. Trying it now and it has a nasty ads window on the bottom.
That throw light on why pistacho wants us to promote his soft. He count on us to earn more money. It's an additional reason to not use his MVCSource. We cannot promote a commercial program. IMO, we should even recommend to not use it, as BDtoAVCHD uses many free tools in a commercial program, without any credits to the authors. Also, the about box pretends that it is freeware, but it is adware. It's not acceptable.