I am trying to use the IMFSourceResolver::CreateObjectFromByteStream method to create a IMFMediaSource instance for a DRM protected WMA file. I am adapting the ProtectedPlayback sample from the Windows SDK as a playground. The end goal I wish to achieve is to have the playback process fed by a custom implementation if IMFByteStream that I will write.
However, I cannot get either my simple IMFByteStream implementation or the implementations returned by the MFCreateFile function to work. Each returns a HRESULT of MF_E_UNSUPPORTED_BYTESTREAM_TYPE when passed to CreateObjectFromByteStream.
I tested the sample project in its default state (using CreateObjectFromUrl on a file) with a DRM protected WMA file and it worked fine. The file is not corrupt and the license is valid. I don’t understand why substituting this bit of code with CreateObjectFromByteStream( MFCreateFile() ) does not work. I have been able to find little documentation that covers using custom byte streams or what the resolver expects from a byte stream instance.
If anybody has any experience with this stuff or any idea what I am doing wrong, some pointers would be appreciated.
The code I am using is here:
IMFByteStream* stream = NULL;
HRESULT hr2 = MFCreateFile(
MF_ACCESSMODE_READ,
MF_OPENMODE_FAIL_IF_NOT_EXIST,
MF_FILEFLAGS_NONE,
L"C:\\IFB.wma",
&stream);
CHECK_HR(hr = pSourceResolver->CreateObjectFromByteStream(
stream,
NULL,
MF_RESOLUTION_MEDIASOURCE,
NULL,
&ObjectType,
&pSource));
I’ve not included the whole thing because its basically the same as the sample, I’ve only changed this part.
Thanks,
Steve
@pisomojado
Thanks for the response, I totally forgot I had posted this question.
The problem was, if I remember correctly, that CreateObjectFromByteStream needs a way to identify the content type. You can either do this by passing in a URL as well as the byte stream instance (pwszURL parameter) or by making the byte stream class implement IMFAttributes and handle the call to GetAllocatedString that asks for the content type. Since I was doing neither of these things, the resolver was just rejecting the stream.
I would have thought that the resolver would attempt to recognize the stream content type via the first few bytes like you suggested in your answer, but for me it did not appear to do so. Not sure why this is, but nevermind.
Steve