DGMVCSource

[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]

@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]

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

These streams (https://mega.co.nz/#!Jk8C1KBJ!wrSurXdtEdcJaQj6kw5cRCmH1RoBkAtXQ37N4UGyRuQ) 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 (http://forum.doom9.org/showpost.php?p=1666422&postcount=81)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?

[Thalyn]

We need to find such a beast first. I know PR shows the same basic error multiple times, but so far only it and Escape from Planet Earth have given me any trouble - everything else appears to go through correctly. I'm progressively working through my collection of around 53 3D movies (28 down) and those are the only two I've seen a problem with, though I haven't done a frame-by-frame screening of them all.

That said, I'm in agreement with R0lz that it's the Intel libraries that are the source of the problem based on simple process of elimination:
- The drive doesn't appear to be the cause in that multiple drives from completely different locations produce identical results.
- The disc doesn't appear to be the problem in that multiple samples from completely different locations produce identical results.
- Decrypting does not appear to be the cause in that...
== an ISO created by AnyDVD HD plays back fine in PowerDVD 13.
== an MKV extracted by MakeMKV plays back fine using the LAV filters or PowerDVD (though this only verifies the AVC stream).
- Extracting the streams does not appear to be the cause in that...
== Four (4) different extraction tools yield identical errors.
== Repackaging the stream allows it to be played fine using the LAV filters or PowerDVD (though, again, this only verifies the AVC stream).
- The source plugins don't appear to be the cause in that it's unlikely the three authors (Neuron2, Pistacho and VideoFan3D) would have independently coded identical faults.
- Encoding doesn't appear to be the cause in that streaming directly to VirtualDub gives the same error.
- QuickSync itself doesn't appear to be the cause in that both Software and Hardware decrypting produce identical results.

And, of course...
- CoreAVC works (though it gives different errors for Escape)

Curiosity also got the better of me and I tried feeding it through Handbrake using its QSV path, which presumably uses the same IM libraries, both reading directly from the disc and from a repackaged stream (just the AVC stream to prevent MVC "taint" as I cannot easily test it). Both of these yielded identical results, which match the results from using any of the plugins based on the IM libraries. This also means that it's not the MVC stream responsible for the issue, but I'm sure it isn't helping.

With all that taken into consideration, the only thing left really is the IM libraries and, based on the errors which CoreAVC presents with certain sources, it's entirely possible that its present incarnation just simply isn't compatible with those streams for whatever reason.

[Sharc]

So it looks to me that we have so far only 2 candidates:
- Pacific Rim, which has been confirmed in several independent tests
- Escape from planet Earth (where even other decoders like CoreAVC seem to have problems)

This is a bit weak to make a strong case, I believe, means we should continue collecting more evidence and reporting back here with supporting material/clips from various sources & testers, supporting Thalyn in his huge efforts. Unfortunately this takes much time because one normally has to watch frame by frame, unless something very obvious pops up. Otherwise we have to wait and see if and how complaints from users will develop over time.

[Thalyn]

The following demonstrates what I've been able to discover so far. If anyone wants to confirm my findings, either using my provided source or their own source, than it would be appreciated.

Exhibit A (https://mega.co.nz/#!co8BzRpL!qXoCWL-vKmFry2RmLe2G1P3oHn0le6NZJ7NnjAMJOck) (97.7MB): a zip file with two (2) pre-combined sources from "Pacific Rim" and the results I got.
Exhibit B (https://mega.co.nz/#!h1l0CIJa!KCxY6TC506bf2aNrZhiD04qdy0GFhdVYdzz00zPHTNA) (50.5MB): a zip file with one (1) pre-combined source from "Escape from Planet Earth" and the results I got.

It may not be a strong case, but it's a start - and it may well be enough for Intel to do some investigating. It could very well be that these two are the only titles which exhibit problems because of some exact sequence in the source streams, however the fact that it applies to the AVC stream on its own as well opens up a lot more potentially "broken" streams (it extends my personal collection of potential issues 6 fold, plus it could apply to any other H.264 stream from any source).

[Guest]

however the fact that it applies to the AVC stream on its own What do you mean by that? You have a 2D stream that fails?

[r0lZ]

Yes, the problem with Pacific Rim is in the AVC stream (and, of course, also in the MVC stream, since it depends of the AVC).
I have not Escape from Planet Earth, but I suppose the problem is similar.

[Guest]

Where is this stream? I have seen the error only when decoding MVC.

[Thalyn]

You can use the same ones I've provided (linked in my last post), though it may satisfy your curiosity better if you split them again. I don't know about EAC3To, but tsMuxer can split already-combined streams.

My AVC tests were done using streams from the original disc (Pacific Rim), both extracted from the SSIF and individually from the M2TS to limit taint. A similar (I can't say identical because I haven't done a screen-capture comparison) issue presents in what appears to be exactly the same place. I checked it initially with DVIM and FRIM, and also with Handbrake (via VidCoder) since the newest versions have a QuickSync path that was co-developed with Intel (you actually have to manually disable QuickSync decoding in the latest Handbrake nightlies, even if you're not using the QSV encoder) and the results persisted.

So, in fairness, it's not strictly a 2D stream as it's a stream from a 3D movie. However, it's 2D in the sense that it was only the AVC stream without any interaction at all with the MVC stream. A thought occurs as I type this and tomorrow I'll check the 2D disc to see if it gives the same error.

PS Dredd (the 2012 one) worked perfectly start to finish. No visible issues to speak of on any frame, even through to the end of the credits. Some beautiful cinematography in that movie (and some very trippy lighting).

*ed: Screw tomorrow - I'll check it now. Interesting initial observation on scanning the original disc, though:
[h264 @ 000000001b664420] non-existing SPS 0 referenced in buffering period
[h264 @ 000000001b664420] non-existing PPS referenced
[h264 @ 000000001b6668a0] non-existing SPS 0 referenced in buffering period
[h264 @ 000000001b6668a0] non-existing PPS referenced
[h264 @ 000000001b6668a0] non-existing PPS referenced
[h264 @ 000000001b6668a0] non-existing PPS referenced
[h264 @ 000000001b6668a0] SEI type 83 truncated at 40
[h264 @ 000000001b6668a0] non-existing PPS referenced
[h264 @ 000000001b6668a0] non-existing PPS referenced
[h264 @ 000000001b669960] non-existing SPS 0 referenced in buffering period
[h264 @ 000000001b669960] non-existing PPS referenced

Kicking along at 80fps+ thanks to the QSV encoder in Handbrake!

[Guest]

OK, I see it decoding 00098.264 by itself, and that same file is played fine by DGDecNV. So, I will use this one to discuss it with Intel.

What tool is producing the trace you gave?

[Thalyn]

That's the feedback from the scan log in VidCoder 1.5.16.0 beta (x64) when selecting the 2D BluRay as the source. Interestingly I just gave it a try with Handbrake proper (xvn5965 nightly) and it outright crashed citing an APPCRASH in "StackHash_87bd".

Loading the 3D one into VidCoder gives the following feedback:
[h264 @ 00000000265912a0] non-existing SPS 0 referenced in buffering period
[h264 @ 00000000265912a0] SEI type 30 truncated at 56
[h264 @ 00000000265912a0] non-existing PPS referenced
[h264 @ 00000000265912a0] SEI type 2 truncated at 56
[h264 @ 00000000265912a0] non-existing PPS referenced
[h264 @ 00000000265912a0] SEI type 4 truncated at 56
[h264 @ 00000000265912a0] non-existing PPS referenced
[h264 @ 0000000026590a80] non-existing SPS 0 referenced in buffering period
[h264 @ 0000000026590a80] SEI type 10 truncated at 56
[h264 @ 0000000026590a80] non-existing PPS referenced
[h264 @ 0000000026590a80] SEI type 2 truncated at 56
[h264 @ 0000000026590a80] non-existing PPS referenced

That said, VidCoder was able to fully process the 2D version of the film with no apparent errors, or it at least had them in different spots (I didn't look elsewhere - just the two errors I know about). The 2D and 3D versions are compressed differently on the discs, however, as there's only 7.3GB difference between the two source SSIFs and the MVC stream is 9.9GB.

To me, this suggests it isn't an issue with the studio and how it made the streams to begin with, unless it's just a lucky co-incidence (or unlucky, depending upon which stream you're referring to).

Unrelated side note: The QSV encode ran at 84fps (37:29 elapsed time) with CPU usage in the teens and GPU usage around 80% with a few tweaks to increase the quality and CQP set at 18. Resulting filesize was 10.6GB and the quality is pretty good but, if I'm honest, a little disappointing as it smears some detail (like skin texture). But if speed is your #1 priority it'd be extremely hard to beat!

[osgZach]

It can decode normal AVC as well.

Think of it as a trial run for a version of DGDecNV that will use the Intel Media SDK rather than NVidia's CUVID. The Intel Media SDK supports both SW decoding and HW acceleration via QuickSync, and therefore DGDecIM will be able to run in SW or HW, depending on the machine capabilities.

Ah, cool.. :D

I haven't had a Nvidia GPU for ages so my license is practically worthless.. It sounds like it would allow me to use DGDecNV again, if I had a Quicksync setup then?

I know you said the source filter will be open, which is cool. Would it have an indexer like the other DG tools? (right now seems like it doesn't?).

[Guest]

It sounds like it would allow me to use DGDecNV again, if I had a Quicksync setup then? No, but you could use the new toolset, not the older DGDecNV.

I know you said the source filter will be open, which is cool. Would it have an indexer like the other DG tools? (right now seems like it doesn't?). I said that DGMVCSource() will be open, and it is. The new DGDec I am working on will not be open source. The former is linear decode only while the latter will have full frame accuracy via indexing, etc.

[osgZach]

Ok, so just so I make sure I am understanding.

There will be a brand new tool released, that I can buy a license for, and it won't be restricted to Nvidia hardware.. Yes?

[Guest]

Ok, so just so I make sure I am understanding.

There will be a brand new tool released, that I can buy a license for, and it won't be restricted to Nvidia hardware.. Yes? Correct.

[Audionut]

Excellent, thanks Don.

I've stayed away from decoding/encoding 3D until now since it's always been to much flaffing around. With SSIF support, that will mean one less step :P

Thanks again.

[HWK]

No, but you could use the new toolset, not the older DGDecNV.

I said that DGMVCSource() will be open, and it is. The new DGDec I am working on will not be open source. The former is linear decode only while the latter will have full frame accuracy via indexing, etc.

Correct.

Do you need me to donate again, or donation I made for dgdecnv will cover it. Just want to confirm how license system gone work?
Also will dgdec work with mvc source.

[Guest]

I haven't decided about licensing yet. Anyway, the chick needs to hatch first. Yes, I plan to support MVC decoding in DGDec.

[HWK]

I haven't decided about licensing yet. Anyway, the chick needs to hatch first. Yes, I plan to support MVC decoding in DGDec.

Thank you, for information.

[allanlee]

I've done a series of test, regarding the bad frames' problem using a short clip from Pacific Rim provided here by Sharc (http://forum.doom9.org/showthread.php?p=1666166#post1666166) and here by Thalyn (http://forum.doom9.org/showthread.php?p=1666217#post1666217).

Results: (use 00098.zip as example, pr.zip give exactly identical conclusions)
1. Using CoreAVC(CoreMVC) based DirectShowMVCSource and ssifSource2 (CoreAVCDecoder.dll from MVCtoAVI 0.33), ssif file muxed by tsMuxer3D (ISO mode).
No problem at all, receiving 100 valid SBS frames. This is what expected - decoder performed well, and the source should not have problem. (or CoreMVC is robust enough to correct them)
LoadPlugin("DirectShowMVCSource.dll")
DirectShowMVCSource("00098.ssif", stf=14)
Lanczos4Resize(1280,360)
LoadPlugin("ssifSource2.dll")
ssifSource2("00098.ssif",100,true,true,true)
Lanczos4Resize(1280,360)

2. Using DGMVCSource(100b22), FrimSource(1.22x86), MVCSource(2.0 from BDtoAVCHD v1.9.5)
6 bad frames (48~54), total 77 valid SBS frames received (including bad ones)
LoadPlugin("dgmvcdecode.dll")
vid=dgmvcsource("00098.264","00098.mvc",view=0,frames=100)
left=vid.selecteven()
right=vid.selectodd()
StackHorizontal(left,right)
Lanczos4Resize(1280,360)
LoadPlugin("FRIMSource.dll")
FRIMSource("mvc","00098.264","00098.mvc","sbs",num_frames=100)
Lanczos4Resize(1280,360)
LoadPlugin("MVCsource.dll")
V=MVCsource("00098.264", "00098.mvc", 100, 2)
R=SelectOdd(V)
L=SelectEven(V)
return StackHorizontal(L,R).Lanczos4Resize(1280,360)

3. Using ssifSource4.1 by slavanap (posted here (http://forum.doom9.org/showthread.php?p=1667073#post1667073))
77 GOOD frames received.
LoadPlugin("ssifSource2.dll")
ssifSource("00098.ssif", 100, horizontal_stack = true, intel_params = "-d3d", debug = true)
Lanczos4Resize(1280,360)

And I've done some further test as well:
a) try to feed m2ts streams from the ISO created by tsMuxer3D to FrimSource, no luck;
b) suspected that avc/mvc combining tool may be the problem - feed the combined avc+mvc stream to the sample_decode.exe (from ssifSource4.1 package), and view the decoded YUV. -- sample_decode.exe worked well with combined stream. Both MVCCombine.exe and dgmvccombine102 tested, same result.
# sample_decode.exe mvc -d3d -i 00098Combined.h264 -o 00098D.yuv
L=RawSource("00098D.yuv_0.yuv",1920,1080,"I420")
R=RawSource("00098D.yuv_1.yuv",1920,1080,"I420")
StackHorizontal(L,R).Lanczos4Resize(1280,360)
c) noticed that ssifSource4.1 calls x64 Intel Media SDK library as default, I tested both x86 & x64 - both give good frames;
d) noticed that ssifSource4.1 uses a different version of Intel Media SDK (4.12.12.3), when DGMVC/Frim use 5.13.12.7. I swapped the dll, but no luck;

Seems that:
- Intel Media SDK can give the correct frames, which was told by ssifSource4.1
- the only differences are the "calling interface" of the Intel dlls, e.g. sample_decode.exe and the AviSynth source filters

I'm really confused with all these results @_@ , but I have to admit slavanap did provide a solution (http://forum.doom9.org/showthread.php?p=1667080#post1667080). However, the key is likely to be at sample_decoder.exe, but may not be the demuxer (http://forum.doom9.org/showthread.php?p=1667274#post1667274).

Some other questions:
1) Anybody know how to dump the output from the directshow MPC MPEG2Splitter to files? The cause of the bad frames can be confirmed by feeding the elementary streams demuxed by the directshow filter to DGMVC/Frim etc;
2) Difference of frame number: DGMVCCombine tells "100 frams processed", CoreMVC returns 100, Intel returns only 77. It could be a problem caused by splitting of the file - anyhow not a big issue.

Hope these results can be reproduced and help solving the problem.

P.S. test platform - AvsPmod 2.2, VirtualDubMod. Intel Media SDK worked in sw mode.

[r0lZ]

I did several similar tests, and I can confirm your findings. It seems that the bug is NOT in the Intel Media SDK.

BTW, allanlee, how did you ran ssifSource4.1 with the "Pac1 (source 192 frames).264" sample file? AFAIK, ssifsource4 works only with SSIF file, and I have been unable to use it with the short sample files.

Now the question is: What is causing that bug in DGMVCSource and FRIMSource? Maybe slavanap has replied to that question here:
Maybe this MPEGSplitter I used to demux the ssif-file (instead eac3to & tsMuxer) can fix this issue with the films.
The same MPEGSplitter used with CoveAVCDecoder for ssifSource2 & DirectShowMVCSource, though it delivers both (main & dependent) streams independently right into CoreAVCDecoder.

[Nico8583]

Thanks for your tests :)
Like allanlee & r0lZ said, there is 2 causes possible :
- Intel Media SDK 5.* has introduced a bug in MVC decoding, but dll swap between 4 and 5 could solve the problem
- MPEGSplitter can fix the issue
Does anyone tried to use a CombinedMVC with DGMVCSource and FRIM ? And demux with eac3to and tsMuxeR with and without SEI data insertion ?

[Sharc]

I tried with lib 4.xxx, 32 bit. No luck, same problem.

[Nico8583]

Perhaps 4 and 5 coding is different :confused:

[r0lZ]

No, v4 and 5 give the same results. Good with ssifsource4, and bad with DGMVCSource, FRIMSource and NVCSource. IMO, it's the demuxer or the combiner that is the culprit. (I'm still doing tests, but so far it's my conclusion.)

[Nico8583]

Have you tried v5 with ssifsource4 ?
It's strange, all of 3 decoders use a different combiner or demuxer :confused: perhaps it will work with eac3to or tsMuxeR and MVCCombine ?

[Sharc]

eac3to or tsMuxeR for demuxing did not mak a difference in my tests. Same Problem with both.

[Nico8583]

Have you tried to demux AVC and MVC (with eac3to or tsMuxeR) and use MVCCombine.exe to create a single H264 file as source ?

[Sharc]

Not sure, I don't remember. Thalyn has done such test IIRC.

[allanlee]

BTW, allanlee, how did you ran ssifSource4.1 with the "Pac1 (source 192 frames).264" sample file? AFAIK, ssifsource4 works only with SSIF file, and I have been unable to use it with the short sample files.


2 methods:

(1) Use tsMuxer(3D) 2.6.11, mux the AVC & MVC elementary streams to BluRay(3D) ISO file, you get ssif (for ssifSource and CoreMVC decoders) and separated m2ts (for Frim, ts input)

(2) Since ssifSource4.1 is a connected pipeline, I've tried to break it apart. What I have done is just ignore the AviSynth plugin first, use only sample_decode.exe from the package to decode the combined avc+mvc stream to YUV files, and check.
I tried both MVCComibine.exe and DGMVCCombine (102), same result - sample_decode.exe always give good frames.


Like allanlee & r0lZ said, there is 2 causes possible :
- Intel Media SDK 5.* has introduced a bug in MVC decoding, but dll swap between 4 and 5 could solve the problem
- MPEGSplitter can fix the issue
Does anyone tried to use a CombinedMVC with DGMVCSource and FRIM ? And demux with eac3to and tsMuxeR with and without SEI data insertion ?

What I have done:
(1) swap the dlls for DGMVCSource/FrimSource/MVCSource and ssifSource4.1;
Result: always bad frames from the former 3 filters and always good ones from ssifSource4.1, so seem to be no bug for both versions in Intel dll.
(2) feed Combined avc+mvc into sample_decode.exe (which is using by ssifSource4.1), described above
Result: still good frames, that means the 2 combiners should not have problem, or at least sample_decode.exe is more robust that the other 3 and can fix some slight errors.
(3) Tried to cross-check. But I failed to dump the output from MPEGSplitter to files. If I can feed them to DGMVCSource/FrimSource/MVCSource, problem will be more clear.
I'm sure slavanap can help with that.


IMO, it's the demuxer or the combiner that is the culprit. (I'm still doing tests, but so far it's my conclusion.)
sample_decode.exe from ssifSource4.1 worked fine with combined streams, and actually ssifSource4.1 uses MVCCombine.exe in its pipline.


My conclusion is:

Seems that:
- the only differences are the "calling interface" of the Intel dlls, e.g. sample_decode.exe and the AviSynth source filters

Here is the most likely to be where the problem lies. But obviously, more tests need to be done to confirm.

[Thalyn]

Not sure, I don't remember. Thalyn has done such test IIRC.

I've used tsMuxeR and EAC3to, both separated and pre-combined, and extraction from the MakeMKV results - all produce the same end results when using FRIM or DGIM. There is some slight variation in the raw streams produced by each (they're not bit-identical) but that doesn't seem to have any effect at all on the output.

This makes things all the more curiouser, if that's even a real word.

On the plus side, if Sample_Decode works than it's possible that the solution is somewhere in the source code there-of, so perhaps a fix isn't too far off. I doubt it's called "Sample" without including source code, anyway.

[r0lZ]

(3) Tried to cross-check. But I failed to dump the output from MPEGSplitter to files. If I can feed them to DGMVCSource/FrimSource/MVCSource, problem will be more clear.
I'm sure slavanap can help with that.I've tried too, but without luck.
I hope slavanap can help us demux with MPEGSplitter, to isolate and confirm the origin of the problem.

[r0lZ]

Does anyone tried to use a CombinedMVC with DGMVCSource and FRIM ? And demux with eac3to and tsMuxeR with and without SEI data insertion ?The last check I did was without SEI data insertion. Same result.

[Thalyn]

Well, I just finished off the last of my 3D movie collection using DGMVC. 52 movies in all from a reasonable cross-section of studios and distributors and none of the others exhibited the same issue as Pacific Rim, in so much as they all remained perfectly in sync from start to finish. That's not to say that none of the others had any errors at all as I've not watched through them all frame-by-frame but quick analysis has found nothing worth mentioning - save Escape of course.

I realise we've already found a potential source of this issue but it really does seem to be extremely isolated, so it's rather lucky (or unlucky, depending on your view) that we even discovered it at all.

PS Yes I did also try with SEI/VUI insertion, leaving it as-is and rebuilding, as well as with and without SPS/PPS. Slightly different (not bit-identical) source files, same output.

[Nico8583]

Thanks for your feedback. For Pacific Rim, do you try allways with 2 inputs file (AVC and MVC) or have you tried with a Combined created by MVCCombine.exe (Neisklar) ?

[allanlee]

Thanks for your feedback. For Pacific Rim, do you try allways with 2 inputs file (AVC and MVC) or have you tried with a Combined created by MVCCombine.exe (Neisklar) ?

Tested just now - DGMVCSource/FrimSource/MVCSource give same output as separated avc & mvc stream input, when using the combined stream created by either MVCCombine.exe (Neisklar) or DGMVCCombine (102).

The sample_decode.exe from ssifSource4.1 accepts only combined stream, both combined streams mentioned above can be decoded without problem.

[Nico8583]

So I don't know where could be the problem :confused:

[r0lZ]

It's relatively simple. The Source filters that fail are all using demuxed files (with tsMuxeR or eac3to), combined with a variant of MVCCombine. ssifsource4 doesn't fail, and it demuxes with the MpegSplitter_mod.ax filter, and it combines the video streams with its own combiner. So, the problem is either in the demux by tsMuxeR or eac3to, or in the MVCCombine method. To determine more precisely the origin of the problem, we need a tool to demux the video streams to files using the MPEGSplitter filter, or a new MVCCombine.exe using the code currently used by ssifsource4.

[Guest]

we need a tool to demux the video streams to files using the MPEGSplitter filter, or a new MVCCombine.exe using the code currently used by ssifsource4. Is the ssifsource source code available?

[r0lZ]

Currently, no. But I'm sure slavanap can share it, or at least help you.
BTW, ssifsource4 (w/o the source) is available here (http://forum.doom9.org/showthread.php?p=1667073#post1667073).

[allanlee]

It's relatively simple. The Source filters that fail are all using demuxed files (with tsMuxeR or eac3to), combined with a variant of MVCCombine. ssifsource4 doesn't fail, and it demuxes with the MpegSplitter_mod.ax filter, and it combines the video streams with its own combiner. So, the problem is either in the demux by tsMuxeR or eac3to, or in the MVCCombine method. To determine more precisely the origin of the problem, we need a tool to demux the video streams to files using the MPEGSplitter filter, or a new MVCCombine.exe using the code currently used by ssifsource4.

I suppose that the MVCCombine.exe ssifSource4.1 uses is an old version of Neisklar's work, somewhere after here (http://forum.doom9.org/showthread.php?p=1599681#post1599681), here (http://forum.doom9.org/showthread.php?p=1600201#post1600201) and before here (http://forum.doom9.org/showthread.php?p=1628058#post1628058). (Running through that HUGE thread is really big work....)
It's a 0.2 version, even before implanting the pipe support.

Tried again to feed the combined stream produced by the MVCCombine.exe (0.2, used by ssifSource4.1) to DGMVC/Frim, still bad frames.

-- Can I have a conclusion that:
(1)at least until the combined streams are "no errors", and
(2)because when DGMVC/Frim and ssifSource4.1 using identical Intel dll, identical combined avc+mvc stream, but produce different decoded frames, there likely to be problems in how the combined stream handled to the dll (decode lib), or how the decoded YUV frames fetched back from it
?

:confused:

[Thalyn]

It's relatively simple. The Source filters that fail are all using demuxed files (with tsMuxeR or eac3to), combined with a variant of MVCCombine. ssifsource4 doesn't fail, and it demuxes with the MpegSplitter_mod.ax filter, and it combines the video streams with its own combiner. So, the problem is either in the demux by tsMuxeR or eac3to, or in the MVCCombine method. To determine more precisely the origin of the problem, we need a tool to demux the video streams to files using the MPEGSplitter filter, or a new MVCCombine.exe using the code currently used by ssifsource4.

Just to check this, using the streams I previously uploaded (Pac1 specifically), I tried loading them into a .ts so SSIFSource4.1 can get at them. This means it's already gone through all of the demuxing and what have you, so the only differences will be the way SSIFSource calls the decoder or the way it merges the streams internally.

Previewing with VirtualDub gave the same basic problem as experienced with DGMVC and FRIM. It didn't appear identical but it was in the same place, and it was actually followed by a brief second error. It was accompanied in the debug windows with the following:
Frame 121 written (100.00%) - 0:00:10 - 0:00:00
will terminate: \\.\pipe\bluray29730\dept_merge.h264
AnnexBReader-Thread ended: \\.\pipe\bluray29730\dept_merge.h264
will terminate: \\.\pipe\bluray29730\base_merge.h264
AnnexBReader-Thread ended: \\.\pipe\bluray29730\base_merge.h264

Decoding just the AVC stream doesn't give the extra "hic-up" using SSIFSource - just the one experienced when using DGMVC or FRIM. To me this suggests the extra glitch is the fault of the combiner in this case.

If you ask me, this just makes things worse, though. It suggests even more that the method of extraction is causing the problem, but that doesn't explain why the AVC stream can be decoded so easily and correctly with non-Intel libraries.

It does, however, suggest that simply using this alternative stream-reading tool (which I'm taken to believe is from MPC-HC and open source) could alleviate the problem entirely, whether it's as a separate demuxer or as part of the source plugin.