#324 ✓ checked-in
David Humphrey

Allow non-HTML5 video backends to work with Popcorn

Reported by David Humphrey | February 9th, 2011 @ 07:42 PM | in 0.4

Right now we assume a mapping between a Popcorn instance and an HTMLVideoElement. This is logical, and was the right place to start, but it is limited going forward. Many bugs currently filed assume a way to pass something else, for example, a link to a youtube video, or vimeo, or blip.tv, or an audio element, or a set of videos that are to be chained, or an animation (Processing.js, WebGL), or a slideshow of Flickr images, etc.

We need a way to pass an object to the Popcorn ctor that implements enough of a video-like interface to be usable by the guts of Popcorn. Likely this means a set of wrapper functions, and therefore a back-end plugin architecture. This fits well with our parser-as-plugin, command-as-plugin model now. It also frees us from having to support a million strange and obscure formats: we specify the interface that any of these objects must implement, and then leave it to them.

Rick tells me that this change is non-trivial, so we should plan and do it right. However, we also need to move on it--not supporting things like YouTube is going to become a deal breaker.

I'm going to ask my team to focus on this over the next 2 weeks, and any others who want to join are welcome. I'm setting this for inclusion in the 0.4 time frame.

If other people have examples of things they know they want, please list them in this bug as examples to help with our design work.

CC'ing various people for thoughts.

Comments and changes to this ticket

  • Brett Gaylor

    Brett Gaylor February 9th, 2011 @ 07:46 PM

    My thoughts are - YES!

    We do need to get some answers from Youtube about HTML5 / webM. Boaz had some thoughts there.

  • David Humphrey

    David Humphrey February 9th, 2011 @ 07:49 PM

    Yeah, the youtube html5 video story is good to know, but it's not going to change our game plan here: we have to support all of youtube, not the subset they have now.

  • brianchirls

    brianchirls February 9th, 2011 @ 08:01 PM

    • Tag set to convenience, feature, selectors

    While you're at it...

    When you're passing Popcorn a string, it only accepts a video id. It might as well handle jQuery-style selectors. I'm guessing that this was planned all along, since the id requires a # before it.

    One of the consequences of doing this would be that you would potentially apply one Popcorn object to multiple targets. This is not necessarily a bad idea, as long as it's documented. It can get tricky/ugly if the target media are synchronized, but that may not always be the case. I can see where someone would want to have multiple media objects on a page, and certainly where they might want to use class- or tag-based selectors.

    Of course, once you're doing that, you might as well accept comma-delimited lists of selectors or even an array. This is not as hard as it sounds; I've done exactly this for Loaderator. Let me know if you need help.

    I'm a big fan of generalization, and this fits nicely with the jQuery-inspired interface. We should go out of our way to accommodate the needs of people using the library, especially those who are not expert programmers. [coughbrettcough] A little extra code to make things easy goes a long way, and most of this stuff will run once at the beginning so it shouldn't affect performance.

  • David Humphrey

    David Humphrey February 9th, 2011 @ 08:27 PM

    from irc...

    19:59 < rwaldron> humph, "Rick tells me that this change is non-trivial"
    19:59 < rwaldron> i said no such thing

    ...which is great news. I'll let Rick weigh in and correct me when he has time.

  • Rick

    Rick February 9th, 2011 @ 08:32 PM

    There seems to be a lot of noise in this ticket and not a lot of signal.

    Most of the "issues" with what Popcorn() accepts can be easily avoided with proper, thorough documentation. Thats the ticket that needs to be filed: documentation.

    I'm pressed for time at the moment and will continue with thoughts on actual ticket subject matter tomorrow AM


    I just wanted to clarify that my "signal/noise" comment was in no way meant to be rude, condescending or obtuse. I was just trying to indicate that I felt the discussion veering off topic.

    If my words came across the wrong way - I am certainly sorry.

    That being said, I'd like to push forward with a high-five to everyone - let's keep making the future awesome!

  • David Humphrey

    David Humphrey February 9th, 2011 @ 08:44 PM

    Hey Rick,

    No criticism is intended, and I'm hoping you'll chime in here, given your knowledge of the core. Our goal is to not go at this piece-meal in other tickets, when a thorough decision could have/should have been made up front wrt supporting all these various things people will want to use. I do think it's more than a documentation issue, though: if I wanted to take a WebGL animation today, and plug that into Popcorn to have it respond to timing events, there's no clean way to do it. However I know it could be made to work, and that's where I'm hoping we'll go.

    I agree, let's not have noise and stay focused on making popcorn awesome.

  • brianchirls

    brianchirls February 9th, 2011 @ 08:54 PM


    I agree with you about documentation. In particular, I see that Popcorn will accept a function in place of an element id, and I don't see this explained anywhere. Also, the Mozilla wiki page is well out of date, which is confusing.

    But I have to take issue with your signal/noise comment. I know quite a few people in the film, music and design communities who are learning very basic Javascript. Brett, Ben and I, among others, are doing what we can to convince artists of the necessity of programming skills, but they are never going to know how to use closures and GitHub or even get around to reading complicated documentation. These people are exactly the ones we need to be courting. We are still very much in the position of selling the world on open video, and we cannot do that if we are exclusive about who can use our the tools.

  • boaz (at bocoup)

    boaz (at bocoup) February 10th, 2011 @ 12:34 AM

    Humph, the html5 videos that youtube have transcoded are not a subset. They have full coverage transcoded as far as I know. What we need is for them to expose an programmatic way of getting them. I'm working really hard on evangelizing popcorn to them. Ideally, they will expose an HTML5 API, and we can implement that. Writing a mapping to the Flash API's method names is not compelling to me. If we could get the real webm's and h.264's, it would be better.

    Give me some time to have this conversation with them.

  • boaz (at bocoup)

    boaz (at bocoup) February 10th, 2011 @ 12:35 AM

    As far as selectors, brianchirls, I see your point. I'm into making this thing easy for artists.

    I do not, however, think we should implement a full selection engine in Popcorn. While we want to serve artists, we also want to server programmers who are building real applications, and they will not like yet another DOM manip library on the page. I think the answer for artists is to think about how we can implement better integration with jQuery. Maybe we can ship a jQuery.fn.popcorn plugin that consumes Popcorn and creates a sexier API. Check out the original API draft notes that we put together. We outlined how this could work there.

  • boaz (at bocoup)

    boaz (at bocoup) February 10th, 2011 @ 12:46 AM


    The list of things popcorn could do is even longer than what has been discussed here. Popcorn could be used for controlling and responding to events in any linear experience. That seems like it might be too much to fit into one API. Especially, when we are dealing with many different entities that have their own internal timelines.

    Instead, we might consider abstracting the timeline managemen system out of popcorn to be a higher level library for managing timelines and linear experience development in general, and then let popcorn consume that library for the html5 video timeline, along with other libraries which would consume this time line management system for webgl, DOM animation, canvas, html5 slideshows, tablet book software, youtube, etc, etc.

    Maybe we call what I'm describing popcorn, based on the brand momentum we have, but, what I am describing really is not popcorn, it's something that bites off way more than what I thought popcorn was intended to do. However, I do like all these ideas, and I think we should implement them somehow together..

  • David Humphrey

    David Humphrey February 10th, 2011 @ 12:47 AM

    All of this stuff is outside what I'm talking about in this bug. I'm not arguing, or interested in arguing, the merits of youtube's webm or html5 commitment, or how we pass a video element into the constructor, whether by id or as an element, etc. We can file other bugs for those things if needed.

    I'm talking about something very specific: for cases where you don't have an html5 video, I want a standard interface for wrapping functionality that is exposed through some other API. Further, I want this be pluggable, such that we don't have to argue about what popcorn should and shouldn't support--we will support anything that can be wrapped in this interface.

  • boaz (at bocoup)

    boaz (at bocoup) February 10th, 2011 @ 12:50 AM

    Why do we want to support situations where users do not have HTML5 video? I thought we were trying to leverage you tube for content, not playback.

  • Brett Gaylor

    Brett Gaylor February 10th, 2011 @ 01:50 AM

    I've retyped this comment a few times, but I think my best contribution is as the filmmaker here.

    Dave - "we will support anything that can be wrapped in this interface."

    Can you limit that to Time-based media? It seems like if so, then Boaz's concern that this is trying to do to much would perhaps be premature. We'd be talking about a fairly limited amount of things, and they'd probably have to pass their time in a consistent format, which would also be a filter.

    Boaz - "Why do we want to support situations where users do not have HTML5 video?"

    I think we have to assume that general consumers, nor media creators, really care that much about our internal preference for HTML5. And I've had to come to terms with the fact that flash is going to be with us for a while!

    It could certainly be that the best approach to youtube support, as popcorn exists now, is through a forthcoming HTML5 API. However, if Humph's approach would also gain us support of a variety of media I really think its worth discussing.

    Creatively, if it means that we could create experiences that mixed video, audio, webGL, processing.js - of course its interesting.

  • Brett Gaylor

    Brett Gaylor February 10th, 2011 @ 01:51 AM

    PS - if that means creating a new library and calling it popcornkernel or sodapop or jiffypopper etc, lets not be afraid of doing that, either!

  • Rick

    Rick February 10th, 2011 @ 09:09 AM

    • State changed from “bugs” to “assigned”
    • Assigned user set to “Rick”

    This is an initial draft of the pluggable playback engines idea...


    It's a little out-dated now, but I will bring it up to date

  • Rick

    Rick February 12th, 2011 @ 03:53 PM

    Closed #288 which was the same as this, but the discussion has moved further here.

  • vvasabi

    vvasabi February 14th, 2011 @ 01:03 PM

    I have just noticed this ticket, after spending a few hours on #140. What I have done so far to enable Youtube support is to hack into Popcorn.p.init and to discover if the video passed in is Youtube. data.youtube is the flag that I currently use. Then, the plug-in that I have written overrides Popcorn's API, including play(), pause(), currentTime(), etc., and performs Youtube logic if data.youtube is true.

    I think I'll have to wait for this ticket before continuing on #140. In the meantime, I would be interested in participating the development for this ticket. Let me know if there is anything that I can help with.

    ps. Rick, your draft of the pluggable playback engine looks really interesting. Since Youtube uses different APIs to play and pause, etc., would the pluggable facility also allow for that?

  • Rick

    Rick February 14th, 2011 @ 02:18 PM

    My next step was to investigate that very question. Essentially, what you've done is what I was thinking could be done in the playback engine factory.

    I'm thinking that instead of writing a plugin, perhaps you could abstract that work and begin laying the foundation for the youtube playback engine - seems like you've already done a lot of the work

  • Scott Downe

    Scott Downe February 14th, 2011 @ 02:50 PM

    I think we just need a way for the user to create a playback plugin, which would be definitions for functions used in the timeupdate function, play, pause, currenttime, etc.

    If no playback is defined, we default to HTML5, if a playback is defined, but a needed function in the playback is missing, we create an empty one.

    This way users and us have the ability to make popcorn control and use ANYTHING we can think of, so when a strange spec is dropped on us, we have the tools to create it. We then make some playback plugins for common things we predict we will need, ie youtube.

    Maybe how this is done is when the popcorn object is created, and when we usually pass in a string containing the HTML5 video id, we can also accept an object. This object would contain the functions needed by our update internals.

  • vvasabi

    vvasabi February 14th, 2011 @ 03:07 PM

    I'm also interested in abstracting an interface for plug-in writers to easily create playback support for new video formats. Since I'm working on the Youtube plug-in, I'm proposing the following interface, based on my current needs for the Youtube plug-in:

      name: 'YouTube Video Handler',
      handles: function(videoDomElement) {
        // return true if this handler can handle the DOM element passed in; false otherwise
      createHandler: function(popcornObject) {
        // create an instance of the handler object for the popcorn video instance specified
        // i would imagine the popcorn core stores this instance for handling subsequent function calls for the video
        return new YouTubeVideoHandler(popcornObject);
    function YouTubeVideoHandler(popcornObject) {
      this.popcorn = popcornObject;
    YouTubeVideoHandler.prototype.play = function() {
      // handle play operation
    // create similar methods for pause, stop, mute, etc...
    YouTubeVideoHandler.prototype.addEventListener = function(eventName, func) {
      // This is called by Popcorn core to register event handlers, such as for the
      // "timeupdate" event. Video handler is responsible for calling the handlers
      // to update Popcorn core's status.
      // And, of course, a formal set of these events needs to be defined.
    YouTubeVideoHandler.prototype.removeEventListener = function(eventName, func) {
      // opposite of the above
  • Steven W

    Steven W February 14th, 2011 @ 04:18 PM

    Hey guys,

    I've also been putting in some work on abstracting out common video functions for a wrapper to be used to define a "data contract". It's messy at the moment, but it seems to have gone in much the same direction as vvasabi's. I've been using youtube as a basis for development as well.

    Part of the reason for the mess is that I've been using their classic JS API rather than the more object-focused iframe api (which is still in beta), but you can see the demo and code behind files.

    To build on vvasabi's interface, I ended up using these:

    var videoProto = {

    get duration() {
      return undef;
    get paused() {
      return undef;
    set src( val ) {
    get src() {
      return undef;
    get currentTime() {
      return 0;
    set currentTime( val ) {
    get readyState() {
    pause: function() {
    play: function() {
    seek: function( time ) {
    extractId: function ( uri ) {
      // Would extract the id of a video source from a uri
      // Useful as the uri gievn to the youtube player follows a different format (www.youtube.come/e/ID)
      //   than their web url (www.youtube.com/watch?v=ID)
    get type() {
      // would return a string (youtube)
    addEventListener: function( evtName, fn, doFire ) {
    removeEventListener: function ( evtName, fn ) {
    distachEvent: function ( evt ) {


  • Rick

    Rick February 14th, 2011 @ 04:25 PM

    get/set is cool - but how much support can we confirm on that?

  • Steven W

    Steven W February 14th, 2011 @ 04:42 PM

    I was going off Resig's 2007 article which cites "Firefox, Safari 3+ and Opera 9.5", which I believe largely coincides with <video> support in those browsers (the code was tested on Chrome 8 as well). Though now that you've brought it up, it seems counter-intuitive to base support for a plugin specifically aimed at non-HTML5 video support on what can be expected in browsers with HTML5 video support.

    This structure would probably be more useful if implemented as getX/setX functions.

  • Rick

    Rick February 14th, 2011 @ 04:51 PM

    So, let me shake this one up and throw you a nasty curveball... Youtube/Flash support secretly means IE support.



  • vvasabi

    vvasabi February 14th, 2011 @ 04:57 PM

    I agree with Rick's point. Though this is probably going to be a bad thing to suggest for a library originally aimed at working with HTML 5 videos. Personally, I have the interest to implement Popcorn.js for a few commercial projects of mine that require closed captioning. And, yes, "commercial" means IE support. So, if Popcorn.js can work with any given Flash video player and on many browsers (such as IE), it would be the perfect tool for many commercial projects.

  • Brett Gaylor

    Brett Gaylor February 14th, 2011 @ 05:19 PM

    We welcome IE support.


  • David Humphrey

    David Humphrey February 14th, 2011 @ 05:44 PM

    Great discussion thus far, thanks for it. Let me add some more thoughts.

    I think it's safe to say that popcorn.js is really about open, HTML5 video, and that our default behaviour is to work with the HTML5 media element spec. That said, and as Rick and I have started describing it in our discussions, we want to support any video-like-object. To me, and returning to what Brian first suggested, and others have implied, this means duck typing: if you can make your object video-like (in the sense of implementing enough of the HTML5 spec that we can use it), we'll let you pass us that object instead of a reference to a video. Whatever it ends up looking like, I imagine:

    var popcorn = Popcorn('#video'); // the normal way
    var youcorn = Popcorn(new Popcorn.YouTubeEngine("http://www.youtube.com/watch?v=dQw4w9WgXcQ")); // youtube wrapper, exposing HTML5-like interface
    var WebGLAnimation = function() {...};
    WebGLAnimation.prototype = Popcorn.BaseEngine.prototype
    var glcorn = Popcorn(new WebGLAnimation(...)); // WebGL animation that acts like a video
    var multicorn = Popcorn(new Popcorn.Wrapper([
                              new Popcorn.DefaultEngine('#video1'),
                              new Popcorn.DefaultEngine('#video2'),
                              new Popcorn.YouTubeEngine("http://www.youtube.com/watch?v=dQw4w9WgXcQ")])); // A set of 3 videos, 2 HTML5 and one YouTube that act like one

    Without bike shedding on the appropriate interface, it should be possible for us to cook up all kinds of backends, and let our users do the same, without changing the core. To do that, we have to use only the parts of the HTML5 spec that are necessary, since every other engine will need to support or fake the same.

    I'd like to suggest that in addition to making YouTube work, we pick one or two other backends which are really different. I'd like to see us design the interface for the engine in such a way that it doesn't limit us later (not that we can't file bugs on it as we go).

  • Brett Gaylor

    Brett Gaylor February 14th, 2011 @ 05:58 PM

    finally a comment I can comment on myself!

    From a branding perspective, this actually helps with the popcorn metaphor - we're cooking up a bunch of kernels to watch a movie. We don't care what kind of corn they came from, or whether you make it in a microwave or on the stove, or how you eat it.

    (slinks back to his cave) bg

  • Rick

    Rick February 14th, 2011 @ 07:04 PM

    So, just to check in, I am still working through different possible solutions to the pluggable playback engine. Once I have one that doesn't wreck our existing work, I'll be pushing a branch for review.

  • vvasabi

    vvasabi February 14th, 2011 @ 10:51 PM

    Based on humph's comment, I have created a quick Youcorn (don't swap 'c' with 'p') proof-of-concept class on github. This class can work with many features of Popcorn and requires only minimal modifications to popcorn.js.

    The only challenge I have so far is to implement HTMLMediaElement interface's attributes, in such a way that changes to them get handled properly. I would love to know if there are methods to implement getters and setters for browsers that don't support them.

  • vvasabi

    vvasabi February 15th, 2011 @ 02:24 PM

    Just had a quick discussion with Steve and Scott. It appears that there are no easy ways to implement attributes in JavaScript that is cross-platform compatible. The solution came out of the discussion was that we would slightly relax the HTMLMediaElement interface, and support alternative ways to get and set attributes.

    For example, attributes may be implemented as functions. When accessing the values, popcorn.js core needs to check if the attribute is a function, and deal with it accordingly. That way, *corn wrappers mocking < video > can be created more easily.

    Right now I need to catch up with some other work, but I will come back to Youcorn once I have the chance.

  • Rick

    Rick February 15th, 2011 @ 03:11 PM

    I'm not sure what "relax the HTMLMediaElement interface" is implying, but the existing API must stay intact and must pass 100% of their existing unit tests.

    The fact is that this code is already being used outside this little circle of devs and we're obligating to continue supporting the API

  • annasob

    annasob February 15th, 2011 @ 03:30 PM

    Hey Rick,
    The consensus there is that Steven W and vvasabi will start on #280 and #140 using JavaScript just to get stuff working. When this ticket is done their code will then be re-factored to use it. The idea here is not to be blocked by this ticket.

  • vvasabi

    vvasabi February 15th, 2011 @ 04:02 PM

    Rick, sorry for the confusion. What I mean is, for wrappers that try to mock HTML5 videos, the core popcorn.js engine would recognize and work with certain uses of non-HTMLMediaElement-conforming syntaxes. Using a function instead of an attribute to implement video.currentTime in the wrappers is one example that I would like to propose. Support for HTML5 videos will remain 100% the way it is now.

  • Rick

    Rick February 21st, 2011 @ 06:43 PM

    @vvasabi I'm working on some tests - is it ok if I throw your code into the mix?

  • vvasabi

    vvasabi February 24th, 2011 @ 01:51 PM

    Please feel tree to do so, although I'm not sure how well my code can help.

  • Steven W

    Steven W February 24th, 2011 @ 02:27 PM

    The Vimeo player for #280 is ready for integration testing.
    Feel free to pull from here: https://github.com/stevenaw/popcorn-js/tree/280

  • vvasabi

    vvasabi February 27th, 2011 @ 05:56 PM

    I use the HTMLMediaElement approach, that humph suggests, to implement the Youtube plug-in. More details, an online demo, and comments about this approach are in #140.

  • Steven W

    Steven W March 2nd, 2011 @ 07:07 PM

    Just checking in on the Vimeo progress here. #280 is nearly ready for peer-review, just two minor issues (one timing-related, one dependency-related) to resolve.

  • Rick

    Rick March 3rd, 2011 @ 11:26 AM

    I've been reviewing the development of the Vimeo #280 and Youtube #140 players - that has happened without a change to the core and there seems to have been a new option opened up - and that is to not change anything within core. The players have been developed to co-exist with the current core and I'm not sure that changing internals and adding more work is the right way to go. Additionally the two players are quite disparate and in their current state would require a great deal of abstraction bridging to normalize.

    I think that the owners of #280 and #140 need to put their heads together to come up with a consistent API - I'm willing to help them with this if they need

  • vvasabi

    vvasabi March 5th, 2011 @ 07:12 PM

    Below is the result of the discussion with Steve pasted directly from EtherPad. A comparison of Steven and vvasabi's approaches:


    • HTMLMediaElement properties and methods are applied directly to the video's DOM object. This allows common DOM behaviour like getElementById
    • Constructor takes the DOM element ID and (optionally) the video url
    • Ordinary attributes are used for video attributes, with a setter function given for modifiable ones (open to data manipulation, but identical to HTMLMediaElement Interface
    • No modification to Popcorn's core has been done.
    • User of this plugin needs to create a Popcorn.VimeoEngine object


    • A mediator is inserted between Popcorn and the video's DOM object to implement HTMLMediaElement.
    • Popcorn's core is modified to handle the insertion of an object into the constructor, instead of a string. A single get/set function is made for each attribute, which sets when an argument is passed (closed to data manipulation, but requires code modifications and a DefaultEngine)
    • User of this plugin is responsible for instantiating a Popcorn.Youtube object and passing it to Popcorn's constructor, after Youtube fires onYouTubePlayerReady().

    Common Approaches

    • Events are faked by a private collection of handlers
    • Events fired by the underlying video player are converted to the closest HTMLMediaElement events.

    Common Issues

    • There is often an event that needs to be fired before the video becomes accessible or usable, some functionality and API calls had to be defered
    • Some HTMLMediaElement events and properties are difficult or impossible to mock.

    Normalized Approach for 0.4

    • Constructor receives a DOM id and optionally uri
    • Creation of Popcorn.players.p, which is an implementation of the HTMLMediaElement interface with empty methods
    • Use of Popcorn.extend to merge DOM object with Popcorn.players.p and custom-overridden functionality:
        Popcorn.extend(domElement, Popcorn.p, { /* Custom code here */);
    • Abstraction of LikeADOM to Popcorn.players.EventHandler
    • Popcorn's constructor accepts an object with the HTMLMediaElement Interface
    • Player plugins are placed under players/, e.g. players/youtube.

    Enhancements for 0.5 (Wish List)

    • Video player plugins are registered into Popcorn, like parsers.
    • Users pass in video DOM element's id and/or url into Popcorn's constructor.
    • For Popcorn to work generically with any elements and/or url, deferral handling of method calls may need to be done, due to the delay that certain video players require to become ready.
    • Video player plugins register detection methods, that Popcorn calls to detect the video type (may be done by url regex or other means).
    • Heavy modification into Popcorn's core may be necessary.
    • A list of events that Popcorn core expects and their behaviours may be published, so that player plugins can implement more easily.
    • Popcorn's functionality may not depend on events that cannot be easily implemented across different plugins, such as ones that notify network status.
  • vvasabi

    vvasabi March 5th, 2011 @ 07:26 PM

    Since I don't have enough knowledge and experience with Popcorn, I would like to ask for direction on which approach to take. Also, I think the decision of such may need to take into the consideration of how client code is written.

    Some approaches above require the client code to be aware of the video used. Others have the benefit of being format agnostic, and have one single way to handle different types of video players. For example, having to call Popcorn(new Popcorn.Youtube('#elementId')) requires the knowledge of the video format beforehand. If Popcorn is able to figure out the format, simply calling Popcorn('#elementId') is sufficient.

    Both of these approaches would have benefits and tradeoffs. Though, I think what is more important is to make sure that future client code would not be broken with later Popcorn releases.

  • boaz (at bocoup)

    boaz (at bocoup) March 5th, 2011 @ 08:14 PM

    It's awesome to see progress here.

    Steven: Your approach is clever. I like how you've thought of a 'fill in the cracks' way to support other interfaces. However, this approach it is probably a bad idea for us to expando a DOM element. This is bad convention, and also dangerous. See http://kangax.github.com/fabric.js/test/demo

    vvasabi: I like the idea of being able to pass an options object to your API to setup my video, but I don't think we should be overloading Popcorn like this.

    Overall, the goal should be to create pass throughs where available or manual implementations where not, of all the Youtube JS API methods to the Popcorn methods following HTML5 Media Element JS API idioms. EG: methods like play() and load(), and events like canplaythrough and durationchange.

    Also, vvasabi, your point that we should "take into the consideration of how client code is written" is an excellant one! API first is a great way to talk about implementation. Take a look at what I did here for sequencing: https://webmademovies.lighthouseapp.com/projects/63272/tickets/385-...

    For example, I might like to be able to do something like this:

      .youtube('#container', 'http://youtube.com/asdsd')
      .listen( 'canplaythrough', function(){
        console.log('I wish this was html5')

    Also, take a look at Rick's approach to extending Popcorn: https://github.com/rwldrn/sequence/blob/master/sequence.js

  • Scott Downe

    Scott Downe March 7th, 2011 @ 01:00 PM

    I am worried about changes to core regarding tickets #280 and #140.

    Imo, getting tickets #280 and #140 working with hacks without touching core is the way to do this, that way when we have the framework to register sequences and playback devices in core, we only have to update the files in #280 and #140 to use said framework. Seems more modular to me.

  • Rick

    Rick March 7th, 2011 @ 01:47 PM

    I'm mostly with Scott here... I like the points made in "Normalized Approach for 0.4" as they are actually in line with the initial vision of having a plugin-like architecture.

  • annasob

    annasob March 9th, 2011 @ 04:38 PM

    • Assigned user changed from “Rick” to “Scott Downe”

    We had another discussion about this today. YouTube and Vimoe is still gonna land in 0.4. Scott will be editing the popcorn core in order to allow passing in an object/element into the constructor. Scott will update this as he starts coding it.

  • Scott Downe

    Scott Downe March 11th, 2011 @ 11:33 AM

    • State changed from “assigned” to “peer-review-requested”


    This allows popcorn to accept an object that looks and acts like an html5 video element, or an id of an html5 video element, or an actual html5 video element.

    Some tests added.

    Tests passing.

    Lint passing.

    Style guide followed.

  • Rick

    Rick March 11th, 2011 @ 01:13 PM

    • State changed from “peer-review-requested” to “under-review”
  • Scott Downe

    Scott Downe March 11th, 2011 @ 04:08 PM


    error checking
    more tests
    and nop functions for required functions like play/pause


  • Rick

    Rick March 11th, 2011 @ 05:11 PM

    • State changed from “under-review” to “super-review-requested”
    • Assigned user changed from “Scott Downe” to “annasob”

    Tested in and passing: Chrome 9, 10, 11; FF 3.6, 4b12, 4

    I'll update the docs when this lands

  • Scott Downe

    Scott Downe March 11th, 2011 @ 06:48 PM

    an update to my commit above ricks, that is in the commit message, but not here in the comments, that I scrapped a large chunk of things I was experimenting and went with a clean and simple solution.

    I simplified by not throwing when an invalid string or element was passed in, or the nop functionality to the object.

    As Rick said, that should be a documentation issue.

    In the future though, we can explore more robust error and validation, but for now, as we are putting in very new and experimental code, let's keep it as clean as possible.

  • Steven W

    Steven W March 12th, 2011 @ 08:36 PM

    Scott, that all looks awesome. I agree we need to keep things clean, but I have a few concerns about the core changes.

    The players need to be able to execute api calls and other code when attributes like currentTime and volume are assigned a value. We can't use javascript get/set because of support concerns and the performance of Popcorn.extend. Is there any way we can allow the core to expect these wrapped attributes/methods as being functions, which in turn may or may not receive an argument?

    I'm thinking something like this:

    Also, vvasabi and I have both found we need to work with our own event handling collections within the player wrapper. Is there any way we can get something like this to be a standard util in Popcorn (like xhr) so this code doesn't have to be duplicated across players?

  • Scott Downe

    Scott Downe March 14th, 2011 @ 10:00 AM

    Also, vvasabi and I have both found we need to work with our own event handling collections within the player wrapper. Is there any way we can get something like this to be a standard util in Popcorn (like xhr) so this code doesn't have to be duplicated across players?

    This may be a possibility.

    The players need to be able to execute api calls and other code when attributes like currentTime and volume are assigned a value. We can't use javascript get/set because of support concerns and the performance of Popcorn.extend. Is there any way we can allow the core to expect these wrapped attributes/methods as being functions, which in turn may or may not receive an argument?

    I want to brainstorm ideas for this with you at some point today if you can, Steven.

  • Scott Downe

    Scott Downe March 14th, 2011 @ 10:25 AM

    Steven, what about something like this: http://en.wikipedia.org/wiki/Observer_pattern

    What I am thinking is have a listener function going, checking for state change in volume or current time, and calling youtube.currentTime( n ) if state is changed. If there is a place in the code already like this, let me know, but if we have to, we can have a independent listener function for this task alone.

  • Scott Downe

    Scott Downe March 14th, 2011 @ 11:02 AM

    • State changed from “super-review-requested” to “review-needs-work”
  • Scott Downe

    Scott Downe March 14th, 2011 @ 11:03 AM

    • State changed from “review-needs-work” to “super-review-requested”

    I accidentally commented on the wrong ticket.

  • Steven W

    Steven W March 14th, 2011 @ 04:21 PM

    Looks good. Chatted with scott and we'll be going ahead with the observer pattern in players for now. Also, having an event handling system within popcorn for use by other players is useful, but something for the 0.5 timeframe.


  • Steven W

    Steven W March 14th, 2011 @ 04:22 PM

    • State changed from “super-review-requested” to “review-looks-good”
  • annasob

    annasob March 14th, 2011 @ 04:27 PM

    • State changed from “review-looks-good” to “staged”

    Staged in annasob/popcorn-js commit

  • annasob

    annasob March 21st, 2011 @ 02:47 PM

    • State changed from “staged” to “checked-in”
    • Milestone order changed from “24” to “0”
  • annasob

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Popcorn.js is an HTML5 video framework that lets you bring elements of the web into your videos.

Popcorn.js is a project of Web Made Movies, Mozilla's Open Video Lab.

Shared Ticket Bins

Referenced by