Forum user: flexer

OK, if anyone interested, I changed the buildPlaylist method adding the regexp that could modify the src.

The fix could be applied also on the href attribute (I think that you could pass *[src|href] as the selector, for example).

function buildPlaylist() {
  wrap.empty();
  $.each(self.getPlaylist(), function() {  
    wrap.append(toString(this)); 
  });                             
  $.each(wrap.find("img"), function() {
    this.src = this.src.replace(new RegExp("^" + location.protocol + '//' + location.hostname + '.*/http'), 'http');
  });
  bindClicks();
}

Sorry, the problem persists but the patch is completely wrong. It must be applied where the attributes are actually injected into the DOM, not in the toString().

:(

Still working...

Just to have a better focus, this is an example on how IE6/t mess things up:

<!-- Given this HTML -->
<div id="orso"></div>

...

$('#orso').html("<img src='${snack}'>");

$('#orso img').attr('src', 
                    $('#orso img').attr('src')
                                  .replace('${snack}', "http://farm4.static.flickr.com/3641/3623885917_bc9bdfa5ea_t.jpg"));

alert($('#orso img').attr('src'));

In IE6/7 the alert will show an extra hostname IN FRONT of our http://farm4...

(this is a well known bug, fixed in IE8)

I don't know if this is could be called a "bug", but when you use ${templates} in the playlist JavaScript plugin you *could* crash onto a bug of IE6/7 by which any modified src or href attribute will have the hostname prefixed.

Say I have something like that: "<img src=${mysrc}>" in my template. When the modified src (via the toString() method of the plugin) will be re-injected in the DOM, IE6/7 will prepend the hostname. That's bad, because I could be using Flickr, for example, as my src hostname.

The fix is simple:

function toString(clip) {
   var el = template;
		
   $.each(clip, function(key, val) {	
      if (!$.isFunction(val)) {
        el = el.replace("${" +key+ "}", val).replace("$%7B" +key+ "%7D", val);
        // My FIX:
        el.replace(new RegExp("^" + location.protocol + '//' + location.hostname + '/http'),'http'));
      }
   }); 
   return el;
}

What do you think?

Best regards,
Claudio

That should *perfectly* do the job (for our use case, at least).

If I'd you, I wouldn't use the "config" name for the file... in case of (for example) RTMP streams, the config file would be different for every Video. So we'd like to be able to write something like ...?config=config_3244.js where 3244 would be the ID of the Video file.

Couldn't you use something like ?config_file=something_anything.js ?

Looking forward to download the DEV branch (seen a commit about this "issue" two hours ago) ;)

As you may know, when a media provider is whitelisted by Facebook, one can use links coming for that provider to embed rich content in its wall. We can't use a full EMBED element, but only use a URL.

Is there a way to pass a full flowplayer config via a GET variable to the swf? It *seems* that a support has been added to 3.1, but I can't find anything in the doc.

Thank you

Finally, I found a way to use an image as the "cover" for an RTMP stream.

The key is: even if you use a "streams" and not a playlist, flowplayer builds (internally) a playlist array in its config object. So we create a playlist anyway with the photo as the first item and the streams as the second one.

Look:

    flowplayer("player", "/flash/flowplayer/flowplayer-3.0.7.swf", {
      clip: {
        autoPlay: false,
        autoBuffering: true
      },
      playlist: [
        {url: "http://www.example.com/mycover.jpg"},
        {provider: 'my_provider',
         streams: [
          {url: 'mp4:FL507082.f4v'},
          {url: 'mp4:FL507086.f4v'},
          {url: 'mp4:FL507089.f4v'},
          {url: 'mp4:FL507090.f4v'},
          {url: 'mp4:FL507092.f4v'}
         ]}
      ],
      plugins: {
        my_provider: {
          url: "/flash/flowplayer/flowplayer.rtmp-3.0.2.swf",
          netConnectionUrl: "rtmp://mystreamingserver.com/store-50/"
        }
      }
    });

Yes, that is a bug... You can track onBegin

I'm playing mp3 via RTMP with FlowPlayer 3.0.x

Using streams: [ ... ].

California, try NOT using the file extension, like "mp3:network/mp3_high/test"

I'm facing a similar issue: starting to play an mp3 streamed via RTMP does not fire the OnStart event on the clip (I think this is related to the no-ID3 tag). Do you confirm?

Hi,

I'd like to show a cover inside the player (under the (Play) indicator). I know that the "normal" way for doing this is using the playlist, where the first item is the image with autoPlay: true.

The problem is that I'm playing a RTMP stream(s), and I can't use the playlist (the playlist take precedence over streams, so I play the image or I play the streams).

Is there a way for doing this? (the best way would show the player controls with the cover inside the video area, not an image that would take all the player space).

Thank you

Cool! I wonder though how a 1ms grained scheduling could be guaranteed... maybe using a callbacks stack (on every cuepoint the callback in not called but stacked... then a timed scheduler will empty the stack. This will have some drawbacks but the movie will not be slowed down, but de-syncronized)

Just a thought :)

With embedded cuepoints the problem persists (I had up to 6 cuepoints skipped in a row. Randomly of course :))

So I have to stick to 3.0.1 that is not affected by this issue... Do you think it could be possibile to have the embedded cuepoints not being timer-scheduled?

Hi :)
While I'm hoping to have the possibility to remove and reinsert cuepoints in a movie, I've found a "dirty" solution that SHOULD work. On the start of the clip I'm setting a cuepoint on every second (every 1000 ms). Then, in the callback, I look for an eventual - program specific - metadata to display to the user (those metadata are inserted by the user himself).

The problem is that it seems that there is no guarantee that the callback is called on EVERY cuepoints (1ms is, like, too close to the next one, I presume :) )...

Is that true? If it is, I'll try EMBEDDING a cuepoint on every second via flvtool2

I'm using Ubuntu and the last Flash Player.

My code, so far, is something like that:

    initCuepoints: function(duration) {
      var clip = this.player.getClip();

      for (var i=1; i <= Math.ceil(clip.duration); i++) {
        this.cuepoints.push(i * 1000);
      }

      clip.onCuepoint(this.cuepoints, function() {
        console.log("Hit " + arguments[1]);
      });
    },

Another update. My demo videos contains cuepoints... is it possibile that seek() "rounds" to the next cuepoint (if embedded cuepoints exist) instead of seeking to the second?

Update: yes, I tried. If cuepoints are NOT present, seek works as expected.