Need help loading video/x-flv with PHP

[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

[etully]

Are the links to the about_us.html page in the Flash movie or in the HTML page that embeds the Flash movie?

[pasiphilo]

etully wrote:

Are the links to the about_us.html page in the Flash movie or in the HTML page that embeds the Flash movie?

The links in question (such as about_us.html) are in the HTML page that embeds the Flash movie. The video playlist links are in the Flash.

[pasiphilo]

Ok, I'm an idiot.

I mistakenly referred to the other pages being clicked as html; they are, in fact, PHP pages (ie. about_us.php), each of which also references a session variable in order to manage the display of the main navigation (ie. show "login" or "logout" menu items).

I've done a bit more research on PHP sessions and found what seems to be reference to the fact that only one script can work on a session at a time. This seems to be the case, because if I remove session_start() from, say, about_us.php, I can navigate immediately to that page.

I found a post that mentioned, without details, using session_write_close() to get around this, but I haven't had a chance to mess with it, yet.

[etully]

Heh. I've never heard about that limitation but in retrospect, it makes sense because if you had two pages both writing data to the same session variables, one would overwrite the other.

Of course, your PHP that serves the FLV file probably isn't writing any data to the session variables so it doesn't strictly apply to you but the limitation is there anyway.

Ok. I can think of a few different ways to overcome this.

1. The best method would be to do the following in the PHP script where the session is truly started (not in the PHP script that serves the FLV): open the database and write the session variable to a table called permit_flv_transfers (or something like that). Write the customer's userid and their session variable. (so you end up writing something like bobsmith,1234567890). Then, when the Flash makes a connection to resource.php, pass in the userid and the session variable. Then resource.php does not start a session but instead checks the permit_flv_transfers to see if this userid and this session id are in the table. If they are, then you know the session is valid and you should permit the transfer. This way, you can accomplish all your goals: (A) retain the security of only letting customers download the flv, (😎 not start an actual session, and (C) hide the actual name of the real FLV file.

2. The other solution is a hack but you could do it. On the link to about us, put a javascript call that messages the Flash. If the Flash ever hears that message, then it terminates hard. This will kill the connection to the PHP script ending its session and permit the start of the new session. Personally, I hate solutions like this because they involve potentially bad timing problems (and cross browser problems - imagine if some user's browser didn't pass the message correctly to Flash).

But in any event, there's two solutions plus the third one that you discovered, session_write_close(). Never having used session_write_close(), I'm not certain if it would actually close the session as soon as the download command is executed or AFTER the entire download has finished so I'd be hesitant to use that solution. You could test it... but in my opinion, solution #1 above is the safest because resource.php never opens a session in the first place.

[pasiphilo]

Hey, etully,

Putting session_write_close() just inside the conditional in resource.php seems to do the trick.

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

session_write_close();

...

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

...

}

I can browse to any other session-aware page of the site before resource.php has finished serving up the FLV without any apparent issues. And, if I load resource.php while not logged in, it doesn't return any file, which is how I wanted it to work.

Do you foresee any gotchas with the above?

J

[etully]

It looks pretty good to me. My initial concern was that "session_write_close" meant that it might only close after it has written stuff to the page (like flush+close or something like that) but actually, it's designed to close the session immediately - so you're just keeping it open long enough to see if it exists... and if so, then close and continue so that should be fine.

One tiny gotcha that I can think of is if someday in the future you want to operate on the session later in the PHP script but that doesn't seem too likely to happen in this application.

On a different topic, I'll mention a different problem that I ran into this week: Even though the HTML/PHP pages retain their session, I was having problems with Flash remembering to pass in the session cookie after an hour so when users would do their work in Flash (it's a graphics application), and then try to save, the server would think that this was a brand new session. Or another way of describing the problem: The HTML page would remember the session but the session in Flash's web connection would time out after an hour. This probably won't be a problem for your application but as you do more sophisticated Flash applications, you might want to keep this in mind. (I solved it by the solution I gave you earlier - Flash would pass in the session variable in the get string in case the cookie had expired).

[dEPUTsTERONE]

Is there also a possiblity to load url's without extension into the flvplayback?
I already tried to use the php you guys offered, but with this url:

http://www.youtube.com/get_video?video_id=nirzWAU6EzQ&t=OEgsToPDskIfrDwNOTLg1DnxzqdKZF0m

it doesn't work...
I try to parse the flv from xml some video communities offer, but the loading of url's without extension fails. I really try to solve this problem for 2 days now.
I hope you guys have a workaround...
Thank you

regards

[Justin_Buser]

pasiphilo wrote:

After much head-scratching and experimentation, I finally figured out that the problem was on the Flash side of the equation. I'm playing back the videos with an FLVPlayback component inside Flash, but loading files with the PHP method I was trying doesn't work with the FLVPlayback component. It does work with the less robust Video component, but even using that component, the FLV won't progressively load into the component like it does when you load the file directly from Flash, which is causing problems with creating user-friendly loading bars.

To say I'm disappointed with Flash would be an understatement. Nevertheless, the input I received from this board was much appreciated. And hopefully the findings in this thread will save someone else similar aggravation.

This WILL work fine with Apache (must add AddType video/x-flv .flv to httpd.conf)

<?
session_start();
if(!empty($SESSION['authenticated'])){
$file=$GET['vidFile'];
header("Content-Type: video/x-flv");
header('Content-Length: ' . filesize($file));
@readfile($file);
}
?>

The problem you are having I believe is that you are setting the source for your video component after it's already on the stage. If you create a new instance of the component and set the source before adding it to the display list your preloaders should work fine.