Bits Turn up the Joost

Really depends on location. Some people can only get DSL, which is a good amount slower than cable. The cable I had was 6Mbit down, 768k up, but I think that was above average. I think ~2Mbit down, ~256k up (if not slower) isn't at all uncommon.

 

Actually my DSL connection is faster than my cable connection but it's all down to the individual ISPs. Either way, it's nasty laggy at the moment. No chance to really test it until Thursday night though. & again, a big Thank you for the invite

 

allow me to shed some light on the quality switching.

with real time video streams, especially in use cases like IPTV, you want to start the stream as quickly as possible to allow channel hopping. this means having a really short buffer in comparison to, say, soemthing like a quicktime trailer, which typically buffers for a good while before starting to play.

another thing. realtime media needs a fairly constant throughput. TCP inherently is a bursty protocol. if you plot TCP transfer rate against time it will be a sawtooth, with it dropping to half of the highest transfer rate just after the apex. this SUCKS for multimedia streams, since it realy screws with your buffer (you need a bigger one than really necessary), which we already said needs to be as short as possible for IPTV.

so, we are left with using UDP. this is fine but provides no measurements in place for quality of service. in TCP, you send a packet, it gets there. UDP, you just start up sending packets (there's no handshake, setup or teardown, you literally just start throwing **** at the receiver. it used to be a fairly common DOS attack, which is why a lot of coporate routers block UDP). you have no guarantee of getting packets, and no acknowledgement of the packets that were received successfully. People get around this by using their own control protocols alongside UDP, though.

right, so we have a short buffer, and we are doing our own packet recovery techniques.

the intenet drops packets. it will happen, it's an inevitability. routers are programmed to preemptively drop packets even when not congested to keep things that way, so at some point we will have to deal with packet loss in our streams. because of our short buffer, there is often SIMPLY NO TIME to wait for the timeout, send a request for a retransmission, and decode. so what is implemented is some kind of error correction. whether it be parity or more advanced mathematical methods, they all involve sending redundant packets, following the 'safety in numbers' ideaology.

now there is one method called media independent FEC (Forward Error Correction), which involves sending two versions of the data - one high quality, one really low quality. If a packet is dropped and there is no time to resend the data, you fall back to the low quality data for as long as needed, until you can jump back up to the higher quality.

To be fair on joost, this is utterly due to the nature of the internet which really wasn't ever designed for low delay, high bandwidth multimedia applications. the guys are doing an amazing job trying to hide the technicalities from us and they should be applauded for that.

A couple of the reasons for the drops in quality could well be on their side, too, like an overly congested server or their infrastructure causing congestion, but yeah, most of the time it's an unreliable link.

ok that turned out to be an essay. hope it was interesting.

 

I'll send you an invite mate.
Give me an e-mail address via PM.

This would be my last invite. I picked up the first request in this thread. Sorry but I haven't got any more invites.

Ciao

 

I've been in the joost beta for quite a bit now, and I must say that as the service has grown so too has the lag on the service. As it is p2p based it is prolly a good idea to leave it connected when your system is on so it can do it'sd p2p goodness, this way it helps to reduce the lag.

One thing it does have going for it is the interface, as this has changed greatly since I first started using it.

 

found an issue... left pc on overnight... joost on standby. Wake up this morning to this

 

Not nice, I bet your PC was quite stuck.
It is a beta version hence you are a beta tester. Do issue a bug report to them.

 

is it better then freeview ?? as i've got a £20 freeview box and have 70 channels to choose from but is the joost gonna be like everything else you have 70+ channels on but nothing to watch lol. The shows i enjoy watching i buy on DVD boxsets as its easier.


so Freeview vs Joost what do you recon ?

 

IMHO: Freeview, there's a better choice with the BBC stuff and from what I've seen, quality is about the same.

 

no not currently as good as freeview, pm me your email address and I'll invite you if you like

 

Hey, first post on this forum, read this article and I figured it warranted a response. I do agree that some of the content is lacking, I have to disagree about the lag issues. I know that I'm based in America, and that could have an impact on this, but I figured that the record should state where the lag occurs, and where is doesn't. Several friends from several parts of the US do not have lag, so that's the one point I have to disagree with on the article. Otherwise, great job!

 

Well, they have used a 1MB DSL connection. I never experienced lags with my 6MB connection either but using a 1MB connection for the review makes sense since it is what most of the people has world wide (In Italy most of the people are still using the cheap 640Kb connection)

 

holy sh*t.... 1Gb++ resource used?

wooo....... damn.

also, again, on the lag issue, none here. probably coz im in canada.

 

I've not seen any of the lag in the UK. Add the reviewer was getting some in the states. Regarding image quality, i've had it very good sometimes, and not so good other times. I guess its due to not putting the key frames on camera changes etc, or lousy encoder.... The bad quality hasn't been that bad though.

 

Can i please have an invite