CARVIEW |
Navigation Menu
-
-
Notifications
You must be signed in to change notification settings - Fork 56.2k
G-API: Basic frame drop functionality #19731
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
Conversation
6a0af23
to
b2c8950
Compare
BTW, python tests with OpenVINO are failed/crashed due to this issue: #19719 |
b2c8950
to
48b0a07
Compare
371a580
to
b180d8d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks quite good!
} | ||
// Iterate through all input queues, pop GRunArg's and compare timestamps. | ||
// Continue pulling from queues whose timestamps is smaller. | ||
// Finish when all timestamps are equal. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the equality strict or in some range? Is it configurable at this point? Is it open to become configurable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently equality is strict, it can be relaxed if needed. And yes, we can give a user possibility to customize it. But what to customize is questionable, it can be just some range for timestamps to be considered synchronized, or maybe it should be some interface which gives the ability to manually interact with the queues to implement more sophisticated synchronization logic. I think it's better to do it separately when we'll better know supposed use cases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it won't work for the case with two USB cameras (at the prototype stage). There is no guarantee frames will have equal timestamps..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please align with @OrestChura on his stereo tool PoC
std::vector<ade::NodeHandle> m_synchronized_emitters; | ||
std::vector<stream::SyncQueue> m_sync_queues; | ||
|
||
std::vector<stream::Q*> newSyncQueue() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why does it return a vector of a single element?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was done this way to conform with reader_queues
signature and not to compilicate outQueues() call with std::vector<Q*> creation
b180d8d
to
716bdd5
Compare
@dmatveev @smirnov-alexey updated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please proceed with the merge
Summary
This PR brings
cv::gapi::streaming::sync_policy
enum which allows to control input streaming sources synchronization when passed as compile arg. Currently possible values aredont_sync
anddrop
. Ifdont_sync
or nothing is passed, framework will behave as previously. Ifdrop
is passed, framework will run the whole graph only on inputs which timestamps are equal, dropping all inappropriate frames. Need to note that const (non-video) sources are not taken into account when comparing timestamps since their output is always the same.Changes overview
For each input our streaming executor creates an
Emitter
which is responsible for pulling data from the source. There is 1:1 correspondence between emitters and GComputation inputs. For const sourcesConstEmitter
-s are created, for video sources -VideoEmitter
-s. For each emitter framework creates a thread which simply pulls data from the according source and pushes this data further to all its readers (islands). There are queues placed between emitters and their readers to maintain pipelining, so emitter simply pushes to according queues while islands are popping from these queues.To add input timestamp synchronization to this picture a new
Synchronizer
entity was introduced. If synchronization is required, it adds additional layer of queues between emitters which need to be synchronized and their readers. A synchronization thread is created to pull data from emitter queues and compare their timestamps, dropping some data till it gets all input data from all emitters having the same timestamp value. After that this synchronized data is pushed further to the islands and the actual calculations are launched.Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
Patch to opencv_extra has the same branch name.
Build configuration