DGMVCSource

[jdobbs]

Originally Posted by r0lZ

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]

Originally Posted by r0lZ

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]

Originally Posted by jdobbs

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]

Originally Posted by Sharc

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]

Originally Posted by 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 ?

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. I hope you can duplicate the issue.

[r0lZ]

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

[Sharc]

Originally Posted by 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?

I can give the answer myself:
YES, it's exactly the same problem.
I guess this makes it pretty obvious that the root cause is the INTEL SDK.

[jdobbs]

Originally Posted by 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?

I don't have a 3D copy of "Pacific Rim", so I haven't tested it.

[Guest]

Thank you for the testing and streams, guys. This is going to be an interesting test case for Intel support. When I was doing the CUVID development NVidia was always very fast to respond and fix things like this. Intel has to do the same if they want the SDK to be successful. We shall see...

[Thalyn]

Originally Posted by neuron2

I don't know what streams you are talking about.

These streams are what I was referencing. There's only a couple seconds of video in each of those spanning where I notice the error, but I think tsMuxeR gave me 1 more frame for one of the streams (and wasn't kind enough to tell me which way the overhang should be).

Sorry about that. I should probably only try to make posts here when I'm more awake, but the time difference means I'll probably be responding well out of sequence.

[Sharc]

You have perhaps seen the comments of videofan3d about the Pacific Rim clip. His conclusion is "bad stream".
I have no clue at which stage between source and production of the clip the error has been introdcued, nor do I have other problematic sources (like Avenger) to test.
I used tsMuxeR for demuxing and producing the Clip. Has anybody tried eac3to, just to exclude tsMuxeR from being the culprit?

[Thalyn]

I've tried it with EAC3To, tsMuxeR and BD Demuxer Pro 3D - all produce slightly different streams but all yield the same error in the same place. I even tried telling tsMuxeR to extract with different options to see if something needed to be rebuilt

I will, however, re-try EAC3to just to confirm. I don't recall exactly how long ago it was I did that so a newer plugin may work.

[Sharc]

ok. I will also try now Pacific Rim with eac3to, and then we can see if we can confirm results.

Edit:
No luck.
- Demuxing Pacific Rim full length with eac3to. Base and dependent streams have identical number of frames (exactly the same number as I got with tsMuxeR)
- Base stream plays flawlessly with SW players (same as before with tsMuxer)
- transcoding from start using DGMVCsource as decoder
=> corruption starts with the same frame as before.

As tsMuxeR was not involved at any stage in this test we can exclude it from being the cause for the problem.

[r0lZ]

I did exactly the same test, and I confirm.

I can also confirm that DirectShowMVCSource and SSIFSource (both using CoreAVCDecoder) do not have the problem.

I have also played the base view with several players, and none exhibit the glitches.

IMO, there is no doubt any more that the culprit is the Intel Media library.

[Nico8583]

So we can only hope neuron2 will get a response from Intel support :/

[Sharc]

Perhaps we should provide to neuron2 a short clip of another problematic source for better evidence. So far most has been based on Pacific Rim. Anyone has a second example?