Stream incompatibility w/ API v1.7

[Jon_E_]

As a result of experimentation with AVISynth and the assistance of some very talented people on the Doom9 forums, I've uncovered an incompatibility with the Intel Media API v1.7.  It would seem that part of the movie "Pacific Rim" simply doesn't work with this version, but only if you're using the 3D disc as the source (the 2D disc appears to work just fine).  There are at least two sections where attempting to use the Intel Media API results in frames being corrupted and lost, each and every time you attempt to decode them.

Some examples are available here: https://mega.co.nz/#!co8BzRpL!qXoCWL-vKmFry2RmLe2G1P3oHn0le6NZJ7NnjAMJOck

Note that these have been extracted from the full stream with tools that are not entirely MVC aware, however the AVC stream alone demonstrates the issue.  Included are both source, raw streams (pre-combined AVC/MVC streams) and the results I get when processing them using the Intel Media API to decode.

That said, another programmer on the same forum has inadvertently found the solution: using API v1.8, at least in short tests (I'm confirming this presently with a  more thorough test, but the results of that are several hours away), gives perfect output.  This would be fine as an alternative if not for two fairly important (in my mind) details: v1.8 decoding cannot presently be hardware accelerated, and actually enabling v1.8 requires a very specific command line.  In fact, the only way I've found to get v1.8 to work is to use Software mode ("SW" flag) and either D3D or System surfaces - D3D11 surfaces revert to v1.7 even in SW mode - meaning anything which does not specify these two conditions while having access to "higher" sets will use v1.7 and ultimately produce the errors; and even when these flags are specified I have seen it still fall back to v1.7.

I realise this may not seem urgent as I have only identified one stream presenting the error (out of the 53 I have so far tested), so it is fairly isolated.  A fix has obviously already been implemented in the v1.8 API as well.  However, I still believe that back-porting the fix to v1.7 is a good idea as most, if not all software which currently uses QuickSync decoding still depend heavily on v1.7.

[Jon_E_]

Just a quick update:

A lengthy test, involving the entire movie, resulted in the same errors.  As best I could tell this was using the v1.8 API, so I'm not entirely sure what to make of that.  The short tests, when I was able to get them to use v1.8, worked fine; though I'm now having a great deal of trouble getting them to use v1.8 over v1.7.

For what I hope are fairly obvious reasons I will NOT be uploading the entire stream to test with.

Regardless, this still leaves the v1.7 API as incompatible with this particular source material, and the v1.8 API may or may not be compatible.

Further update:

Yet another user on the same forum has more correctly identified what allowed one source plugin based on the Intel Media SDK to work, but not the others.  Evidently this was not specifically a feature which was added to v1.8 of the API but rather a regression between the 2013 SDK and the 2013 R2 SDK, specifically in the "sample_decode.exe" program.  In other words, using the older executable gave the correct results, while the newer executable did not, while the newer API may or may not have any relevance at all.

Even further update:

Further testing has revealed that it isn't exactly a regression, but there is a regression as well as an incompatibility.  Using the older version of the Sample_Decode.exe eliminates the visible glitching, however several frames (roughly 47 by my estimates) are still absent from the resulting output.  This number of missing frames matches the newer version almost if not exactly but the "edges" are "clean" for lack of better terms.

Correct (CoreAVC-based decoding): https://mega.co.nz/#!w0lWAYwT!GFSGIKUu0-QJl_VIsUwL6wf7AO272rUUbrHHulvcQ30

Incorrect (Intel Media-based decoding): https://mega.co.nz/#!V9FWmAyB!EXRB97SBIbv5O11_3wDX2n5T1-YvhSfwcwfTifIj2AI

(note that the x264 command line varies for the two streams, however this should have no effect at all aside from a slight variation in the output's visual fidelity - not the missing frames.  Sound is provided in these samples to more obviously demonstrate the missing video frames.  The Intel Media stream was decoded using the initial 2013 release in software mode, hence only missing frames and no visible glitching)

I'll be the first to admit that the information I've provided isn't exactly fully comprehensive.  While I used to program DOS applications and still do my share of scripting, I am not familiar with actually using this SDK to produce an end result so I'm only able to comment as a consumer - not as a developer.  I'm hoping that one of, if not all four (4) of the other developers from Doom9 who have provided tools based on this SDK will eventually be able to either chime in here with more information or create a new, more accurate thread on the topic.  I know at least one of them has been collating information but they have other projects they're working on at the moment.

Ultimately all I can do is provide the small demonstrations that I already have and bring the issue to Intel's attention.  Hopefully this is enough to get the proverbial ball rolling on a solution, however.