h a l f b a k e r y"Bun is such a sad word, is it not?" -- Watt, "Waiting for Godot"
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
for media players. When I know my connection speed is too
slow for the amount of buffering done I want a button to push
to add a BIG buffer to my streaming video.
[link]
|
| |
Good idea. Smarter software should even do this for you
automatically, no? |
|
| |
Ian, do you live on high ground, or at the top of a tower
block? If so, you've probably just got low pressure. You
should install a big header tank in the loft, and connect to
that rather than from the rising main. |
|
| |
Just be careful you know what you're doing though. If you
get it wrong, you'll start siphoning, and then some bugger
living further down the hill will get all your Sky channels
bubbling up out his earth connection. |
|
| |
Bun for the idea (I really need this). I fiddle and frick around with buffer size settings on the media player, all to no avail, there is some setting I can't get to. I've found some pages allow you to pause after a second of playing and let the whole thing buffer (youtube) - but others won't load more than 30 seconds or so and just pause waiting for you to catch up. It's like there's an assumed DL speed inbuilt into the player. |
|
| |
Another bun for the title. |
|
| |
The pressure thing's stupid, cause we all know electron flow is turbulent in CAT5 cable anyway. What you need is bigger pipe. |
|
| |
A bun just for fun. You guys are great. [+] |
|
| |
now I'd quite enjoy the sound of the tardis materialising while I ran my bath. |
|
| |
You just want David Tennant to see you in the bath |
|
| |
I told you not to broadcast that fantasy. |
|
| |
The thing is, most of the time you aren't watching a streamed video. It's actually a progressive download. Youtube and the like use TCP (Transmission Control Protocol) to make sure the video gets to it's destination in one piece. This might take a little time (and so the buffer is required). If you've got the bandwidth to play the video then something like RTP (Real Time Protocol) would be better - that's what it's designed for, after all. |
|
| |
Ah well - enough lamentation about the existence of the problem. Now on to the pastry for the solution: [+]. |
|
| |
You could also realise massive efficiencies in the video-transmission protocol by changing the
"video-on-demand" model so that everyone "demanded" the video at the same time such that a single data stream could be transmitted to everyone. The power of suggestion may work for this - you may find, for example, that suggesting a certain time of day for a particular video stream to start is enough. If you printed this time in major newspapers and put it on popular websites, you may find that everyone would then "demand" the video stream started at that time. |
|
| |
Replace [hippo]'s innovative suggestion with multiple, time shifted versions and you get a "broadcast carousel". This might, at first sound like the "+1" channel, but there is research out there about the correct scheduling of data into carousel systems to minimise waiting times or maximising data availability and so on.
(A lot of these research ideas have become redundant because they were based on the premise that much of the data transmitted could not not be stored at the end points so would have to be retrieved from source when needed. Of course, now you can store entire movies on a USB stick that costs about £10). |
|
| |
[ edit: High Five bigsleep!] |
|
| |
//you could probably get 90% of bandwidth over to a broadcast model// |
|
| |
I'm not sure of the %age, but you're not far away. My doctoral studies looked into this and there is a lot of evidence to suggest that file popularity fits a Zipf-like distribution. This means that the most popular file in a system is typically twice as popular as the next... and so on with a long tail of stuff behind. You also see this kind of effect with many web news outlets that supply a "popular" list or a "trending" list. |
|
| |
If you can transmit this content out when the network is good and store it on user devices before the users make the demand, then you can improve file access times. |
|
| |
+ ...and you could buffer my bun. |
|
| |
A broadcast carousel isn't the right solution -- it
would require that the data continually be sent to
the entire internet simultaneously. Instead what's
wanted is a multicast carousel. |
|
| |
With a multicast connection, there's a data
originator, and several data recipients; the
originator sends out sends out a single data
packets, and each router between the originator
and recipients will, send a copy of that packet to
every router that's connected to it which along a
path to a recipient. |
|
| |
Unfortunately, not all routers implement multicast
routing. |
|
| |
However, while a multicast carousel would reduce
the load on the internet, and increase download
speeds, it doesn't solve the Voice's real problem --
the recipient application not buffering enough
data. |
|
| |
The obvious solution would be to design your
streaming video viewing application so that it
downloads the first second or two of the video,
and calculates your download speed based on how
long that took; it should then buffer enough video
so that the video will finish playing a few seconds
after it finishes downloading. |
|
| |
The obvious problem with that solution is that if
your network connection speed drops after the
beginning of the download (quite possible on
wireless networks), the viewing of the video will
catch up to the end of the downloaded portion of
the video. Obviously, when the program has run
out of data to show, it is forced to pause to buffer
more data. |
|
| |
The solution to the problem's solution's problem, is
to have the viewer *continuously* calculate the
rate at which the data is being received. The
instant the download rate slows to the point that
the program thinks that it *might* take longer to
download the remaining video than to display it, it
should immediately pause to buffer more video. |
|
| |
This will result in the video pausing to buffer
earlier, when it's less likely to interrupt something
interesting/important. |
|
| |
Also, it will only pause to buffer data at most once
for each time the download speed decreases. |
|
| |
//The solution to the problem's solution's problem, is to
have the viewer *continuously* calculate the rate at which
the data is being received// |
|
| |
Yep. RTP will do that for us. The application can react as
it sees fit.
{P.S. I know that I didn't say anything to
the contrary, but I didn't mean using a broadcast carousel
on t'internet... } |
|
| |
I expected to read this idea and see footage of pirates, sodomising their shipmates. Instead I just got ads and a short comedy rotine. |
|
| |
Does anyone know of a player that simply downloads the lot before trying to play the file? Bearing in mind most embedded video files can't be right-click-saved. |
|
| |
Lipid lets you set this as a preference. |
|
| |
After much deliberation, [Voice], I have decided to buffer your bun. No, wait a minute; that's just not right. I have decided to bun your buffer. <grins> [+] |
|
| |
Apparently the new version will be called Insipid,
[MB]. It's a bit like your running joke. |
|
| |