Add server video stream tutorial

[MarcSkovMadsen]

Adds a ServerVideoStream tutorial motivated by questions on discourse. For example in https://discourse.holoviz.org/t/best-practice-for-displaying-high-resolution-camera-images-captured-on-server/4285 and https://discourse.holoviz.org/t/streaming-local-video/6929.

As this tutorial uses manual threading I would also like to fix #6724.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 37.20%. Comparing base (76c911a) to head (9bfd4d9). Report is 30 commits behind head on main.

:exclamation: Current head 9bfd4d9 differs from pull request most recent head 3e65612. Consider uploading reports for the commit 3e65612 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6727      +/-   ##
==========================================
- Coverage   40.01%   37.20%   -2.82%     
==========================================
  Files         313      313              
  Lines       46194    46224      +30     
==========================================
- Hits        18486    17197    -1289     
- Misses      27708    29027    +1319     

Flag	Coverage Δ
ui-tests	37.20% <ø> (-2.82%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[MarcSkovMadsen]

This PR can be reviewed. It can work for users.

But it would be much stronger if https://github.com/holoviz/panel/issues/6724 was first addressed and this PR updated accordingly.

[philippjfr]

this PR updated accordingly.

I'm not sure what you mean by that, are you saying that this guide currently does not use best practices?

[MarcSkovMadsen]

this PR updated accordingly.

I'm not sure what you mean by that, are you saying that this guide currently does not use best practices?

No i'm saying I don't know what best practice is. It would be great to get that established in the how-to guide and then apply here.

[philippjfr]

Got you, thanks!

[MarcSkovMadsen]

Got you, thanks!

This use case is not described in the how-to guide. It explains how to setup a worker thread for each session in a served file.

This use case sets up a shared worker thread in a separate module. All sessions listen/ subscribe/ take the same frame. Currently shared via a parameter on a Parameterized class.

For example right now each time the app is autoreloaded a new worker thread is started and the old not stopped. Your comment in other issue about using on_session_destroyed does not apply here as that only works for sessions.

I've needed this architecture many times for streaming use cases. How do you ingest and share some shared data globally? It could be from video camera, a data base, Kafka etc. Can I safely share the PIL Image, DataFrame, hvPlot plot, Plotly Figure or even a HoloViews or Plotly pane. For efficiency reasons as much as possible should be shared. Should I push to the session? Or should the session regularly pull shared objects?

What I've seen described so far is how each session loads data separately and pushes it to plots, tables and other components in the session.

[philippjfr]

For example right now each time the app is autoreloaded a new worker thread is started and the old not stopped. Your comment in other issue about using on_session_destroyed does not apply here as that only works for sessions.

I don't follow, autoreload creates new sessions.

[philippjfr]

Ah sorry, I guess I'm following you. You're saying this guide demonstrates the shared worker thread and you want each session to subscribe and unsubscribe. That still should still be done via on_session_destroyed handlers though, so I'm not entirely following this point "on_session_destroyed does not apply here as that only works for sessions".

[philippjfr]

I guess, the missing piece is that you need a --setup script to start the worker thread.

[MarcSkovMadsen]

But i dont want that friction. I just want to panel serve as normal such that the component can be imported and used as other component even though its shared.

It gives less to explain. It makes deployment easier if you are not in control of deployment.

[philippjfr]

You can use the cache to to share the thread instance. I appreciate the pursuit of "reducing friction" but you can't reduce all friction for every conceivable complex use case.

[MarcSkovMadsen]

The session is not the problem. The problem is that the external module is reimported on autoreload - thus starting another thread. I dont know where the Old module and thread lives - But its still there.

[philippjfr]

The session is not the problem. The problem is that the external module is reimported on autoreload - thus starting another thread.

Got it, that makes sense. I guess another reason to use the cache.

[MarcSkovMadsen]

The cache is a good idea. Did not Think about that.