Forum user: aigumnov

Are you asking me?
Remember, this topic is about Highwinds CDN implementation. Highwinds doesn't reserve its datacenters exclusively for one type of usage (i.e. exclusive datacenter for rtmp streaming).

To your proposal:
Yes, it is possible, but it requires the full reconfiguration on the Highwinds' side. Note, the Highwinds software will report "404 not found" if client will request the SMIL name which doesn't match physical FLV file. Thus, we have to resolve the file name (low vs high quality version) before actually knowing the streaming server IP address and thus - before _definst_ connection. That's the way their system works.

The "image bwcheck" gives the same result as with _definst_ bwcheck. The bandwidth checking procedure, in fact, determines networking conditions between the client and the server (datacenter).

On load balancing:
I'm not an expert in Highwinds system architecture, however I'm quite sure that they perform the following computations while serving the SMIL files.

1. The HTTP requests of every kind go to closest datacenter (by BGP routing). This applies both to GIF files and SMIL files (which are not physical files, but scripts). Note: not the least loaded in terms of computing power, but closest and least loaded in terms of network load between the user and remote system (there is also the possibility to prioritize datacenter usage).
2. SMIL output contains hostname of the streaming server, which is selected (with load balancing) from the RTMP-streaming server farm in this given datacenter (selected on step 1).
3. GIF file request will be REDIRECTED to and served by the ordinary HTTP server selected from HTTP server farm in this given datacenter (again, with load balancing).

Keep in mind that "bwcheck" and "smil" requests go sequentially and with very small pause - we can safely assume that network conditions (and BGP routing) and datacenter average load won't change in 0.5-1 sec.

Given this, we can also assume that "step1" above will select the same datacenter for 2 subsequent requests.

And the conclusion here is that bwcheck and streaming connections will be served by the same datacenter and via the same network route, but obviously with different server farms within that datacenter (for http and rtmp serving). Again, I'm talking about Highwinds only.

All said is checked and confirmed with traceroutes. If you worrying about changing network conditions and datacenter load, you could disable the caching of bwcheck result or set the caching time to be very low.

The 'crossdomain.xml' doesn't cause any issues by itself. Actually, this file must exist if you're trying to request files (not streams) from other domains (not matching the domain of your main swf).

That issue was triggered by HTTP header (Pragma: nocache) used by previous versions of Flowplayer while requesting the bwcheck file.
When using CDN, the publisher often is not able to modify that file and the provided crossdomain.xml file may not allow custom HTTP headers http://flowplayer.org/forum/5/19782#post-20776

About your example:

1. First, you must have the xml file at http://video.trainingportal.us/crossdomain.xml . Or you must serve the Flowplayer main swf from video.trainingportal.us (i.e. http://video.trainingportal.us/1/flowplayer-3.1.3.swf )
2. Second, I suggest you not to use small swf files for bandwidth checking. The bwcheck file must be big enough to give consistent results. You are free to copy my file from http://e1.simplecdn.net/u9x2j9f4/cds/_util/bwcheck.gif
3. As the current version of Flowplayer doesn't issue cache busting headers while requesting bwcheck file, you must specify the reference file url as such: bwcheck.gif?rnd=' + Math.random()

Hello,
Please, consider implementing the skinScaleMaximum property binding for Flowplayer. This Flash property is described at
http://www.adobe.com/devnet/flash/articles/flvplayback_fplayer9u3_02.html
in "Handling skin distortion" section of the document.

This setting could be used in pair with already existing accelerated Clip object's property which is used to toggle hardware accelerated fullscreen mode.

Thank you
Alexey

If you ask me, I don't think you should implement msfilter transitions within this particular tooltip plugin. Such things should be abstract; maybe it could be another jQuery plugin which somehow overload or extend generic animation methods of jQuery. Such plugin could be loaded on-demand with MSIE's conditional comments.

Not everybody has alpha-transparent images on their tooltips. The element's transparency and/or fading doesn't always fit site design. Thus, it is enough to have addEffect and let users implement their own transitions.

Just for information: in fact, IE does support PNG24/PNG32 fading transitions, but not in the way like jquery does that.

You have to wrap the element, which you want to fade into another DIV and then apply Fade filter (or BlendTrans in 4.0 notation) to that external wrapper.

http://msdn.microsoft.com/en-us/library/ms532990(VS.85).aspx

I'd try to use bwcheck Javascript API for custom url resolving.

http://flowplayer.org/plugins/streaming/bwcheck.html#api (specifically, checkBandwidth() method)

Hello,
First of all, your code has 3 syntax errors of the same type (superfluous comma).
Next, the embedded example obviously will not work because of unresolved php-tags inside.

As you are keeping your test page with stream and file urls in secret, I've compiled my own 'proof-of-concept' example.

http://medigroup.tmweb.ru/brusca/brusca.html

In this example you can see some video with preselected bitrate playing for 3 seconds. Then, the bandwidth checking occurs and the same video will play for 15 seconds using bandwidth mapped stream variant.

Note the urlResolvers usage on the first clip in the playlist ('pre-roll'). My example uses SimpleCDN for streaming - you will have to adapt it to suit your needs by changing urlPattern, netConnectionUrls, dynamic: true, serverType and so on.

You may also need to reset (delete) your flash storage settings for your testing domain at:

http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html

<script language="javascript">
// our custom configuration is given in third argument
flowplayer ("playerContainer", "path/to//swf/flowplayer-3.1.2.swf", {
flowplayer("player", "/flowplayer2/flowplayer-3.1.2.swf", {

Delete the string which is in bold.
Also, the latest version of the bwcheck is 3.1.2, not 3.1.3.

And I doubt that flowplayer-3.1.2 will work with bwcheck-3.1.2. You need either bwcheck-3.1.1 or flowplayer-3.1.3. Flowplayer-3.1.3 in turn will require rtmp-3.1.2 instead of rtmp-3.1.1. Thus, recheck all plugin versions and their references in your configuration. Unfortunately, Flowplayer and it's plugins are not always forward compatible.

I found that flowplayer-3.1.3.min.js doesn't add random number to the url of the SWF while embedding. The older flowplayer-3.1.2.min.js does so embedding player's main SWF like this: http://<somehost>/util/fp/flowplayer.comm-3.1.2.swf?0.38339078127716

The newest version of the jQuery Tool's flashembed (which is the base of the flowplayer.js) has new configuration parameter - cachebusting.

http://flowplayer.org/tools/flashembed.html

Previously, this setting was not configurable and it was always enabled.

http://flowplayer.org/forum/20/21090

In newest version of the flashembed (flowplayer.js) this setting is configurable, but it is disabled by default. It looks like all abovementioned development and testing was made with older flashembed and it worked then. It works again with either:

• specifying cachebusting: true like this:

  
  flowplayer("player", {
  	src: "/swf/flowplayer-3.1.3.swf",
  cachebusting: true,
  	version: [9, 115],
  }, {
  	clip: "http://blip.tv/file/get/KimAronson-TwentySeconds6421.m4v"
  });
  

  
  
• switching back to flowplayer-3.1.2.js (using 3.1.2 javascript with 3.1.3 swf).

This solution doesn't solve the core of the problem (event handling while preloading cached objects, in my opinion), but it prevents the bug from appearing.

>For example, this statement
>is flat-out wrong (or at best
>incomplete):
>"On refresh, stage.{SIZES} are
>set to 0 in IE."

Of course, if you take this statement out of context of the whole message, it is "at best incomplete". Otherwise, the whole discussion is proposing the variation of what you are writing here at http://www.flowplayer.org/forum/8/24973#post-25458

>1. Wait for Stage.Width and
>.Height to be > 0. (Don't do a
>tight loop in code; check every
>5-6 ms.) The alternative is to
>set up a listener for the stage
>resize event first thing, and
>then go from this event.

However, I think that the further discussion about "flat-out wrong" statements somethere is offtopic here.

> It can happen on first load.

What is the definition of "first load"? Primed browser cache? Empty browser cache? Primed intermediate proxy cache? What page components are in the cache? Any transparent HTTP accelerators? Antivirus? Personal firewall? Do you know that the traffic may flow through caching proxy server which is invisible to clients?

Personally, I've found the original issue on Firefox, then successfully reproduced it on MSIE. Moreover, I saw similar preloader-related issues in every possible browser in non FLV-player context of flash programming (with SWFObject). I never saw it on true first load. It is my personal experience, however.

>At least for the latest build
>the buffer spinner and no
>video/controls might be
>specifically related to
>Protected Mode in Win7/8
>under Vista and Win7.

My setup is not so fashionable. I tested with MSIE6 on Win2000 Advanced Server and with MSIE8 on WinXP-SP3.

>Secondarily, the staging setup
>error most commonly associated
>with this glitch is that Flash
>may fail to set Stage height/width
>on load.

I mentioned this 3 weeks ago at http://www.flowplayer.org/forum/8/21736#post-24757
The url I referenced was
http://stackoverflow.com/questions/547408/rectangle-doesnt-get-drawn-on-root-object-on-refresh-in-ie

Haven't followed the thread for some time, but tried the freshly released version.

The bug-induced visual effect has changed, but the bug itself is still here. I'm reproducing the bug as such:

1) Clear the browser cache.

2) Run any demo with configured plug-ins, for example http://flowplayer.org/plugins/streaming/bwcheck.html

The org.flowplayer.view.Preloader debug log entry is (I'm listing the log from my own sample page):

[LOG] time 19:32:58.869 :: org.flowplayer.view::Preloader : Launcher instantiated [object Launcher]

3) Reload the demo page. All page components, including the swfs must not be rechecked from the remote server. This is important note.
4) Run the demo again. The "loading circle" sign will be at the upperleft corner and will last forever.

!!!!!
Note that the org.flowplayer.view.Preloader debug log is empty.
org.flowplayer.view.Launcher is empty too, because the Launcher is not instantiated by the Preloader.
!!!!!

5) Clear the browser cache again (no need to close the browser).

6) Run the same demo again, it will work fine. Then you may go to the step 4 and with the same negative effect.

Personally, I found the "cure" that prevents appearance of this bug in every situation I can try. My solution is to append '?rnd='+Math.random() to each plugin reference
within Flowplayer's configuration thus making all urls unique and preventing the cache use.

Also, I still personally think that the root cause of the issue is Flash event handling specifics (see previous' thread posts). By introducing delays one just tries to implement some timeouts for some kind of internal activities instead of actually listening to events.

Look here:
http://www.actionscript.org/forums/showthread.php3?t=136345

checkOnBegin setting of bwcheck plugin (see http://flowplayer.org/plugins/streaming/bwcheck.html ) will probably help you.

Currently, my site is running with the pre-release of the upcoming flowplayer-3.1.3 which fixes the problem at least for on-demand rtmp-streaming (and one doesn't need to use "clustering"). This feature was developed by my request.

Thanks a million!!