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

[frencher]

This is good news :D
When this plugin is available ?

[Neisklar]

This is good news :D
When this plugin is available ?

Now;-)

http://www.share-online.biz/download.php?id=XG3QQKBMDM3

Here some parts from the included Readme:

DirectShowMVCSource Beta6

This is an Avisynth Plugin based on the 2.5.8 DirectShowFilter sourcecode,
which provides MVC (aka 3D Bluray/ssif) decoding through an DirectShow Graph
using CoreAVCDecoder.dll and MPEGSplitter.dll provided by MVCToAVI
(http://www.3dtv.at/Products/MvcConverter/Index_de.aspx) and optionally the
StereoTransformFilter (stf.dll) provided by Stereoscopic Player
(http://www.3dtv.at/Products/Player/Index_en.aspx) up to Version 1.8.1

###########################################################################
So the big work was done by the CoreCodec team and Peter Wimmer, so a big
thanks to them. Although it works with the unregistered versions, please be
so kind and support that work, by byeing at least a licence for the MVCToAVI
tool.
###########################################################################

Please note: it is only testet with the dlls from MVCToAVI Version 0.3.3
and onyl fro stf.dll 1.8.1. The stf.dll from the Stereoscopic Player 1.9.1
will NOT work.

Important: Except for the MPEGSplitter.dll which is under GPL, all other dlls
are copyrighted, so NEVER ask me to provide them to you. You have to get them
yourself. I'm sure the downloads with dlls working with this plugin will be
removed soon, so grab them now.

Additionally i want to make it clear that there is NO hacking/patching
(neither on disk nor in memory) of that dlls happening from this plugin,
it just uses them as they are, it only works around some "security", or
in better words, usage restrictions.
(for details see below after installation/usage)

I'm a Delphi, not a C(++) coder, so consider this as an hack to the original
DirectShowsource sourcecode with possible bugs, maybe memoryleaks (esp for the
interface retain/release stuff in the DirectShow COM world).
It's a classical "works-fine-for-me" thing.
There is a little bit error checking inside, but don't trust on that, so
if you use it the wrong way it may crash

Hopefully someone will improve the code, maybe even code SBS, OU, Anaglyph
functionality directly inside that plugin so that we don't need the stf.dll
anymore.

Quick Installation:

1) Create a Directory named "MVCTOAVI.EXE"
2) Put/Install there your encoding/working software
3) Take the MPEGSplitter.dll and CoreAVCDecoder.dll from the MVCToAVI
install-package and put them in the same directory as the
DirectShowMVCSource.dll Avisynth-plugin will be.
4) additionally for SBS, OU, anaglyph support take the stf.dll from the
StereoscopicPlayer install-package (max version 1.8.1 NOT the 1.9.x one)
and also put it aside the plugin dll

(If you use the CoreAVCDecoder.dll from the StereoscopicPlayer install-package
the directory you need to create is "STEREOPLAYER.EXE". It SHOULD work, but
it's not testet)

Just to be clear:
the external dlls need to be in the same directory as the DirectShowMVCSource.dll
plugin, and can be anywhere at your harddisk.
The executables MUST have (somewhere) in their path that magic string (it should
be caseINsesitive)

Usage:

# example AVS Script resulting in Half-OU, utilizing the stf.dll

LoadPlugin("DirectShowMVCSource.dll")
video = DirectShowMVCSource("X:\BDMV\STREAM\SSIF\xxxxx.ssif", stf=16) # Full OU, left eye top
AssumeFPS(video, 24000, 1001) #plugin is already relativly good at framerate detecttion, but
#sometimes slightly off
return video.BlackmanResize(1920, 1080)
#------------------------------------------------------------

Some more examples:
* Decodes the right eye full sized, doesn't need the stf.dll at all
video = DirectShowMVCSource("X:\BDMV\STREAM\SSIF\xxxxx.ssif")

* Decodes the left eye full sized, doesn't need the stf.dll at all
video = DirectShowMVCSource("X:\BDMV\STREAM\SSIF\xxxxx.ssif", decodeleft=true)

* Decodes both eyes and combines them with the stf.dll, here as Full SBS
video = DirectShowMVCSource("X:\BDMV\STREAM\SSIF\xxxxx.ssif", stf=14)

Some of the Values you can use for the stf-param:

14 - Full SBS, left eye left
16 - Full OU, left eye top
27 - Grey Anaglyph red-cyan
39 - Color Analglyph red-cyan
and more, just have a look at the bottom of the MVCStuff.h file from the source
For SBS/OU you always get Full version, so resize them in the avs script.

As it is based on the original DirectShowSource it supports many of that
parameters (http://avisynth.org/mediawiki/DirectShowSource):
fps, seek, convertfps, seekzero, timeout, pixel_type, framecount, logfile, logmask

Except the logging nothing is really testet, and i'm sure there are problems with
seeking, so try it for yourself.

If somthing not working you can enable logging with
logfile="somelogfilename.txt", logmask=-1. But don't use that during an normal
encode, since that logfile will grow huge, and the really interesting part is
only at the beginning.


Known Problems:

* too few errorcheks inside
* delphi coder, tried to code c++
* in rare circumstances the graph refuses to start
* and many more


Details on the CoreAVCDecoder.dll:

---snip---see ReadMe---snip

Im' pretty sure after releasing this information the security of that dll will change, so grab
them now as i won't provide them, since i do now own any rights on them.
And i hope they will be not so pissed because of that plugin.

############################################################################################

A big thank you to r0lZ, which tested code from an him unknown person on his computer,
and did a great help to find and fix some of the most show stopping bugs.


To decode an seamless branching movie just do something like this (out of head, so untestet):

LoadPlugin("DirectShowMVCSource.dll")
part1= DirectShowMVCSource("X:\BDMV\STREAM\SSIF\xxxxx.ssif", stf=16)
part2=DirectShowMVCSource("X:\BDMV\STREAM\SSIF\xxxxx.ssif", stf=16)
AssumeFPS(part1, 24000, 1001)
AssumeFPS(part2, 24000, 1001)
return (part1+part2).BlackmanResize(1920, 1080)


Have fun, and happy encoding.

[Penecho]

its running :D

your THE MAN (or woman) Neisklar :)

my script for half side-by-side:


LoadPlugin("DirectShowMVCSource.dll")
video = DirectShowMVCSource("X:\Temp\movie\BDMV\STREAM\SSIF\00034.ssif", stf=14)
AssumeFPS(video, 24000, 1001)
return video.Lanczos4Resize(1920, 1080)


only weird thing is, the framerate x264 shows me now is: 10000000/417083

I mean its 23,976043137696813344106568716538 alright, but looks weird :P

I report back when encode is done :)

[samfednik]

Neisklar

http://i25.fastpic.ru/big/2012/1008/c9/9f3351dd5efc81473ab46d454d6685c9.jpg
It works, but there is a question, why cannot use the for example Trim(500,1000) to encode a particular piece of video? And programs such as VirtualDub can not open the script.

P.S.: this is the Google Translator. I myself am from Russia.

[Neisklar]

It works, but there is a question, why cannot use the for example Trim(500,1000) to encode a particular piece of video? And programs such as VirtualDub can not open the script.

That plugin still has issues with seeking, as i provided the source, hopefully there is someone to fix it. I think Trim(500, ... requires to seek to frame 500, since Trim(0,-100) for example is working.

VirtualDubMod can open that file, if not, what is the error message?
Is it about NV12 Colorspace? then Try the pixel_type param in the Script or other Colorspace Conversions. If not, please provide a log file from the opening try (See Readme)
Please post logfiles and such stuff to sites like http://pastebin.com/

[r0lZ]

only weird thing is, the framerate x264 shows me now is: 10000000/417083
I've noticed the same thing when you don't force the framerate with AssumeFPS(). Note that the standard DirectShowSource has exactly the same problem.

What I don't understand is that in your script, the AssumeFPS command is present. It should therefore overwrite the wrong frame rate reported by the filter. Try with Info(), and see if the frame rate is correct.

[r0lZ]

And programs such as VirtualDub can not open the script.Don't forget that the app that opens your script MUST be in the "magic path". Read the doc, and try to move VDub where it will have a chance to work!

The Trim() problem (and the impossibility to seek to a specific time with a player, AvsPmod or VDub) is a known bug.

[samfednik]

Neisklar
Sorry, but took the dll from mvctoavi, Trim(...) working, and this is really cool! Different versions of the decoders (in stereoscopic ver.2.1.0.1, and mvctoavi - ver.2.5.1.0) work differently!
Use the following script:

SetMemoryMax(512)

LoadPlugin("DirectShowMVCSource.dll")

OU1 = 16 #OVERUNDER1 left top
OU2 = 15 #OVERUNDER2 right top
SBS1 = 14 #SIDEBYSIDE1 left first
SBS2 = 13 #SIDEBYSIDE2 right first

DirectShowMVCSource("p:\BDMV\STREAM\SSIF\00042.ssif", STF = OU1).Trim(5600,6100)

AssumeFPS(24000, 1001)

Lanczos4Resize(1920,1080) #Half Size

#ConvertToYV12 #For Anaglyph 3D coding x264

With x264 works:
http://i26.fastpic.ru/big/2012/1008/5b/1de03883600744a1e724d5d3c3ae945b.jpg
and how to open a Dub, do not understand? Can you explain with an example?

Added Logs:
http://pastebin.com/aRYkRz0J
http://pastebin.com/rKFgCuaW

[Penecho]

SBS1 = 13 #SIDEBYSIDE1 left first
SBS2 = 14 #SIDEBYSIDE2 right first





Hmm, the read me from Neisklar says 14 is left eye first...:

Some of the Values you can use for the stf-param:

14 - Full SBS, left eye left


Whats correct? and does it matter what eye is on which side whan watching it on a TV!?

[Neisklar]

and how to open a Dub, do not understand? Can you explain with an example?

Added Logs:
http://pastebin.com/aRYkRz0J
http://pastebin.com/rKFgCuaW

I don't understand what you mean with "open a Dub".

Both of your logs shows that there was some problem adding the CoreAVCDecoder.dll DirectShowFilter to the graph. I'm pretty sure thats because the calling application(*) was not in the magic path. I did forget to log the location from the calling application. So it's just a guess.

(*) Calling Application is that Applicatiopn which opens the .avs file, cause all .dll are loaded in that Applications context.

Whats correct? and does it matter what eye is on which side whan watching it on a TV!?

My tests showed 14 is left eye left (on stf.dll 1.8.1), and working on my TV. On my TV, if the pictures are interchanged, the deep is inverted, and thats something you definatly not want.

[samfednik]

I don't understand what you mean with "open a Dub".
This is = opens 3D.avs script in VirtualDub program...

I created a file path:
l: \ _3D \ MVCTOAVI.EXE \

just copy the virtualdub.exe and it worked.
http://i26.fastpic.ru/big/2012/1009/f1/3b380c0b3f17f7a1439ce67770a158f1.jpg
it is important that, you only need to run this copy in a folder virtualdub.exe!

Thanks for the cool hack MVCDecoder!

[r0lZ]

Whats correct? and does it matter what eye is on which side whan watching it on a TV!?
14 and 16 are left first.
And yes, the side matters. Currently, most TVs use by default left first, and it's becoming the standard. So, please do not use the 13 and 15 modes. It's a pain to have to go to the settings of the TV to swap the views!
(BTW, the picture just above this post seems inverted. It has the right eye on top.)

[PurpleMan]

Simply outstanding work! It works perfectly on the impossible MIB3 disc.

Running through x264 as we speak. Will let you know once the encoding is finished.

[frencher]

Above all we can say that Neisklar to hit god, very nice work :goodpost:
Before with ldecod and ultrafast preset, I reach the 5 fps x64 version
I wanted to test x264x86 SBS and ultrafast preset, I reach the 84 fps
I imagine a version compiled for x264x64 DirectShowMVCSourcex64.dll @ + 100 fps :D
Tested with i7 3930k not OC

Same work ;) AssumeFPS(23.976)

[r0lZ]

Unfortunately, it is not possible to make an x64 version of the decoder, because it uses x32 DLLs.

23.976 is NOT the correct frame rate for NTSC film. It must be 24000/1001 (23.976023976023976...), or, in avisynth, "ntsc_film".

[Neisklar]

Unfortunately, it is not possible to make an x64 version of the decoder, because it uses x32 DLLs.

What you can however do, is use (32bit) tools like 'avs2yuv' to pipe it to an 64bit x264.

[r0lZ]

That's right. But the decoding part will still run in 32bit mode.

[Penecho]

Do i need to do something speical with the Subtitles or can i just use bdsup2sub++ as usual...

Or are there problems when creating 3D half side-by-side video and put the subs from bdsup2sub++ in?

[r0lZ]

It depends of what you need. BD3D2AVS simply converts the SUP to IDX/SUB (and optionally extract only the forced subs) with BDSup2Sub++, and mux the IDX/SUP file with MkvMerge.

But my Samsung TV doesn't recognise the IDX/SUB format (and furthermore, it displays the SRT subtitles without any 3D depth, and it's a nightmare to read them), so usually, I prefer to hardcode the subtitles. That's a bit more difficult to do manually, as you have to modify the AVS script. If you want to hardcode the subs, I suggest to use BD3D2AVS to generate the script, then modify it to use the DirectShowMVCSource filter instead of ssifSource, and encode it with your version of x264.exe in the "magic path".

Also, many players or TVs need 3D subtitles (with two times the same bitmap, one for each view). If it's the case of your TV, you have to convert them. Currently, BD3D2AVS doesn't support that option, as there are no program to convert 2D subtitles in bitmap format to 3D, but that may change soon.

Anyway, try to simply convert the subs to IDX/SUB and mux them. Verify if your player or TV can show them, and if it's the case, you're lucky. :-)

I am currently writing a new version of BD3D2AVS that will use DirectShowMVCSource, but don't expect it soon. I have many modifications to do...

[frencher]

What you can however do, is use (32bit) tools like 'avs2yuv' to pipe it to an 64bit x264.
Have you example ?

23.976 is NOT the correct frame rate for NTSC film. It must be 24000/1001 (23.976023976023976...), or, in avisynth, "ntsc_film".
AssumeFPS(23.976)
avs [info]: 1920x1080p 1:1 @ 2997/125 fps (cfr) result is 2997 / 125 = 23.976 fps

AssumeFPS(29.97)
avs [info]: 1920x1080p 1:1 @ 2997/100 fps (cfr) result is 2997 / 100 = 29.97 fps

For fun
AssumeFPS(24.976)
avs [info]: 1920x1080p 1:1 @ 3122/125 fps (cfr) result is 3122 / 125 = 24.976 fps

[Neisklar]

That's right. But the decoding part will still run in 32bit mode.

But finally the decoding part isn't anymore the bottleneck;-)

Do i need to do something speical with the Subtitles or can i just use bdsup2sub++ as usual...

Or are there problems when creating 3D half side-by-side video and put the subs from bdsup2sub++ in?

This will be going to get longer, so please excuse;-)

You really need to test what your system can display, and it is also most important how you play it:

External Player:
If i play for example an TB or SBS Video from my WDTV Live, then my TV set doesn't know anything about subtitles, and subtitle rendering, thats all the job of the WDTV. Furthermore the WDTV itself doesn't even know that it's displaying 3D content/TB/SBS. So the TV sets gets only a video with the subtittles "burned in". For that the subtitles must be duplicated one for the left and one time for the right eye (with maybe some deep offset).
Since the WDTV doesn't even know its' displaying 3D stuff, .srt subtitles won't work at all (unless someday in the future there is an firmewareupdate which lets the user chose to display them 3D style).
The other subtitles are the image based ones like .sup (BD) or .sub/idx (VobSub). The Player could duplicate and scale that image accordingly or - and thats what i think will be the only good working way to do it - have the subtitle images be already 3D subtitles. So playing 3D stuff works an all external players regardless of 3D support or not!

Internal Player of TV set:
My TV set for example can display .srt subtitles and sub/idx Subtitles, BD .sup ones not at all.
Having an TB 3D Video and displaying it NOT in 3D mode, .srt subtitles are shown, switching to 3D mode, .srt subtitles aren't shown at all. Maybe there will be an firmware update someday in the future.
And i have forgotten my testing results of .sub/idx image based subtitles in 3D mode. I will edit my post later if i did it again.


I have written an quick'n'dirty commandline tool which will convert .sup and .sub subtitles to 3D subtitles in either .sup or .sub format with settable deep, utilizing bdsup2sub++.exe
You can download it here (current Version V0.5): http://www.share-online.biz/download.php?id=VYU90QCMHK0
Please be warned that it may crash, the result may not be as expected. For example i had one movie where the alpha was not correctly handled, so i got a big black bar on screen. Also the 3D subtitle file sare much larger.

To make things easy, put the bdsup2sub++.exe in the same dir as the tool and run it for example (default to OverUnder mode)
Suppe3D.exe -d 15 -if originalsubtitle.sup -of 3dsubtitle.sup
for SBS do:
Suppe3D.exe -sbs -d 15 -if originalsubtitle.sup -of 3dsubtitle.sup

Just run it without arguments to get a quick'n'dirty help

The -d param sets the deep, negative values are behind the screen. Don't set them to big, also it depends on the movie. I have for example one, where you even don't need deep at all, they are already placed out of the way of 'sticking out' objects.

This little tool won't be finished, please consider it only as a temporary solution till SassBot has the time to code that functionality inside the bdsup2sub++.exe

Edit2:
Have you example ?

Take for example the commandline MeGui creates
"X:\Rip\MVCTOAVI.EXE\MeGui2153\tools\x264\avs4x264mod.exe" --level 4.1 --tune film --crf 20.0 --keyint 240 --sar 1:1 --output "O:\3DMovie.mkv" "O:\SourceScript.avs"
This little helper calls the x264 and ppasses through all arguments.

Or with an "normal" avs2yuv one
avs2yuv <input avs> -o - | x264_x64.exe [opts] -o <out_file> - --demuxer y4m

[r0lZ]

AssumeFPS(23.976)
avs [info]: 1920x1080p 1:1 @ 2997/125 fps (cfr) result is 2997 / 125 = 23.976 fps

AssumeFPS(29.97)
avs [info]: 1920x1080p 1:1 @ 2997/100 fps (cfr) result is 2997 / 100 = 29.97 fps
I don't understand what you mean. I know that if you force 23.976 fps (or 29.97), Avisynth will do it.

The problem is that 23.976 and 29.97 are frames rates that DO NOT EXIST officially. The NTSC standard imposes a frame rate of 30000/1001, that is exactly 29.9700299700299700299700299700... ad infinitum. (It's why it is impossible to specify exactly the NTSC frame rate with a single floating point number.) 29.97 is therefore only a more or less good approximation, but if you mux a movie encoded at 29.97 with the original audio stream, you will have a slight AV sync problem at the end of the movie. You should therefore NEVER use 29.97. Instead, use 30000/1001 (or, in avisynth, "ntsc_video").

The problem with 23.976 is exactly the same. You MUST use 24000/1001, or "ntsc_film". (BTW, it's a pity that the HD video spec has validated that stupid NTSC film frame rate, as well as all problems associated with that impossible rate, such as the "drop frames" problem. IMO, it should have imposed the real film rate of 24 fps. The modern hardware must be able to show the video at 24 fps anyway, so I don't understand why the NTSC frame rate still exist, at least for film material.)

To make thing worse, the Info() command of avisynth displays always the rounded floating point frame rate, even when it is not exact. Do not trust it!

Of course, a video badly encoded may use the rounded frame rate of 23.976 or 29.76, and you may have to use that frame rate if you re-encode it. But you will never find that frame rates in BDs or professional video material. I repeat: they do not exist!

[frencher]

Ok Thank to all ;)

[Neisklar]

I'v updated the little 3D subtitle creation tool, to fix an alpha-background issue i had
you can get it here:
http://www.share-online.biz/download.php?id=C6W0PMBM8A

[Neisklar]

I have updated my little 3d subtitle creation tool to fix an issue with alpha channels
You can download it here:

http://www.share-online.biz/download.php?id=C6W0PMBM8A

[Penecho]

If i need to crop, can i just do

video = DirectShowMVCSource("blabla\00034.ssif", stf=14).crop( 0, 140, 0, -140)

and then resize to 1920x800 (in my example)

or do i need i to do it some special way?

[r0lZ]

You need to separate the two views, crop them, and recombine them in SBS or Top/Bottom.

BTW, it is not recommended at all to crop 3D material. Most TVs require full 16:9 images to display them correctly, so if you crop them, they will not be supported (or at least not correctly shown) by your TV. And if your current TV doesn't have that limitation, or if you watch your 3D movies on your PC, take in mind that someday you will buy a new TV.

[samfednik]

All for interesting! If you have a CoreAVC codec (not 3D, but a simple 2D), its settings "Brightness", "Contrast" and "Saturation" will affect MVCdecoder!
This is settings AVCdecoder ver.3.0.1:
http://i26.fastpic.ru/big/2012/1010/ff/493feef944d45ac05098b4fa07c369ff.jpg

Neisklar
Building on this finding, I ask you something. If the settings affect Picture level properties, it may have some hidden settings in the plugin to manage them?
And yet, is it possible to control the properties MVCdecoder the page "Options" settings are particularly interested options "Deinterlacing" for 3D-videocamera movie (http://dl.dropbox.com/u/28877157/00004.MTS) and "Cuda" option for Nvidia cards.
This is settings MVCdecoder ver.2.5.1.0:
http://i26.fastpic.ru/big/2012/1010/bf/6bdee717ecaddd08c4a77eee3874c5bf.jpg
And it would be cool if the tray icon appeared properties decoder if it really do?

[frencher]

All for interesting! If you have a CoreAVC codec (not 3D, but a simple 2D), its settings "Brightness", "Contrast" and "Saturation" will affect MVCdecoder!
This is settings AVCdecoder ver.3.0.1:
http://i26.fastpic.ru/big/2012/1010/ff/493feef944d45ac05098b4fa07c369ff.jpg

Neisklar
Building on this finding, I ask you something. If the settings affect Picture level properties, it may have some hidden settings in the plugin to manage them?
And yet, is it possible to control the properties MVCdecoder the page "Options" settings are particularly interested options "Deinterlacing" for 3D-videocamera movie (http://dl.dropbox.com/u/28877157/00004.MTS) and "Cuda" option for Nvidia cards.
This is settings MVCdecoder ver.2.5.1.0:
http://i26.fastpic.ru/big/2012/1010/bf/6bdee717ecaddd08c4a77eee3874c5bf.jpg
And it would be cool if the tray icon appeared properties decoder if it really do?

Just add some dll(s) and update DirectShowMVCSource not ?
CUDA Yeah :goodpost:

[Neisklar]

Unless im not mistaken there is no CUDA Support for MVC decoding, only for normal AVC decoding.
I could let the plugin display the decoder icon in the systray, but afaik thats not a normal CoreAVCDecoder. But i can set some options by code, but i'm not sure if i implement them all. But the plugins code is open source and some of the settings can be looked up in code, so feel free to adjust it to your needs;-)
I'm also the meaning that the plugin should be decode and provide the raw frames to avisynth, and then let do avisyth do filtering and co.

[Penecho]

You need to separate the two views, crop them, and recombine them in SBS or Top/Bottom.


Would that even be possible when using DirectShowMVCSource and the ssif file?

[r0lZ]

Yes, why not?
You can even decode the two views separately so that you don't need to crop the original video:

left=DirectShowMVCSource("filename.ssif", decodeleft=true).Crop(your crop params)
right=DirectShowMVCSource("filename.ssif").Crop(your crop params)
last=StackHorizontal(left, right)
BicubicResize(width, height)
AssumeFPS("ntsc_film")

Of course, you must modify the parameters in red to suit your needs.

The method above works only for SBS and Top/Bottom modes. If you want to encode in anaglyph, it's even more simple, as there is only one view, and no Resize:

# Optimized anaglyph red-cyan (stf=45)
DirectShowMVCSource("filename.ssif", stf=45)
Crop(your crop params)
AssumeFPS("ntsc_film")


It might be more difficult to encode in a fancy 3D mode such as row or column interleaved, but IMO, the script should be (almost) identical to the anaglyph script. Just change the value of the stf parameter.

Just be sure to always crop by an even number of pixels.

[Penecho]

left=DirectShowMVCSource("filename.ssif", decodeleft=true).Crop(your crop params)
right=DirectShowMVCSource("filename.ssif").Crop(your crop params)
last=StackHorizontal(left, right)
BicubicResize(width, height)
AssumeFPS("ntsc_film")



isnt that missing the stf = 14 at some point? or on the right= a decoderight=true or something?


edit: ah never mind just looked at the readme :x


* Decodes the right eye full sized, doesn't need the stf.dll at all
video = DirectShowMVCSource("X:\BDMV\STREAM\SSIF\xxxxx.ssif")

* Decodes the left eye full sized, doesn't need the stf.dll at all
video = DirectShowMVCSource("X:\BDMV\STREAM\SSIF\xxxxx.ssif", decodeleft=true)

[r0lZ]

No. You need the two views in different clips, not already stacked in a single view. The Stack and Resize commands combine them to Half-SBS (in my example).

Of course, if you encode in SBS format and you crop only the black horizontal bars of a Cinemascope movie, you can also use stf=14, and do the crop on the combined view. That should be a little bit more rapid:

DirectShowMVCSource("filename.ssif", stf=14).Crop(0, y1, 0, -y2)
BicubicResize(1920, height)


When the stf parameter is not specified (or is -1), the stf.dll is not used at all. (The decoding might be a little bit more rapid, but I'm not sure.) The parameter decodeleft=true is sufficient to get the left view, and decodeleft=false (the default) decodes the right view. The parameters decodeleft and stf are mutually exclusive, so don't try to specify them at the same time!

BTW, here are the values of all sft parameters that do not require special hardware or graphic cards:

Full Side by Side, Left first 14
Full Side by Side, Right first 13
Full Top/Bottom, Left first 16
Full Top/Bottom, Right first 15

Row interleaved, Left first 18
Row interleaved, Right first 17
Column interleaved, Left first 20
Column interleaved, Right first 19

Anaglyph: Optimised, Red - Cyan 45
Anaglyph: Optimised, Cyan - Red 46
Anaglyph: Optimised, Yellow - Blue 47
Anaglyph: Optimised, Blue - Yellow 48
Anaglyph: Optimised, Green - Magenta 49
Anaglyph: Optimised, Magenta - Green 50

Anaglyph: Colour, Red - Cyan 39
Anaglyph: Colour, Cyan - Red 40
Anaglyph: Colour, Yellow - Blue 41
Anaglyph: Colour, Blue - Yellow 42
Anaglyph: Colour, Green - Magenta 43
Anaglyph: Colour, Magenta - Green 44

Anaglyph: Half-colour, Red - Cyan 33
Anaglyph: Half-colour, Cyan - Red 34
Anaglyph: Half-colour, Yellow - Blue 35
Anaglyph: Half-colour, Blue - Yellow 36
Anaglyph: Half-colour, Green - Magenta 37
Anaglyph: Half-colour, Magenta - Green 38

Anaglyph: Grey, Red - Cyan 27
Anaglyph: Grey, Cyan - Red 28
Anaglyph: Grey, Yellow - Blue 29
Anaglyph: Grey, Blue - Yellow 30
Anaglyph: Grey, Green - Magenta 31
Anaglyph: Grey, Magenta - Green 32

Anaglyph: Pure, Red - Blue 23
Anaglyph: Pure, Blue - Red 24
Anaglyph: Pure, Red - Green 25
Anaglyph: Pure, Green - Red 26

Monoscopic 2D: Left only 1 (equivalent to decodeleft=true)
Monoscopic 2D: Right only 2 (equivalent to decodeleft=false)
Monoscopic 2D: AVC Source only 0

As you can see, left=DirectShowMVCSource("filename.ssif", decodeleft=true) is equivalent to left=DirectShowMVCSource("filename.ssif", sft=1) and right=DirectShowMVCSource("filename.ssif", decodeleft=false) is equivalent to right=DirectShowMVCSource("filename.ssif", stf=2), with the difference that stf.dll is used with the second syntax.

Also, stf=0 doesn't decode the MVC stream, and returns the AVC stream, that is usually (or always?) the left stream, so normally, stf=0 is equivalent to stf=1 and to decodeleft=true, and should also be equivalent to DirectShowSource("filename.m2ts").

[frencher]

It's possible with this code ?

left = DirectShowMVCSource("Left.h264", stf=?)
right = DirectShowMVCSource("Right.h264", stf=?)
return StackHorizontal(left, right).BicubicResize(1920,1080).AssumeFPS(24000, 1001)

[r0lZ]

I don't understand why you want to do that. DirectShowMVCSource decodes the left and right views, so if you have them already in h264, you can't decode them again. Anyway, to use the stf parameter, you need to decode a SSIF file. It doesn't work with raw h264 streams, or with m2ts files. (BTW, due to limitations in the Stereo Player filters, it doesn't work either with MPLS files. Pity!)

I suppose you need something to source a h264 stream, right? IMO, the best method is to mux it to mkv, and then use DirectShowSource.

[frencher]

I tried but without success it is possible to have an example?:D

[frencher]

No right is MVC demuxed with eac3to ;)
left = DirectShowMVCSource("Left_AVC.h264", stf=?)
right = DirectShowMVCSource("Right_MVC.h264", stf=?)
return StackHorizontal(left, right).BicubicResize(1920,1080).AssumeFPS(24000, 1001)

[r0lZ]

DirectShowSource("filename.mkv") ;)

[frencher]

Left_AVC.h264
Right_MVC.h264

[r0lZ]

No solution!

[frencher]

Update of DirectShowMVCSource :thanks:

[r0lZ]

I'm not sure it's feasible. It uses the original DLLs for what they can do.

[frencher]

I thought redirection of pipe...

[r0lZ]

How? It needs probably the structure of a BD to work correctly.

[frencher]

Left_AVC.h264
Right_MVC.h264I search a software to remux a stream AVC + MVC streams into .mts or.mp4 (3D) usable with DirectShowMVCSource ?
3D camcorder use .mp4 3D and .mts 3D (SONY)
3D MTS Sample 1 (http://img1.lesnumeriques.com/produits/16/11050/00035.MTS), 3D MTS Sample 2 (http://img1.lesnumeriques.com/produits/16/11050/00023.MTS)

[Eseninzhiv]

perhaps
Adobe Premiere
EDIUS 6.5
without DirectShowMVCSource

[r0lZ]

I've noticed something strange with DirectShowMVCSource. When encoding in SBS, Top/Bottom or monoscopic format, the pixel_type is YV12, and that's correct IMO.
But when encoding in any anaglyph or interleaved format, the pixel_type is RGB32.
I suppose that the CoreAVCDecoder filter produces RGB in anaglyph and interleaved format, and that the DirectShowMVCSource plugin doesn't convert it. Not a big deal, but that's strange. Is it normal, or intentional?

Also, I have tried to add the pixel_type = "YV12" argument to the DirectShowMVCSource command (in anaglyph format), but when I do that, it complains that it cannot determine the frame rate! Without the argument, it assumes a slightly wrong frame rate, but it works. Also, even more strange, the pixel_type argument works well in SBS or T/B format.

Example:
DirectShowMVCSource("Z:\BDMV\STREAM\SSIF\00006.ssif", stf=45, pixel_type="YV12") # anaglyph
returns: DirectShowSource: I can't determine the frame rate of the video, you must use the "fps" parameter.

But this command works perfectly:
DirectShowMVCSource("Z:\BDMV\STREAM\SSIF\00006.ssif", stf=14, pixel_type="YV12") # SBS
(Checked also with "RGB32" and it works fine.)

I don't understand why the pixel_type seems related to the frame rate.

Note also that DirectShowMVCSource identifies itself in its error messages with "DirectShowSource". Small bug to fix here.

[Neisklar]

Sorry for answering late, but much work to do

I search a software to remux a stream AVC + MVC streams into .mts or.mp4 (3D) usable with DirectShowMVCSource ?

Without test, just a wild guess. Use tsMuxer and mux it in an .ts or .m2ts file and try that.

I want to point out again the inner workings of that plugin for those which didn't already have a look at the source.
The plugin itself doesn't do any fancy stuff, it just builds an mostly STATIC(*) DirectShow-Graph with an FileSource/Splitter Filter (the MPEGSplitter.dll), then the decoding with the CoreAVCDecoder.sll Filter optionally some stereo tranformations with the stf.dll Filter, and thats it. Mostly all is handled by external filters, which where written by other people.
(*) static means, all Filters are loaded by hand, connected by hand and so on.

So, of course it is possible to use some other FileSource Filter to get the data in the graph, it should probaly work with the simple Microsoft "File Source (Async.)"-FileSource Filter. But that means more logic inside the plugin, more possible errors (remember i am a delphi not a c++ coder), and more options for the filter to add, since i don't know how to code an autodetection.
Although DirectShow-Graphs support an autorendering feature which automagically loads the needed filters and builds the graph, this won't work in this case due to the special circumstances and inner workings of the used filters.
(Well it's possible, but thats heavy work: Let DirectShow autogenerate the graph, then walk through that graph, throwing most of the unneeded filters out, only to get the right loader filters.)

It is just better to take the code, its GPL, modify it to have two filename params, modify it to use the other FileSource Filter.


I've noticed something strange with DirectShowMVCSource. When encoding in SBS, Top/Bottom or monoscopic format, the pixel_type is YV12, and that's correct IMO.
But when encoding in any anaglyph or interleaved format, the pixel_type is RGB32.
I suppose that the CoreAVCDecoder filter produces RGB in anaglyph and interleaved format, and that the DirectShowMVCSource plugin doesn't convert it. Not a big deal, but that's strange. Is it normal, or intentional?

I have no idea;-), but that colorspace stuff is done by the stf.dll not the decoder.

Also, I have tried to add the pixel_type = "YV12" argument to the DirectShowMVCSource command (in anaglyph format), but when I do that, it complains that it cannot determine the frame rate! Without the argument, it assumes a slightly wrong frame rate, but it works. Also, even more strange, the pixel_type argument works well in SBS or T/B format.

I don't understand why the pixel_type seems related to the frame rate.

Maybe there is anything interesting in the logfiles, haven't checked that mailbox yet. Unless im not mistaken the code taken from the original DirectShowSource Filter can do some colorspace conversations. Maybe that pixel_type can also just mean that the final "frame-grabbing"-filter only accepts this colorspacel, the stf-filter can't provide it, so the Pins of the filters are not connected correctly resulting in an non working graph, which then can not provide an framerate.

Note also that DirectShowMVCSource identifies itself in its error messages with "DirectShowSource". Small bug to fix here.

I know;-) next version, we also need some better errormessages if the file is just not found.

[r0lZ]

I have no idea;-), but that colorspace stuff is done by the stf.dll not the decoder.
It's what I've supposed. Anyway, no big deal, but IMO it's something the users must know.

Maybe there is anything interesting in the logfiles, haven't checked that mailbox yet. Unless im not mistaken the code taken from the original DirectShowSource Filter can do some colorspace conversations. Maybe that pixel_type can also just mean that the final "frame-grabbing"-filter only accepts this colorspacel, the stf-filter can't provide it, so the Pins of the filters are not connected correctly resulting in an non working graph, which then can not provide an framerate.
Perhaps, yes. No big deal again. Luckilly, with Avisynth, it is possible to use ConvertToYV12() and AssumeFPS().


I know;-) next version, we also need some better errormessages if the file is just not found.
I know you know ;-)
Consider it as a reminder.