Show HN: DudelDu a simple SHOUTcast server in Go | Hacker News Reader

Show HN: DudelDu a simple SHOUTcast server in Go

github.com

30 pointskrotik18 comments

Interesting. The project structure looks a bit weird, though. It's basically an own GOPATH, which makes it harder to vendor. I would suggest putting src/devt.de/dudeldu in the root and everything else in subdirectories.

Raise an issue?

Hmm, I would like to provide a demo. For now I host the GOPATH structure on github, which includes a demo, while the code which you get via "go get" is on a self hosted server. So you can write:

go get -d devt.de/common devt.de/dudeldu

if you want just the source (vendor form) or you can:

git clone https://github.com/krotik/dudeldu/ .

if you want it with a demo. You can then build the executable and run it with the demo folder.

I use a self hosted machine to run the build and unit tests overnight. I know the vast majority of Go projects does it differently - I am still unsure but so far it worked for me ...

The demo should really be in a separate repo and then you can link to it in the README.

Yes, I could host the demo on my server and move the code to the root directory. However, I am not sure about the benefit.

In my understanding the main reason why people put code in the root is so that you can use "go get" to do a checkout. "Go get" then creates a src dir and puts the code there. This functionality is already covered by my server. Since my code path uses devt.de "go get" will always use my server and not github.

The only way someone could use the github code would be with "git clone" and here I think the src dir in the repo might be useful. Otherwise, you have to make sure to create this yourself.

Am I missing something?

Personal servers are more prone to intermittent operation, caused by things such as an OS upgrade gone bad and the owner not finding the time at the moment to fix it. If on the other hand you have a repo on GitHub that one can go get then users will know with much greater confidence that the repo will stay available at all times for the foreseeable future.

I run my own web and mail servers, but the canonical repositories for all my code is on GitHub, both because then I know my code is always available to myself but also because I know that it means that others will have fewer reasons not to use my projects, because even though I know that my uptime and stability is good, others can't know that, but they know that GitHub is.

I have to admit, I really like the name! (Gonna have to test at home before I can say anything more substantial, though.)

Can it handle streaming of videos? README only mentions mp3 files.

Shoutcast only ever did audio, I think

No, SHOUTcast is only about audio. It is quite simple and straight forward.

I did implement some time ago a basic video streaming server (in Java) using Adobe's Real Time Messaging Protocol (only a partial implementation). It worked well enough for jwplayer and flowplayer. However, Flash is now on the decline and also it was a real pain to implement it.

I would be interested in implementing a video streaming server in Go. Does anyone know a good streaming protocol for HTML5 video? It should support seeking though - this was one of the main points why I went through the RTMP implementation.

I asked because of this from their FAQ[0]:

What is Icecast, the program?

Icecast is a streaming server, which can stream audio (and video) to listeners/viewers. It supports Ogg (Vorbis, Theora), Opus, FLAC and WebM (VP8/VP9), nonfree codecs/formats like MP4 (H.264, MPEG4), M4A, NSV, AAC and MP3 might work, but we do not officially support those.

EDIT: is your Java code for video streaming somewhere? I'm interested in streaming my Raspberry Pi camera as all existing solutions don't satisfy me at the moment.

[0] http://icecast.org/faq/

Icecast is not SHOUTcast...

https://en.wikipedia.org/wiki/SHOUTcast

https://en.wikipedia.org/wiki/Icecast

I am currently travelling but once I have a stable connection I can upload it.

If you just want streaming (unidirectional) then you could just write a simple server which streams the byte stream from the camera. I remember one of my colleagues at work did this for our foos table scoring system. I suspect this is also what Icecast does.

I went through the pain of RTMP because I wanted support for seeking which requires bidirectional communication.

Hi, I managed now to dig out my Java code. It is here:

http://devt.de/tmp/rtmp_example.zip

It is just an experiment so not much documentation and/or unit tests. I hope it helps.

You could certainly send video with shoutcast framing, but you would need a client that knew how to handle that. It wouldn't be seekable, but that would be expected for live video. Adapting to available bandwidth is mostly expected for video, but not as much for audio.

Shoutcast definitely supported video streaming using the nsv format. I used to run a server back in the day.

https://en.m.wikipedia.org/wiki/Nullsoft_Streaming_Video

Thanks, I stand corrected. So I guess I have to try to stream a video :-)

Though sadly, I understand that this will not allow seeking.

My previous comment was wrong. After some more testing I can confirm that it does indeed support streaming of video. I've added a small video to the demo.

Reply on news.ycombinator.com