No way to set poster image after initialization

[tomsaffell]

After initialization, there is no way to set the poster image.
The player does have a .poster(src) function, but it doesnt change have any effect on the poster image src after initialization.

There are two possible fixes:

1. improve the .poster() function to handle changes to the poster at any time

2. allow a poster attribute to be passed with src, eg.

   .src({src: 'http://foo.com/foo.mp4', poster: 'http://foo.com/foo.jpg'});
   

Does anyone have a preference?

[rhues]

The first option would be helpful to me. Thanks.

[SergiDiaz]

Both options would be good, I'm having the same problem.

[heff]

The first option looks best to me. The best approach would probably be to trigger a 'posterchange' event any time poster(src) is set, and then have the poster component listen for that event and update the poster source depending on how it was originally set. https://github.com/videojs/video.js/blob/master/src/js/poster.js#L31

[tomsaffell]

@heff Yeah, that sounds like a good solution.

[jwlms]

What's the purpose of having a separate poster image rather than using the <video poster="poster_url">?

Posters don't seem to be displayed on iOS devices in the current implementation, and trying to append the poster attribute after initialization doesn't seem to work (which I think is the topic of this post). Would love to chip in here, but not sure why the poster attribute isn't being used in the first place.

[heff]

Trying to remember all the details, but I know there are/were a few reasons for creating a custom one.

• Older versions of Safari Desktop/iPad would break the video if you used the native poster. Also mentioned here: http://camendesign.com/code/video_for_everybody
• With Flash you run into security issues when you load an external image from a URL.
  So with those issues it was easier to be consistent and use the same poster across all platforms.

The older versions of Safari probably aren't a concern anymore, but I wouldn't want to kill the poster component because of Flash and potential other future techs that may not support a poster image, e.g. Quicktime or Divx.

[tomsaffell]

With Flash you run into security issues when you load an external image from a URL

I dont think that's quite accurate. When you load an image 'as data' (i.e. in a way that allows you to read pixel values) then you're subject to cross-origin restrictions and policies. When you load it merely to put it on the stage, there is no cross-origin restriction, or other security restriction that i know of.

Of course, that doesnt mean it isnt best to have a separate html element, I'd have to think about that.

Given that the controls have already established an html-over-flash pattern, it seems fine to continue that way to me.

[heff]

Here's the last conversation I was able to find on the matter with @alemay. I don't think we ever moved to bytes, and not clear on why Andy wanted to avoid that.

Either way, I'm not seeing a strong need to kill the poster image yet.

Okay, I think I've figured out the problem: oddly enough, it's the poster image. Flash chokes when you try to "manipulate" bytes in an loaded asset without having explicit authority to do so. Since there's no crossdomain.xml on the domain that the poster frame is being loaded from, Flash will load it, but attempting to do anything to it will throw an error and freeze the call stack. Apparently, this behavior is invoked when attempting to do two of the things that I need to do:

1. Set smoothing on the loaded image, so that it doesn't look like shit when it's resized.

2. Resize the poster frame when the player size changes.

I'm researching options right now. One person suggested loading the image asset as bytes, then running those bytes through an image parser to create a bitmap and then display it. I'd really like to avoid that.

[tomsaffell]

AFAIK, resizing would not cause that. There's a couple of different classes that can be used to load and display images, perhaps @alemay's comments refer to a more restrictive one.

But maybe this is a red herring - maybe it should be an html element anyway - isnt that simpler? What's the downside?

[heff]

Yeah, not sure of any yet. But doesn't hurt to document all this either way. :)

[alex-bender]

I found out another way:

1. get the video
   var video = $('#video_1 video')
2. change attr
   video.attr('poster', 'http://1x1px.me/000000-0.png')

[faiyazalam]

My working code:
let player = videojs('videoplayer', options);
player.poster("video_poster_url");
player.src({src: "video_url", type: "video/mp4"});

[gkatsev]

We also have a loadMedia method you can use to do it one operation:

player.loadMedia({
  src:  {
    src: 'video.mp4',
    type: 'video/mp4'
  },
  poster: 'poster.png'
});