Streaming Video Slow over the network
hunglv213 opened this issue · 6 comments
HI author,
Thank you for your great work !.
I've tested the PUB/SUB with threading machanism. The publisher sends a lot of frames. However, the receiver shows the returned images extremely slow.
I have no issues with deploying local. Everything run smoothly. But when I expose the port globally which can be accessed via Internet, I encounted that problem.
Hi @hunglv213,
Thanks for reporting this. Could you perhaps post a few more details? What OS, what version of pyzmq, what version of Python? A number of users have had issues with PUB/SUB and someone may have suggestions.
Thanks,
Jeff
Thank you for your quick response.
I've tested in this environment:
- Python 3.7
- PyZMQ: 19.0.1
- Ubuntu: 18.04
- ImageZMQ: 1.1.1
I only test with 1 sender and 1 receiver. The difference scenarios are hostnames.
I've described in this repo to replicate the problems. Could you please check it out. https://github.com/leviethung2103/imagezmq_replicate
I would like to receive for suggestions for further development.
Thank you,
Hung
Hi @leviethung2103,
Thanks for the detailed info and for providing your test repository.
I went to this link to see your repo: https://github.com/leviethung2103/imagezmq_replicate .
I looked at your updated example programs: pub_sub_receive.py and pub_sub_broadcast.py. I can see the places you changed the addresses.
Everything in your example programs looks OK to me when I read the code. I was not able to actually run your code because I don't have an outside-my-local-network internet address to test it with.
It is possible this is related to your DNS / IP address provider; they may have a speed limit on some of their accounts. Or they may be buffering or caching or trying to fill buffers up to fixed block sizes. I don't know anything about your DNS provider and I can't tell from their website if they have a restricted firewall or port forwarding speed limits. Perhaps their customer service / support can help?
I'm sorry, but I don't have any suggestions for other things to try. I am going to leave this issue open in case someone else has some suggestions.
If you do solve this, I would appreciate you providing an update in this thread so others can learn from it.
Thanks,
Jeff
Thank you for your enthusiastic support. I think there is a bottle neck at my network or may be the framework is currently not supporting well for my case.
I will wait for anyone has a same problem like me and have a better solution.
Thank you @jeffbass so much again.
Hi Guys, thanks for reporting the issue and keeping it open. I have just noticed a possibly strange behaviour, which I am trying to resolve for a few days now without a success.
I guess my main question is this: Is it realistic to expect the stream using imagezmq to run at 30 FPS between Pi (POE) and a powerful desktop PC in a local network (ethernet with a modern switch)?
I think that I was able to do that from September last year until March 2020 for the data collection from my Pi, but now after getting a new broadband (much faster!) I am only getting a few FPS on Pi. Here is my script:
https://github.com/Alchemication/iot-vstream-client/blob/master/client.py
I am using Buster and Python 3.5 on Pi, jpg compression set to 90, all up to date from apt-get POV, and I need a 720p quality stream to render it to the user (my wife;) )
The question is this: Am I going crazy and I was never able to run this pipeline so fast before, or is this pipeline capable to operate at 30 FPS speed between R-Pi and a PC and I need to investigate my network deeper??
Thanks!
Hi @Alchemication,
The short answer is I don't think 30FPS continuous sending is possible at 720p quality. Even on wired ethernet. But it depends on what the receiver is doing as well as the sender. I looked at your script and it looks correct for sending images with no slowdowns.
I use 640x480 as the highest resolution in my projects. I can get 16 FPS and sometimes higher framerates on WiFi and only somewhat higher on wired ethernet. I use the REQ/REP messaging option. I send images as jpgs because sending OpenCV images was much slower. I use a mix of mostly RPi 3 senders and a few RPi 2 and RPi 4 models. My receivers are fast laptops running imagehub.
I don't need higher resolutions for my projects, but I did some brief testing at higher resolutions like 720p. I rarely got faster continuous throughput than 16FPS at higher resolutions than 640x480. Mostly much slower than that. There is a tradeoff between using jpg compression on RPi (which takes more CPU time) and sending OpenCV images (which takes much more network time). Also, REP/REP (which your script is using) makes FPS dependent on the speed of the receiving program in returning the REP. Slowdowns in your setup may actually be due to a slow speed in your receiver loop. Test your setup with a very simple receiving program that quickly returns the REP (with minimal processing) to see how that affects your FPS. If you try PUB/SUB, It can have speed issues as well, again depending on the speed of the receiver. That is discussed in several places in the imageZMQ docs. But in both REQ/REP and PUB/SUB, continuous FPS will be affected by the frame turnaround speed of the receiver. PUB/SUB will drop frames at higher resolutions while REQ/REP will receive all frames, but at a slower FPS for higher resolutions.
My own projects send brief bursts of images from 8-10 imagenodes at varying times, so I don't have any significant experience with frame rates for continuous image sending.
I would love for someone to post some timing results for higher resolutions when sending continuously. Frame rate FPS would be affected most by resolution, but also affected by jpg compression, REP/REQ vs. PUB/SUB messaging option, network speed, receiving program speed, etc.
Keep in mind that sending individual OpenCV frames will always be much slower than sending video, because video compression algorithms don't send all frames as full frames; some frames are sent as full frames and most frames are just "what changed" from last full frame (I am way oversimplifying, but that is the essence of achieving video transmission speeds).
I don't think ZMQ is slower than other messaging protocols for full frame images, but MQTT might be worth a try. I did some brief testing and found ZMQ (and imageZMQ) the fastest for my own projects.
If you do further FPS testing, it would be great if you posted your timings under various scenarios in this issue.
Thanks,
Jeff