search

qnkhuat / tstream

Live streaming from your terminal
https://tstream.xyz
MIT License
267 stars 9 forks source link

Build instructions #50

Closed Kabouik closed 2 years ago

Kabouik commented 3 years ago

Thanks for this, it's pretty cool concept. It would be cool if we could set a password to restrict the stream to just selected users. Is that on the to-do? [Edit] I just saw it's planned, sorry.

Any plans on adding build instructions? I'm not a big fan of downloading precompiled binaries, which also makes it more difficult to upgrade than just git pull and build. It would also allow using tstream on ARM devices, which are now very widespread.

Not related, but I may as well mention it just in case: while the stream worked flawlessly when viewed on a Debian machine in Firefox and Chromium, glitches appeared on my Solus machine from Firefox (Chromium not tested) with part or all of the text being rendered as square characters, mostly $PS1, but not only. In Nyxt browser, the web page only shows up briefly before it turns 100% white with nothing displayed. Both issues are probably not related to tstream itself and may be just local issues but never know, maybe tstream uses something that is not properly supported in all configurations.

What is tserver used for? Is that for hosting your own instance of the website?

Kabouik commented 3 years ago

My bad, I jsut saw that private sessions are planned.

qnkhuat commented 3 years ago

Hi @Kabouik,

Any plans on adding build instructions? I'm not a big fan of downloading precompiled binaries, which also makes it more difficult to upgrade than just git pull and build.

Yes I'm going to write one soon, there are some people asking about it too.

On a future note: I think it'd be more convenient if tstream could update itself, but I just haven't had time to do that.

It would also allow using tstream on ARM devices, which are now very widespread. Mind if I ask which machine you're using and what OS?

In the previous versions, we support pretty much all OS and arch except for Windows. But on version 1.3 where I added the voice chat feature, due to the limitation of the framework I'm using It can't support more than MACOS (arm + x86) and Ubuntu(x86).

I have a plan to modify the build system in a way it will just disable the voice feature on unsupported systems. That way we can keep the core functions and support a wide range of systems (if you're familiar with the go build system then maybe you could help me on that ^^ )

Not related, but I may as well mention it just in case: while the stream worked flawlessly when viewed on a Debian machine in Firefox and Chromium, glitches appeared on my Solus machine from Firefox (Chromium not tested) with part or all of the text being rendered as square characters, mostly $PS1, but not only. In Nyxt browser, the web page only shows up briefly before it turns 100% white with nothing displayed. Both issues are probably not related to tstream itself and may be just local issues but never know, maybe tstream uses something that is not properly supported in all configurations.

Thank you to point it out. Currently, I'm using the xtermjs library to render on the client-side. And I think we will stay that way for a long time. As you said it is kind of hard for me to dive into that because I haven't done much research on that area. My current focus is to support the majority. But in the future, it might be an issue since our platform is for developers and developers has strange preferences 😆  

What is tserver used for? Is that for hosting your own instance of the website?

The tserver is our actual server that serve streaming content and APIs. Briefly speaking what happens when you stream is this:

Hope this help you understand tstream system.

Btw if you're on Discord then I invite you to join our server: https://discord.com/invite/qATHjk6ady.

We just talked about the build issues a while ago on Discord ^^

Kabouik commented 3 years ago

Hi @Kabouik,

Any plans on adding build instructions? I'm not a big fan of downloading precompiled binaries, which also makes it more difficult to upgrade than just git pull and build.

Yes I'm going to write one soon, there are some people asking about it too.

On a future note: I think it'd be more convenient if tstream could update itself, but I just haven't had time to do that.

Thanks! Built-in update system would be cool, but I'm happy with manual compilation too since there are probably not too many dependencies.

It would also allow using tstream on ARM devices, which are now very widespread. Mind if I ask which machine you're using and what OS?

The Solus machines I use are regular x86_64 PCs, and the Debian machine is a keyboard phone running SailfishOS as host and Debian as a LXC container. I'm posting from it right now (see a quick demo I made). But there are a lot of more common ARM devices with single-board computers, recent M1 chips, ultraportable laptops, etc. I suppose even a small fraction of mobile OSes like Sailfish or Android+Termux could be interested.

In the previous versions, we support pretty much all OS and arch except for Windows. But on version 1.3 where I added the voice chat feature, due to the limitation of the framework I'm using It can't support more than MACOS (arm + x86) and Ubuntu(x86).

I have a plan to modify the build system in a way it will just disable the voice feature on unsupported systems. That way we can keep the core functions and support a wide range of systems (if you're familiar with the go build system then maybe you could help me on that ^^ )

Sounds good, unfortunately I'm afraid I don't know much about go!

Not related, but I may as well mention it just in case: while the stream worked flawlessly when viewed on a Debian machine in Firefox and Chromium, glitches appeared on my Solus machine from Firefox (Chromium not tested) with part or all of the text being rendered as square characters, mostly $PS1, but not only. In Nyxt browser, the web page only shows up briefly before it turns 100% white with nothing displayed. Both issues are probably not related to tstream itself and may be just local issues but never know, maybe tstream uses something that is not properly supported in all configurations.

Thank you to point it out. Currently, I'm using the xtermjs library to render on the client-side. And I think we will stay that way for a long time. As you said it is kind of hard for me to dive into that because I haven't done much research on that area. My current focus is to support the majority. But in the future, it might be an issue since our platform is for developers and developers has strange preferences

Understood! In Solus, I don't know what was the issue but I'll need to try on another Solus machine I have, to check if that was a local issue on my laptop. About Nyxt, it's still a young browser and it is likely the issue was not even related to it but rather to WebKit, but surely this will improve eventually regardless of tstream development.

What is tserver used for? Is that for hosting your own instance of the website?

The tserver is our actual server that serve streaming content and APIs. Briefly speaking what happens when you stream is this:

  • tstream will make a WebSocket connection to the tserver which is under URL: https://server.tstream.club
  • now any changes on your terminal will be sent to this server
  • A viewer joins the stream on https://tstream.club ( it is a react application ) and also creates a WebSocket connection to the server https://server.tstream.club.
  • The server does some checking and will broadcast the streaming content to the viewer, which then we use xtermjs to display

Thanks! That's what I was expecting from a server binary but somehow I misunderstood the instructions because it's never mentioned. I was not sure if it was necessary to use tstream (which I couldn't see because I downloaded both anyway) or necessary to build an independent website.

qnkhuat commented 3 years ago

Hey, I've added a Build from source section. Hope it helps!

Kabouik commented 3 years ago

Thanks!

I tried it on my aarch64 Debian device but I am getting the following error:

 user@debian-sid ~/P/t/tstream  $ go build cmd/tstream.go                                                                                            main 
# github.com/qnkhuat/mediadevices/pkg/codec/opus
/usr/bin/ld: ../../../go/pkg/mod/github.com/qnkhuat/mediadevices@v0.2.3/pkg/codec/opus/lib/libopus-linux-arm64.a(celt.c.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `stderr@@GLIBC_2.17' which may bind externally can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: ../../../go/pkg/mod/github.com/qnkhuat/mediadevices@v0.2.3/pkg/codec/opus/lib/libopus-linux-arm64.a(celt.c.o)(.text+0x4): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `stderr@@GLIBC_2.17'
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

I assume one of the go dependencies is not available in that architecture.

qnkhuat commented 3 years ago

oh yea, that's a package we used to encode voice. I'll try to add filter out this feature if it's not available on the build system later.

qnkhuat commented 2 years ago

hey @Kabouik, Just wanna let you know that I added private session.

Please update to v1.3.2 and you can start private session with tstream -private

Kabouik commented 2 years ago

Thanks, I'll definitely look into it!

On 2021-08-30 16:17 Quang Ngoc @.***> wrote:

hey @Kabouik, Just wanna let you know that I added private session.

Please update to v1.3.2 and you can start private session with tstream -private

--
You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/qnkhuat/tstream/issues/50#issuecomment-908382365