Is this a crummy way to display web video?

[Brian Luce]

I have a hodgepodge of sources, Canon 7d (rendered to CF) EX1, and M2t from a JVC HD200.
From Vegas 9c I render out uncompressed avi (HDV720) 1.0 PAR

Import to SUPER (freebie encoder) settings: 720x480, 16x9 aspect, 1500 kbps, container is FLV, codec h264 avc. A two minute video is about 22 megabytes.

The finished product seems decent enough. I'm wondering if I can do better and or if my file size is too large for web. It plays fine on my computer but this baby is head to Latin America and perhaps they're pipelines are n't as good.

[Edward Troxel]

It would take me five to ten minutes (possibly more depending on other factors) to download your two minute video.

[Brian Luce]

Originally Posted by Edward Troxel

It would take me five to ten minutes (possibly more depending on other factors) to download your two minute video.

But isn't the norm for video to start streaming as it's downloading? Just on wifi it plays almost immediately when I open it.

[Adam Stanislav]

Originally Posted by Brian Luce

But isn't the norm for video to start streaming as it's downloading?

No, there is no such norm. It is the default of the flash player, but many people change the default.

And for those who have kept the default, if downloading a 2-minute video takes five minutes, it will start playing, then stop and wait for more data, then start again, stop again, and so on. A very frustrating experience for the viewer, who is most likely to just cancel and will never see the entire video.

One common solution is to have different renders available to choose based on one's Internet connection.

[Brian Luce]

Originally Posted by Adam Stanislav

No, there is no such norm. It is the default of the flash player, but many people change the default.

And for those who have kept the default, if downloading a 2-minute video takes five minutes, it will start playing, then stop and wait for more data, then start again, stop again, and so on. A very frustrating experience for the viewer, who is most likely to just cancel and will never see the entire video.

One common solution is to have different renders available to choose based on one's Internet connection.

Okay, 720 bitrate takes my two minute vid to about 10 megs. What would be a good file size for good all around web viewing?

[Adam Stanislav]

I wish there was a straight answer to that. Essentially you want the combined bit rate of the video and the audio to be less than the bit rate of the Internet connection of the person watching the video (and listening to the audio).

Alas, there are so many different bit rates people connect to the Internet with, a dial-up is very slow, hence a very low bit rate. DSL is faster, but not the same for everyone. DSL bit rates can be anywhere between about 25 kb/s and 52 Mb/s. And it is not the same all the time, plus it varies with the distance (e.g., someone on the other side of the Atlantic will typically have a slower connection than someone in the next town).

[Adam Stanislav]

Let me add that my ISP's lowest priced DSL is alleged to be 384 kb/s. I suspect that is what most of their customers pay for. So a combined video+audio bit rate of 300 kb/s would cover a lot of people.

[Seth Bloombaum]

We should stick to the standards here - a small "b" indicates bits, a capital "B" indicates bytes. Internet connection speeds are rarely measured in bytes per second, almost always in bits per second, eg. 800Kbps or 800Kbs, or 1.5Mbps, etc.

IMHO a conservative bitrate for broadband is around 450Kbps, an agressive bitrate is perhaps 800Kbps. How to choose? Well, you can provide both, as mentioned above. In some cases you know that your audience is general, go lower. Hi-techy, go higher.

Generally, the MP4 in FLV that Super-C produces is fine. I've lately become a big fan of the VP6 in FLV produced by Flix Standard ($40 USD), not quite the same picture quality per bitrate, but darn close and much less processor load on the decode.

Stay away from the "flash" codec in flv that Super-C and other freeware/lowcost programs include, it's the Sorenson Spark codec and it's horrible by today's standards.

File size is secondary when you're streaming. Bitrate is everything. Test your code on multiple browsers to ensure that your player is playing while downloading, aka progressive play, aka http streaming, instead of downloading then playing.

[Brian Luce]

Originally Posted by Seth Bloombaum

File size is secondary when you're streaming. Bitrate is everything. Test your code on multiple browsers to ensure that your player is playing while downloading, aka progressive play, aka http streaming, instead of downloading then playing.

This is why Ed and Adam's replies confuse me. I thought everyone uses progressive streaming.

Also, how about the start of my chain? rendering out avi uncompressed at 1.0par? Any issues there?

[Adam Stanislav]

There is transport streaming and file streaming (there can be other type, no doubt, but these two are the main types of video streaming).

Transport streaming is used mostly by digital TV. It sends out a continuous stream of data. The same data to all of its recipients at any moment. You can join the stream at any time and you will start watching whatever is being streamed at the moment, but you will miss everything that was streamed up to that moment. And if you miss any data while watching, you cannot recover it.

File streaming is used on DVDs, computers, Internet, etc. Regardless of when you start watching, you can see the stream from its beginning to its end because its entire contents are delivered directly to you.

So, unless you want to run an Internet based TV station with continuous programming, you will be using file streaming. And even if the player is set to start playing the show as soon as the data starts coming in, there is a download of a file type of stream (or an actual file) going on in the background. It is usually not saved on the local hard drive (except for some caching), but it is still downloaded from the server. And when the download speed is lower than the bit rate speed of the video and the audio, the player pauses the playback until it has received (downloaded) more data.

Indeed, technically, any and all data that comes to a computer from the Internet is downloaded, and any data the computer sends out to the Internet is uploaded. Whether its purpose is to be displayed or saved permanently makes no difference in that. Though, admittedly, many people think that downloading means fetching a file and saving it to their disk. But technically, any data is either coming down (to a client from a server) or going up (from a client to a server).

And that is what Ed was talking about when he said it would take him five to ten minutes to download your video.

[Seth Bloombaum]

Originally Posted by Adam Stanislav

...And when the download speed is lower than the bit rate speed of the video and the audio, the player pauses the playback until it has received (downloaded) more data...

Adam's description of the behind-the-scenes is pretty good. However, players can be slightly more intelligent in their operation than quoted above. Granted, if download speed is lower than bitrate it's gonna buffer. However, depending on the file and player in use, it may buffer prior to the start of playback. This can be (roughly) controlled in some encoders, you set a flag that says "download x seconds before playback starts".

Some players, especially Windows Media Player, keep track of current network performance, and may download more content before beginning playback, depending on current conditions and whether you've set "automatic" detection of network speed in the prefs. Joe's Flash Player - anybody's guess. Certainly Youtube's doesn't do a good job with this.

Originally Posted by Brian Luce

...Also, how about the start of my chain? rendering out avi uncompressed at 1.0par? Any issues there?

AVI Uncompressed is the theoretical top quality, bar none. It's great source for any encoder for any purpose. If you tend to keep these Digital Intermediates (DI) around, they get pretty huge.

Lots of people (me included) create high-bitrate MP4 as a DI. This is handy for all sorts of purposes, including upload to online encoding/hosting services (youtube, vimeo, xr, etc.)

In this case, high bitrate might be something like 2.2Mbps for SD, or 7.5Mbps for HD. It depends on the material - highly complex picture takes more encoding bits. Sometimes it's just simpler to go uncompressed on clips with lots of camera movement.

***edit***
PS. Just reread the OP. The square pixel equivalent of SD widescreen that I usually use is 854x480. Highly recommend avoiding non-square pixels out of Super-C or any encoder!

[Brian Luce]

Originally Posted by Seth Bloombaum

Lots of people (me included) create high-bitrate MP4 as a DI. This is handy for all sorts of purposes, including upload to online encoding/hosting services (youtube, vimeo, xr, etc.)

Yes, I tried to import MP4's to SUPER but they'd either give error messages or the finished product would not show up in the player.

[Edward Troxel]

Brian, I don't care if it streams or not. If it takes 10 minutes for me to download your 2 minute file, it's basically unwatchable to me. If it streams, it will start, play for 15 seconds, stop, wait 30 seconds, plays for another 15 seconds, stops, and the process repeats. This start, stop, stream more, start, stop process will drive you nuts.

To be honest, if I watch a youtube video (and I don't that often - mainly because of this), here's the process I use:

1. Press Play
2. Press Pause
3. Go do whatever else I need to do (which could include browsing other sites but, of course, that slows down the download).
4. Come back later and watch the clip after most, if not all, of it has downloaded.

But at those file sizes, I would NOT be able to view your 2 minute clip in 2 minutes.

[Adam Stanislav]

That's exactly how I watch YouTube videos as well. And often I just give up.

[Brian Luce]

Originally Posted by Adam Stanislav

That's exactly how I watch YouTube videos as well. And often I just give up.

That's how I watch them too.