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.
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:
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 ...
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.
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.
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.
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.
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.
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.
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.