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

Web streaming multithread example #375

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@BigNerd95

BigNerd95 commented Feb 14, 2017

Added a new example.
Web streaming multithread server with producer and consumer method, so
each client is independent from the speed of the other ones.

With the monothread web_streaming.py example, if there is more than one client connected, and one of these is slower than other ones, all the clients will be slowed down to its speed.

With multithread and producer/consumer method, this problem is solved.

Web streaming multithread example
Added a new example.
Web streaming multithread server with producer and consumer method, so
each client is independent from the speed of the other ones.
@waveform80

This comment has been minimized.

Owner

waveform80 commented Feb 25, 2017

I take the point that the current (deliberately simple) example could be improved, but I'm afraid I can't accept the PR as it is:

  • The authentication stuff is nice to have in a full blown script, but this is meant to be a minimal example for the camera docs. This sort of thing might be added to a more extensive demo (like pistreaming), but it really doesn't belong in the docs which are trying to demonstrate a single thing (web-streaming) without unnecessary adornments.
  • Same thing for the '/info' output; nice to have, but unnecessary in a minimal example
  • Same thing for the '/screen.jpeg' handler
  • No need for the close_connection=False line in the request handler given that the threaded handler sticks around serving subsequent frames
  • Ignoring all exceptions in the main block of the program is not something I'd want to encourage! That said I should add some logging into the catch-all exception handler in the request handler (it's acceptable to ignore exceptions on client disconnect but they should still be reported somehow)
  • A few cases of PEP-8 violations (isAuth, notifyAll, etc.)

So, the suggestion overall is worthwhile but as I'm planning on getting 1.13 out today, rather than go back and forth with a PR, I'll tweak the recipe to include the threading bits from this. Sorry I couldn't accept it as is, but many thanks for the PR anyway!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment