Need help loading video/x-flv with PHP

[etully]

pasiphilo wrote:

When I request resource.php with wget, it still downloads a file called "resource.php" but now that file is 5 MB in size (instead of 262 bytes)

And what happens when you point your Flash player at this PHP script to load the "flv"?

pasiphilo wrote:

I suspect that if we can get this PHP script to serve up the FLV with the right file name - or even just with an .flv extension - it ought to load into my FLVPlayback component properly.

Why do you need to mess with the filename? The flash player just wants to see a stream of bits come down the line - most programs don't care what the file name is because they know that often, they are getting piped through an intermediary just like you're doing now.

Try using your Flash player to connect to your server and request the PHP script. It should work.

[pasiphilo]

If you want the file to be saved by the user, add this header :

I actually need the file to get loaded into my Flash app as opposed to being downloaded by the user. I did try the Content-Disposition header as a means of forcing the correct filename, but that didn't work for the Flash app.

And what happens when you point your Flash player at this PHP script to load the "flv"

Believe me, that was the very next thing I tried, but that part still doesn't work.

Why do you need to mess with the filename? The flash player just wants to see a stream of bits come down the line

The FLV isn't actually streaming (since I'm not using a streaming server) but loading progressively into the Flash app. I'm 90% sure that the FLVPlayback component will not load anything without a .flv extension whether streamed or not, however.

Is there no way to serve up the FLV from PHP with the correct file extension?

[etully]

Is there no way to serve up the FLV from PHP with the correct file extension?

You sir, are in luck. As mentioned earlier in this very thread, you can have FLV files parsed for PHP.

Do this:

1. create a directory called resources (you've already done that)
2. put the FLV in there but change the extension to something like XXX or whatever
3. put the PHP serving file in the resources directory too
4. change the extension of the PHP file to FLV
5. create a file called .htaccess (note the dot at the beginning of the name)
6. The entire contents of the file are:

   AddType application/x-httpd-php .flv

7. put the .htaccess file inside the resources directory
8. double check the PHP script to make sure that it includes the FLV file by the new name (.xxx)
9. point your Flash player at the PHP script that has the new FLV extension

This will solve your problem IF you are correct that the Flash player is determined to get the file with an FLV extension.

By the way, this is just one way to make your web server serve up a file with a different name than what the user thinks they're asking for. There is another way called a rewrite rule but for this situation, I think the .htaccess solution is more elegant.

[pasiphilo]

etully... IT WORKS! 😃

That extension switcheroo trick cinched it. You are awesome!

Here is the working solution, consolidated into one post for anyone else who ever has this problem...

The files in the "resources/" folder:

resources/
-- .htaccess
-- test.xxx (a renamed FLV file)
-- resource.flv (a renamed PHP script)

The .htaccess file:

AddType application/x-httpd-php .flv

The PHP script (renamed to "resource.flv"):

$filename = "test.xxx";
header('Content-Type: video/x-flv');
header('Length: ' . filesize($filename));
header('Content-Disposition: attachment; filename="'.$filename.'"');
$fd = fopen($filename, "r");
while(!feof($fd)) {
	echo fread($fd, filesize($filename));
	flush();
	}
fclose ($fd);

The salient ActionScript:

//my FLVPlayback compontent instance is named "video"
video.load("http://www.myserver.com/resources/resource.flv");

That should cover it.

Thanks again for all your help! I hereby promote you to "Señor" Curmudgeon. 😉

J

[etully]

Cool!!

I'm a little disappointed in Flash that it needs the FLV extension. Maybe it's just the player you are using but if it's a requirement of Flash, they should know that people often have reasons to name files something other than .flv (your situation is a textbook example).

Note, for your own edification, that by putting the .htaccess file in the resources directory, you are telling your web server that you only want FLV's parsed for PHP when they are inside this directory. You could have put the .htaccess file one directory up (in your root) but then every FLV file that you ever put on your web site would be parsed for PHP which would slow your web server down because you're forcing it to look for PHP code in files where none exists.

Also be aware that now that we know the cause of the problem it's possible that you could use the readfile() command instead of the fopen code. It's also possible that the Content-Type doesn't actually need to be "video/x-flv". I understand that you have the system working and don't want to break it but do realize that those parts might not be strictly necessary.

I hereby promote you to "Señor" Curmudgeon

One of our experts here (Weedpacket) used Señor Curmudgeon and my title is a little nod to his wisdom and experience. Thank you for the vote of confidence but I will remain Juñor for quite some time.

[pasiphilo]

I'm a little disappointed in Flash that it needs the FLV extension.

This is the error I was getting from Flash before trying the file extension trick, when it thought it was getting a .php file:

1005: Invalid xml: URL: "http://www.myserver.com/resource.php" No root node found; 
if file is an flv it must have .flv extension

Your warnings about the .htaccess file and the extraneous headers are well heeded; I'll be fine tuning further as I integrate this solution into the final application.

Thanks again,

J

[pasiphilo]

Hi, etully,

I just hit a (hopefully minor) snag, something I should have accounted for before now: My full-blown app needs to send an id in the querystring to the resource.flv, like so:

resource.php?id=12345

I'm finding that when calling resource.flv (PHP) from the Flash like above, the querystring gets appended to the filename extension returned, so instead of feeding "resource.flv" into the Flash, the script returns "resource.flv@id=12345" instead, meaning it no longer has that much-needed .flv file extension. (Flash seems to interpret ".flv@id=12345" as the whole file extension, in other words.)

You mentioned a "rewrite rule" a couple of posts back that might serve as an alternative for rewriting the file name. Could we try that?

[etully]

Add this to the bottom of your .htaccess file:

RewriteEngine on
RewriteCond %{REQUEST_URI} .*translate.*
RewriteRule .*translate-(.*)\.flv resource.flv?$1

Now, when you call your FLV file, give it a name like this:

translate-id=12345.flv

This way, Flash is requesting "X" and when the web server hears the request, it looks for "Y" instead and sends the data back to Flash.

The PHP script thinks that the user actually requested "resource.flv?id=12345" but Flash thinks that it asked for translate-id=12345.flv

The rewrite rule looks for TRANSLATE - (something) . FLV

and converts it to: RESOURCE.FLV?(somthing)

So whatever the "something" is gets tacked onto the end after the question mark.

The only caveat is that you can no longer use any files in the resources directory with the word "translate" in their title because when you try to call them they would get converted!

[etully]

It's kind of bad form to use re-write rules and "AddType application/x-httpd-php" at the same time. That can make for a real headache when someone else has to figure out what you did when you are no longer involved with the project.

The "correct" way to handle this should be to take out the "AddType" directive in .htaccess and make the rewrite condition change the name from translate-id=12345.flv to resource.php?x=12345

(and change the name of resource.flv back to resource.php of course. And change the name of test.xxx back to test.flv. And change the PHP script so that it's once again calling an FLV file instead of an XXX file.)

Everything should work fine if you don't make these changes... but you always need to consider that if you get hit by a bus, someone else is going to have to figure out what kind of crazy maze you built.

[pasiphilo]

Hey, etully,

I had already decided to try reverting all the renaming, etc, as I figured out that it was no longer needed with the rewrite rules. I'm all for keeping things sane.

Now for the crazy part: While implementing these latest fixes, I stumbled upon - quite by accident - a much simpler and incredibly stupid fix (hack) for this whole serving-an-FLV-to-FLVPlayback-with-PHP issue.

Remember our initial attempts involving the PHP script that used readfile() to send an FLV back, the method that fed a file with a .php extension back to Flash? Well, I found that if I simply use that same script, but adjust the call to it like so:

resource.php?id=12345[B]&f=.flv[/B]

That trailing ".flv" in the last name/value pair is persisted when it goes back to the Flash, so the FLVPlayback component is satisfied that it received a FLV file.

:queasy:

You want to know how I figured that out? After implementing your latest rewrite rule fix, I blindly tested on my local box (Windows) and was surprised to find that it worked - surprised because I don't have the mod_rewrite installed on my Windows box. After that, I realized that the ".flv" in your "translate-id=12345.flv" call was the key.

It seems to work both locally (Windows) and remotely (Linux) on all my target browsers (in case that involves browser functionality), but I'll be 100% certain when I'm done.

How crazy is that?

J

[etully]

Well, I'm not really in love with that solution.

Don't get me wrong - it will work - but it just makes me a little nervous. Something about it isn't elegant.

I guess it's that you're using the get string for something it wasn't designed to be used for. The rewrite tool was specifically designed for this exact situation.

I don't know what to tell you - I'm a curmudgeon.

It's clever though - I'll give you that. I wouldn't have thought of it.

[suntra]

When developing, you want things to go as quick as possible, if you can avoid something to speed things up, avoid it !

In your case, don't use mod_rewrite and use pasiphilo's solution... I don't understand how you can find that non elegant... will people see the URL ? No !

This way, you'll get a direct request to the PHP script, so a (tiny) bit more speed 😉

If you don't want unused get variables, you could do something like this :
resource.php?id=12345.flv

And then substr the string to remove the .flv (substr($_GET['id'], 0, -4))...

[etully]

When developing, you want things to go as quick as possible, if you can avoid something to speed things up, avoid it !

First of all, that's some pretty bad advice right there.

Second of all, dude, chill. We're just chatting about programming here and I shared a gut instinct that comes from 25 years of programming. There's no need to get excited.

Third, you can do a mod_rewrite rule in about two minutes. It's not like I'm suggesting he do an extra half a day's coding.

Here's a math problem for you: If solution X takes one minute and solution Y takes ten minutes - and both will solve the problem - but two years from now, Johnny is going to have to waste three hours of his day trying to find a workaround to a problem caused by your sloppy coding, which solution is correct? Hint, the answer rhymes with pod_rewrite.

And people call me the curmudgeon, sheesh.

[pasiphilo]

Hey, Guys,

We're all friends here. 🙂

etully, I share your philosophy and may end up using your mod_rewrite after all simply because my gut tells me it's probably more reliable in the long-run. Who knows how future Flash Player plug-ins will interpret what I've done with the querystring, for example. This is why I described my fix as "stupid" because it's really just a hack.

Anyway, it's all good.

Thanks,

J

[suntra]

((( by the way, I was talking about SERVER speed, not programming speed 😉 )))

[etully]

suntra wrote:

((( by the way, I was talking about SERVER speed, not programming speed 😉 )))

I just re-read your post and I can see that you meant server speed. Sorry, I obviously misunderstood you - and yes, I agree that you should always look for ways to speed up the execution time of your code. And of course, there are exceptions to every rule. Common sense has to rule out: I would sacrifice some server speed in some situations.

I just measured the speed of a mod_rewrite on my Apache server. On a very small download (less than 1K), mod_rewrite slows the page down by 4%. On a very large download, (6M😎, mod_rewrite slows the page down by .0009%.

So in this FLV example, the overhead of mod_rewrite is a very safe trade off to keep the code sane.

[pasiphilo]

Hey, guys,

Got a question related to the resource.php functionality. I've got all code on this page wrapped in a conditional checking for the existence of a "logged in user" session variable to ensure that - in the event that someone figures out the resource.php url and tries to download the file with a direct call to it - only logged in users can actually do so.

The problem I've noticed is that while resource.php is busy serving up a large video file, such as one that take a minute to progressively load, any other page loads are delayed until that video has finished loading. For example, if I start loading a large video, then change my mind and try to click-thru to another page in the site, the browser won't go to the new page until the video has finished loading.

I've determined that its the session handling in resource.php that is causing this, because if I remove that condition, there is no delay.

Is there a way around this?

Note that resource.php and all videos are in a different subdomain, so I've set

php_value session.cookie_domain ".mydomain.com"

in my root .htaccess file.

Thanks,

J

[etully]

To be honest with you, those symptoms don't make any sense. I believe you when you say that it happens - but technically, what you're describing is impossible.

Have you tried this in different browsers and different platforms?

Now let's be specific about the recipe:

1. Conditional is in place
2. You click a link to an HTML page that contains the Flash player
3. The embedded Flash player connects to resource.php, FLV starts downloading

And then step 4 is that you click STOP and then click a link on the page? Or do you simply click another link on the page before hitting stop? Is the link that you click a hyperlink or a Form/Post button? Which browser and platform are you seeing this in.

As far as your browser (and Flash) knows, you have connected DIRECTLY to an FLV movie. Since the headers are the same and the content is true FLV, there is absolutely positively no way that the browser would have any way of knowing that the PHP code is / isn't wrapped in a conditional. More specifically, the headers are exactly the same no matter whether or not the PHP's code is wrapped in a conditional.

When you click a link in the browser, it doesn't check with the server to see if it's "permitted" to abort the download. It just doesn't.

[pasiphilo]

This is a strange one, I agree.

I have only tried it on Firefox so far, but intend to test other browsers.

1. Conditional is in place
2. You click a link to an HTML page that contains the Flash player
3. The embedded Flash player connects to resource.php, FLV starts downloading

4. Click another html hyperlink on the page that should take me to another page, but waits until the video has finished downloading.

I know this is the case because I have a progress bar indicating how much of the video has loaded; when that bar reaches its full extent, only then does the link action to another page resume.

I have also noted, curiously, that when clicking to load another video in the Video player (there is a playlist of videos in the Flash app) loading of the next video is not delayed, but simply cancels the first and starts loading the second.

I will look further into this and get back to you, because it's possible that some other things are at play here, but I have confirmed that if I remove the conditional checking for the session variable from resource.php - my temporary work-around - this delay does not occur.

I was just wondering if the problem was related to some nuance of sessions that I wasn't aware of.

Thanks,

J

[pasiphilo]

Hey, guys,

This issue happens in IE and Firefox; I don't think it's a browser issue, though.

Here is the scenario:

• A custom Flash-based video player is embedded into an HTML page, we'll call player.html.

• Clicking a video title from a playlist in the Flash video player calls resource.php, which progressively loads the corresponding video into the Flash video player.

The problem:

• While the video is loading (resource.php is executing) no other action can be performed with the browser, such as clicking through to another page (example: about_us.html) until the video has finished loading.

Interesting to note:

• Clicking another video title from the playlist during the first video's loading does load the new video, so it does seem possible to interrupt resource.php with another call to resource.php.

Abbreviated resource.php

session_start();
if(isset($_SESSION["valid_id"])){

...

$src = "videos/myvideo1.flv";        
header('Content-Type: video/x-flv');
header('Content-Length: ' . filesize(realpath($src)));
readfile(realpath($src));

...

}

I have also tried:

session_start();
if(!isset($_SESSION["valid_id"])){
			exit;
}

...

$src = "videos/myvideo1.flv";        

header('Content-Type: video/x-flv');
header('Content-Length: ' . filesize(realpath($src)));
readfile(realpath($src));

...

Current work-around:

• If I comment out session_start() and the conditional, the problem does not occur, meaning that I can interrupt the video load by clicking through to another html page.

Any ideas?

Thanks,

J