[WIP]: Adds streaming over WebSockets support

[p3javier]

This PR address the issue on #485

• Updated base images in Dockerfile to use Go 1.23 and Node 18 (bookworm).
• Added WebSocket streaming support in the client, including new methods for handling binary data and managing streaming modes.
• Introduced a new WebSocket pipeline in the server for fMP4 streaming, with configuration options for video and audio codecs, bitrates, and fragment duration.
• Enhanced the BaseClient to support streaming mode selection and improved error handling for WebSocket connections.
• Updated Vue component to integrate WebSocket streaming features and manage state accordingly.

[Gauvino]

Quick question, why is the project still on nodejs 18 since the latest lts is 22, it is not the moment to update to it ?

[m1k1o]

@Gauvino the whole client is pending a rewrite because Vue2 is EOL #358 and there is no simple way to upgrade, just rewrite basically from scratch. Its the next step on the roadmap.

[Gauvino]

@Gauvino the whole client is pending a rewrite because Vue2 is EOL #358 and there is no simple way to upgrade, just rewrite basically from scratch. Its the next step on the roadmap.

Thanks for the explanation and good luck re-creating the client

[p3javier]

@Gauvino the whole client is pending a rewrite because Vue2 is EOL #358 and there is no simple way to upgrade, just rewrite basically from scratch. Its the next step on the roadmap.

Thanks for the explanation and good luck re-creating the client

Actually I think it will be more optimal switching to React for the new version instead of Vue 3. But this is not the thread and it is a decision that should be taken by the maintainer.

[m1k1o]

@p3javier I am considering switching to react.

[p3javier]

@p3javier Yeah, mainly because I think is going to be easier to find React contributor than Vue contributors. Btw did you have opportunity to review the code I pushed?

[m1k1o]

Btw did you have opportunity to review the code I pushed?

Yes, I look at. As a POC it looks good, but there are some changes needed prior this can be merged to the master:

• The code on the client and server should be encapsulated to its own module.
• I am unsure about whether the existing WS connection sould be used or we should create dedicated one for the audio/video data. Probably we should write some advantages/disadvantages and decide on that.
• You imported github.com/go-gst but currently the project is implementing its own gstreamer bindings. We should either migrate all bindings to go-gst or just continue writing our own. But since go-gst wants to change their bindings completly and revert to v0 generate bindings with gotk4 go-gst/go-gst#170 , it is not a good idea to be dependent on them now.
• We are creating a new encoding pipeline for WebSocket data. Since encoding is very expensive on CPU usage, we should not create a new one since there is already existing pipeline running. So we should either:
  • Take the audio/video content from appsink and repackage it for fMP4 (can be again gstreamer pipeline or some native go solution)
  • Add tee to the existing pipeline and have another parallel output for websocket data. Although this can generate unused outputs when there is no WS video client, the repackaging is not an expensive operation. We could also modify the pipeline on the fly and just include outputs that we currently need.

I would say that the last point is the most important, as doubling the CPU usage is not what would be something that we want, if it can be avoided.

[p3javier]

Btw did you have opportunity to review the code I pushed?

Yes, I look at. As a POC it looks good, but there are some changes needed prior this can be merged to the master:

• The code on the client and server should be encapsulated to its own module.

• I am unsure about whether the existing WS connection sould be used or we should create dedicated one for the audio/video data. Probably we should write some advantages/disadvantages and decide on that.

• You imported github.com/go-gst but currently the project is implementing its own gstreamer bindings. We should either migrate all bindings to go-gst or just continue writing our own. But since go-gst wants to change their bindings completly and revert to v0 generate bindings with gotk4 go-gst/go-gst#170 , it is not a good idea to be dependent on them now.

• We are creating a new encoding pipeline for WebSocket data. Since encoding is very expensive on CPU usage, we should not create a new one since there is already existing pipeline running. So we should either:

  • Take the audio/video content from appsink and repackage it for fMP4 (can be again gstreamer pipeline or some native go solution)
  • Add tee to the existing pipeline and have another parallel output for websocket data. Although this can generate unused outputs when there is no WS video client, the repackaging is not an expensive operation. We could also modify the pipeline on the fly and just include outputs that we currently need.

I would say that the last point is the most important, as doubling the CPU usage is not what would be something that we want, if it can be avoided.

I think you @m1k1o have way more context and experience with this project than me. I don't know if you can take on this. If I need to develop fully this feature is going to take me probably a couple months haha.

[m1k1o]

@p3javier we could get this working as PoC as it, and then when it proves to be working good I can take on this and ensure that it integrates to the project.