Yes, it is. Myself, and a small group of enthusiasts developed the service.

We launched in 2011, with the idea that the hearing impaired could use the service to access a great source of realtime information - television.

The hearing impaired could now objectively access and review online the quality of captions delivered by broadcasters.

Since then, it has grown into a useful resource for everyone.

One of the biggest benefits, we believe, is that our service raises the awareness of captioning to others who haven’t traditionally relied on it.

For those technically minded, it's a client-server model built with custom client hardware. Currently, we're only streaming Australian channels, however, there's scope to plug in any terrestrial broadcast, and feed it into TVeeder.

There's a REST API too.

That's pretty awesome. Thank you for stepping up to work on this.

Thanks for the clarification, that's more what Hacker News readers want to know :) .

I wish you best of luck and congratulations.

Is there any documentation for the API, or at least a link to it?

Sure. It's a simple REST API. Here's the link: http://tveeder.tumblr.com/post/60208341417/oh-theres-an-api-...

I'm not sure it's working, I just tried the SBS of the GER POR game and after some ads (which corresponded to the websocket data):

  ...
  "text": " Every second of every game ",
  "text": " live on the big screen at Crown. ",

All that ever came back was:

  {
    "range": []
  }

It's like there were no captions whatsoever. Failing under load?

Try this link: http://beta.tveeder.com/785/byrange?&from=1402972200&to=1402...

It worked from Safari but not FF on the proxies network. During the BELvALG game there are lots of trouble again, seems to only get a small portion of the captions and then stops updating. Here is the last of what I was able to get:

    {
      "id": 4399254,
      "channel": 785,
      "text": "But at BOQ you can talk to one person",
      "date": 1403023783.284,
      "cid": 7
    }

what about Streaming API?

Not yet. Websockets are utilised on the frontend, however the API is vanilla REST.

I second, great project. Is it just failing under load ATM (cause of MEX v. CMR)? It may not work from this network (worked earlier from another) which uses a transparent proxy. websockets tends to fall over with most proxies. I see you use ws:// maybe wss:// would get through more often but maybe that is too much. Again thanks, this is great what you all created.

yea I just see the event information, no captions