-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pylonsrc: handle corupt frames #32
pylonsrc: handle corupt frames #32
Conversation
New property FAILRATE [0..100] default 10 failed frames before giving up and quitting. Counter reset after each good frame.
Useful when trying to understand bandwith related issues on the Basler cameras.
…ameras and limited bandwidth situations.
…ependent, and must be adjusted accordingly. See Pylon manuals, and PylonViewer, to understand these relations.
Sorry @AB-Eskild , I somehow missed this PR. I just tested it out, and it does seem to help. I know packetsize needs to be adjusted at least to accommodate hardware that doesn't support jumbo packets, and failrate is set to how much you can tolerate dropped/corrupted frames. grabtimeout I suppose could be for cameras that are slower to generate their first frame. The other properties I'm not sure how they might need to be adjusted. It looks like interpacketdelay and frametransdelay can be adjusted according to the application note from Basler titled Controlling packet transmission timing with delays. Before merging, I'd like to prefix the commit messages with "pylonsrc: " as other commits have shown. If you're still interested in this PR, maybe you can rebase to fix them and maybe squash the bugfix commits. If not, I'll try and do this soon. |
I've applied some of the ideas from this PR in my corrupt-patch branch. As I really need high FPS and stable stream on GigE camera. |
I've rebased this branch on top of my changes, as @AB-Eskild does not respond and there are many merge conflicts. I'll open a new PR after my current one is merged |
Closing this, as this has been included in #51, thanks @AB-Eskild |
This should help solve issue #14 handling corrupt frames.
I found that many errors occurred because the transport layer not being able to keep up with the frame-rate and packet size required for the application. This can also be seen when connecting through the PylonViewer that comes with the Pylon SDK.
The parameters added helps with optimizing the bandwidth usage. And creates some tolerance for error messages related to incomplete packages.