We presently use the IPP library to decode mpeg2 and h264 videos at HD and 4k resolutions. We recently tried the sample_decode.exe application from the Media SDK, but it is failing on a large fraction of our test mpeg2 and h264 videos, all of which decode fine with IPP.
An archive of the test videos is here: https://www.dropbox.com/s/q0yc2vl42rgmi1z/VideoTesting.zip
We are using the decoder with settings such as sample_decode.exe mpeg2 -r -i Vote.mpg (or h264 for the h264 files.)
All of the files in the archive fail to decode properly with sample_decode from the Media SDK but work fine with IPP.
Is there a setting in the Media SDK that the we or the sample decoder program is not setting correctly for these file formats? It seems curious that a newer product would fail on a number of files that the previous library works fine with.
We're on Windows 7/64 bit, VC2010.
Thanks for setting up the dropbox with the sample videos. It looks like what's happening is you're running sample_decode with container files. While Media SDK is starting to support processing container formats now, the encode, decode, and transcode samples expect elementary stream input. I was able to verify that Media SDK can decode the elementary streams in the files you sent without issue. (In some cases the elementary streams themselves are corrupted, but this does not appear to be the case here.) However, before running sample_decode I demuxed with YAMB first to extract the elementary streams.
Great to know why the files were not working. The new behavior is, however, a regression from the IPP library, which is able to play all of these files without external modification. Using a third party tool to process each MPEG file before decoding is not a workable solution for us.
Is there an ETA for when these files will 'just work' out of the box with the Intel Media SDK?
>> Using a third party tool to process each MPEG file before decoding is not a workable solution for us.
Rather than using any third party tool, I think you can workout for a solution by combining the demuxer/splitter library from IPP and then decoder from IMSDK, till the time IMSDK also starts providing the demuxing functionality.
I guess there is no issue in combining the IPP and IMSDK libraries together.
For one of our need, we have also used this mixed approach and it is working fine.
Hello Ramashankar and Jeff,
If we have to use the IPP library to do demuxing/splitting, why would we use the Media SDK for decode? Does it provide performance improvements over the IPP decoders, or handle decode on Xeons better, or what? We're using Xeon E5-2660s in our application to decode MPEG2 and h.264.
You don't have to mix IPP and Media SDK for container support. Media SDK has recently added this capability. For an example of the Media SDK approach please see the full transcode sample at the Media Solutions Portal. You can also integrate with other frameworks as illustrated by the ffmpeg integration example in the Media SDK Tutorials.
Of course it is up to you if you prefer IPP for decode, but here are some advantages of Media SDK:
* IPP UMC was always only a sample. Media SDK is fully productized.
* IPP is CPU only. Media SDK provides access to hardware acceleration. This means performance and power advantages.
* IPP UMC is end of life. All codec-related new development will be in Media SDK.
I downloaded and compiled the full transcode sample under VS2010 without any errors in Release x64 mode on Win7/64.
I then tried transcoding the various files in my test set with the command
sample_full_transcode.exe -i h264\Short4K.mp4 -o out.mp4 (example)
This fails with [ERROR] MFXVideoENCODE::Query, sts=-3
main.cpp :58 [ERROR] Exiting...
I tried the same thing with most of the other files in the examples that I uploaded, with errors of either -3 or -15. In the code, this corresponded to either 'Unsupported' or 'Invalid video param', but the full transcode example should be able to handle these mpeg2 and h264 container files.
Does this reproduce on your side? If so, is there something I'm doing wrong with my input parameters, or is there an ETA for when these files will be playable with the Intel Media SDK?
There is more info on command line parameters in readme-full-transcode.rtf. I'm able to run with your inputs with a command line like this:
./sample_full_transcode.exe -i in.mp4 -v:b 2000 -a:b 128 -o out.m2ts -hw
There are still a few audio issues I'm looking into but hopefully this will help get you started.