|
Poster:
|
 tracey pooh |
Date:
|
February 11, 2012 12:31:29pm |
|
Forum:
|
movies
|
Subject:
|
Re: new video/audio player 'opt in' is live! |
these are slight delays due to buffering.
it really comes down to the software to try to get around that.
*yes* it is technically possible in all environments with javascript (not flash -- that I know less about innards-wise) and that are not iOS (they don't allow you to be buffer 2 A/V media files at once) where i've made three generations of javascript code and players that allow the client/browser to be buffering the next clip to go in a hidden player in the background -- so when it comes time for the "next song", it's already prebuffered and you just swap the players and pause/play, respectively!
however, it has implications to the A/V players we use and how they interact with playlists and embed codes, etc. so it gets tricky fast. it's not likely we'll go that route (since it's always the first thing to be blamed for any kind of issue in internal using it for many many months).
another option is a kind of "media pipe" that you just throw bytes into. that works brilliantly well when the media is relatively/completely uniform (which thankfully it most often is for us, since we are playing our "derivatives" most of the time and we have similar pixels sizes (videos) and framerates and bitrates (both audio and video)). this is how providers like netflix operate -- you get lists of ~10 second little chunks of A/V in a constant stream, and the client just keeps playing what it gets. however, that's obviously a bit more complex than we'd like. we aren't splitting our audio/video into 10-second little file chunks and even if we did or did that "dynamically" on the backend (or just sent the whole file down these "byte tubes" 8-) it requires more smarts in the player and client end.
that latter one, is relatively industry standard (also referred to HLS and/or apple adaptive streaming) and just about every mobile device and browser (and most players) can handle it. since it's standardized, we *may* go with it in the future, but it's not anything short-to-medium term if i use my psychic powers at the archive 8-)
hope that's way more info than you'd care for on your saturday morning-with-coffee wanted to know!
-tracey, staff
PS: we have continually been a bit baffled by the large A/V player javascript library offerings *not* including a javascript "prebuffer next clip if client platform can" option. we've asked it of every major player we've used here: flowplayer, mwEmbed (Kaltura), and jwplayer; and even of some browser folks. we often get answers "it's not possible" (it is!) and see plenty of other users w/ same request in the player package folks' forums. I think the HLS solution makes most player package developers feel they'd rather support that instead... (HLS is also a bit more "ad serving" and content protection/encryption friendly/common, and they are all in the side business of getting bills paid, too, soo.....)
This post was modified by tracey pooh on 2012-02-11 20:31:29
