DGMVCSource

[Sharc]

We are greatful to videofan3d and neuron2 for having given to us 2 excellent plug-in decoders! We now even have the choice and may select the most suitable solution, depending on the application scenario and HW infrastructure.
:thanks: :thanks: :thanks:

[Nico8583]

So I have made new tests with same script and same cmdline than Sharc. Here are results :
- DGMVCSource SW : average 17,58 fps
- DGMVCSource HW : average 22,71 fps
- FRIMSource SW : average 16,90 fps
- FRIMSource HW : average 19,85 fps

So yes with x264 encoding DGMVCSource is faster than FRIMSource :)

[Sharc]

In a transcoding scenario the required overall time seems to be dominated by the SW encoding which tends to mask the benefit of fast HW decoding, I guess.
No reason for me to buy a new PC :D

[Guest]

In a transcoding scenario the required overall time seems to be dominated by the SW encoding which tends to mask the benefit of fast HW decoding, I guess. Yes, I think you are correct about that.

[Nico8583]

So no reason to go to Intel for me too :D

[Sharc]

Although it's off topic I like to add that the fastest method is FRIMDecode via stdout to x264. So for my previous half-SBS example (http://forum.doom9.org/showpost.php?p=1665166&postcount=393) the total time becomes:
FRIMDecode(SW) > stdout > x264 = 175 sec.

[jdobbs]

Although it's off topic I like to add that the fastest method is FRIMDecode via stdout to x264. So for my previous half-SBS example (http://forum.doom9.org/showpost.php?p=1665166&postcount=393) the total time becomes:
FRIMDecode(SW) > stdout > x264 = 175 sec.Yeah... but you also lose the functionality of AVISYNTH -- which is pretty important.

[Sharc]

Yeah... but you also lose the functionality of AVISYNTH -- which is pretty important.
Sure -- fully agree -- but same is true when piping FRIMDecode to FRIMEncode.

[Thalyn]

I know I said I'd take a step back from this thread, but I've run across an issue a few times now - enough that I'm fairly sure it's not specifically my fault, though it appears to be caused by my workflow.

Basically, attempting to use DGMVSCSource (Hardware mode - I'll admit I haven't tried software) with Jack the Giant Slayer, Man of Steel, Pacific Rim and The Smurfs 2 is giving pretty messed up results. Both the AVC and MVC frame go crazy before it finally appears to time out and go blank. The good news is this behaviour seems very consistent - Jack, for example, would pack in the towel around frame 850 each and every time, and would even crash entirely when attempting to preview it with VirtualDub.

Now, the reason I suspect it's due to my workflow is because I don't quite follow exactly what seems to be the more popular option of using EAC3To to extract it from a disc decrypted with AnyDVD HD. Instead, I'm using MakeMKV to extract from the disc, then tsMuxeR to extract from the resulting MKV as EAC3To cannot correctly identify a multi-view MKV file and only extracts the AVC stream. These are then run through my standard script and the problem follows, either kicking back an error in MeGUI or stalling briefly before taking off at an incredible speed (the blank frames).

FRIMSource (also in Hardware mode) works for these files, though, which is why I believe them to not be faulty. I'll understand if you don't place too much value on that belief after my earlier posts. It is, however, slower to process - hence my desire to use DGMVCSource instead (Pacific Rim is processing at barely 14fps even using DGMVCSource, compared to my usual 20-26fps, so faster is better).

However, if I use MKVExtract to dig out the pre-combined multi-view stream and feed that through DGMVCSource instead than it works. This again suggests that the issue is somewhere between the way MakeMKV is creating the streams, tsMuxer is outputting those certain streams and the way your plugin is reading them. It just seems odd that there would be 4 that cause problems against the other 23 I've done so far without issue (not including Escape). Obviously I can use this method instead but I feel avoiding the issue isn't the best solution possible.

I've uploaded an MKV with the first 1,001 frames of Pacific Rim. I've tested to be sure and that's sufficient to see the garbled output I was talking about, as well as the stall which should occur at or around frame 967. tsMuxeR 2.6.12 is what I used to extract the individual streams when the error occurs, while the MKVExtract as provided by MKVToolNix v6.7.0 produces the working, pre-combined stream.

Pacific.mkv (https://mega.co.nz/#!0hNjVQwZ!1M92_Hh9GTBE7h8X4BbjwEv-ZRDL9gQmb2bYT2AoiqA) (111MB)

NB I'm not very familiar with these file-hosting services, so if that doesn't work then let me know.

[Guest]

@Thalyn

Can you please do the demuxing for me? You can give me the two sets of corresponding elementary streams, one of which works, and one does not. That will be the best thing for me to have to solve your issue.

[Guest]

My plan to have a single DGDec has forced me to back off to Visual Studio 2012 Express, as the latest CUDA toolkit 5.5 does not support VS 2013. I have managed to build DGDecNV and DGMVCSource in VS 2012, so all systems are now go. Who knows, I might even add support for libav SW decoding. :D

[jdobbs]

My plan to have a single DGDec has forced me to back off to Visual Studio 2012 Express, as the latest CUDA toolkit 5.5 does not support VS 2013. I have managed to build DGDecNV and DGMVCSource in VS 2012, so all systems are now go. Who knows, I might even add support for libav SW decoding. :DThat would be too cool.

[Guest]

That would be too cool. Yeah, as long as I don't end up in another Hall of Shame. ;)

What's going on with all that after the coup d'état? Is it still split into warring factions?

[Nico8583]

Dear neuron2 :D no I will not ask a new feature ;)
I would like to know if you have a to do list updated ?
And do you plan to implement MPLS support ? Because like r0lZ said in another topic, there are MPLS and multi angle inside this MPLS so it could be more difficult to support this ?!

[jdobbs]

Yeah, as long as I don't end up in another Hall of Shame. ;)

What's going on with all that after the coup d'état? Is it still split into warring factions?I haven't heard much on that subject in quite a while.

[Sharc]

@Thalyn
I demuxed your .mkv with tsMuxeR 2.6.12. I confirm that SW Decoding with DGMVCsource fails (garbled output).

Did you try without the intermediate .mkv i.e. demux with tsMuxer directly from the source .ssif?

Edit:
I just did this with Pacific Rim:
- demux the .ssif with tsMuxeR 2.6.12.
- Decoded the 2 Input files with DGMVCsource¨
=> Everything is perfect.
So I guess there is something odd with the .mkv. IIRC there is something special or proprietary with the MakeMKV 3D format. I just didn't find the post ....

[Guest]

Thanks, Sharc, for your feedback. Did you try the files demuxed from the MKV with frimsource? I would be surprised if they worked there but not in dgmvcsource, and would want to address that.

The best thing is to give me what I asked for, the two sets of files. Then I can simply compare them to see what is going on. Can you provide the two sets of demuxed files?

[Sharc]

Uploading ..... it may take a while ...

Yes, decoding with FRIMsource works, and so does viewing with Stereoscopic Player which uses CoreAVC decoder.


Thalyn's demuxed .mkv:
http://www.mediafire.com/download/xez6wecvz86sqnq/Bad.zip

Demuxed .ssif:
http://www.mediafire.com/download/4j0r3rp889naivz/Good.zip

[Guest]

Thanks, Sharc, I'll see if I can figure out what is happening here.

[Thalyn]

Sorry about the delay. I pretty much turned in for the night after making that post (was 3am), but I've separated the streams and just finished uploading them.

MKVExtract combined stream (https://mega.co.nz/#!d0UCmAaD!Y95vemF0xBaUXYN0ud99luz6eVEc5Ej5VibhOKEEe4g) (111MB)
Script:
## *Load plugins
LoadPlugin ("T:\BluRay Tools\Plugins\DGMVCDecode.dll") # Primary decoder
#LoadPlugin ("T:\BluRay Tools\Plugins\FRIMSource.dll") # Backup decoder
LoadPlugin ("T:\BluRay Tools\Plugins\SupTitle.dll")
LoadPlugin ("T:\BluRay Tools\Plugins\VSFilter.dll")
## *Source files
SP = "T:\BRD\" # Source path (must end in "\")
SF = "Pacific (MKVExtract)" # Source file names (raw streams only)
# AVC and MVC must be H.264 format
# (Optional) Subtitles must be SUP
FC = 1001 # Frame count of source
FR = FC # Frames to return (default: FC)
SFL = "" # (Optional) Left subtitle file for non-SUP
# Can be SUB/IDX, SSA, ASS, SRT, SUB, SMI, PSB, USF or SSF
SFR = 9 # (Optional) Right subtitle information
# (.SUP only) Subtitle horizontal offset. Good offsets are 6-12
# (Non-SUP) right subtitle file (non-SUP). Can be set to SFL for 0 offset
LC = 0 # Left cropping (typically 0)
TC = 0 # Top cropping (typically 0, 20, 132, 138 or 140)
RC = LC # Right cropping (typically the same as LC)
BC = TC # Bottom cropping (typically but not always the same as TC)
## *Load video file - default assumes AVC is Left (most common).
Try { # Attempt to use backup FRIM decoder
Source = FRIMSource (codec="mvc", filename=SP + SF + ".264", filename_dep=SP + SF + ".mvc", \
cache=4, num_frames=FC)
}
Catch (errDec) { # Attempt to use DGMVC decoder if FRIM is unavailable (default)
Source = DGMVCSource (SP + SF + ".264", "", view = 0, frames = FC)
}
## *Crop stream
Source = Source.Crop (LC, TC, -RC, -BC)
## *Split interleaved frames
AVC = SelectEven (Source)
MVC = SelectOdd (Source)
## *Assign left and right streams - switch as necessary (default Left = AVC).
Left = AVC
Right = MVC
## *Hard subtitles - add/change as necessary.
Try { # Attempt to add subtitle file as offset PGS
Left = Left.SupTitle (SP + SF + ".sup", forcedOnly=false, relocate=true, \
relocOffset="0, " + String (TC) + ", " + String (SFR) + ", 0")
Right = Right.SupTitle (SP + SF + ".sup", forcedOnly=false, relocate=true, \
relocOffset=String (SFR) + ", " + String (TC) + ", 0, 0")
}
Catch (errPGS) { # Try to read subtitles with VSFilter if not PGS format
Try { # First attempt to read as IDX/VOB
Left = Left.VobSub (SP + SFL)
Right = Right.VobSub (SP + SFR)
}
Catch (errVOB) { # If not IDX/VOB, attempt to read as text subs
Try {
Left = Left.TextSub (SP + SFL) # Recommend SSA/ASS for text subs
Right = Right.TextSub (SP + SFR)
}
Catch (errTXT) { NOP } # If subtitle file not found or not compatible, do nothing at all.
}
}
## *Merge to HOU.
Try { # Attempt to merge frames normally
HOU = StackVertical (Left.BilinearResize (Left.Width, Left.Height / 2), \
Right.BilinearResize (Right.Width, Right.Height / 2))
}
Catch (errCrop) { # If reduction fails, convert to RGB for the merge then back to YV12
Left = ConvertToRGB (Left, matrix = "rec709")
Right = ConvertToRGB (Right, matrix = "rec709")
HOU = ConvertToYV12 (StackVertical (Left.BilinearResize (Left.Width, Left.Height / 2), \
Right.BilinearResize (Right.Width, Right.Height / 2)), matrix = "rec709")
}
## *Output - adjust trim as necessary.
return HOU.Trim (0, FR - 1)

tsMuxeR AVC stream (https://mega.co.nz/#!0sM1FLSa!S_ABwOOkGkQ-UE-Wa8rCoTW0YSXKH9I1mYJjAQ7Z_Gs) (74.5MB)
tsMuxeR MVC stream (https://mega.co.nz/#!IxUnRJTQ!4bdQ2St4h0yKCqjeKy_WEs1ZTiQd6nsqTqgJo9-oWIE) (36.7MB)
Script:
## *Load plugins
LoadPlugin ("T:\BluRay Tools\Plugins\DGMVCDecode.dll") # Primary decoder
LoadPlugin ("T:\BluRay Tools\Plugins\FRIMSource.dll") # Backup decoder
LoadPlugin ("T:\BluRay Tools\Plugins\SupTitle.dll")
LoadPlugin ("T:\BluRay Tools\Plugins\VSFilter.dll")
## *Source files
SP = "T:\BRD\" # Source path (must end in "\")
SF = "Pacific (tsMuxeR)" # Source file names (raw streams only)
# AVC and MVC must be H.264 format
# (Optional) Subtitles must be SUP
FC = 1001 # Frame count of source
FR = FC # Frames to return (default: FC)
SFL = "" # (Optional) Left subtitle file for non-SUP
# Can be SUB/IDX, SSA, ASS, SRT, SUB, SMI, PSB, USF or SSF
SFR = 9 # (Optional) Right subtitle information
# (.SUP only) Subtitle horizontal offset. Good offsets are 6-12
# (Non-SUP) right subtitle file (non-SUP). Can be set to SFL for 0 offset
LC = 0 # Left cropping (typically 0)
TC = 0 # Top cropping (typically 0, 20, 132, 138 or 140)
RC = LC # Right cropping (typically the same as LC)
BC = TC # Bottom cropping (typically but not always the same as TC)
## *Load video file - default assumes AVC is Left (most common).
Try { # Attempt to use backup FRIM decoder
Source = FRIMSource (codec="mvc", filename=SP + SF + ".264", filename_dep=SP + SF + ".mvc", \
cache=4, num_frames=FC)
}
Catch (errDec) { # Attempt to use DGMVC decoder if FRIM is unavailable (default)
Source = DGMVCSource (SP + SF + ".264", "", view = 0, frames = FC)
}
## *Crop stream
Source = Source.Crop (LC, TC, -RC, -BC)
## *Split interleaved frames
AVC = SelectEven (Source)
MVC = SelectOdd (Source)
## *Assign left and right streams - switch as necessary (default Left = AVC).
Left = AVC
Right = MVC
## *Hard subtitles - add/change as necessary.
Try { # Attempt to add subtitle file as offset PGS
Left = Left.SupTitle (SP + SF + ".sup", forcedOnly=false, relocate=true, \
relocOffset="0, " + String (TC) + ", " + String (SFR) + ", 0")
Right = Right.SupTitle (SP + SF + ".sup", forcedOnly=false, relocate=true, \
relocOffset=String (SFR) + ", " + String (TC) + ", 0, 0")
}
Catch (errPGS) { # Try to read subtitles with VSFilter if not PGS format
Try { # First attempt to read as IDX/VOB
Left = Left.VobSub (SP + SFL)
Right = Right.VobSub (SP + SFR)
}
Catch (errVOB) { # If not IDX/VOB, attempt to read as text subs
Try {
Left = Left.TextSub (SP + SFL) # Recommend SSA/ASS for text subs
Right = Right.TextSub (SP + SFR)
}
Catch (errTXT) { NOP } # If subtitle file not found or not compatible, do nothing at all.
}
}
## *Merge to HOU.
Try { # Attempt to merge frames normally
HOU = StackVertical (Left.BilinearResize (Left.Width, Left.Height / 2), \
Right.BilinearResize (Right.Width, Right.Height / 2))
}
Catch (errCrop) { # If reduction fails, convert to RGB for the merge then back to YV12
Left = ConvertToRGB (Left, matrix = "rec709")
Right = ConvertToRGB (Right, matrix = "rec709")
HOU = ConvertToYV12 (StackVertical (Left.BilinearResize (Left.Width, Left.Height / 2), \
Right.BilinearResize (Right.Width, Right.Height / 2)), matrix = "rec709")
}
## *Output - adjust trim as necessary.
return HOU.Trim (0, FR - 1)

Yes, the two scripts are nearly identical. This is my standard "cover all" script. The key differences are uncommenting the LoadPlugin line for FRIMSource and changing the SF variable.

Incidentally, Pacific Rim failed on a full run even using the pre-combined source. Sections of the video were missing, about a second long each time it happened (total of about 5-6 occurrences though I didn't find them all). I plan on taking another look later to see if EAC3To streams work properly but for now I'm checking the stream with FRIM to see if that gives the same results.

Disregard - that seems to be a source problem. Next step is demuxing straight from the disc.

Update: Streams extracted straight from the disc using tsMuxeR are fine, however the same stutters I was getting before (eg circa frame 95,200) are still present. Between this and Escape I've clearly got another problem that needs fixing - will need to experiment.

[Guest]

Well, the bad streams are formally wrong. For example, at times there is an extra PPS at the end of a NALU just before the next AUD NALU. Somehow Frank's combiner is cleaning them up sufficiently to allow things to continue working, while mine is not. As my main goal now is on getting DGDec functionality working (full frame accuracy/seeking) and less on 3D stuff, I may leave it and just assert "bad streams". Or if I get curious enough, I'll look into what Frank's combiner is doing that allows it to survive these streams.

[Sharc]

I suspect that the tool which created the .mkv is the culprit.

[Guest]

Following is an example of the stream violations. Here the PPS is appearing before the AUD NALU when it should be after. I believe Frank's combiner is moving these to the right place. That's very thoughtful of him but I wonder if it is deliberate or just a lucky consequence of how he implemented the combiner.

[videofan3d]

Following is an example of the stream violations. Here the PPS is appearing before the AUD NALU when it should be after. I believe Frank's combiner is moving these to the right place. That's very thoughtful of him but I wonder of it is deliberate or just a lucky consequence of how he implemented the combiner.


It se definitely only good luck :-)

FRIM uses "MVCCombiner" which I sent you - and I wrote it only upon empiric observation of the structure of AVC and MVC and Combined streams which produces Intel Media MVC Encoder.
I really have no special knowledge in this domain :)
And I'm sure that this algorithm is far from perfection - the fact that nobody reported problems doesn't mean it is bug free - not at all ! :D

[Thalyn]

"Bad streams" sounds a fair enough declaration to me, given the information in the streams is in the wrong order. I guess that's just something to note: Don't use split-streams made from the output of MakeMKV (but the combined stream seems OK).

Now if I could only figure out what's messing up my extraction of both Pacific Rim and Escape. Both play back flawlessly under PowerDVD 13 so I'm fairly sure that my discs, drives and drivers aren't the problem. But I'll be buggered if I can successfully get a full run of either without one or more glitches (which seem to be isolated to my system) occurring...

[Guest]

It's definitely only good luck :-) Still, it will be interesting to trace your combiner to see how it avoids barfing on these malformed streams. Thanks for providing the source code. At first, I thought it didn't work but it turned out to be a problem on my side. :)

FRIM uses "MVCCombiner" which I sent you - and I wrote it only upon empiric observation of the structure of AVC and MVC and Combined streams which produces Intel Media MVC Encoder.
I really have no special knowledge in this domain :)
And I'm sure that this algorithm is far from perfection - the fact that nobody reported problems doesn't mean it is bug free - not at all ! :D There is one strange thing your combiner does with these streams. It outputs a combined stream with an 8 NALU immediately following the last base slice, but immediately preceding a 24 NALU. I would have thought that was wrong but Intel Media accepts it fine. I suspect they ignore 24 NALUs, and anyway my combiner suppresses them from the output and they work fine that way (with legal streams).

I think it is worth it for me to investigate this further as it will be useful to have a complete reliable specification of what a combiner should do and how it can be made as robust as possible against dubious input. If only Intel would document their combined format more thoroughy; the best I have seen from them is first present all the base slices and then the dependent slices!

[Guest]

So after looking everything over closely, including the test results and Frank's combiner, it's apparent that I've been overthinking what is required of a combiner, and the process is really very simple. All you have to do is interleave the base and dependent access units (access units are delimited by a 9 NALU in the base stream and a 24 NALU in the dependent stream). That's all, folks!

So I have released new versions of the standalone combiner DGMVCCombine and the source plugin DGMVCSource. The source filter now succeeds with the bad streams the same as FRIMSource.

http://neuron2.net/mine.html

[Thalyn]

After managing to screw myself around a whole heap (got my source streams well-and-truly mixed up and found myself processing an already-processed stream), quick testing is yielding the same results with B22 as with B20. That is to say good results aside from a couple of baffling exceptions that only I seem to be able to produce. I did, however, discover that using the driver provided from Windows Update for my HD 4600 had disabled hardware accelerated decoding, so if anyone's having trouble with it make sure you use the drivers from Intel and not MS.

Per your request I've uploaded a snippet from the middle of Pacific Rim as made by DGSplit with the only processing done by AnyDVD HD (7.4.2.0). In case it's in any way, shape or form relevant, it's bytes 21,670,573,312 to 21,870,573,312, containing around 35 seconds. The error I experience should present itself about half-way through, covering the scene transition just after the Kaiju (the monster if you haven't seen the movie before) roars, lasting only around a second, but I included extra to ensure as little important data is missing as possible (when I tried to cut it finer it appeared to miss parts of the MVC stream).

00098_0.ssif (https://mega.co.nz/#!wx1QjTaS!-NgZoX7BXDdL5LbG27iKxwnRVyyTwRpwViWPw87FUEA) (190.7MB)

[Sharc]

I transcoded Pacific Rim in full length and confirm Thalyn's observation of glitches shortly after frame 95300.
DGMVCsource 0.22b / SW.

[Guest]

Does it happen with FRIMSource also? In a PM, Thalyn said "I cannot for the life of me figure why feeding certain streams I've extracted through either Intel decoder doesn't work". If it is an issue in the Intel Media SDK, there's not much I can do about it; I don't have any special contacts with Intel support, and you can just as well post a thread at their forum about it as I can.

Also, I cannot use that SSIF file because eac3to will not open it. Something is wrong with it.

[Thalyn]

It's literally 200,000,000 bytes extracted from the middle of much larger ssif file using DGSplit. I lack the knowledge (and possibly tools) to make a more accurate "cut" without first demuxing the streams (even if to put them into another container) - like the streams I already linked to you - so that's unfortunately the best I can do while keeping the amount of pre-processing to an absolute minimum.

If there's another, more useful way to make the extraction I'm quite willing to give it a go.

*ed: Curiously, what made those extracted streams "bad"? Is it something that can be fixed during extraction (such as telling tsMuxeR to rebuild the SEi and VUI data) or by the plugin (like those NALU thingies - NB I don't know what any of these acronyms mean), or is it something irreparable like a missing keyframe?

[Guest]

I asked this but you did not answer: Does it happen with FRIMSource also? Can you please answer it?

Curiously, what made those extracted streams "bad"? Is it something that can be fixed during extraction (such as telling tsMuxeR to rebuild the SEi and VUI data) or by the plugin (like those NALU thingies - NB I don't know what any of these acronyms mean), or is it something irreparable like a missing keyframe? I don't know what streams you are talking about.

[Sharc]

I didn't try with FRIM, but I will do it now and report back.

[r0lZ]

Does it happen with FRIMSource also?I am currently encoding Pacific Rim with FRIMSource. I should be able to tell if it had the same problem in 2 hours or so...

I can already confirm the bug when it is encoded with DGMVCSource b22 (SW).

[Sharc]

Also, I cannot use that SSIF file because eac3to will not open it. Something is wrong with it.
I can open and demux it with tsMuxeR.
The .ssif however includes the base view only (which has no glitches). The dependent view seems to be missing.

[r0lZ]

Yes, I've seen that. Only the AVC stream is detected by tsMuxeR (as well as a lot of audio and 2 subpic streams).
... the base view only (which has no glitches).Are you sure? I have noticed with my test encoding that the base view is badly decoded too. IMO, it's the base view that the Intel decoder cannot decode properly. The glitch in the dep view is of course a consequence of the bad base view. When I will have some time, I'll encode the base view only, just to be sure...

[r0lZ]

Same problem with FRIMSource. :-(

[Guest]

Same problem with FRIMSource. :-( or :) from my point of view.

[Sharc]

Yes, I've seen that. Only the AVC stream is detected by tsMuxeR (as well as a lot of audio and 2 subpic streams).
Are you sure? I have noticed with my test encoding that the base view is badly decoded too. IMO, it's the base view that the Intel decoder cannot decode properly. The glitch in the dep view is of course a consequence of the bad base view. When I will have some time, I'll encode the base view only, just to be sure...
I mean that the demuxed base view is without glitches.
Glitches are introduced only when processed by DGMVC or FRIM. Both behave the same: The Base view AND the Dependent view have glitches.

[r0lZ]

or :) from my point of view.Yes, you have nothing to do. But it's a bad news anyway.
I mean that the demuxed base view is without glitches.
That means only that the decoder used by the player has no trouble with it, and (probably) that there is nothing wrong with the encoding or authoring of the BD. And that confirms probably that the culprit is Intel!

[jdobbs]

Yes, you have nothing to do. But it's a bad news anyway.

That means only that the decoder used by the player has no trouble with it, and (probably) that there is nothing wrong with the encoding or authoring of the BD. And that confirms probably that the culprit is Intel! Except, of course, that TSMUXER doesn't see the dependent view in the stream.

@Sharc

Have you tried demuxing from the two M2TS files?

[Sharc]

Yes, you have nothing to do. But it's a bad news anyway.

That means only that the decoder used by the player has no trouble with it, and (probably) that there is nothing wrong with the encoding or authoring of the BD. And that confirms probably that the culprit is Intel!
Yes, that seems to be most likely.
- The BD plays ok on a standalone
- The dumuxed base view has no glitches
=> The source (BD) is most probably clean.

- FRIM and DGMVC behave the same
=> the common set is Intel.

[Sharc]

Except, of course, that TSMUXER doesn't see the dependent view in the stream.

@Sharc

Have you tried demuxing from the two M2TS files?
The missing dependent view happened only with Thalyn's snippet.
I took the original .ssif and tsMuxeR demuxed the Base and Dependent files as expected.

[jdobbs]

The missing dependent view happened only with Thalyn's snippet.
I took the original .ssif and tsMuxeR demuxed the Base and Dependent files as expected.Ok. I misunderstood.

[Sharc]

I may just add that Stereoscopic Player (licensed, using CoreAVCdecoder.dll) plays Pacific Rim without issues.

[Nico8583]

Bad news for Intel SDK :-(
I think there is the same issue with MVCSource...
Does anyone already contact Intel support to report this bug ?

[Sharc]

@jdobbs (or anyone):
Did you try FRIMDecode piping into FRIMEncode (or stdout to x264 SBS)? Same problem as with the plugin-decoders for Pacific Rim?

[Guest]

Bad news for Intel SDK :-(
I think there is the same issue with MVCSource...
Does anyone already contact Intel support to report this bug ? I will be happy to pursue this with them, but right now all I have is an SSIF that I cannot demux. Somebody has to give me something I can use to duplicate the issue.

[Sharc]

Trying to produce a working cut ......

Got it. Uploading .... be patient ....

Edit:
Here we go (http://www.mediafire.com/download/bib2za0uxzcctfm/pr.zip). I hope you can duplicate the issue.

[r0lZ]

As I suspected, pistacho's MVCSource has the same problem.