You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Change the way pipeline TX handles the order of framebuffers. Track
per-frame sequence numbers so transport can dequeue the newest converted
frame instead of always taking the next one, needed as otherwise
we cannot drop frames, as they will not be in order.
(This also makes it easier for multi threaded applications to use
the api should improve performance with multiple threads from the api
only).
Add a new flag to the TX pipeline to enable droping frames when we jump
over epoch. Mostly will aid with user control pacing.
Implemented in a way that only drops one frame in a scenario where late
is detected. This creates limitation for extreamly high drops The stream
will still not adjust immidiately instead doing
send frame | drop frame | send frame | drop frame ...
until we catch up.
(Done mostly as big jumps over more than 2 frames could be undesirable
and if you have that big of a drop ... well this is the least of your
troubles).
Due to lack of consumer and producer print stats of the queue via
reporting the framebuffers statuses (removed the ACCURATE_FRAMEBUFF) as
it became redundant.
Reverts: 772621d
All above done in pipeline as the purpose of the api pipeline is to
smoothe the library tight timing requirements from the user
applications.
Fix the st20p wrong user timestamp reporting in frames snapped to
the next frame.
if times given by the application looks as follows
----|--frame-1--|--frame-2--|--frame-3--|--frame-4--|-...
epoch-1--|--epoch-2--|--epoch-3--|--epoch-4--|...
This causes frames to snap to the next epoch, resulting in incorrect
timestamp reporting where every frame appears to have a "wrong user
timestamp" due to the forward snapping behavior.
Fixes: 88c3566
Fix the usdt for st40p tx (only to add the spurn event).
Fixes: 921fa0d
0 commit comments