sipsorcery | VoIP library for C # and .NET | Video Utils library

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.

I needed to manually wire up a colour conversion MFT (I'm pretty sure some Media Foundation scenarios wire it in automatically but probably only when using a topology) AND adjust the clock set on the Direct3D IMFSample provided to the EVR.

Working example.