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

[vanden]

Maybe the new Decoder even works with the old STF.dll in single stream MVC-mode.
Unfortunately no ...

[Thalyn]

New Splitter and most of all new MVC Decoder!!!

Anyone had a try?
Given it a run using the same ol' DirectShowMVCSource.dll... seems to have worked perfectly for Monsters Vs Aliens (no black lines towards the bottom of the frame), but The Amazing Spider-Man had some points in the middle of the movie (around frame 71,290) where the right eye stalled (for lack of a better term), putting the right eye behind for the rest of the movie.

If you really want your brain to hate you, try watching a 3D movie with the eyes slightly out of sync.

Running it again with the old DLLs to see if it's an incompatibility or bad source.

Update: Recode using the original DLLs worked just fine. Not quite sure what to make of that other than the source not being at fault.

[jdobbs]

Given it a run using the same ol' DirectShowMVCSource.dll... seems to have worked perfectly for Monsters Vs Aliens (no black lines towards the bottom of the frame), but The Amazing Spider-Man had some points in the middle of the movie (around frame 71,290) where the right eye stalled (for lack of a better term), putting the right eye behind for the rest of the movie.

If you really want your brain to hate you, try watching a 3D movie with the eyes slightly out of sync.

Running it again with the old DLLs to see if it's an incompatibility or bad source.

Update: Recode using the original DLLs worked just fine. Not quite sure what to make of that other than the source not being at fault.I've seen that happen with the old DLLs. Interestingly, all I had to do was run the job again and it was fine.

[r0lZ]

Hum, maybe It's what I got too. I have encoded a 3D BD in SBS and watched it. Everything was OK, but I have decided to re-encode it anyway because I wanted a higher bit-rate. The second time, I got many problems in a part of the movie (approx 5 minutes), certainly not due to x264. In both cases, I've used the "old" DLLs. Nothing has changed in the decoding process, and I don't understand why the same DLLs can give different results when decoding exactly the same source, with the same parameters. A random bug?
I'm currently encoding the same BD for the third time, but this time I use a CombinedMVC.m2ts stream as input.

[EDIT] Third encoding finished. No problem (at least in the 5 minutes that were bad in my previous try. I haven't watched the whole movie yet.) So, either the MVCCombine method is more reliable, or there is a random bug in a DLL, that happens only from time to time.

[slavanap]

Here is a pre-version of ssifSource3. I tried to add precise frame seeking (may not work in all cases yet) and several ssif-files support. New method for framecount detect will be added soon. Works with the latest CoreAVC decoder (3.0.0.2), but previous version of mpegsplitter (1.5.2.3102).
Parameters of ssifSource3 is similar as ssifSource2.
ssifSource2(ssif_file, frame_count, left_view, right_view, horizontal_stack)
ssifSource3(ssif_files_list, left_view, right_view, horizontal_stack)

Example:
ssifSource3("first.ssif;1000;second.ssif;2000;third.ssif;3000", left_view = true, right_view = true)
where first.ssif has 1000 frames, second.ssif - 2000 frames and so on. (use 0 value as framecount to force framecount autodetection).
The result video will have 6000 frames.
Ssif-files is loaded as they needed (and unloaded if not) so 2GB memory should be enough (use avisynth setmemorymax command for sure).

The result video sequence is the sum of referenced video files.

ssifSource2 method is also supported.

Link: http://sendfile.su/816447

[r0lZ]

Thanks!

BTW, how do you determine what streams (AVC or MVC) contains the left and right views? I have always supposed that the AVC stream contains always the left view, but it's not the case. At least 3 3DBDs have the left and right view "inverted". Unfortunately, eac3to assumes also always the first (AVC) stream as being the left view, as you can see here (http://forum.doom9.org/showthread.php?p=1629986#post1629986). If ssifsource3 assumes also AVC=left & MVC=right, can you add an option to invert the two views?

If someone knows how to determine for sure the order of the left/right views, please share your method.

[r0lZ]

@Neisklar: I've found a strange bug with Suppe3D (v0.5), when converting subtitles from the Ice Age 3 3DBD to 3D.

These commands do not work:

CD /d "D:\My Additional Documents\Desktop2\BD3D2MK3D_projects\IceAge3\00001_m2ts"

"D:\Tools\BD3D2MK3D\toolset\Suppe3D.exe" -b "D:\Tools\BD3D2MK3D\toolset\BDSup2Sub++.exe" -d 10 -r bilinear -sbs -if "16 Subtitle (PGS), French.sup" -of "16 Subtitle (PGS), French 3D.sub"

creating temp dir: D:\My Additional Documents\Desktop2\BD3D2MK3D_projects\IceAge3\00001_m2ts\.suppe3d\
###########################
Extracting subtitles to PNG
###########################
calling: "D:\Tools\BD3D2MK3D\toolset\BDSup2Sub++.exe" -o "D:\My Additional Documents\Desktop2\BD3D2MK3D_projects\IceAge3\00001_m2ts\.suppe3d\temp.xml" "16 Subtitle (PGS), French.sup"
done ("D:\Tools\BD3D2MK3D\toolset\BDSup2Sub++.exe" -o "D:\My Additional Documents\Desktop2\BD3D2MK3D_projects\IceAge3\00001_m2ts\.suppe3d\temp.xml" "16 Subtitle (PGS), French.sup")
Done extracting subs as PNG
##########################################
Starting creating Stereo images full sized
##########################################
EFOpenError: Datei D:\My Additional Documents\Desktop2\BD3D2MK3D_projects\IceAge3\00001_m2ts\.suppe3d\temp_0006_2.png kann nicht geöffnet werden. The system cannot find the file specified

Indeed, temp_0006_2.png doesn't exist in the .suppe3d temp dir.

Strangely, these commands work perfectly (of course, applied to the same SUP file in the same directory):

CD /d "D:\My Additional Documents\Desktop2\BD3D2MK3D_projects\IceAge3\00001_m2ts"

"D:\Tools\BD3D2MK3D\toolset\Suppe3D.exe" -b "D:\Tools\BD3D2MK3D\toolset\BDSup2Sub++.exe" -d 10 -r bilinear -sbs -if "D:\My Additional Documents\Desktop2\BD3D2MK3D_projects\IceAge3\00001_m2ts\16 Subtitle (PGS), French.idx" -of "16 Subtitle (PGS), French 3D.sub"

I haven't included the output messages, but they are absolutely normal.

Note that the ONLY thing that has changed is the full path in the input file name. Strange, isn't it?

Note that BD3D2MK3D uses always the filename without the path (after having set the current directory correctly of course), and I have never seen that bug. However, in this case, there are many messages related to fades in the original subtitle palette, and I suppose it's why temp_0006_1.png (and normally temp_0006_2.png) are generated in addition to temp_0006_1.png.

I can upload the SUP file if you need it.

[EDIT] Seems it's a BDSup2Sub bug. With that subtitle file, it creates often strange black PNG images, not included when the SUP is converted to SUB, but present when it is converted to PNG/XML. And for many subtitles, it creates only 2 different images, but it references more images (up to 5) in the XML file. Of course, Suppe3D cannot process the missing images.
I've found a workaround for BD3D2MK3D: Since the SUP is converted to 2D SUB anyway (and before the 3D conversion), I use the 2D SUB file as input. That works perfectly.

[jdobbs]

Thanks!

BTW, how do you determine what streams (AVC or MVC) contains the left and right views? I have always supposed that the AVC stream contains always the left view, but it's not the case. At least 3 3DBDs have the left and right view "inverted". Unfortunately, eac3to assumes also always the first (AVC) stream as being the left view, as you can see here (http://forum.doom9.org/showthread.php?p=1629986#post1629986). If ssifsource3 assumes also AVC=left & MVC=right, can you add an option to invert the two views?

If someone knows how to determine for sure the order of the left/right views, please share your method.In the AppInfoPlayList() table of the MPLS file -- look for MVC_Base_view_R_flag. It is a 1 bit flag -- if it is set to 0 then the MVC base view is for the left eye. If it is set to 1 then the base view video stream is for the right eye.

Note: It is bit 4 of the byte located at offset 56 (0x38) of the MPLS file (with offset 0 being the first byte of the file).

OFFSET 0x38: 000X 0000

[Edit] Corrected the offset -- I forgot to account for the UO_Mask table.

[Thalyn]

First encode with ssifSource3 went through without a hitch after I figured out what I was doing wrong with the parameters, Slavanap. Good speed and good results, so I'll put it to task and try a couple more when I'm done typing here.

Source material was The Adventures of Tintin, in case you're keeping a compatibility list.

[jdobbs]

Here is a pre-version of ssifSource3. I tried to add precise frame seeking (may not work in all cases yet) and several ssif-files support. New method for framecount detect will be added soon. Works with the latest CoreAVC decoder (3.0.0.2), but previous version of mpegsplitter (1.5.2.3102).
Parameters of ssifSource3 is similar as ssifSource2.
ssifSource2(ssif_file, frame_count, left_view, right_view, horizontal_stack)
ssifSource3(ssif_files_list, left_view, right_view, horizontal_stack)

Example:
ssifSource3("first.ssif;1000;second.ssif;2000;third.ssif;3000", left_view = true, right_view = true)
where first.ssif has 1000 frames, second.ssif - 2000 frames and so on. (use 0 value as framecount to force framecount autodetection).
The result video will have 6000 frames.
Ssif-files is loaded as they needed (and unloaded if not) so 2GB memory should be enough (use avisynth setmemorymax command for sure).

The result video sequence is the sum of referenced video files.

ssifSource2 method is also supported.

Link: http://sendfile.su/816447Wow. Thanks. This should save some time in combining the segments. Is the DLL supposed to be named "ssifsource2.dll" when I download? I just want to make sure I'm getting the right one.

Just for clarity: Does this plugin always assume the base MVC is the left-eye view, or can it tell dynamically?

[r0lZ]

In the AppInfoPlayList() table of the MPLS file -- look for MVC_Base_view_R_flag. It is a 1 bit flag -- if it is set to 0 then the MVC base view is for the left eye. If it is set to 1 then the base view video stream is for the right eye.

Note: It is bit 4 of the byte located at offset 56 (0x38) of the MPLS file (with offset 0 being the first byte of the file).

OFFSET 0x38: 000X 0000
Thanks. It's exactly what I need.

Where can I see a complete description of that table?

Just for clarity: Does this plugin always assume the base MVC is the left-eye view, or can it tell dynamically?
Since ssifSource2 doesn't read the MPLS file, I suppose it assumes always the AVC=left and MVC=right order. That means that the command line option to invert the order is really necessary. Also, for consistency, the "left_view" and "right_view" parameters should be renamed "avc_view" and "mvc_view" (or simply avc and mvc), but that's less important.

[jdobbs]

Thanks. It's exactly what I need.

Where can I see a complete description of that table?


Since ssifSource2 doesn't read the MPLS file, I suppose it assumes always the AVC=left and MVC=right order. That means that the command line option to invert the order is really necessary. Also, for consistency, the "left_view" and "right_view" parameters should be renamed "avc_view" and "mvc_view" (or simply avc and mvc), but that's less important.In the BD standard they are called "base view" and "dependent view" -- but I get your meaning and as long as we're consistent it really doesn't matter. :)

[r0lZ]

Oh, well, the "base/dependent view" terminology is OK for me! It's what DVDFab displays, and I must admit that for a newbie, that terminology is simpler to understand than AVC/MVC. Anyway, the user of a GUI should not have to bother with these views. He wants, say, side-by-side left first, and it's the responsibility of the GUI to combine the views in the correct order.

[Thalyn]

Wow. Thanks. This should save some time in combining the segments. Is the DLL supposed to be named "ssifsource2.dll" when I download? I just want to make sure I'm getting the right one.

I thought that at first, too, but it definitely has the ssifSource3 command in it. It also has the ssifSource2 command, just to be confusing, but I've no idea if that uses the old or new code so I'm just sticking with the 3 for now.

Underworld: Awakening worked just fine with it. Speed was a little less impressive than Tintin at around 2/3 the 2D speed (vs ~92%), but I guess some title-to-title variation is to be expected. Universal Soldier is next (guess what letter I'm up to in my transcodes?:rolleyes:)

Update: Interesting observation with UniSol. I've been getting my durations using the in-built DirectShowSource and FrameCount commands, but UniSol claimed it had billions of frames when I did that. This could be part of why the auto-detection doesn't work correctly sometimes.

Update 2: UniSol stalled out at frame 100992/163826 - no error, but it stopped processing. Going to extract the streams from the ssif just in case there was something else in the container it didn't like, and report back.

Update 3: EAC3to reported a "sync byte missing" at a time which would be around the same frame the earlier attempt failed at, with the left and right streams actually reporting the same error at different times. I suspect this is the cause, which means it's more the source than the plugin at fault. Will be interesting to see if re-packaging it actually works at all.

[jdobbs]

Here is a pre-version of ssifSource3. I tried to add precise frame seeking (may not work in all cases yet) and several ssif-files support. New method for framecount detect will be added soon. Works with the latest CoreAVC decoder (3.0.0.2), but previous version of mpegsplitter (1.5.2.3102).
Parameters of ssifSource3 is similar as ssifSource2.
ssifSource2(ssif_file, frame_count, left_view, right_view, horizontal_stack)
ssifSource3(ssif_files_list, left_view, right_view, horizontal_stack)

Example:
ssifSource3("first.ssif;1000;second.ssif;2000;third.ssif;3000", left_view = true, right_view = true)
where first.ssif has 1000 frames, second.ssif - 2000 frames and so on. (use 0 value as framecount to force framecount autodetection).
The result video will have 6000 frames.
Ssif-files is loaded as they needed (and unloaded if not) so 2GB memory should be enough (use avisynth setmemorymax command for sure).

The result video sequence is the sum of referenced video files.

ssifSource2 method is also supported.

Link: http://sendfile.su/816447Is this release "throttled" somehow to the frame rate of the video? In my testing is seems that no matter what X264 settings I use -- the encode speed is locked at no more than 1x the frame rate.

I also notice that my cpu usage only hangs at aroung 40-50%, indicating that X264 is waiting for frames.

[slavanap]

Another pre-version: http://sendfile.su/817250

ssifSource2(ssif_file, frame_count, avc_view, mvc_view, horizontal_stack, swap_views)
ssifSource3(ssif_files_list, avc_view, mvc_view, horizontal_stack, swap_views)

swap_views values :: -1 for autodetect (on blu-ray disc, thanks for jdobbs solution), 0 - not swap (avc = left, mvc = right), 1 - for overwise.

Thank you for testing!

Wow. Thanks. This should save some time in combining the segments. Is the DLL supposed to be named "ssifsource2.dll" when I download? I just want to make sure I'm getting the right one.

Just for clarity: Does this plugin always assume the base MVC is the left-eye view, or can it tell dynamically?

I rename ssifSouce2 to ssifSource3 when I finish the work on it. It now just a pre-version (alpha). Please, tell me about any bugs you found.


Update 2: UniSol stalled out at frame 100992/163826 - no error, but it stopped processing. Going to extract the streams from the ssif just in case there was something else in the container it didn't like, and report back.

Update 3: EAC3to reported a "sync byte missing" at a time which would be around the same frame the earlier attempt failed at, with the left and right streams actually reporting the same error at different times. I suspect this is the cause, which means it's more the source than the plugin at fault. Will be interesting to see if re-packaging it actually works at all.

Sorry for taking your time. I probably have to get back the timeout parameter for frame decoding that I have deleted. I haven't thought about buggy content.

Is this release "throttled" somehow to the frame rate of the video? In my testing is seems that no matter what X264 settings I use -- the encode speed is locked at no more than 1x the frame rate.

I also notice that my cpu usage only hangs at aroung 40-50%, indicating that X264 is waiting for frames.

It seems, that it is mine fault, sorry for that. I started to use DirectShow timings to make proper seeking through the video. So I think it uses default framerate when playing now. I'll fix ASAP.

Thank you for the feedback. I don't know how much time I would have to spend to find out all of that info.

[Nico8583]

Is it possible with ssifSource3 to create 1 avs for left eye and 1 avs for right eye ? Or output must be a stack (horizontal or vertical) ?
Thanks !

[r0lZ]

@slavanap: Thanks for the swap_views parameter (and the avc/mvc terminology)!

@Neikslar: Is it possible to add a swap_views parameter in DirectShowMVCSource? It is not really needed when encoding from a CombinedAVC-MVC.m2ts file (since the combination of the two views to SBS or TB is made by the AVS script anyway), but it is necessary when using the stf parameter.)

@nico8583: I guess this is what you want:
AVS 1:
ssifSource2(ssif_file, frame_count, avc_view=true, mvc_view=false)
AVS 2:
ssifSource2(ssif_file, frame_count, avc_view=false, mvc_view=true)

[Nico8583]

@nico8583: I guess this is what you want:
AVS 1:
ssifSource2(ssif_file, frame_count, avc_view=true, mvc_view=false)
AVS 2:
ssifSource2(ssif_file, frame_count, avc_view=false, mvc_view=true)
Perhaps :) I would like to create 1 AVS to see 1920x1080 left eye and 1 AVS to see 1920x1080 right eye but without stack. I'll try your tip ;)

[slavanap]

Wow. Thanks. This should save some time in combining the segments. Is the DLL supposed to be named "ssifsource2.dll" when I download? I just want to make sure I'm getting the right one.

Just for clarity: Does this plugin always assume the base MVC is the left-eye view, or can it tell dynamically?

Yes, correct, you are using the right dll. Actually it does not matter what name dll has, because one dll can export different AviSynth fuctions.
I've added auto views swap detection, which is based on mpls files in blu-ray disc. swap_views parameter is used to set should views be swapped.
If it equals 0 - base view (AVC) is assumed left view, dependent view (MVC) is assumed right view;
if it equals 1 - base view is assumed right view, dependent - left;
if it equals (-1) then autodetection algorithm runs. it searches ssif filename in mpls files located in "..\\..\\PLAYLIST\\" directory related to directory with ssif file. (See the ssifSource log messages for more info. Log messages is available, for example, when you encoding with x264.)


Underworld: Awakening worked just fine with it. Speed was a little less impressive than Tintin at around 2/3 the 2D speed (vs ~92%), but I guess some title-to-title variation is to be expected. Universal Soldier is next (guess what letter I'm up to in my transcodes?:rolleyes:)

Speed issue might be fixed for you in dll in the next post.

Update: Interesting observation with UniSol. I've been getting my durations using the in-built DirectShowSource and FrameCount commands, but UniSol claimed it had billions of frames when I did that. This could be part of why the auto-detection doesn't work correctly sometimes.

Can you try the new ssifSource lib with framecount autodetection on that source? It may fail, of course.

Update 2: UniSol stalled out at frame 100992/163826 - no error, but it stopped processing. Going to extract the streams from the ssif just in case there was something else in the container it didn't like, and report back.

Update 3: EAC3to reported a "sync byte missing" at a time which would be around the same frame the earlier attempt failed at, with the left and right streams actually reporting the same error at different times. I suspect this is the cause, which means it's more the source than the plugin at fault. Will be interesting to see if re-packaging it actually works at all.

I think I have to test it by my own, to get to know what happens with CoreAVC during processing this film. Where can I get the source you use?

[slavanap]

Well, the beta (i hope so) version of ssifSource lib:
http://sendfile.su/817501

Changes:
* now all ssifSource solutions is combined in this lib.
ssifSource, ssifSource2 and ssifSource3 functions are available.
* fixed the issue with decoding speed throttle.
* framecount autodetect algorithm improved.
* left_view & right_view parameters renamed to avc_view & mvc_view.
* added swap_views parameter.

About the fuctions:
The old one:
ssifSource(ssif_file, width, height, frame_count, left_track, right_track, left_264, right_264, show_params)
Parameters description are available in previous ssifSource package. This fuction uses ldecod_mod.exe & eac3to.exe (the modified one for proper pipes support).

ssifSource2(ssif_file, frame_count, avc_view, mvc_view, horizontal_stack, swap_views)
ssifSource3(filelist, avc_view, mvc_view, horizontal_stack, swap_views)

Actually ssifSource3 uses ssifSource2 to display each of the files in the filelist.

filelist - string parameter, the list of files that will be displayed sequentially. filelist format is filename1;framecount1;filename2;framecount2 and so on.
filenameX - is filename (related or fully qualified) of the ssif file. framecountX is the framecount in that file. if you specify 0 as framecount, then ssifSource2 will try to autodetect framecount of this file.

avc_view, mvc_view - boolean. Defines that base and/or dependent views should be displayed.

horizontal_stack - boolean. It makes sense only when avc_view and mvc_view are true. If horizontal_stack is true, views stacks horizontally, overwise - vertically.

swap_views - integer. It makes sense only when avc_view and mvc_view are true. Defines in which order views are displayed. If swap_views = -1 then autodetection algorithm based on mpls files tries to detect whether or not them should be swapped. If swap_views = 0 then views are not swapped, if = 1 then they are swapped.
Explanation for horizontal_stack = true:
swap_views = 0 -> base (avc) view is on the left, dependent (mvc) view is on the right
swap_views = 1 -> dependent view is on the left, base view is on the right.

Note: coreavc version 3.0.0.2 & mpegsplitter version 1.5.2.3102 is required for ssifSource2 & ssifSource3
(also works with older ones).

Please, do not rely on accurance of framecount autodetect and frame seeking. (In my testing I get the worst accurance is 4 seconds of video). I really don't know how the decoder works, I just use the data it returns in the most effective way. So what I gonna do next is adding a create-text-based-index feature in ssifSource2&3 to dump directshow timings for each frame. (actually, decoder does not support frame seeking, and my solution is based on processing of directshow timings).

I hope, that description of the new features would be enough.
If you'll find any bugs, please let me know.

ADDED:
Default values for ssifSource2&3 parameters are:
frame_count = 0 // forces autodetect
avc_view = false
mvc_view = true
horizontal_stack = false
swap_views = -1 // forces autodetect
If you did not specify any of these parameters, the default value is used.

[jdobbs]

@slavanap

I'm running the newer version on a job with a huge number of segments right now... it's working great, with an impressive speed improvement over the last release. Sweet. I'll let you know how it works out.

[Thalyn]

Can you try the new ssifSource lib with framecount autodetection on that source? It may fail, of course.

*snip*

I think I have to test it by my own, to get to know what happens with CoreAVC during processing this film. Where can I get the source you use?

The source was apparently the where my problems were. Source being an original Universal Solder: Day of Reckoning 3D BluRay.

Seems if you use the SSIF directly (including copying it to a HDD) than it gives all of the problems I had - the stall, the EAC3To errors and the bizarre framecount. Working from the two M2TS files instead gave me a good source and subsequently clean results. So I'd personally chalk that one up to just something weird with how the disc was mastered.

I'll give the new plugin a try as soon as my current transcode finishes. I got a few I need to re-do as I originally used H264StereoSource (had to trim frames), so they should give the auto-detect and seamless branching a good work-out.

[r0lZ]

About the fuctions:
The old one:

Parameters description are available in previous ssifSource package. This fuction uses ldecod_mod.exe & eac3to.exe (the modified one for proper pipes support).
Can you upload the two exes or give the link to download the previous ssifsource package? I'm not sure I have the correct versions of the exes.

[PurpleMan]

I was just wondering, is there currently any advantage in using ssifSource over DirectShowMVCSource (based on coremvc)?

(Other than the fact it costs money)

[Nico8583]

ssifSource2 uses CoreAVC dll but CoreAVC is free ?

[jdobbs]

ssifSource2 uses CoreAVC dll but CoreAVC is free ?No. But you can get it fairly cheaply by buying "Stereoscopic Player" at www.3dtv.at (I did). It costs about 39 euros. You used to be able to get it with "MVC to AVI" for 19 euros -- but that price has risen to 29 euros now.

[frencher]

Update my package ultimate Intel MVC Decoder x86 & x64 & SSE support + src (http://forum.doom9.org/showthread.php?p=1627007#post1627007)

[Nico8583]

What does your package do or permit ? :)

[r0lZ]

It does MVC decoding, encoding and transcoding. I'm currently testing it. It is open source. IMO, it could be the best solution for us, as it has several advantages over the current method: open source, official updates by Intel, no need for a "magic path", no copyright problems, can probably be converted to an avisynth plugin relatively easily.

Currently, it can only decode a CombinedMVC.264 file to 2 uncompressed YUV streams, and therefore it requires MUCH disc space (for example, it requires about 800 GB to convert Ice Age 3 to YUV!) But with some changes in the code, it should be possible to output the 2 streams to pipes, and implement an avisynth plugin working like the old ldecod. Or, with a bit more work, it can certainly be implemented as a totally independent avisynth plugin. I suppose that it can also be modified to accept the 2 AVC and MVC streams produced by eac3to without any need to combine them first.

However, it seems that it has a bug with Ice Age 3. I will confirm that when I'll finish to encode it. The bug produces artefacts in the left and right borders of the image, especially in scenes with fast moving objects or fast camera movements. But it must be noted that the ssifsource2 and DirectShowMVCSource methods have exactly the same bug! (And the ssifsource1/ldecod method doesn't work at all with that BD.) I guess Peter uses the Intel SDK for his CoreAVCDecoder.

Anyway, thanks to Frencher for his great finding. (He did also the batch files in the package, useful to understand how the various commands work.)

[Nico8583]

So package is not modified ? I believed Frencher had made some changes in the source code :)
I've tried to decode / encode with Intel MVC but there are 2 problems :
- MVC Decoder seems to be OK (but need much disc space)
- MVC Encoder only support a space color that not corresponding with Blu ray space color -> Colors not corresponding
- MVC Transcoder gives a bad quality (details, colors) with "quality" parameter
I'm waiting for your test result ;)

[r0lZ]

I don't think we should use it to encode. The MVC decoder only is really useful for us.

[Nico8583]

MVC Encoder/Transcoder should be used to create true BD 3D (and not SBS/TB) :)

[r0lZ]

Here is an example of the bug in CoreAVCDecoder (MVC stream only, of course) and probably also in the Intel SDK MVC decoder. (Still to be confirmed.)

http://img443.imageshack.us/img443/9253/bugbw.png (http://imageshack.us/photo/my-images/443/bugbw.png/)

Look at the right side of the picture. There is also a white rectangle at the left side, but usually, the artefacts are more important in the right side.
This BD has been decoded with DirectShowMVCSource, but I did also a test with ssifsource2 and a decoding from a CombinedM2TS file, just to be sure, and they have the same problem.
When decoded and encoded with DVDFab, there is no problem. (The image quality is terrible, but it's DVDFab!)

Please wait for the Intel SDK test. I need to use my computer for other things right now, and I'll launch the encoding tonight...

[Nico8583]

DVDFab is not the best software for video but is not the poorest, source code could be a good thing but it is not available...

[r0lZ]

I know. I hate DVDFab's h264 encoder, but the other things it does can be useful.
I installed and used it only to test if its MVC decoding engine has the same bug than CoreAVCDecoder (and also to test if a badly authored Ice Age 3 3DBD could be the culprit). Since DVDFab can correctly decode the MVC stream, I can only deduce that there is a bug in CoreAVCDecoder. However, there must be something strange or new in the Ice Age 3 BD, as all encodings of other 3DBDs I did were successful.

[r0lZ]

Oh, well, the decoding of Ice Age 3 with the Intel SDK is even worse:

http://img849.imageshack.us/img849/7060/bugsdk.png (http://imageshack.us/photo/my-images/849/bugsdk.png/)

However, I did another quick test with the NetBlender demo 3DBD (that has no problem with the CoreAVCDecoder), and it worked perfectly. So, that confirms that there is something strange (or a new variant of the MVC encoding?) in Ice Age 3, but apparently, the SDK decoder is as good as the CoreAVCDecoder for the vast majority of the 3DBDs currently available.

If you are interested in trying it, here is what you should do.
I had to download and install the RawSource Avisynth plugin (http://avisynth.org/warpenterprises/files/rawsource_25_dll_20060728.zip).

1. Combine the AVC and MVC streams to H264 with MVCCombine. (Do not mux to M2TS.)
2. Convert the Combined.h264 file to 2 YUV files with the sample_decode_x64.exe from the SDK. (You need much disc space!):
sample_decode_x64.exe mvc -i Combined.h264 -o TEST
3. Use this script (or similar) to encode in SBS:

LoadPlugin("rawsource.dll")
left =RawSource("TEST_0.yuv", 1920, 1080, "I420")
right=RawSource("TEST_1.yuv", 1920, 1080, "I420")
StackHorizontal(left, right)
BilinearResize(1920, 1080)


No problem at all with the NetBlender demo ISO, but as you can see above, that doesn't work well with the Ice Age 3 BD. (In addition, Ice Age 3 has the left and right view inverted, but that's not a problem.)

Anyway, that confirms that the Intel SDK could be a good solution for us. With some coding, it should be possible to convert it to an avisynth plugin that will work with most BDs, without the need to produce large intermediate files, and (probably) without seek problems. It should even be possible to encode directly from the BD without having to write any file on disc, with the help of pipes.
We can also hope that the "Ice Age 3 bug" will be fixed by Intel. If it's not the case, we have the source code, and we can try to find and fix the bug. (Unfortunately, I can't help on that point. I'm not a C++ coder, and I know nothing in decoder programming.)

I wonder what makes Ice Age 3 so difficult to decode. Someone has an idea?

[jj666]

I wonder what makes Ice Age 3 so difficult to decode. Someone has an idea?

I have the Ice Age 3 disk that was bundled with the Panasonic players - this is also not processable in Scenarist (I forget which error but a missing flag in the H264 stream or similar). Is this also the version you were trying r0lz? Or a store bought Ice Age 3, which I assume would be a different encode.

Cheers,

-jj-

[Thalyn]

Slavanap: Given your newest build a bit of a run, but I'll be damned if I can get the auto-detection to work properly. I'm not sure whether it's just not working right with branched movies but I've had all sorts of results from around 100 frames less than there should be to almost 200 more. Not to mention it takes a lot longer to suss it out than DirectShowSource (not the MVC variant) does - many minutes against a second at most, even with only a single source file. This has subsequently limited my testing also of branched sources.

On the plus side, it's working fabulously with single-file sources whether they're CombineMVC output or raw SSIF files; provided I copy them off the BluRay first. I tried going straight from the disc once... let's just say that I could have copied it to the harddrive and run the transcode three times over with a couple hours to spare in the time it would have taken to go direct from the disc just once.


I do like the sounds of that Intel decoder, though - and the encoder as well, if I'm honest. It would be nice not having to jump through hoops and having an MVC encoder would also mean being able to store my 3D movies in more backwards-compatible format. Frame Sequential might get the same or better compression but if you play it back through something that's not FS-aware than you're not going to have a good time, where MVC is transparent if it's unrecognised.

Definitely some promise there.

A thought on Ice Age, though: Monsters, Inc gave me some weird errors if I worked from the SSIF files (sync issues, missing frames, etc). However, if I worked from the M2TS files, even though they're theoretically the same stuff, it was fine. I had to use MakeMKV to find out what files made up the MVC encode since I don't know how to read playlists yet. Perhaps something you could look into for Ice Age 3?

[jdobbs]

@slavanap

I'm running the newer version on a job with a huge number of segments right now... it's working great, with an impressive speed improvement over the last release. Sweet. I'll let you know how it works out.I've now done four titles with this version, including one that froze on the previous release. All have completed successfully and I've seen no issues. I haven't tried the automatic framecounts at all, since I get that information easily from the MPLS. In fact, this release has worked so well that I'm considering using it (replacing DirectshowMVCSource) in the next BD Rebuilder release. I need to do more testing, though.

Thanks.

[Nico8583]

I would like to make a little survey on 3D users : have you compared a true BD3D and the same movie in half SBS or half TB format ? If yes, what is the size of your screen/projector and have you found any difference ? Thanks !

[jdobbs]

I have a 60" Samsung ES7150 3D display. I can definitely see the difference between half SBS and the original full HD 3D disc... but frankly you have to look for it, and if you weren't looking for it you probably wouldn't notice.

[PurpleMan]

I have a 60" Samsung ES7150 3D display. I can definitely see the difference between half SBS and the original full HD 3D disc... but frankly you have to look for it, and if you weren't looking for it you probably wouldn't notice.

I agree. I'm with a 65" Panasonic ST50 and you *really* have to look for it. Keep in mind that most people can't tell the difference between 720p and 1080p, and that even half the effective resolution of 1080p (such as what you get with SBS-3D) is still more pixels than a 720p equivalent.

1280x720 = 921,600 pixels of image data.
960x1080 (half SBS) = 1,036,800 pixels of image data.

[frencher]

"Ice age 3" is 3DBD of Panasonic, the Intel MVC decoder have same problem of Stere oscopic player and MVCtoAVI ;)

Ice age 3 demo original (http://ul.to/zdq2bgud)

Ice age 3 demo recoded with Intel MVC Decoder (http://ul.to/5bsx3g3r) (Start_sample_multi_transcode_x64.cmd)

[r0lZ]

I have the Ice Age 3 disk that was bundled with the Panasonic players - this is also not processable in Scenarist (I forget which error but a missing flag in the H264 stream or similar). Is this also the version you were trying r0lz? Or a store bought Ice Age 3, which I assume would be a different encode.

Cheers,

-jj-
I have the same version too. I would appreciate if you can try it with Scenarist again and post here the error message. If we know why it doesn't work well with the MVC decoders, perhaps we'll find a workaround. Thanks in advance.

[Rumbah]

I have a Philips 47'' tv and for me there isn't any difference between full hd 3d and half TB as it uses polarization and halves the vertical resolution anyway for 3d ;)

But I don't notice the resolution loss except for stills where you can see the stair steps.

[frencher]

I bring full attention to the use of the SDK Intel MVC and all programmers interested in working for avisynth dll

http://static.pcinpact.com/images/bd/news/mini-97270-intel-media-sdk-3-0.png

[jdobbs]

I've now done four titles with this version, including one that froze on the previous release. All have completed successfully and I've seen no issues. I haven't tried the automatic framecounts at all, since I get that information easily from the MPLS. In fact, this release has worked so well that I'm considering using it (replacing DirectshowMVCSource) in the next BD Rebuilder release. I need to do more testing, though.

Thanks.Unfortunately it appears that most of the multi-part output that I've done with ssifsource3() appears to be losing or adding frames and the left/right pictures are falling out of sync. Is anyone else experiencing this? It appears it may be happening at the points where the multiple segments are joined -- but I'm not sure yet.

[Thalyn]

That sounds fairly similar to my to my experiences when I managed to get it to work, Jdobbs. I suspected the issues I was encountering were along the joins, and I suspect it's something related to why the framerates were showing incorrectly with the auto-detect. Of course, the two could be entirely unrelated as well - I honestly don't know enough about decoding to even make an educated guess.

[jdobbs]

That sounds fairly similar to my to my experiences when I managed to get it to work, Jdobbs. I suspected the issues I was encountering were along the joins, and I suspect it's something related to why the framerates were showing incorrectly with the auto-detect. Of course, the two could be entirely unrelated as well - I honestly don't know enough about decoding to even make an educated guess. I'm not using autodetect, so I'm positive the framecounts are correct. I'm not sure why it is going out-of-sync.

I wonder if its possible that the cut points don't necessarily fall on a frame boundary (e.g. the main view of a frame may be in one SSIF and the dependent view in the following)? I noticed that sync was also an issue with DirectshowMVCSource() before I started combining the multiple SSIF files prior to encoding.

@slavanap

Is there a way to simply read the multiple files sequentially as if they were one unit as opposed to specifying a framecount for each file independently?