Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Modern Video Players Work

blog.streamroot.io

Post reply on HN
Print view View original

11–16 of 16 posts

Re: How Modern Video Players Work

#11

Post by eldod »

Nutmog wrote: post #5

All this fancy software and yet watching videos on the web is just as painful as it was 15 years ago if you don't have a fast enough connection. The download won't keep up with the play speed and they don't accommodate that nearly as well as they could. In the early 2000's with dial-up, you could just press pause then come back a few minutes later to watch what had been buffered. Nowadays that trick often doesn't wor…

Actually as the article mentions, most broadcasters today are using adaptive bitrate formats like HLS and DASH, that are solving this issue by serving you a bitrate that is low enough for you to handle.

Today the major broacasters often have 6 or 7 different qualities, going from 300kbps up to 4000Mbps for HD.

Re: How Modern Video Players Work

#12

Post by ollifi »

aaroninsf wrote: post #6
Nutmog wrote: post #5

All this fancy software and yet watching videos on the web is just as painful as it was 15 years ago if you don't have a fast enough connection. The download won't keep up with the play speed and they don't accommodate that nearly as well as they could. In the early 2000's with dial-up, you could just press pause then come back a few minutes later to watch what had been buffered. Nowadays that trick often doesn't wor…

This! Related gripe: WTH is there no full-track buffering mode for any web players (looking at You, Tube!) and apps like Pandora or Spotify, for low- or sparse- bandwidth travel?! I don't care if you limit it geographically or only make it work with bandwidth throttling or whatever... ...just make it work. Then your apps would work and I would not be cursing and throwing my phone out the window every road trip. This…

Spotify has preloading offline mode in the mobile player. Maybe not exactly what you are looking for.

Re: How Modern Video Players Work

#13

Post by kbart »

Nutmog wrote: post #5

All this fancy software and yet watching videos on the web is just as painful as it was 15 years ago if you don't have a fast enough connection. The download won't keep up with the play speed and they don't accommodate that nearly as well as they could. In the early 2000's with dial-up, you could just press pause then come back a few minutes later to watch what had been buffered. Nowadays that trick often doesn't wor…

Yes! Pause&wait was my default behavior on slow connections (i.e. smartphone in the middle of nowhere) and removing it is a huge step back. I mostly can't use Youtube on my phone anymore and forced to look for videos somewhere else, where this "old-fashioned" method still works. Is there any technical reasons that won't let the video download while paused?

Re: How Modern Video Players Work

#14

Post by HappyTypist »

kbart wrote: post #13
Nutmog wrote: post #5

All this fancy software and yet watching videos on the web is just as painful as it was 15 years ago if you don't have a fast enough connection. The download won't keep up with the play speed and they don't accommodate that nearly as well as they could. In the early 2000's with dial-up, you could just press pause then come back a few minutes later to watch what had been buffered. Nowadays that trick often doesn't wor…

Yes! Pause&wait was my default behavior on slow connections (i.e. smartphone in the middle of nowhere) and removing it is a huge step back. I mostly can't use Youtube on my phone anymore and forced to look for videos somewhere else, where this "old-fashioned" method still works. Is there any technical reasons that won't let the video download while paused?

Apps are built for the average, everyday user. I'm sure their user testing has shown that the majority of users don't do the "pause and wait" ritual, and a large amount of pauses are never resumed.

So, they choose to save the bandwidth.

Re: How Modern Video Players Work

#15

Post by contingencies »

bagels wrote: post #7
aaroninsf wrote: post #6

Earlier quoted context omitted.

This! Related gripe: WTH is there no full-track buffering mode for any web players (looking at You, Tube!) and apps like Pandora or Spotify, for low- or sparse- bandwidth travel?! I don't care if you limit it geographically or only make it work with bandwidth throttling or whatever... ...just make it work. Then your apps would work and I would not be cursing and throwing my phone out the window every road trip. This…

The other side of the equation involves at least: 1) Video provider pays for bytes sent to the user that are not used. If the cache policy is "cache the whole thing", you would find yourself paying (a guestimate) 2x for bandwidth. This is because most people do not watch even nearly the entirety of every video that they start loading. 2) Using server bandwidth for bytes that are not used. This increases contention fo…

I live in China which has crap international bandwidth. Youtube via VPN is the only way ... my solution is to use VideoDownloadHelper plugin for Firefox @ https://addons.mozilla.org/en-US/firefox/addon/video-downloa...

OTOH, China has an awesome "who cares about gwailo IP" progressive IP policy which allows you to stream lots of copyrighted stuff instantly via multiple domestic providers. Hell, new TVs have this sort of thing built in! It's awesome for Hollywood crap, just not the content (eg. EU / art-house films) or type (eg. documentaries) that I am typically looking for. Then again we have torrents...

Somewhere, somehow, the internet finds a way. When all is said and done, it's only people who are scared, stupid or spendthrift that pay... or those who want the authentic cinema experience, collect media, or are commercial operations that need to worry about legal challenges.

A few years ago I actually used to live in Hollywood and London working for a big DRM-based video solutions provider that did work for literally most of the world's major mobile device manufacturers. Boring, but a great insight in to how corrupt the industry is. (Very)

Re: How Modern Video Players Work

#16

Post by aaroninsf »

bagels wrote: post #7
aaroninsf wrote: post #6

Earlier quoted context omitted.

This! Related gripe: WTH is there no full-track buffering mode for any web players (looking at You, Tube!) and apps like Pandora or Spotify, for low- or sparse- bandwidth travel?! I don't care if you limit it geographically or only make it work with bandwidth throttling or whatever... ...just make it work. Then your apps would work and I would not be cursing and throwing my phone out the window every road trip. This…

The other side of the equation involves at least: 1) Video provider pays for bytes sent to the user that are not used. If the cache policy is "cache the whole thing", you would find yourself paying (a guestimate) 2x for bandwidth. This is because most people do not watch even nearly the entirety of every video that they start loading. 2) Using server bandwidth for bytes that are not used. This increases contention fo…

Yes, I was thinking specifically of client-side caching. I would like my mobile apps to aggressively cache forward in the play list so that I always have

a) the complete current song, and ideally b) the complete next song

Except in game over insufficient bandwidth full stop scenarios, natch.

I would imagine the most user-friendly version of this would be to start playback using as soon as there is a conventional "sufficient buffer," but to be much more aggressive about sucking every possible byte to maintain the above caching...

Personally I would solve the 'very long delay before play' problem by defaulting to the 80% case of playing one of N songs from the last used playlist/station, _as cached locally from last play_. (Maybe not simply the most recently played, maybe the highest ranked, least skipped, whatever...)

That wouldn't help with people who are flipping stations, but my road trip case would be sudden bliss... no more constant drop-outs.

Disclosure: part of my problem is no doubt sticking with Sprint because I don't want to lose unlimited (sic) data. :P

Post reply on HN