Modify ↓
Opened 9 years ago
Last modified 9 years ago
#247 new defect
IPECamera adds 16 bytes before the header
Reported by: | Suren A. Chilingaryan | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | UFO Camera | Version: | |
Keywords: | Cc: | Matthias Balzer, Michele Caselle, Matthias Vogelgesang |
Description
When starting the grabbing process, sometimes before first frame magic there are extra 16 bytes of padding. Just an example:
00000000 00 00 00 00 │ 00 00 00 00 │ 00 00 00 00 │ EF BE AD DE 00000010 11 11 11 51 │ 22 22 22 52 │ 33 33 33 53 │ 44 44 44 54 00000020 55 55 55 55 │ 40 04 00 50 │ D8 7E 00 55 │ 09 0B 90 50
This results that every so often the 32-byte header is split between 2 DMA packets. With ipecamera r267 I have implemented a workaround and it is of no consequences so far.
However, if we have to use GPUDirect/DirectGMA technologies, this will become an issue. GPU architecture is only optimal for processing of large volumes with static layout. All preprocessing steps to find where the packet actually begins, etc. will kill the performance.
Attachments (0)
Change History (2)
comment:1 Changed 9 years ago by
Summary: | IPECamera adds pads 16 bytes before the header → IPECamera adds 16 bytes before the header |
---|
comment:2 Changed 9 years ago by
Note: See
TracTickets for help on using
tickets.
It seems to be triggered by switching between manual and auto triggering modes. Using the following strategy it seems pretty persistent:
Switching stream and single produces the problem as well.