I went back and checked the MSDK 3.0 Beta 4 Dshow filters, and found that I could connect the smart and infinite T filters to the h264 encoder filters without problem. Can you make sure the filters that are being loaded are the ones you are expecting?
Regarding whats happening with your encode, I am not sure I have enough information to make a guess. Can you explain, or share your source filter and the clip its outputting? Is it a push or pull filter? This usage model has been used over and over, so Id like focus in on the source filter first. A bit more information will help me get you up and running.
It sounds like the async filter doesnt recognize the file format. Can you explain what you are trying to do with the graph? The first message didnt contain the decoder filter and now it does. Perhaps theres a better way to do it?
Regarding the Infinite T filter. We have ran across the problem before. We found that when we construct this graph: Camera->MJPEG Decompressor->Infinite T -> Encoder -> etc the Infinite T filter does not pass the MJPEG Decompressors allocator requests through to the encoder. It sends 1 instead. I suspect the same thing happening in your case. We were able to use the T filter if we just removed the : if(nMin > (mfxU32)props.cBuffers) check and just return S_OK. Not very elegant, I know. But since we dont have access to that filters source code, it was the best we could do. We tested that graph quite a bit and didnt run across any problems with allocations. Try it, and test.
You have a good weekend as well!
Great. Seems like you are making progress. Thats good. However, 20% seems a bit high if the GPU was active. So, can you take a look at the CBaseEncoder::SetAcceleration() and see what impl is being returned? For the sake of completeness what is the version as well?
The HW lib is loaded by the MSDK dispatcher. The algorithm it uses to find the right implementation is documented in the mediasdk-distrib file in the \doc folder. The HW lib is only installed by the graphics driver it is not part of the MediaSDK download. If you havent done so, Id recommend updating your driver first.. then set about troubleshooting.
Ill code something up to simulate your graph building problem tonight, but in the meantime..
So we know this works fine in graphedit Ive checked it again today to ensure I didnt miss anything. So, question - when constructing the graph in code are you setting the filename the filewriter filter needs to output too? I noticed you need to QueryInterface the ISinkFilter->SetFilename method. Seems like this could cause an exception if it was overlooked. Can you confirm?
Have you compared your code against the MSDK sample "DShowPlayer"? This sample builds a graph programmatically - and connects the muxer to the filewriter when the user transcodes a file.Its running w/o issues.