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

[slavanap]

Thalyn,
The cause might be that looking forward is forbidden. And the frame cannot be asked twice (here's your bug).
After such a huge frame-related operations, AviSynth clears its cache and asks for the frame again, that probably appears as your error.
You can avoid it by setmemorymax(256), or 512, for example. But big values here can make program run out of memory because its 32-bittness.

I'll fix twice frame acquire a bit later, thanks for the info.

[Thalyn]

Bumping up the memory allocation to 2048 (figured I'd be a little silly to start with then dial it back until it broke) didn't actually change anything - same issue with the first two frames, then every 30 frames starting from #29. I figured it had to be something to do with a cache flush or similar, but it just seems odd since I'm only actually reading each frame once and then tinkering with it in different buffers. Annoying that there isn't a way to accurately specify a resize kernel, or to split a stream into scanlines and discard every second frame in one step, since I'm sure that doubling the framerate and then halving it again isn't helping the situation.

I look forward to 4.44 (or whatever version it winds up being). I rather like the new results I've been getting (yet to test them on an active display, but they're nice on passive) and there's still at least two movies I can only get to process correctly using your source plugin.

[slavanap]

New version will be soon.

Btw, recently I'm looking for someone, who can speed up Intel sample_decode.exe decoder. AFAIK, someone has already done that successfully.

[Nico8583]

Please add a comment to this post : https://software.intel.com/fr-fr/forums/topic/516009
Perhaps Intel will help us if there are many users...

[slavanap]

New version of ssiSource4 - 4.44: http://sendfile.su/988099
Minor fixes:
* twice current frame acquiring
* crash when launched from 2 different users accounts fix
* swap_view autodetection fix for mplsSource, mplsSource parameters renaming

P.S. I haven't fully tested this version (as always), so please keep this in mind.

[Thalyn]

Sadly that's a negative on my issue. Same errors in exactly the same places. In case it in any way helps, the exact source I'm using is as follows:

SAVC = Source base stream
SMVC = Source dependant stream
FC = Frame count (manually predetermined)
Swap = False (manually predetermined)
TC, BC, LC and RC = Cropping amounts (manually predetermined)

Source = ssifSource (avc264 = SAVC, mvc264 = SMVC, frame_count = FC, use_ldecod = true, swap_views = Swap)
Left = Source.Crop (LC, TC, -RC, -BC - 1080)
Right = Source.Crop (LC, 1080 + TC, -RC, -BC)
Left = SelectEven (SeparateRows (Blur (Left, 0, 1), 2))
Right = SelectOdd (SeparateRows (Blur (Right, 0, 1), 2))
HOU = StackVertical (Left, Right)
return HOU.Trim (0, FC - 1)
The original script is quite a bit longer, but I've boiled it down to that in order to remove the chances of anything else interfering and the issue still occurs. I'd substitute the values in directly for the variables but that just seems redundant at this point. The error is always on frame #0 and #1, then every 30 frames starting from #29; unless I start playing back and then pause it to skip frame by frame, which changes the offset of the issue but not the period (still every 30 frames just not necessarily starting from #29 anymore).

[r0lZ]

Have you tried to do the Crop after the SelectEven/Odd?

Something like this:

Left = SelectEven (Source)
Right = SelectOdd (Source)
Left = Left.Crop (LC, TC, -RC, -BC - 1080)
Right = Right.Crop (LC, 1080 + TC, -RC, -BC)
Left = SeparateRows (Blur (Left, 0, 1), 2))
Right = SeparateRows (Blur (Right, 0, 1), 2))

[Thalyn]

Interesting...

I can't actually use that exact script because Slavanap's plugin provides the frames as either TAB or SBS, not sequential like FRIM or DGMVC (though when I use those, your script is pretty much exactly how I do it). If I apply the Select before I Separate them than I'm going to wind up with the left and right "eyes" one frame out of sync, as well as displaying the same frame twice (once for each set of scanlines).

That having been said, taking that idea and running with produced something that worked:

Source = SeparateRows (Blur (Source, 0, 1), 2)
Left = SelectEven (Source)
Right = SelectOdd (Source)
Left = Left.Crop (LC, TC / 2, -RC, -BC / 2 - 540)
Right = Right.Crop (LC, 540 + TC / 2, -RC, -BC / 2)

While this is theoretically the same (just working with only the Source buffer instead of both Left and Right), this actually works perfectly and gives pixel-identical results to the other method (sans the error) - so long I'm applying at least 1px of vertical cropping. If there isn't any cropping than there will be a half-pixel of bleed at the bottom of the left into the top of the right. If I Crop before I Blur to deal with this bleed than I wind up right back where I started, so this unfortunately isn't a panacea.

I'm gonna try breaking it down to individual commands again to see if it makes any difference. Maybe AVISynth is buggering up the order and messing things around. I'll edit this post if it makes a difference (no edit = no difference).

*ed: I got this far before the error came back:

Left = Source.Crop (LC, TC, -RC, -BC - 1080)
Right = Source.Crop (LC, 1080 + TC, -RC, -BC)
Left = Blur (Left, 0, 1)
Right = Blur (Right, 0, 1)

I started with just the two Crop commands and it worked fine. The instant I put those Blurs in? Bam - error like explained previously. In fact, it's the act of blurring the upper frame that's causing the problem! By "upper" I mean whichever frame comes first in the final StackVertical command, so it isn't specifically the Left or Right (AVC and MVC respectively). If I only apply the Blur to lower frame (whichever it is) than there's no issue, and only if I'm stacking both of the streams (stacking the same stream twice works fine). Even if I extend the script out to include the SeparateRows and then Select it still works just fine so long as I'm not applying the Blur to the upper stream.

Now I'm even more confused!

[r0lZ]

You apply the blur only along the Y axis, right? And you want to crop the two images to handle them separately, right again? Then you can probably use the SBS mode of Slavanap's decoder, apply the blur on the whole combined views (and it should not affect the borders of the adjacent view), and crop the two views later. You'll end up with the Left and Right clips anyway, and you can stack them vertically, to obtain a final T&B 3D movie if you wish.

Anyway, imo, to avoid the bug, you should read the frames only once, so that the decoder doesn't receive multiple requests for the same frame.

[Thalyn]

I.... hadn't even considered that. Horizontal input lets me avoid the bleed while using the other command order that works. Solves all the problems in one fell swoop, and a quick test has it working absolutely perfectly.

I didn't actually think I was requesting the same frame more than once anyway. I wanted Source to get the frame, and then worked exclusively from Source - which should mean only one request, despite what I'm doing to it, right? I guess AVISynth thinks otherwise.

Can I curl up into a ball and cry yet? I like things to make sense, and frankly this doesn't. At least it works now...

I've finally got something that works and should neatly fit in with my existing script to handle things like subtitles:

Source = ssifSource (avc264 = SAVC, mvc264 = SMVC, frame_count = FC, use_ldecod = true, swap_views = Swap, horizontal_stack = true)
Source = Blur (Source, 0, 1)
Left = Crop (Source, LC, TC, -RC - 1920, -BC)
Right = Crop (Source, 1920 + LC, TC, -RC, -BC)
Left = SelectEven (SeparateRows (Left, 2))
Right = SelectOdd (SeparateRows (Right, 2))
HOU = StackVertical (Left, Right)
return HOU.Trim (0, FR - 1)
Evidently blurring it before cropping it is the answer, for whatever reason. I don't pretend to understand why since I crop with other plugins first, but since my brain now hurts I'm no longer sure that it matters. It does mean any subtitles I add won't get affected by the blur, but 'eh....

[r0lZ]

I must admit that I don't understand the problem either. It is very strange, especially that pattern repeated every 30 frames.

When you will have made some more tests, please report if your method with the blur gives better results than the standard method. Thanks in advance.

[Thalyn]

Well, I've made a bunch of runs so far - 24 titles in all. As I mentioned with my earlier testing on the subject (http://forum.doom9.org/showthread.php?p=1680155#post1680155) it really is very hard to tell, though I do prefer my new approach.

What I can say with absolute certainty is that if you take a 2D stream and split it with the blur, then recombine it as it would appear on an interleaved screen, the results are noticeably better than doing the same with BilinearResize or VerticalReduceBy2. Of course, in that same situation if you don't blur than the results are better still because you're effectively converting from 1080p24 to 1080i48 and back to 1080p24 again.

When you go over to 3D, however, the situation changes. If you don't blur in that situation than it introduces some pretty obvious aliasing. It's still quite watchable and, strictly speaking, does have the "truest" detail retention of them all, but it's just not as good as it could be in playback. Plus if, for whatever reason, you have to watch it back in 2D than it becomes a pretty terrible deinterlaced version of source material that wasn't interlaced to begin with. Comparing the Blur to the Resize, however, isn't so clear-cut in the differences.

Chiefly I need a second set of eyes on it so I can rule out personal bias. I've uploaded 119 seconds (01:49:58.59-01:51:57.59 - I actually asked for 2 minutes from 01:50:00, but 'eh) of The Avengers with both methods if you want to take a look - it's got some high contrast bits, some fast action bits, some slow bits, some small bits, some fine detail, some straight lines, some Scarlett Johansson... hopefully enough to make a decent evaluation. The only difference between the two is the method used to resize the frames for half over/under storage and how x264 subsequently reacted to that change.

BilinearResize (X, Y / 2) (https://mega.co.nz/#!5l1inJAB!Ktg1oLnBitSevB4X9dtte07HUp5Do92mCWtzQ3Q8zWs) (113.2MB)
Select (SeparateRows (Blur (0, 1), 2)) (https://mega.co.nz/#!ho1giYqZ!D_HliCgftIuHKqAc539ZyGDUMZ7F_uOo8F2YTcy4cGE) (117.6MB)

Fair warning: These clips open with an immediate burst of static-like noise from the lead-up, so you might want to dial back the volume before playing them for the sake of your ears and equipment. It's not that loud (there's louder in the clip) but it could be an unwelcome surprise.

[r0lZ]

Thanks. And is it a noticeable speed difference when encoding with the standard and your methods?

[Thalyn]

Depends on the stream. That one, for example, was 19.84fps vs 18.93fps in favour of a traditional bilinear resize. The Adventures of Tintin, on the other hand, was 23.41fps vs 23.74fps in favour of the blur. Generally, however, it is the slower option by a small margin.

Overall video bitrate for The Avengers was 3898kbps vs 4056kbps with the bilinear being smaller, and that seems to be a common trend for the 24 I've done so far. Blurring has never been a huge amount larger, but it is always larger (usually within 100-200MB on files between 3GB and 4GB).

[r0lZ]

Interesting. I don't have a TV compatible with your method, so I can't test it myself, but I appreciate your finding. Unfortunately, it seems too complicated to add your method as an option in BD3D2MK3D, because it is totally different than the methods currently implemented, and I don't know how many peoples would be interested. Anyway, obviously, you don't need an automated tool to do it yourself!

[Thalyn]

Strange. That should be a stock-standard half over/under video. It's not cropped in any way since the original didn't have any letterboxing to speak of. Though it's possible the AVC settings I've used just aren't compatible (4 keyframes, 6 B-frames, CABAC, etc etc). It should play through pretty much any software player, though, if you've got facilities to connect a PC to your screen.

Otherwise, if you can provide me with some x264 settings that work with your setup I can run some streams through for you to evaluate.

[r0lZ]

Oh, sorry. I can see your files on my PC without problem, but if I understand correctly your idea, your method should give better results on a 1080p 3D passive screen with row-based separation. When it's not the case, the standard method (based on the resize) should give better results anyway, no?

[Thalyn]

Ahh. Yeah, theoretically (at least, according to the rumblings in my head) it should yield better results on am passive screen almost every time. The rest of the time it shouldn't look any worse, at least, which is why I'm re-doing all of my stuff without any real concern.

The only real testing field I have is my PC, which is attached to an AOC D2757Ph. I know a guy with a 120Hz PC setup but I haven't had a chance to see him in a while.

[Thalyn]

Uuuuurgh! Brain!

Even with only applying the Blur once using Slavanap's plugin, it's not right. The AVC and MVC stream are briefly getting out of sync, but there doesn't appear to be any rhyme or reason to it unlike blurring each stream separately. What's even worse is that they appear to be getting out of sync with themselves, too - I'm looking at a frame right now where the AVC and MVC stream have gotten one frame out of sync, but the MVC stream is also "tearing" between two frames (changing frames mid-refresh) towards the top. A slightly later frame is even worse as it appears that the new input to the MVC stream has actually changed frame part way through a scanline!

The only commonality between each incidence is that the MVC frame seems to be the one struggling the most, which would also be the lower frame. There is no common period between the errors, at least as far as frame count is concerned, nor is there solid commonality as to the duration of the issue (I'm seeing anything from 1 to about 4 frames) or even the location of the tearing when it's visible. After the issue it resumes as if nothing has ever happened, but I've seen gaps as small as 3 frames separating problems out to about 27.

The AVC/upper frame looks to be behaving perfectly with no skipped or torn frames, at least.

I don't pretend to understand why, but ssifSource (currently) just isn't compatible with the Blur command, pretty much regardless of when you use it.

*Ed Just for emphasis, I'm not saying there's specifically a problem with ssifSource. I've used it before with great success. It's only when used in tandem with the Blur command that there's a problem, so I'm likely to be the only person it affects in any way, shape or form.

*Ed2: A thought occurs. How difficult would it be to either A: including a frame-sequential option for ssifSource's output, or B: configure it so that, instead of returning a single stream (eg: Source = ssifSource (whatever)), it can return two streams (ssifSource (Left, Right, whatever))? It may not help so if it's difficult or tedious than it's not worth it, but you never know for sure...

[r0lZ]

Damn, it's really strange!
Have you tried with GDMVCSource and FRIMSource? It may be interesting to know if the same problem occurs also. Or is it a reason to use only or preferably ssifSource?

[Thalyn]

Both DGMVC and FRIM work just fine and dandy with my script, which is why I'm wondering about the possibility of sequential feedback from ssifSource. I wouldn't have even bothered pursuing it at all if I'd never gotten it to work, after all. The basic script (paraphrased) I use for those is as follows:

Source = plugin (gubbins)
Crop (Source, left, top, right, bottom)
Left = SelectEven (Source)
Right = SelectOdd (Source)
Left = SelectEven (SeparateRows (Blur (Left, 0, 1), 2))
Right = SelectOdd (SeparateRows (Blur (Right, 0, 1), 2))
Return StackVertical (Left, Right)

And, yes, you're seeing correctly - I'm splitting the frames via Select twice in there. Crop first since it's sequential, then I split them to break the sequential into individual AVC/MVC streams. Following that, they're blurred, broken up into scanlines and then half of those are discarded. Subtitles go in between the first Select and the second one so they get blurred as well, plus I can apply an offset to each stream separately.

*ed: The example I posted earlier from The Avengers was made using DGMVCSource, both for BilinearResizing and Blurring. Unless I've lost what's left of my mind, those both work equally well as each other.... don't they?

Problem is, I own two movies that don't work with either of those plugins. Pacific Rim, as expected, and Escape from Planet Earth (which I have still never gotten to work with DGMVC or FRIM). They do, however, work perfectly with ssifSource 4 - Escape regardless of which decoder I use, and Pacific Rim so long as I use the JM decoder. Other than those two I use predominately DGMVC simply in the interest of speed (hardware decoding is hard to beat).

[r0lZ]

OK, it's only for the possibility to decode Pacific Rim and Escape without the infamous Intel bug that you need ssifSource. I wondered if it was for another reason, related to your method.

BTW, thanks to remind me that Escape from Planet Earth is also a "problematic 3DBD". We tend to forget it and to consider that the Intel decoder bug affects only a single movie, and therefore that it is not really important.

[Thalyn]

The effect on Escape is a bit hit and miss. I've been able to reproduce it each and every single time using the two other Intel decoders, but Neuron2 (DGMVC) hasn't ever had it happen. I'm not sure whether Videofan3d (FRIM) has managed to reproduce it either, but they always seemed more focussed on the encoding side of things rather than the decoding so I'm really not sure.

Even more interestingly, it works fine in ssifSource 4 through its Intel path. But I believe it uses 1.6 at all times, where the other 2 will use 1.8 in software mode and 1.7 in hardware.

[r0lZ]

So, you are not sure that it's the Intel bug that affects Escape? As far as I know, all versions of the Intel library have the same bug, at least with Pacific Rim. Unfortunately, I don't have the Escape BD to test it myself.

[slavanap]

Thalyn,
Looks like functions SeparateColumns / SeparateRows were added in AviSynth 2.60. Which version of AviSynth do you use? AviSynth 2.60 Alpha #?
http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/

P.S. As for me, I use 2.58 (2.5.8.5).

ADD: My bad. Sorry. Twice frame acquiring fix wasn't done properly. Trying to fix it right now. (Tested with 2.6.0.4)

ADD2: Here's the fix (http://forum.doom9.org/showthread.php?p=1683660#post1683660).
Just replace the dll.

PPS. for some reason I've noticed decoding problems with ldecod at secondary ssif file (00005.ssif) in Avatar disc. Be careful using it. The problem I've noticed is that only half of frame changes when next frame is decoded (only in the beginning of the sequence (first 30 frames), not related to SeparateRows). Looks like this (http://postimg.org/image/80clpyrq3/), appears randomly and only in first 2 seconds (tested 10 times), only for ldecod. The bottom part of mvc view is the part of next frame.

[Thalyn]

So, you are not sure that it's the Intel bug that affects Escape? As far as I know, all versions of the Intel library have the same bug, at least with Pacific Rim. Unfortunately, I don't have the Escape BD to test it myself.

I can't say it with absolute certainty, no. I know I can reproduce it every time with ease, regardless of whether I use FRIM or DGMVC, or what version (until I go far enough back that they stall at the frame which otherwise causes errors), but if memory serves correctly Neuron2 wasn't ever able to reproduce it. I'd put it down to my Haswell except it persists with those plugins using software, but that doesn't discount the possibility that it's Win8 causing it (or at least contributing).

Thalyn,
Looks like functions SeparateColumns / SeparateRows were added in AviSynth 2.60. Which version of AviSynth do you use? AviSynth 2.60 Alpha #?
http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/

P.S. As for me, I use 2.58 (2.5.8.5).
I'm using 2.60 Alpha 4, but you can get the same result in 2.5.8 release using SeparateFields instead. The only difference there is the requirement to specify AssumeTFF before using SeparateFields, and obviously dropping off the ", 2" parameter. My first instinct was to make sure it worked with the release version in case something stupid was going on with the Alpha.

Testing out the fix now. Will edit this briefly with results.

*Ed: I have good news, bad news and, as always, confusing news.

The good news is that I'm no longer getting the green frames at all. I've tried blurring both before and after splitting, as well as both horizontal and vertical stacking.

The bad news, though, is that I'm observing exactly the same thing you were on Avatar (which is the same basic issue I mentioned earlier when blurring before splitting); only with ldecod as you mention (IM works fine). I've tried stripping out the blur since that caused problems before but it seems that doesn't do anything this time around. Unlike Avatar, though, I'm noticing it sporadically as far in as the 2-minute mark. In case it's relevant, I'm working from raw h.264 streams and not the ssif file.

The confusing part, though, is that while Escape only shows it on the MVC stream, Pacific Rim shows it on both streams. And when I say "both" I don't mean just that the MVC frame is just being distorted as a result of the AVC stream decoding incorrectly, but rather that it's adding additional distortion of its own on top of that. Unfortunately, while I can use the IM path for Escape I can't use it for Pacific Rim.

If it were a videogame I'd suggest enabling V-sync, but I have no idea if ldecod includes that kind of facility - or why it wouldn't have it on by default when it's serving up a stream frame-by-frame. The plot thickens...

[slavanap]

Thalyn,
My bad again (forgot about thread synchronization objects' initial status; need to stop programming at night..).
ldecod works perfect, it wasn't the cause of that artifact.
http://sendfile.su/990052

@all,
Is there any sample, ldecod can't handle? I've heard "Coraline" may have one. Can anyone confirm?

[Nico8583]

So if I understand, ldecod can decode properly Pacific Rim ? It uses also Intel Media SDK or is it a standalone filter ?

[Thalyn]

Thalyn,
My bad again (forgot about thread synchronization objects' initial status; need to stop programming at night..).
ldecod works perfect, it wasn't the cause of that artifact.
http://sendfile.su/990052

@all,
Is there any sample, ldecod can't handle? I've heard "Coraline" may have one. Can anyone confirm?

Had an unexpectedly long day today so I'm only just getting a chance to test it out now. Initial results are promising - very promising. I'll have to do some full runs to be sure but I think you've got a keeper here.

:thanks:

I'll be honest in that I'm not sure if there's anything that ldecod can't do, mostly because it's my "backup" transcoder for when IM fails as hardware IM used to be a lot faster. However, I can start running some tests if you'd like (I've still got another ~36 movies to go in 3D) - both for compatibility testing and to see how the speeds stack up these days.

So if I understand, ldecod can decode properly Pacific Rim ? It uses also Intel Media SDK or is it a standalone filter ?

Last time I tried it (which is before I started messing around with my new frame packing technique), Pacific Rim worked perfectly with ldecod via ssifSource4 - not even a hint of the issue IM decoders experience. I'll be able to let you know tomorrow for certain whether that's still the case.

My understanding is that ldecod is a different filter. I believe it's based on the JM Software SDK (currently v18.6) but Slavanap will know more about it than I do.

[r0lZ]

Yes, ldecod is the first decoder that has been freely available, long before the Intel SDK has been released. It is terribly slow, but afaik, it has always worked perfectly. I don't know if someone has tested it with Pacific Rim though.

[Sharc]

If I remember correctly, videofan did some tests with Idecod and PacificRim. I tried to find the post ......

Edit:
Here it is. (http://forum.doom9.org/showpost.php?p=1666387&postcount=79)

[Sharc]

There seems to be a new release of Intel SDK (https://software.intel.com/en-us/forums/topic/516395)

[r0lZ]

If I remember correctly, videofan did some tests with Idecod and PacificRim. I tried to find the post ......

Edit:
Here it is. (http://forum.doom9.org/showpost.php?p=1666387&postcount=79)
Damn, obviously, ldecod is not a solution for Pacific Rim!
Thanks for the link.

[r0lZ]

There seems to be a new release of Intel SDK (https://software.intel.com/en-us/forums/topic/516395)
Yes, it is already included in the latest version of BD3D2MK3D:
# v0.37 (June 3, 2014)
[...]
# - Updated the Intel MVC decoder library to the latest version (libmfxsw32.dll v5.14.4.28)
Unfortunately, the latest Intel decoder doesn't fix the Pacific Rim bug.

[Thalyn]

If I remember correctly, videofan did some tests with Idecod and PacificRim. I tried to find the post ......

Edit:
Here it is. (http://forum.doom9.org/showpost.php?p=1666387&postcount=79)

As much as I trust that Videofan3d was indeed able to get the error mentioned in that post, I can't verify it myself. Not only do I not get the error about allocation, but the frames mentioned rendered perfectly. I just double-checked the transcode I did last time with ssifSource 4.4 via the ldecod pathway and saw nothing out of the ordinary.

It's possible that was with an earlier version of ldecod, of course. Whatever version Slavanap put in his 4.4 release (I believe that was still 18.6 but they can correct me if I'm wrong) worked just fine for me, though, and I'll know by tomorrow when I get up if 4.44c works or not.

Interesting to note about the newer SDK, though. I wonder what that might do in tandem with the newer HD/Iris drivers (v15.33.22.3621, released May 21st) for hardware decoding..?

[r0lZ]

AFAIK, there is nothing new in the MVC decoder part.

Extract from the release notes:

Intel ® Media SDK 2014 R2 introduces API version 1.9. This version is backwards
compatible with the previous API version 1.8.

API version 1.9 introduces the following major features:

Four new fourCC codes for color format were added:
MFX_FOURCC_P010 and MFX_FOURCC_A2RGB10 to support HEVC MAIN10
profile decoding and VPP resize and color conversion in 10-bit format.
MFX_FOURCC_A2RGB10 is specifically required for rendering on a 10 bit-
display. Microsoft* DirectX* equivalent of MFX_FOURCC_P010 format is
currently not supported in Intel display drivers.
MFX_FOURCC_ARGB16 and MFX_FOURCC_R16 to support Intel® Media
SDK Professional Camera Pack product. Please refer to Intel Media
Solutions Portal for more details about this product.

mfxFrameInfo structure was extended with controls for bit depth and shift
which defines values alignment.
VPP composition alpha blending support.
At the moment of this release this feature is supported only by Intel ® Media
SDK for Linux* Servers product.
AVC skip frame control which forces skipped frame encoding.
At the moment of this release this feature is supported only by hardware
implementations of Intel Media SDK Library coming with Intel ® Iris TM and HD
Graphics Driver for Microsoft Windows* 7/8/8.1 on platforms listed below in
System Requirements section.
AVC slice size limitation control.
At the moment of this release this feature is not supported by any
implementation of Intel Media SDK Library.
New mfxExtAVCRefLists extended buffer which allows application to manage
reference lists.
New plugin GUIDs definitions were added to mfxplugin.h:
MFX_PLUGINID_VP8D_HW and MFX_PLUGINID_HEVCD_HW: for hardware
accelerated HEVC and VP8* decoder plugins which will be distributed
as default plugins with graphics driver along with hardware
implementation of Intel ® Media SDK library. These components are not
available in existing platforms and will be added in future.
MFX_PLUGINID_CAMERA_HW: for Intel ® Media SDK Professional Camera
Pack.

Additionally, dispatcher source code was updated with capabilities of default plugin
loading, fixes for handling plugin version vs. library version during plugin loading and
for compilation under MinGW* environment.

Please note that all the new APIs listed above are not supported by software
implementation of Intel Media SDK Library, with exceptions for VPP resize in P010
format and VPP color conversions P010->A2RGB10 and P010->NV12.

In a particular platform specific hardware implementation of Intel Media SDK Library
some of the features may also be unsupported. Make sure to call Query functions to
check the actual support.

I don't know if there is a more detailed release notes file somewhere, but it is not included in the pack.

[Guest]

Thanks for that. Nothing in there to justify doing anything with my source filters. :(

[r0lZ]

I agree. I have just updated the Intel DLL, and your Source filter works as expected, without any visible modification.

[Thalyn]

It's possible that was with an earlier version of ldecod, of course. Whatever version Slavanap put in his 4.4 release (I believe that was still 18.6 but they can correct me if I'm wrong) worked just fine for me, though, and I'll know by tomorrow when I get up if 4.44c works or not.
Just following up on this: ssifSource 4.44c (the 3rd hotfix - not sure what Slavanap calls it internally) using the ldecod path worked just fine. No errors in the first 200 frames, no sign of either of the two well-documented IM errors and sound sync persists until at least the last possible point to check it.

Speed is fairly pedestrian compared to IM, but may prove to be a necessary evil on occasion. PR, for example, processed at 11.47fps overall, while Escape managed a slightly better 12.93fps. None of my IM-sourced transcodes have gone even close to that slow so far - high teens is about the lowest I see from it, and it's normally closer to realtime.

However, I cannot pin that speed down entirely on the use of ldecod. Since I'm not using a pre-combined stream it's possible the act of piping it has an adverse effect on speed, plus the dependence on the external MVCCombine executable of unknown optimisation.

Sadly, however, I can only confirm the speculations with regards to the new IM dlls. Minor fixes like what we need are rarely documented properly but I've been unable to tell any difference between the results of the older and newer dlls, whether using hardware or software.

[slavanap]

If I remember correctly, videofan did some tests with Idecod and PacificRim. I tried to find the post ......

Edit:
Here it is. (http://forum.doom9.org/showpost.php?p=1666387&postcount=79)

Just tested (http://sendfile.su/990659) this source with ssifSource4 Intel & ldecode,
Intel returned 211 frames, ldecode -- 234 frames. Where's the decoding errors?

Had an unexpectedly long day today so I'm only just getting a chance to test it out now. Initial results are promising - very promising. I'll have to do some full runs to be sure but I think you've got a keeper here.
Thank you for kind words! :)

I believe it's based on the JM Software SDK (currently v18.6) but Slavanap will know more about it than I do.
I've just compiled the source from here (http://iphome.hhi.de/suehring/tml/download/) with minor changes (about 10 lines of code) to speed up a decoding a bit (that's all I can without understanding the whole source code) and one bugfix because of what ldecod might crash with 'access violation' error.

It's possible that was with an earlier version of ldecod, of course. Whatever version Slavanap put in his 4.4 release (I believe that was still 18.6 but they can correct me if I'm wrong) worked just fine for me, though, and I'll know by tomorrow when I get up if 4.44c works or not.
Nope, there's the latest JM18.6 version in the package.

Just following up on this: ssifSource 4.44c (the 3rd hotfix - not sure what Slavanap calls it internally) using the ldecod path worked just fine. No errors in the first 200 frames, no sign of either of the two well-documented IM errors and sound sync persists until at least the last possible point to check it.

Speed is fairly pedestrian compared to IM, but may prove to be a necessary evil on occasion. PR, for example, processed at 11.47fps overall, while Escape managed a slightly better 12.93fps. None of my IM-sourced transcodes have gone even close to that slow so far - high teens is about the lowest I see from it, and it's normally closer to realtime.

However, I cannot pin that speed down entirely on the use of ldecod. Since I'm not using a pre-combined stream it's possible the act of piping it has an adverse effect on speed, plus the dependence on the external MVCCombine executable of unknown optimisation.

Intel decoder is slow in the ssifSource4...(whatever) package because it is just a compiled binary from Intel Media SDK samples. It HAS NOT been optimized in any sense (looks like some student wrote it). Both decoders Intel & ldecod MAY be optimized a far more, but I haven't enough free time to read and understand their code entirely. Pipes mechanism is fast enough to support realtime playback, but the decoders code mostly use only single CPU core (and, of course, it doesn't use the GPU). That's why they are a bottleneck here.

[r0lZ]

How did you the Intel test? With ssifsource4 w/o hardware acceleration? The result seems bug-free.
For the number of frames, I don't know. Have you tried to examine the input clip with MediaInfo?

[slavanap]

Just fixed ldecod to handle sequence from Ice Age 4 properly (Intel handled it well already, but ldecod failed with "max_dec_frame_buffering larger than MaxDpbSize" error message).
http://sendfile.su/990671.
Of course it's experimental. Any videos (with same level_idc = 41) may fail now.

(let it be another ssifSource4 patch 4.44d)

[slavanap]

How did you the Intel test? With ssifsource4 w/o hardware acceleration? The result seems bug-free.
For the number of frames, I don't know. Have you tried to examine the input clip with MediaInfo?

Yes, with ssifSource4, Intel decoder without hardware acceleration and with "-d3d" option. Unfortunately, I have a version of MediaInfo without top menu, and it doesn't show the framecount. AVC source is about 9 sec. long - that's all I know.

[r0lZ]

If you demux it with tsMuxeR, it will tell you the exact number of frames.

[r0lZ]

# v0.38 (June 18, 2014)
# - Added Tools -> Verify 3D-planes compatibility to show info about the undefined Depth values in the 3D-planes for a particular subtitle stream.
# - Fix: Tools -> Convert Subtitles to 3D (with 3D-Plane) bug when verifying the output file extension.
# - Fix: Added vcomp100.dll (from the ImageMagick package), needed on some systems to convert the subtitles to 3D.
# - Added Tools -> MkvMerge GUI to open MMG.exe easily from BD3D2MK3D.
# - Updated MkvMerge to the latest version (and added MMG.exe in the toolset folder)

Mainly a bug fix release, but there is also a new function that you can use if you need to convert a subtitle to 3D and you don't know what 3D-plane to use. The new function checks if all 3D-plane files from a specific directory have valid depth values for all frames during which the subtitles of the specified subtitle file are displayed. For best results, you should select the 3D-plane with the lowest number of undefined depth values. (Of course, if the subtitle file comes from the BD itself, you should select the 3D-plane associated with it, except if that 3D-plane has been obviously badly authored.)

Download: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

[Privateer5000]

@r0lZ

wrong Download-Link

BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

[r0lZ]

Damn, it's not the first time! :-(
Link fixed. Thanks!

[slavanap]

If I remember correctly, videofan did some tests with Idecod and PacificRim. I tried to find the post ......

Edit:
Here it is. (http://forum.doom9.org/showpost.php?p=1666387&postcount=79)

Well tsMuxer reports about 238 frames. ldecod: 234, Intel: 211.
Decoding results are here (http://sendfile.su/990659). I haven't noticed any artifacts reported in this (http://forum.doom9.org/showthread.php?p=1666387#post1666387) post.

Looks like ldecod can decode anything for me right now.
Does anyone have difficult video sources to prove that?

[r0lZ]

# v0.39 (June 22, 2014)
# - New option to hardcode the PGS (BD SUP) subtitles to the video with SupTitle.
# - Fix: Bug when converting subtitles with an original width of 1920 pixels to 3D.
# - Added a warning when BDSup2Sub++ is selected in the Settings menu.
# - Several little bugs fixed.

I have noticed problems with strange subtitles from bad BDs such as "Amphibious 3D". The width of the subtitle is always 1920, and therefore it cannot be moved along the X axis to convert it to 3D. I have added a workaround: the transparent background of the subtitle is now cropped when necessary. But I'm still wondering how the BD players are supposed to display that subtitles in 3D. Is it allowed to use negative X values? Anyway, v0.39 can now handle them correctly.

But when I have analysed that subtitle problem, I have noticed that BDSup2Sub++ has a very big bug. When it imports a XML/PNG subtitle file with a fully transparent border around the subtitle, it crops the useless part of the background, and it is supposed to modify the position in X and Y of the subtitle accordingly. BDSup2Sub.jar does that correctly, but BDSup2Sup++ fails miserably, and creates crazy, extremely high X and Y values. Therefore, I highly recommend to use only the java version of BDSup2Sub! Since the ++ version was the default in the old versions of DB3D2MK3D, the users of the old versions should change that setting in the Settings menu. (Now, the java version is the default except when the program detects that java is not installed, and a warning is displayed when the user changes it to use the ++ version.) You have to install Java 32-bit on your machine also. Sorry for that.

I have also improved the way the subtitles are hardcoded on the video. Now, it is possible to hardcode the high quality PGS (.SUP) stream with the SupTitle avisynth plugin (http://forum.doom9.org/showthread.php?t=148167), rather than the VobSub (IDX/SUB) file with DirectVobSub. Thanks to Zachs for his permission to distribute his SupTitle plugin with BD3D3MK3D!

As usual, you can download the latest version of BD3D2MK3D here: BD3D2MK3D.7z (http://download.videohelp.com/r0lZ/BD3D2AVS/BD3D2MK3D.7z)

I repeat:
Please use only the java version of BDSup2Sub!
(Change the BDSup2Sub setting in the Settings menu and install java 32-bit if necessary.)

[Sharc]

Did anyone try THOR - The Dark Kingdom 3D?
This seems to be another case - like PacificRim - where Intel Decoder fails badly, e.g. the scene between 00:28:00:000 .... 00:29:00:000.
I will do more test when I find some time.