try_pop_buffer sometimes return (broken) frames for which get_system_timestamp goes “back in time”

[Ekleog]

Describe the bug When not popping buffers for a while (more than aravis could buffer with its buffer queue), then resuming popping, aravis appears to return:

• A few frames that had been correctly put in the buffer queue before the pause are output
• Then some frames (more than the number of buffers in aravis' queue) that show significant black stripes (note: we reset buffers to black before giving them back to aravis) and also have system timestamps that are before the few frames from the above bullet point (the same system timestamp as the one of the first frame of the above bullet point to be precise)
• Then it starts streaming from the camera again, as one would expect

The weird thing being these few frames with significant black portions that go “back in time”

To Reproduce

• Start streaming (from a TIS GigE camera, but as it's with system timestamps, I'd guess it's camera-agnostic)
• Pop frames for 30 seconds
• Do not pop frames for 5 minutes
• Start popping frames again
• Observe the timestamps before and after the “do not pop frames” step, and see that they match the description above

Expected behavior The back-to-the-past frames should not be returned, and no frame should be claimed as available instead — a workaround for now is to check the system timestamp and ignore frames that go back in time and call try_pop_buffer again (workaround which appears to also avoid the frames with significant black regions).

Camera description: TIS GigE camera

Platform description:

• Aravis 0.7.5pre2, on commit b537efc2e86b4d2adf134bc135ebff5560a4a444 (via the aravis rust crate on crates.io)
• OS: NixOS
• Hardware x86_64

Additional context Please tell me if there is anything more I could do to help debug this!

As usual, thank you for this great piece of software :)

[EmmanuelP]

Hi Léo,

Thanks for the report.

Does your code check for ArvBuffer status ? If the status is not ARV_BUFFER_STATUS_OK, the buffer should not be used, only put back to the buffer queue.

It would really help if you could provide a sample test code that exhibits your issue.

Does this behaviour also show using a USB device ?

[Ekleog]

Yes, I do check for ArvBuffer status, but I probably get back ARV_BUFFER_MISSING_PACKETS, as literally all frames I receive from the camera are tagged “missing packets” (despite the fact that, even with this reset-to-black, the frames show up perfectly well) — that is another issue I was thinking of investigating, but this one I'd guess probably would be due to the camera, hence my not reporting it here yet.

I'll try to make a minimal test code that shows the issue! though unfortunately i don't have any USB device on hand and so couldn't check with that.

[Ekleog]

On latest master, it looks like this no longer happens, but instead I now (I think, haven't cleaned up the code yet) get one timeout buffer and then the stream connection is lost. I'm not sure whether I should keep this issue open for this other issue, or close it, open a new one and attempt to find a reproducer for this other issue?