CODEWITHSUNDEEP
visual-c++ms-media-foundation
sipsorcery
sipsorcery

Reputation: 30699

Sample Grabber Sink not setting media type GUID

I'm using the example code from the Sample Grabber Sink reference page except that I'm processing an mp4 file to get both audio and video samples (my sample code). To process the samples in the callback I need to know which ones are audio and which ones are video. The problem is the REFGUID guidMajorMediaType never seems to get set.

Below are the results of printing out the properties of each callback sample. The smaller samples (less than 750 bytes) are audio and the larger ones the video. But the guidMajorMediaType is always empty. Do I perhaps need to set a additional property on the IMFTopologyNode's? I couldn't spot anything obvious.

Sample Grabber test console starting...
Guid = {00000000-0000-0000-0000-000000000000}
Sample: start = 0, duration = 426250, bytes = 682
Guid = {00000000-0000-0000-0000-000000000000}
Sample: start = 0, duration = 416666, bytes = 353280
Guid = {00000000-0000-0000-0000-000000000000}
Sample: start = 416666, duration = 416666, bytes = 353280
Guid = {00000000-0000-0000-0000-000000000000}
Sample: start = 426250, duration = 463750, bytes = 742
Guid = {00000000-0000-0000-0000-000000000000}
Sample: start = 833333, duration = 416666, bytes = 353280
Guid = {00000000-0000-0000-0000-000000000000}
Sample: start = 890000, duration = 465000, bytes = 744
Guid = {00000000-0000-0000-0000-000000000000}
Sample: start = 1250000, duration = 416666, bytes = 353280

Update: Looks like this is could be a Media Foundation bug (at the very least it was re-produced by two independent parties).

Upvotes: 0

Views: 249

Answers (1)

mofo77
mofo77

Reputation: 1515

From Using the Sample Grabber Sink

The Source Reader is an alternative to the Sample Grabber Sink and has a simpler progamming model.

Do you really need Sample Grabber Sink ? Source Reader is the modern way to do. I would say Sample Grabber Sink is deprecated.

If yes :

documentation is not clear : MFCreateSampleGrabberSinkActivate function

Remarks To create the sample grabber sink, call IMFActivate::ActivateObject on the pointer received in the ppIActivate parameter.

In their example, "Using the Sample Grabber Sink", they don't.

Perhaps using IMFMediaSink after ActivateObject on IMFActivate, you will get correct guidMajorMediaType inside OnProcessSample. It's just an optimistic way of looking at this. But I have doubts about this.

This Seems to be a bug. I confirm OnProcessSample passes GUID_NULL for REFGUID guidMajorMediaType. It should not, because all others parameters seems to be valid.

I just think Sample Grabber Sink is deprecated, and you should not use it.

Explain why you really need to use sample grabber sink, when other solutions exists, without bug.

For me "Sample Grabber Sink" is just a sort of DirectShow approach, and now, with MediaSession, Source Reader, tee node, and so on... it no longer has any interest.

EDIT

I want the simplest way to get audio and video samples to a byte * buffer from either a file or device source and ideally be able to include at least one transform (such as the H264 encoder/decoder) in between.

The Source Reader does exactly this. Yes you don't have byte * buffer, you have IMFSample. But with IMFSample, you can get byte * buffer.

But the Source Reader documentation also states "The source reader does not send the data to a destination; it is up to the application to consume the data.

Using the Sample Grabber Sink, it's up to you to consume the data. Same situation.

the source reader can read a video file, but it will not render the video to the screen.

The Sample Grabber Sink will not render the video to the screen. Same situation.

Also, the source reader does not manage a presentation clock, handle timing issues, or synchronize video with audio.

That's a difference, yes, but I don't really see any advantage. See MF_SAMPLEGRABBERSINK_SAMPLE_TIME_OFFSET

Offset between the time stamp on each sample received by the sample grabber, and the time when the sample grabber presents the sample.

Do you know wich offset to apply : extra work. Same situation.

The SampleGrabber returns the audio and video samples in the correct order with the correct timestamps

The source reader also returns the audio and video samples in the correct order with the correct timestamps. Same situation.

Won't that be extra work for the Source Reader case?

No, for me it will be the same extra work in both case.

Also :

Using Source Reader : Source Reader -> your application

Using Sample Grabber Sink : MediaSession (with Sample Grabber Sink) -> your application

In term of performance (cpu/memory/thread usage), I'm pretty sure Source Reader is better than MediaSession.

But it's up to you to choose the Sample Grabber Sink. I will just suggest you to tell to Microsoft there is a bug with REFGUID guidMajorMediaType.

Upvotes: 1

Related Questions