-
Notifications
You must be signed in to change notification settings - Fork 53
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
Python integration with sender and receiver pipeline #363
Comments
Alternatively, would it be better to provide a filesink mechanism, like Gstreamer, to write the frames on disk? |
hi @himansingh, there is multiple options how to achieve this – basically you'd need to use some of auxiliary displays, eg.: a. unix_sock – output will be written as RGB to specified UNIX socket, from which it can be read with the Python Personally, I'd suggest either a or c. a is quite straightforward, for c you'd perhaps want to use something like:
Then it would dump raw RGB files to /tmp/dir (00000001.rgb and on) which you can directly process (and you'd perhaps also like to delete processed files). |
@MartinPulec Thank you for the quick response. I did try the The |
The suggested commands were running smoothly until now. My team just noticed a random change in the index of the file at the start of the receiver command. System Information Description Sender Command: Receiver Command: Expected Behaviour Observation Steps to replicate:
This is a random behaviour so it's very difficult to replicate. We have observed this just a couple of times out of hundreds of runs. |
Thanks for reporting, we've looked through the code and I believe that the frame with the index 1 will be always output if there is the input. Can I ask what is the first index value? Is it some small number or anything entirely random? Is the sequence continuous? The incorrect directory listing would be ideal. Also UG might be useful for debugging.
Thanks, but I'd need more about the steps, namely steps 1.-4. Is there some specific reason why those are needed? The thing is that if you remove the dump directory before step 6, the behavior should not be affected by the steps 1.-4. It it would, it implies that there is some insane state, probably on filesystem (eventually network state, eg. NAT |
PS: (for the record) I've tested with following script and I didn't manage (yet) to reproduce the problem: script.sh (can be split to sender and receiver if needed)
But of course, it doesn't emulate much timing issues, if there is some race-condition. Important: If you intend to use the script, make sure to download recent UltraGrid, because when the AppImage was run in background, killing the AppImage left the UG processes running! Also be very cautious, because the script uses rm etc. |
Hello everyone, thank you for this great product.
I am trying to utilize UltraGrid to send and receive video frames from a USB camera using a Python script with minimum latency.
Machine1 (Edge Device):
Connected to a USB camera -> UltraGrid sender streams the camera feed
Machine2 (Placed in a server room and is part of an on-premise cluster):
Receives the feed -> processes individual frames in python using opencv
Any help in integrating UltraGrid with python opencv would be very much appreciated.
The text was updated successfully, but these errors were encountered: