gpac
Replace Remotery with gpac websocket monitoring server
Hi all,
Linked branches:
- https://github.com/gpac/testsuite/compare/buildbot-rmtws
- https://github.com/gpac/wiki/compare/buildbot-rmtws
This PR was motivated by the fact that we don't really use the profiling features of Remotery. The only part of Remotery actually used is the exchange of log messages through the websocket server.
We have been exploring the possibility of creating a live UI for gpac through this websocket for a while.
As a first step towards this goal we have decided to remove the complex Remotery tool from gpac and just add a monitoring websocket server that is lighter and allow us more possibilities in terms of message exchange between a future UI and a controller written in one of the available gpac bindings language.
The goal was also to reuse as much existing gpac features as possible (for socket handling, http sessions, etc.) instead of using Remotery's ad-hoc network stack.
More details about features and usage can be found here: https://github.com/gpac/wiki/blob/buildbot-rmtws/docs/Developers/tutorials/rmtws.md
The folder at https://github.com/gpac/gpac/tree/buildbot-rmtws/share/rmtws contains a more full fledged example of usage in all 3 languages (it sends and displays the list of filters of an active session in json format).
This is still work in progress so feel free to comment and add suggestions, objections, and all that.
Buildbot test results for revision: 2.5-DEV-rev1465-g9a58d4c2-buildbot-rmtws
✅ No obvious regression from master, check the links below for full results
Please also make sure that the github checks below are not reporting any build issue.
Buildbot test results for revision: 2.5-DEV-rev1492-g76b81d2c-buildbot-rmtws
❌ Tests failing on all platforms only on this branch:
Please also make sure that the github checks below are not reporting any build issue.
Many thanks for this heavy work.!
One thing I'd like to see changed is the way we use rmtws in gpac JS: instead of attaching the callback to the FilterSession object, I believe it would be better to use JS core by attaching a private stack to the main Sys object and holding the ref to the callback there. It feels strange to use libgpac in NodeJS and Python but FilterSession in JS. Also things could get messy/confusing when loading multiple filter sessions in JS.
Do you think that's manageable ?
Also, please add gf_ prefix to all exported rmt_ws_* functions
Buildbot test results for revision: 2.5-DEV-rev1509-gb2f7828e-buildbot-rmtws
✅ No obvious regression from master, check the links below for full results
Please also make sure that the github checks below are not reporting any build issue.
Buildbot test results for revision: 2.5-DEV-rev1510-ga44795fc-buildbot-rmtws
❌ Tests failing on all platforms only on this branch:
| test | result |
|---|---|
| ffmx-mkv-sub | remux:HashFail |
Please also make sure that the github checks below are not reporting any build issue.
Buildbot test results for revision: 2.5-DEV-rev1529-g92171026-buildbot-rmtws
✅ No obvious regression from master, check the links below for full results
Please also make sure that the github checks below are not reporting any build issue.
Buildbot test results for revision: 2.5-DEV-rev1529-g92171026-buildbot-rmtws
✅ No obvious regression from master, check the links below for full results
Please also make sure that the github checks below are not reporting any build issue.
I'm setting this as ready to review and merge.
I've addressed the previous review by implementing both changes.
If you have further comments feel free.
Once approved I'll merge it myself to check that there are no issues during build.
thanks
I think this is some solid work. I have a few questions though:
- I'm wondering what the global picture is. I think this is an iterative work with the monitoring use-case in mind, correct?
- WebSocket is intrusive (e.g. compared to having filters reporting in a shared memory as we did in Signals), but it also allows bi-directional communication. Do we plan to use the back channel?
I think this is some solid work. I have a few questions though:
- I'm wondering what the global picture is. I think this is an iterative work with the monitoring use-case in mind, correct?
yes, to sum up the main rationale / history of this change:
- initially we tried Remotery which uses a websocket server to communicate with a html/js ui to display profiling info about cpu cycles and all that
- the main problem was that the info collected and displayed is not very useful with the filter architecture
- so we started hijacking custom messages from remotery to try and build demo UIs that can display filter info
at that point keeping the whole remotery network stack, message encapsulation, and profiling made little sense and we started exploring removing remotery and redo the parts that we might actually use from scratch
the main ideas were:
- replace all possible networking parts with already existing gpac apis (for sockets, http sessions, etc.)
- be able to exchange arbitrary messages on the websocket (binary or text) and be protocol agnostic (it's up to the user to define if they want to exchange json messages, protobuf, custom stuff, etc.)
- support multiple clients and ssl websockets
- support js, node, and python
as you said the main goal we had in mind is to develop a webui on top of this to display live filter info
- WebSocket is intrusive (e.g. compared to having filters reporting in a shared memory as we did in Signals), but it also allows bi-directional communication. Do we plan to use the back channel?
the advantage of websocket is that it is easy to use on the "client" side, especially since we had web UIs in mind ; you can just do new Websocket() in javascript and use this to communicate with gpac (like this minimal page: https://github.com/gpac/gpac/blob/buildbot-rmtws/share/rmtws/index.html)
it also integrates well with the existing filter session apis in js/node/python
we can imagine having a local static html/js webui like remotery had (that you open as a file without a webserver)
we can also contemplate having a hosted ui that connects to a local gpac via websocket
and as you say since it's bi-directional we have experimented with updating filters properties from a ui (the fullscreen prop of vout works well with this for example), we are also wondering about adding/removing filters, peeking into the currently processed data, etc.
there is a lot left to be done, we hope this base is small and generic enough so that we can implement interesting stuff on top of it
Buildbot test results for revision: 2.5-DEV-rev1567-g28e38eb0-buildbot-rmtws
✅ No obvious regression from master, check the links below for full results
Please also make sure that the github checks below are not reporting any build issue.
Buildbot test results for revision: 2.5-DEV-rev1590-ge394cbbf-buildbot-rmtws
❌ Tests failing on all platforms only on this branch:
| test | result |
|---|---|
| dash_fwd_hls_twores | encrypt_segb_hls_c1:HashFail |
| dash_fwd_mpd_oneres | encrypt_segb_hls_c1:HashFail |
| dash_fwd_mpd_twores | encrypt_segb_hls_c1:HashFail |
| hls-saes-gen | hls-seg9:HashFail |
Please also make sure that the github checks below are not reporting any build issue.
Buildbot test results for revision: 2.5-DEV-rev1606-g8a68e35b-buildbot-rmtws
✅ No obvious regression from master, check the links below for full results
Please also make sure that the github checks below are not reporting any build issue.