Are you playing the video from the same machine off the server as locally? I'm wondering if there's more codec support locally than the typical user.
Exactly what format is the video? x-flv isn't enough info. Container and codec info?
ON VP6 - x-flv was the MIME type obviously. And yes, playing from the same machine. However as FLV only has two progressive codecs it would be unfortunate if the player couldn't recognise it. I can't overstate how basic this particular requirement is and how 'plain vanilla' the production pipeline has been - the video is CGI with minor edits from After Effects with a bit-rate of 350kbps and loaded without code - only placed on a stage within a movie clip.
Remember that flash IDE and either the ActiveX plugin or Flash Player installed in browsers may differ. Make sure your flash player in the browsers is up to date.
It is, I produce a lot of video. However given that it's the same browser that plays the file locally presumably this is not the issue. Incidentally, the error message does not appear locally if I have the FLV in the same folder as the SWF, and the meta-data - in terms of the first frame - displays correctly whereas it does not in a subfolder. To be certain that there are no UNC issues both are on my desktop.
What are your IOErrorEvent's reporting? Something must be erroring. Also are you monitoring the state of the video player to see if it ever begins loading, is buffering, etc?
Too often I get so busy it's something stupid like a capital letter which doesn't bother a windows rig but fails on case sensitive unix..
Yes. Yes indeed. Of course setting the MIME type correctly does not appear to help the situation if you don't clear your cache when re-testing (expletive deleted). Thanks for being a sounding board Sinious, it's good to talk Test fle is at http://www.tinyplanet-guides.com/flashpane1.html and the video plays if you click on 'my video' button. Flash absolutely needs a de-bug message that tells you to go back and check the stupid stuff first.
So is all good now? problem solved?
Not entirely, no. I want to know why I get this error message when I place the FLV in a folder below the SWF on a local system. I have not as yet tested that on a live server but it would frankly be a pain in the backside if I have to keep the FLVs at the same level as the SWF. I'll look at this when I'm back in the office on Monday and post the result.
I typically do it the other way around. I keep my applications (SWFs/HTML/etc) at a low level and assets in subfolders. I've had no issue, either way, loading up or down. I have loaded down a directory before simply via double-dot relative pathing e.g. ../video.flv
If this SWF is loaded by another HTML page or SWF who's path differs from the video player you'll need to accomidate that. The URL to the video will be from the original HTML wrapper or SWF that is loaded 'first'. In that case it'd just fire off an IOErrorEvent telling you it can't find the file to open.
You can place the Flash and any Flash assets in any folder location that you want.... provided that you understand how Flash assets (like .flv files) are "Pathed" or located by the .swf that is calling them. The underlying principle is that the Flash assets need to be pathed relative to the Web page that the .swf is located on, NOT the actual, physical location of the .swf.
Almost always when it works on the local machine and not the server, it's a pathing problem.
You can put your Flash related files in whatever folders you want, they do NOT have to be in the root, they do NOT all have to be in the same folder. But if you have a problem and if sticking them all in the root folder works, then you know that the issue was a pathing problem.
Just remember that paths used in the .swf become relative to the Web page on which the .swf is placed, NOT it’s physical location. So for example, if your .swf is in the flash/data folder and you use that .swf on a Web page in the root folder, you are in effect, removing that .swf from flash/data and putting it in root. So if the .swf is loading any related files (xml, images, video, etc), the path used inside the .swf to load the .xml file has to be relative to it's new location in root and then back down into flash/data. This is true even though when testing the .swf by itself, it can be inside flash/data and work just fine, since relative to it's location, the path is just fine, they are in the same folder. But if that same path is used when the .swf is placed on a page two folder levels up, the relative path has changed, the old "same folder" path will not work.
In fact if you are placing the .swf on a web page in a different folder than the .swf is stored in, and that .swf calls external assets, then direct clicking and opening of the .swf in it’s folder should NOT work! That’s because the paths to the external assets should be relative to the Web page and not the physical location of the .swf.
So just be sure that you use addresses relative to the final Web page locations (not physical file locations) and you can put the Flash related files in what ever folders you want.
Eye for Video
So you can place the .flv wherever you want, but you can't just go and move the .flv without also correcting the path to the .flv inside the .swf.
So be sure that you have the .flv in the correct subfolder before you do any insert of the Flash player.
Also I'm not a great fan of requiring my viewers use the latest and greatest (and most bug filled version) of any pluggin or software for that matter.
<param name="swfversion" value="184.108.40.206" />
I refer NOT to upgrade to ver 11 so will not be seeing your Flash anytime soon. If you want to appeal to a large audience, change that to version 10.
Cheers for all that; the page on the dev server is just a default Dreamweaver test - prior to changing MIME types I'd used the HTML produced by Flash. Yes, totally agree about v.11 although stage 3d looks like hours of fun.
Path info helpful too although my hesitation is with the error message I'm getting within Flash even when I load the FLV as a component. In thie first instance it had appeared as though this was the root of the problem, in that Flash did not seem to be able to retreive metadata / imagedata from the file even though it sat in that folder under the FLA / SWF. It might just be that I've run into two separate issues simultaneously, one being the MIME types, the other a possibly spurious error message that would have produced the same result if it were in fact a problem - but I'd really like to confirm this.
What exactly is the metadata and image data you are retreiving? and how are you displaying this?
As for the error message
video player is in the connection error state. It enters this state when a video stream attempted to load but was unsuccessful. There are two possible reasons for the error: no connection to the server or the stream was not found
This does not seem like a normal error message when using the FLVPlayback component for progressive download. Of course that is assuming that the .flv is in the correct location and the path is correct.
I wonder if the player is either corrupted somehow or that the player is looking for a connection to a streaming server, such as a Flash Media Server.
Have you checked these two FLVPlayback params down in the "Parameters" panel... next to "Properties" panel...
If either is set to "true" the player will be expecting to connect to a streaming server... failing that, it will throw an error.
After more testing this morning I think I've just about reached the bottom of this, and the remaining issue can probably be filed under 'curiosity. I think what has happened is this:
In the first instance I loaded the FLV from a folder underneath the SWF / FLA and received the above message. As the file worked locally I ignored it. When I went to the staging server - correctly maintaining the path - the file failed to playback. As this error message was the only clue I had, I assumed this was something to do with the problem. This was clearly wrong, because the issue was with MIME types not being set on the server, compounded by the problem appearing to persist once the MIME type was set correctly because I hadn't cleared my cache - Chrome being 'helpful.' So far so good.
My final test this morning was to create a copy of the FLA, delete the video (which was by now in the same folder as the FLA) and re-import that from the folder underneath the FLA, put it onto the staging server and test again. This time everything works fine.
However, the error message remains and there is one noticeable difference with importing the video, which is this: if I place the video in the same folder as the FLA, the first frame of the video appears correctly in the IDE and the message does not appear. But if I place the video one folder 'down' and link to it from there, the first frame is not collected (loading message here is 'collecting metadata') and the error message occurs. I confirm that both 'isLive' and 'isRTMP' are not flagged. But the video plays on staging.
Having trawled through various threads on the forum I seem to see a fair few questions being asked about FLV playback, and as you say Adninjastrator in the majority of instances these are down to pathing issues. As an 'aide memoir' for myself as much as anything else, can you please confirm that the following two statements are true?
1: The video path should be relative to the HTML page in which the SWF is placed, not the SWF itself.
2: If the video path is correct and yet the video stills fails to play then the two most likely problems are either that 'isLive' or isRTMP' are checked when in fact you are attempting to progressively download the video, or that the MIME type (video/x-flv) is not set on the server.
Thanks and best regards, apart from the 'curiosity' I'm inclined to say that 'our work here is done!'
On #1 it is absolutely true. The HTML wrapper for the SWF is the 'root' to which all subsequent loads of any kind will be run from.
#2, I've never set a mime type on my server (local or network) because flash is directly requesting the file, not asking the server to parse it. This is a standard 'download'. The typical nature of a webserver with an unknown file type is simply to serve it as a download. Flash shouldn't have any problems regardless how your server is set up and especially if x-flv is not a type. Unless your server is actually configured to disregard any unknown mime type (never seen it happen before, but possible for the admin who feels like a long tailed cat in a room full of rocking chairs).
Make a file and name it something random, abc.123. I'm sure .123 is not a known type. Yet when I request it via urlloader I can access the contents and if type'd correctly, use it any way I wish.
I'm used to these bizarre happenings with AS2 as it tended to have a mind of its own and send me into hours and hours of "this can't possibly be happening" (mostly over font issues) but as3 doing this to you is pretty new.
It was only a matter of time
I suppose I should mention the staging server is running IIS, and I'm wondering if it is to some extent parsing the file because in my latest test an 8mb file starts playing instantly. My internet connection isn't that good! I have the suspicion that with IIS MIME can cause a few problems - I guess I could test by deleting the mime-type, but I'm sort of in 'if it ain't broke, don't fix it' mode now!
If it ain't broke, don't fix it.
In the future just consider keeping your media to something common. I've long abandoned FLV/F4V for MP4 H264. I find the quality as good or in most cases better and the container is usable/playable in HTML5. That makes flash a potential fallback rather than a necessity as FLV/F4V requires.
As for #1, Flash assets, such as the video file and skin, should be pathed relative to the HTML page that the main .swf is located on and NOT the physical location of the .swf. You can use as many sub folders and disperse them however you want, as long as you keep that in mind.
#2.Almost never in this day and age where Flash has been around so long, does the server have the wrong MIME type. All reputable Web hosts will have discovered and fixed that issue years ago. About the only exceptions would be correctly setting the MIME type for the newer .f4v video (which is still relatively new) or if you have a dedicated server account and you are going your own new install of server software.
Also almost never is the problem "isLive" or "isRTMP" related... those are very rare exceptions when trouble shooting and the common solutions don't fix. When you say "I confirm that both 'isLive' and 'isRTMP' are not flagged"... you checked down in the Parameters panel and neither where set to "true"?
Second to pathing issues is the "missing file" problem. For example, you typically need 4 files if you use the FLVPlayback component:
The video player .swf
the video player skin .swf
the actual video file .flv/f4v
a swfobject.js file (used for Flash detection)
If any of these are missing or incorrectly pathed, problems will result.
Some trouble shooting tips:
If all pathing to all files is correct and the video plays local but not on the server... check the spelling of the file names. Local machine is not case sensative while server is. So MyVideo.flv is NOT the same as myvideo.flv. result fill be file not found.
Test the web page in a browser... if page comes up blank... right click on the area where the Flash is located. If you see the dialog box and at the bottom "About Flash Player" then you know that the main .swf is loaded but the video is not playing... most likely because the .swf skin file is missing. If you right click on the flash area and don't see the Flash message, then the main .swf did not load.
Very hard for us to trouble shoot further without an actual Web page to diagnose.
Best of luck to ya'
Excellent point - however, the one big gripe I have with h.264 (actually the only gripe) is that it doesn't support alpha channels. We're using video layered over flash for certain customisation features in this particular site, and that means using alphas. http://www.tinyplanet-guides.com/flashpane2.html and the 'my space station' picture is the way it works.
At least I'm 99% sure h.264 doesn't support alpha channels? It'd be really handy if I was wrong...!
Oy transparency. H264 supports it but mp4 container support has been slow for that. H264 is a 'codec', MP4 and FLV are 'containers'. They both need to support transparency. Although MP4 can support it, to my knowledge flash doesn't parse it properly yet. Flash since R9 has supported f4v h264 with transparency so if you want that you're going about it the right way, especially if it's just for effects.
There are several variants of H264. I use MainConcept to encode it via Sorenson Squeeze 8. Perhaps download a trial version of it and encode your FLV with that using mainconcept instead of xflv. There are other h264 codecs to choose from as well. One of them will certainly work with your server as they're all very mainstream.
Sorenson Squeeze isn't cheap but it does an excellent job of scene detection which is the typical gottcha on cheap encoders. When the scene changes and you don't insert a keyframe you see chunky blocks until the next keyframe hits and clears them up. If your video does that a lot it might be worth paying for software with scene change detection and multiple codecs to choose from. Your whole problem may have gone away using another codec with one more simple encode.
If your video isn't too long I wouldn't mind re-encoding it for you with SS8 and MainConcept H264 with scene detection just to test it. I'd need the source video rather than your FLV though. I can take the FLV itself but with video the rule is garbage in garbage out. For the best quality I'd need a uncompressed or lightly compressed version of the video. To just test if mime type was your issue I can take any specific video you want to test and convert it (although it will remain the same quality or worse).
Ah, thanks, I'll certainly give that a try. One of the other things we're messing with is using flash to make stuff for iPad, interactive comics mostly. I've tried embedding the flv in the time-line but it runs at about 5fps. A transparent video clip overlaid on a page would look pretty nice - especially with their really high contrast displays...
Now you're getting dangerous. As much as we'd love to think iphones and android phones are computer, they're not. Just drawing some text and slapping some images in a sprite and trying to drag that sprite across the screen can feel "very boggy". Asking a mobile phone or tablet to handle transparent video just may exceed the CPU.
Remember, that video will be played via CPU rather than GPU, even if you select GPU as your rendering. If you want GPU hardware accelerated H264 playback, you can't use transparency. You're going to need to use StageVideo or play the video in a StageWebView, neither of which supports anything useful to transparency. StageWebView plays "over" your flash content (no transprency support for the SWV instance = no transparency overall) and StageVideo plays "Under" your flash content so transparency through that is useless.
If you expect to support devices back to ipad1, iphone 3gs, single core android phones, etc etc you're going to get miserable performance with timeline video (all CPU).
Heh; I half suspected I suppose I'd better wait for iPad 3...! Actually at this point embedding an episode of the TV series in an ebook would probably be just fine (calling it as an external video component). However, I'm also a bit confused by the way both Apple and Adobe are working with NewsStand and iBooks - the former in particular. I'm not convinced I want to learn x-code to lay out a book or magazine - but then I'm not convinced I want to pay $400 a month to Adobe (as in very unconvinced). Still, I guess I'm headin a long way off-topic...
$400 a month to Adobe? For what? A subscription based purchase of their apps? I never looked into the pricing but that's pretty insane if that's what it is.
If you're embedding any movies in general (that don't need transparency to show things 'under' the video) then StageVideo or playing it in a StageWebView (via HTML5 built in controls) will play back silky smooth on both ipad1, 2 and surely 3. I'm expecting 3 to finally have a HDMI out and the ability to play HD video as well as output it to a TV. But that's just hoping...
Never import a video onto a timeline for playback on a mobile device! You want to encode the F4V in H264, include it in your project and then play it with a StageVideo or StageWebView.
e.g. fullscreen ipad1 SWV, GPU accelerated fullscreen video
var myVideo:File = File.applicationDirectory.resolvePath('video/episode.f4v');
var swv:StageWebView = new StageWebView();
swv.stage = this.stage;
swv.viewPort = new Rectangle(0,0,1024,768);
So out of curiosity.. are you using a video with alpha in 'my space station'?
I'm just not sure that I see the w/alpha part.... is the chair and round window a background and the animated characters a separate video file w/alpha?
If so, how are you playing that video? In the timeline? FLVPlayback or NetStream player?
@ Sinious: yes, take a quick look at: http://www.adobe.com/products/digital-publishing-suite-family/buying-guide.html and then go and look at the prices - it's an 'interesting' business model, not sure how sustainable it is - seems a tad opportunist really. Thanks for the StageVideo tips - that's extremley helpful.
@ Adninjastrator - yes indeed. In this promo the whole background is one PNG and the characters are FLVs - now playing from a folder sitting beneath the SWF, so many thanks! I've tried it with components and importing video via the 'wizard' and as this is progressive both seem to achieve the same effect. On the live site the background is customisable, in that kids can change the walls, floors, toys (whihc have intereactions) etc. Space outside of the window moves too.
On the live site (large update going live in the next week or two hopefully) the videos end up being played in the timeline so we can control the branching behaviour more easily. Most of the coding is sub-contracted (we're basicaly an artwork studio) but it's useful to be able to roll up the sleeves and get stuck in from time to time. I'm looking forward to the opportunity to mix 2d animation, video and real-time 3d with the new tools in flash - I think that's going to be a lot of fun!
I never looked at what you did but you'll definitely get an awful amount of bog with 'that much going on'.
It's not impossible but it might be a bit difficult to do if you need ipad1 in the equation (assuming from the size of it you don't care about iphone). If you don't convert what you're doing to Vector arrays of sprite sheets and play essentially a 'png sequence' instead of a FLV with transparency you may find the performance is unacceptable.
Luckily AIR 3.2 is in release candidate mode and enables Stage3D. Re-writing your code so it uses something like Starling (2d) and recreating those characters using sprite sheets will speed up everything to the point it'll all probably look and work exactly like you have it. Although, that is a very tall order of coding.
It's quite interesting, our characters come out larger as vectors than as bitmaps The reason is fur. In order to have a visually acceptable representation, we have to put so much detail into the fur that the file size becomes self-defeating. It is a problem that's plagued us for years... Suprisingly though, the performance of the scene even with all those layers on a pretty middling spec PC is perfectly acceptable. For mobile though (really meaning ipad 2 at this point) even a single layer of video with alpha is (as you said it would be) rough.
I'm interested in the distinction between a PNG sequence and an FLV in regards to performance though. This wouldn't be hard, the renders are all to PNG sequences prior to going into After Effects to create the FLVs so going back 1 step would be straightforward. The impression I had with FLVs was that the main advantage we gained was a) file size because of inter-frame encoding, and b) even with progressive the files start to play 'pretty much' instantly, whereas with PNGs we have to wait for the whole thing to download. Understanding the performance differences here would be helpful; vectors are kind of 'persona non grata' for us though!
Air 3.2 with Stage 3d? Exciting!