1

Our application writes uncompressed video frames to an avi file. In case of not sufficiant performance frames are dropped (probably by the Avi Muxer). This cant be fixed of course. But our problem is that we didnt found a way to inform the user about that. We measure the frame rate we send to the Avi Muxer and this is correct. But we can see with unsufficiant writing performance there are lost frames in the writen avi file. Does somebody know how to measure the number of writen frames to the avi file?

I found a related question here, but this didn't give me an answer.

Matthias
  • 37
  • 8

2 Answers2

1

Frames are dropped because write of uncompressed video takes too much time and this eventually blocks the pipeline so that video capture filter has its capture delayed and the capture filter has to drop while capturing.

So you can possibly check your video capture filter with IAMDroppedFrames and find out the drop stats as the capture goes.

Next, you can check time stamps of video frames before the AVI Mux and interpret unusual time gaps a dropped frames. This can be done in any custom filter you already have in the pipeline, and if you don't have any then you can add a Sample Grabber instance just to have an eye on the streamed content.

And finally once your file is created and finalizes you can read the video track back and again compare frame times against the frame rate. Once you see a bigger distance between frames than the expected frame time, you can convert that into the number of dropped frames.

Roman R.
  • 68,205
  • 6
  • 94
  • 158
  • If you suggest I should look for time gaps, could this mean: I have all frames processed but a jittering in the delivery could cause the muxer to drop frames? I guess this case could not be detected by the IAMDroppedFrames interface of the push source filter. – Matthias Jun 25 '18 at 12:58
  • AVI file format has fixed frame rate, jittering is eventually ignored. A valid source filter is expected to have gaps in produced frames. If you have a custom push source then you might need to profile it. It might have no `IAMDroppedFrames` and its time stamping behavior might, in worst case, ignore concept of dropping completely. – Roman R. Jun 25 '18 at 14:41
  • Yes your right. The custom source filter do not expose IAMDroppedFrames. But I logged the timestamps between the source and the muxer. With a framerate of 1kHz every was fine (from any frame to the next a difference of 10000 units). With a frame rate of 80Hz (should have 125000 units) it alters between 60000, 100000 and 160000 (longtime everage was a bit below 125000). This is what I mean with jittering.The Muxer/Writer seems to have no problem with it. But I dont know what will happen on a slow hardware. Do you not what is the limit when the muxer begins to drop frames. – Matthias Jun 25 '18 at 15:47
  • Slow/insufficient disk performance eventually affects your push source and slows down its ability to deliver frames. Multiplexer, at least this simple one, does not drop the frames because of performance, it only checks assigned frame time stamps. – Roman R. Jun 25 '18 at 16:24
0

If you are saving to a standard hard drive, consider saving to a SSD instead, as it is much faster this may prevent dropping frames.

If too much space is required, eventually use the SSD a temporary drive, then once the recording is completed, move the .avi file to a hard drive in the background.

user9689647
  • 1
  • 1
  • Thanks for your suggestion. This really makes sense. Unfortunately it is out ouf our control. The software is installed as a standard software on many customer computers worldwide. Somtimes it is installed on very small computers at the edge of the reasonability. The goal is to inform the user if the recording jams. – Matthias Jun 25 '18 at 15:27