[YouTube-API] Re: using loadVideoById, iPad can only play 4 videos before it stalls

Never heard back on this, so I'm just following up again.  It would be extremely helpful for us for there to be some movement on this issue.  I previously provided two possible ways in which to modify the API so that those of us needing continuous play could get our applications working properly on devices requiring HTML5.  A little more detail:

 

1.) The first resolution was to simply allow us to change the size of the video tag pool.  In the present API source, when the user first initiated playback, one of the things that happens is the initialization of a pool of video tags via the call:

 

ql.fillPool(4);

 

What I'm requesting is that we be provided with a way to override the hardcoded 4 and pick something else.  For example, I might instantiate the player like this:

 

player = new YT.Player('player', {
    height: '390',
    width: '640',
    poolsize: '40',
    events: {
        'onReady': onPlayerReady,

        'onError': onError,
        'onStateChange': onPlayerStateChange
    }
});

 

The "poolsize" would then get used instead of the default of 4 when calling fillPool so that I can play 40 consecutive videos without stopping.  This seems like it would be realtively easy to implement.  Other than perhaps providing a warning to developers that excessive pool sizes could impact performace, it could be implemented with confidence that it wouldn't impact any existing API users, as their current code would still use the default of 4 tags.  Given that we've been waiting on a fix for a year now, this is at least would provide some flexibility for developers so that we aren't limited by the "arbitrarily" selected cap.

 

2.) As I mentioned previously, the other option is to reuse an existing video tag rather than creating a new one.  There's a function in the API right now that is as follows:

 

    p.zt = function() {

        return this.a.length ? this.a.pop() : rl(this)

    };

 

I changed the single line of code in that function to instead read:

 

        return this.a[0];

 

After doing so, I could play as many videos consecutively as I wanted.  Granted, this would entail testing across multiple platforms and OS versions to ensure that there aren't and side-effects from reusing the same video tag repeatedly, and I completely understand that would take time.  I also understand that this isn't truly a single-line fix, since if this approach were found acceptable, it would be necessary to clean up the code to remove the portions related to the creation of the video tag pool.  I just thought it might be helpful to show the code to better explain my point above.

On Friday, August 10, 2012 11:00:08 AM UTC-4, Jeffrey Posnick wrote:

Hello Ted,

 I've just pinged the internal bug for an update, but as of right now, the situation remains the same.

Cheers,

-Jeff Posnick, YouTube API Team

apiblog.youtube.com | Google+: goo.gl/bZflZ

YouTube Developer Relations is hiring! developers.google.com/jobs

On Friday, August 10, 2012 12:59:54 AM UTC-4, Ted Cannelongo wrote:

Any possibility of getting an official update on the status of this bug?  Has any progress been made since last year?

--
Starting October 15, 2012, this group will stop accepting new posts. We recommend that developers start using Stack Overflow and the Issue Tracker for YouTube API support. More details about this change and relevant links can be found at http://apiblog.youtube.com/2012/09/the-youtube-api-on-stack-overflow.html