my YUY2 output does not work with Video Renderer filter

0
votes

I have a basic avstream driver (based on the avshws sample).

When testing the YUY2 output I get different results based on which renderer I use:

  • Video Renderer: blank image
  • VMR-7: scrambled image (due to the renderer using a buffer with a larger stride)
  • VMR-9: perfect render

I dont know why the basic video renderer (used by amcap) wont work. I have examined the graph of a webcam outputting the same format and I cannot see any difference apart from the renderer output.

2
directshow
Perhaps bad-formed media type. You have not posted relevant details. - Roman R.
Can you elaborate please? - djp
By "You have not posted relevant details." I mean that you should add to the post what you have found during your graph examination: "same format" and "any difference" in particular. Otherwise you ask us to shoot in the dark. - Roman R.
Unmodified avshws code works with YUY2 and Video Renderer. It stopped working after I removed the scatter/gather and DMA stuff. I changed it so that the pin process dispatch just returns STATUS_PENDING, and when the fake hardware timer fires it fills out a pending video buffer and restarts processing (KsPinGetLeadingEdgeStreamPointer, copy memory, KsStreamPointerUnlock(eject=true), KsPinAttemptProcessing). This works in RGB24 mode but not YUY2... - djp

2 Answers

1
votes

I'm assuming you're writing your own filter based on avshws. I'm not familiar with this particular sample but generally you need to ensure two things:

  • Make sure your filter checks any media types proposed are acceptable. In the DirectShow baseclasses the video renderer calls the output pin IPin::QueryAccept which calls whichever base class member you're using e.g. CBasePin.CheckMediaType or CTransformFilter.CheckTransform
  • Make sure you call IMediaSample::GetMediaType on every output sample and respond appropriately e.g. calling CTransformFilter.SetMediaType and changing the format/stride of your output. It's too late to negotiate at this point - you've accepted the change already and if you really can't continue you have to abort streaming, return an error HRESULT and notify EC_ERRORABORT or EC_ERRORABORTEX. Unless it's buggy the downstream filter should have called your output pin's QueryAccept and received S_OK before it sends a sample with a media type change attached (I've seen occasional filters that add duplicate media types to the first sample without asking).

See Handling Format Changes from the Video Renderer

0
votes

I have figured out the problem. I was missing one line to update the remaining bytes in the stream pointer structure:

Leading->OffsetOut.Remaining = 0;

This caused certain filters to drop my samples (AVI/MJPEG Decompressor, Dump) which meant that certain graph configurations would simply not render anything.