I'm trying to get a streaming movie on a web site I'm doing and the only thing I can't get to work is the preview frame. I've got it in the code, and the code is straight from Apple. Anyone have any experience with this?

Here is the page: www.motorcityimprov.com/video/rr101.htm and the "poster" file is here: www.motorcityimprov.com/video/rr101.mov

This part of the site goes live in about a week, so I want to get it ironed out. It uses Mpeg4, so you'll need Quicktime 6.0 or newer....

Pulling my hair out!

Man this streaming thing is tricky...

I managed to get the thumbnail (poster) preview to work, but now some people are having issues streaming... I'm beginning to think that we encoded the file at too high of a data rate...

Anyone have any tips on data rates for Mpeg4 streams? We have 10 videos to put up, it's just the first one that's killing me! lol

More coffee will fix this,... I know it!

83k/s is pretty high for 320x240, but not high enough that any half-modern system shouldn't be able to play it if it's got the bandwidth.

The black letterboxing bars are not good for encoding efficiency.. I don't absolutely know that Apple's codec in particular does it, but other MPEG-4 codecs like 3ivx track the motion of 'objects' as they move offscreen, and they can't (don't know how to) do that if "offscreen" is in the middle of the image. Also just representing the sharp line between the video and black takes space. If you really want the black for some reason, since you're using QuickTime anyway you can just add a black 320x240 image centered behind your 320xWhatever actual video. Remember to keep the Whatever a multiple of 8 when you do that.

Apple's codec is not very good either, you could encode with any other Simple Profile encoder and still play with Apple's. I would recommend 3ivx, especially if you're on a Mac. D4.1 will be released quite soon and kicks ass. I have access to seeding builds, if you want to send me your source video I could encode a sample for you to compare. D4 is good too, and there's XviD and DivX 5.

Is there some reason you want to do streaming instead of just progressive downloading? Streaming requires the viewer be able to keep up with 83k/s, whilst progressive download just starts downloading the file and starts playing it when it's received enough to play it continuously. For people with fast connections it's just as good, and people with slow ones they can still watch your file (and save it to disk to watch offline). It's also simpler, just stick your files on your webserver, no Streaming Server required.

Thanks alot x99. We are totally new to this. I talked to my editor, an avid Mac user, about stepping the data rate down to 60k bytes per second. From what I remember, we encoded straight out of Final Cut Pro 4, and not within Quicktime, but I don't know if it was a plug-in or whatnot. I'm also looking into http streaming, but I've been having issues getting the movie to "fast start". I must be doing something wrong in the code because it wants to download the enitre movie before it starts.

Despite being frustrating, this is actually quite a fun learning experience. We have so much good content that we are sitting on, and this will really be a great way to promote it. HBO contacts us every 12-16 months, so this is a good way to let them know that we've been busy.

Having the bandwidth is the point though. 83KB/s is equivalent to a connection of at least 664Kbps so adding on overhead would be even more. The average broadband connection over here in the UK would be ADSL and that's capped at 512kbps.

It's possible to get faster services but it's not as common. I've no idea what the average user in the US would have.

Another thing would be server bandwidth. If each stream is 83k/s then you'll be hammering your uplink everytime more than one or two people start downloading. The bills will rack up fast!

In order to be progressive-download-able the last thing you do has to be a Save As -> Self Contained from Quicktime Pro (or equiv, there are free tools if you don't have Pro). This creates a new file (you'll have to choose a different name) with all the header info it needs at the beginning of the file so that the downloader can read it right at the start. This used to be called "flattening" because on a Mac it would also move the video data from the Resource fork to the Data fork so as to not be lost if it touched a PC.

If you do a normal save on a file (or FCP probably doesn't output a flattened file to begin with) then the changes to the header data are written at the end of the file and the original header is marked up to tell it to look at the end.. since the downloader doesn't have the end, they have to wait until it arrives.

In the US cable is more common, usually 3mbits down. Progressive downloading would let it play as soon as the viewer has cached enough to be able to keep up.. If they have plenty of bandwidth that's immediately, if they're on a 56k it has to download say 90% of the file before it can play.

Definitely a huge hit on the server bandwidth though if you're paying by the gig or don't have big fat pipes.

I have to make do with my 2mbps ADSL. I'm a bit too far to get any faster

2mbps isn't too bad. It really sucks if I go visit my mum though. Only got 56k there and that's really unreliable for some reason

Some hosting companies don't mind you bursting but on average over the month/week you can't exceed a certain value. Doing streaming will soon exceed this so it will definately involve fat pipes or a very understanding ISP.

We're thinking of taking a new approach to this (probably the one we should have from the start). We are thinking of offering streaming for our dial-up users only (ie, lower quality and image size). Then we will preserve the high quality version fo download. Then, the lower quality streaming will also serve as a "preview" for broadband users so they can decide if they want to spend the time to dl.

But... does anyone know what the "standard" data rate for 56k users should be?

5kbytes/sec is pretty safe, 6 is probably pushing it once you get add in overhead and other losses.

Another thing you can do is create a reference movie that can look at the speed the user has specified they have in QT's prefs and automatically choose a version of your video. So you link to one file and a 56k user might get a 5k/s version, a mid DSL user 30k/s, and a fat bastard pipe user 150k/s.

Cool, we have all the videos recompressed for Fast Start and have 4 versions depending on connect speed. I have the "RefMaker" utility by Quicktime, but I still have to figure out how to tell it what files are for which connection speed.

Thanks for your tips, hopefully this will be back online tomorrow.

I hate to bug you guys about this.. I'm really a novice at online video...

I did manage to get the ref file made, and I think that it's working just fine (detecting the connection speed in the user's settings), but I can't get the videos to "fast start". My editor swears that he exported the videos for fast start (moving the header to the front of the file). Is it my code, his export or something else?

Here's the link again.

I guess we had an issue w. our export, but it's all good now! I even managed to get a cleaner looking page.

Thanks for all your help!

Sorry i wasn't around for a few days... glad you got it figured out, let me know if you need anything else.