Preloading - A temporary hack

[Kelly Sutton]

I got to the point last week where I went to implement preloading in
the blip player. I noticed our test page of 15 embedded players liked
to hang the browser. In theory, preloading should be as easy as
setting the "preload" attribute to a video tag. Unfortunately, this is
not something that has yet been implemented in Chrome or Safari (not
sure about Firefox/IE9).

After poking around a bit, I found a little blurb about this on the JW
HTML5 Player page:

http://www.longtailvideo.com/support/jw-player/jw-player-for-html5/11891/html5-video-tag-reference

To solve the problem, the JW player blanks the "src" attribute of any
video tag. When the video goes to play, they set the source and call
load(). After tinkering around with this a bit myself, this approach
seems to work pretty well.

So until the browser makers bring themselves up to spec, this is a
good temporary solution. Does anyone know of something a little more
elegant?

[Christopher Zacharias]

Last I heard, it was not that Chrome and Webkit had yet to add support for the "preload" attribute, it was that they had dropped it. This was a while ago. I think this approach you are taking was the recommended alternative approach.

--
Christopher Zacharias

christophe...@gmail.com

http://www.chriszacharias.com

+1 585-415-4440 (cell)

[Zachary Ozer]

Actually, we now do something far more nefarious.

Once we added playlist support, we decided that the easiest way to
handle all of this was to blow away the <video> tag and just reinsert
it for each playlist item. I'm not sure which is better in terms of
memory / computational performance, but it keeps it clean.

The one caveat: the iPad is not a happy camper about putting visual
elements on top of the <video> tag unless the tag is in the DOM before
document.ready is fired. I've never gotten it to work personally
(regardless of whether or not the <video> tag was cooked into the
page), but Michael Dale (of Kaltura / mwEmbed fame) showed me a demo
where this was working.

Have any of y'all gotten a display element on top of a <video> tag on
the iPad during playback?

Best,

Zach
--
Zachary Ozer
Developer, LongTail Video

w: longtailvideo.com • e: za...@longtailvideo.com • p: 212.244.0140 •
f: 212.656.1335
JW Player  |  Bits on the Run  |  AdSolution

[Kelly Sutton]

> Once we added playlist support, we decided that the easiest way to
> handle all of this was to blow away the <video> tag and just reinsert
> it for each playlist item. I'm not sure which is better in terms of
> memory / computational performance, but it keeps it clean.

We used to do this approach before we started working with some ad managers. When they go to play an ad, they overload the video element you were expecting to play. It's not the most graceful thing out there. Thankfully, they are willing to work through problems like these since it's a young space.

Kelly

[Zachary Ozer]

On Mon, Nov 1, 2010 at 1:56 PM, Kelly Sutton <ke...@blip.tv> wrote:
>> Once we added playlist support, we decided that the easiest way to
>> handle all of this was to blow away the <video> tag and just reinsert
>> it for each playlist item. I'm not sure which is better in terms of
>> memory / computational performance, but it keeps it clean.
>
> We used to do this approach before we started working with some ad managers. When they go to play an ad, they overload the video element you were expecting to play. It's not the most graceful thing out there. Thankfully, they are willing to work through problems like these since it's a young space.

Doesn't this dump the video buffer? Have publishers complained?

We suggested to an advertiser recently that they should:
* Create a new <video> tag for the ad
* Hide the existing player <video> tag
* Position the ad <video> tag in the same location as the player's <video> tag
* On completion of the ad, delete the ad <video> tag and unhide the
player's <video> tag

Admittedly it's a bit complex, but it keeps things nicely separated.

[Kelly Sutton]

It does dump the buffer, which is nasty. Most of the HTML5 use is through blip.tv and not user embeds. On our site, visiting an episode's page immediately goes to play the video. There isn't too much data that's loaded and then thrown out. Again, it's not an ideal solution.

Ad managers will implement a similar system to how things are done now in Flash: you load an opaque component that generates the video tags or HTML for an overlay and handles the behavior. When it's done doing it's thing, it will executes your callback. We're working with FreeWheel to get their JS ad manager up to the same level as their Flash ad manager.

Kelly

[Jason Burke]

From UI point of view, reusing the publisher player as the ad player removes some of the positioning challenges, but as Kelly and Zach mention, the dumping of the buffer, along with trashing of publisher event listeners (or introducing some events which create bumps in the road for various listeners that publishers have set up) are compelling reasons for the ad manager to using its own ad rendering componetn. There will be publishers that demand interface for tracking playback which likely begs for callbacks or event throwin from this component, but keeping control of the rendering is imperative for flexibility (and to avoid stomping on publisher functionality)

-Jason

[gthmb]

>There will be publishers that demand
> interface for tracking playback which likely begs for callbacks or event
> throwin from this component, but keeping control of the rendering is
> imperative for flexibility (and to avoid stomping on publisher
> functionality)

I agree that ad vendors should render outside of the publisher player.
As far as interfacing goes, VPAID, or a similar approach, is the way
to go. Basically, keep it event based and get something standardized
across ad vendors.

> > > w: longtailvideo.com • e: z...@longtailvideo.com • p: 212.244.0140 •

[Kelly Sutton]

We used a similar approach to of hiding/unhiding video tags for
certain events, like switching to HD. I'm trying to move away from
that though, since I don't like the complexity of having to deal with
two video tags and the constant juggling of event listeners.

We've been utilizing <source> elements for deciding what media to
attach to the video tags, but what I'm working on now has one video
element and all of the source elements.

To enact the preloading hack, I first load the src into a "data-src"
attribute. Loading the media is as easy as swapping "data-src" to
"src" and calling load(). It's pretty elegant. And legal.

This works fine in Chrome, but Safari is nice and crashy with the src
attribute swapping on a <source> element and subsequent load(). Anyone
seen hard Safari crashes while being aggressive with src and load()?

Kelly

> w: longtailvideo.com • e: z...@longtailvideo.com • p: 212.244.0140 •

[Zachary Ozer]

I would check out the Kaltura player source - I believe that they're doing this.

--
Zachary Ozer
Developer, LongTail Video

w: longtailvideo.com • e: za...@longtailvideo.com • p: 212.244.0140 •

f: 212.656.1335
JW Player  |  Bits on the Run  |  AdSolution