[AVStream] Capture filter stream timeout

NTDEV
1

We have a capture filter with one video output pin that produces 60 frames per second HD resolution. It is connected to the input pin of a processing filter. Our allocator requirement is 16 frames. We have verified that these 16 frames are granted by the graph.

Sometimes the processing filter is slower than the incoming frame rate. When all buffers are consumed, we drop incoming frames.

When the incoming stream stops, we detect a timeout at the capture filter.
When at this point, there are e.g. 10 frames still “in flight”, who/what pushes these frames through the processing filter ? In other words, when we stop producing frames, will we get back empty frames after the timeout ( in our Process callback) ? Or is the graph allocator advanced only when we start producing new frames ?

Thanks in advance for any help !

  • Bernard Willaert
    Barco - Healthcare division
    Belgium
2

xxxxx@barco.com wrote:

We have a capture filter with one video output pin that produces 60 frames per second HD resolution. It is connected to the input pin of a processing filter. Our allocator requirement is 16 frames. We have verified that these 16 frames are granted by the graph.

Sometimes the processing filter is slower than the incoming frame rate. When all buffers are consumed, we drop incoming frames.

When the incoming stream stops, we detect a timeout at the capture filter.
When at this point, there are e.g. 10 frames still “in flight”, who/what pushes these frames through the processing filter ? In other words, when we stop producing frames, will we get back empty frames after the timeout ( in our Process callback) ? Or is the graph allocator advanced only when we start producing new frames ?

When the consumer is finished with a frame, the frame returns to the
“available” pool, and the framework will call your Process callback
again. It doesn’t matter whether you’re pushing anything.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Thanks, Tim!
This is exactly the behaviour we expected.

In the mean time, we tracked down the problem to a DMA engine inside our FPGA.

Thanks again !

  • Bernard Willaert