Hello people,
I'm going to ask this here rather than on Yahoo answers or similar because I think the things that are important to me will be to my fellow Vegas-ites as well.
Can anyone recommend a web hosting service or the like,
or,
can anyone tell me the best way to start up a web site?
Do most of you do it yourselves?
Am I better off to employ a "Web site guy" to do it for me?
Most important thing of course is to be able to host your own videos, are there other things to be wary of?
Should you get a local host, or doesnt it matter if its on a different continent?
Thoughts and opinions greatly appreciated.

for clients use dropbox

for all else i use vimeo (and embed in websites)

if you're expecting any traffic at all hosting your own isn't really practical.

thanks for the reply Leslie,
So you dont have your videos on your lesliewand.com.au , you just embed the vimeo links.
Did you set up your lesliewand.com.au yourself? was there much in it?
Is the first step to purchase the domain name? Does it matter who from?
cheers

Hi Gerald

I have been on powweb.com for about 10 years now and they are awesome!!! I used to upload FLV video clips to their server but I found that with Aussie brides accessing a USA server, there was too much buffering and waiting.

What I do now is embed a YouTube Custom Player on my site and then create a playlist called "weddings" for it ..that way the brides have a choice of maybe 40 wedding clips and samples to choose from and YouTube's servers are pretty quick too....I got tired of people saying "your videos take too long" It's not the most professional method but it gives easy access to brides...I also upload clips in SD not HD (just 640x360) ....that also speeds things up and brides will seldom appreciate or have the time to watch HD clips anyway!!!

In Vegas 9 I just render in Sony AVC as an MP4 file and set the template to 640x360 and it make an easy to upload MP4 clip for clients!!

Chris

I used GoDaddy years ago, and returned to it for my self-hosted videos (Yogananda, fundamentalism, atheism: A journey toward self-realization (http://www.torealize.net)). You can get 3 years, unlimited bandwidth, unlimited storage, for $48 per year (as I recall; I paid for 10 years).

Rendering for the web from Vegas is the pits. I want top quality and low bandwidth. Here's a sample at an astonishing 500 kbps:

Physics: The quantum explanation" (http://www.torealize.net/2physics.html)

I render .MXF files from Vegas, then put the .MXFs into Handbrake. Here's a tutorial that outlines various options:

Sony Creative Software - Forums - Vegas Pro - Video Messages (http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=755224)

If you search for "Handbrake" on the above forum, you'll get easy-to-use settings for Handbrake. It takes me about 3 min. to put a .MXF file into Handbrake and get it rendering. Rendering usually is around 60 or 70 frames per second, so it goes fast. 2-pass variable bitrate rendering takes about twice as long.

Just last night, I deleted my YouTube account because I didn't like the username that I had chosen (you can't change it - you can only delete the account and all videos on it and start over again. I'm in the process of uploading the first 2 videos on my new account (you should be able to find it tomorrow if you search for "Larry Dominus Reavis" or "LarryDReavisPhD" from within YouTube - in case you wish to compare quality with the self-hosted videos.

YouTube is OK, but limited to 15-min. videos. Quality suffers a bit, too, but not like a few years ago. However, it is likely to play well all over the world; some folks on this forum said my self-hosted videos were streaming poorly.

It you get your own site, I'd say do it yourself. That way, you'll have total control. My son has pros in India manage his business website, and - although they do a good job - I can see that there are improvements that he probably could make if he did it himself. On the other hand, the pros will avoid many common pitfalls - such as too much highlighting (I did that), too many exclamation marks !!!!!!!!! etc.

I like the free nVue for building and editing my website, but you do need to know at least the basics of .HTML to get it to do fancy stuff.

Right now, I'm preferring to use YouTube to drive traffic to my website. We'll see if that strategy works.

Thanks guys, will look at these options.
Larry, that video @ .5mbps is remarkable, I thought mine were ok at 1-1.5mbps but that lifts the bar.
Now i'm late for work, couldnt stop watching Larry's vid, lol. Love that guitar playing!
:)

Check out Big Black Bag. They have a 2 week free trial.
The nice thing about their sites is they are iPhone friendly. The templates are easy to learn and the free training is well done.

thanks for the reply Leslie,
So you dont have your videos on your lesliewand.com.au , you just embed the vimeo links.
Did you set up your lesliewand.com.au yourself? was there much in it?
Is the first step to purchase the domain name? Does it matter who from?
cheers

no videos on my site - all embedded from vimeo (free)

yes, use dreamweaver, but there's a huge amount of cheap (even free) website software out there and it's no longer rocket science (you don't need coding!!!).

you can get your domain via your isp (they're separate entities, but the isp can arrange it for you).

good luck.

Larry, that video @ .5mbps is remarkable, I thought mine were ok at 1-1.5mbps but that lifts the bar.

fwiw, HandBrake can produce some amazing quality at low bitrates. I did some comparisions - Vegas h.264 (mp4) Renders from Sony & MainConcept vs HandBrake @ 200Kbps. Here: Low Bit Rate Testing (http://www.jazzythedog.com/testing/lowbitrate.htm)

...Jerry

btw, this is a GoDaddy hosted account.

Edit: I should note that content of the video is a major factor in achieving low bitrates - a "quiet" video, e.g. a talking head with little background movement & no transitions is much easier to achieve quality at low bitrates than a "busy" video with lots of motion.

Right. I include transitions and other bandwidth eaters when necessary, but I shoot with good light in order to cut down noise, I use green screen (like all the opening talking-head shots) and then blur the background and keep background motion low (the trees and bushes in the opening green screen are not moving much - I shot on a day with low wind), I don't do too much movement of stills, etc.

Incidentally, that clip also looks OK at 200 kbps, but it looks a tad better at 500 kbps; and I figure there is no point in going lower (in most cases - except overseas at some locations where GoDaddy servers struggle).

For those whose players can't play flash and for those folks overseas, I'm going to embed the YouTube versions on my website - hopefully today.

Incidentally, that clip also looks OK at 200 kbps, but it looks a tad better at 500 kbps; and I figure there is no point in going lower (in most cases - except overseas at some locations where GoDaddy servers struggle).

I would suggest the the main reason for keeping the bitrate as low as possible is because not all users have high speed internet connections.

...Jerry

I would suggest the the main reason for keeping the bitrate as low as possible is because not all users have high speed internet connections...
Yah, but... how low is low? (sorry...)

500Kbps is pretty good, and pretty conservative for a broadband audience. Any home user with cable modem or DSL is good with it. Almost any office user, too.

The problems come in high-use shared connections, like coffee shops. If a couple other users in the shop are streaming video, maybe HD on Hulu, it's pretty easy to flood the service.

But, even with that, how low is low? If you encode at 200Kbps, you know, 180 is lower... at a certain point you just stop and say that picture quality is as low as you want to go.

***********************************************************
Larry, that is some pretty outstanding 720p at 500K. I've had some significant experience in compression, I teach a college class in it, your results are really very, very good!

But, even with that, how low is low? If you encode at 200Kbps, you know, 180 is lower... at a certain point you just stop and say that picture quality is as low as you want to go.

"Low" is the point where a rendered version of your video has subjectively good visual quality. The point I'm trying to make is that this process is trial-and-error. A "busy" video will require a higher bitrate than a "quiet" video. The higher bitrate will be tougher to progressively download for users with lower bitrate connections. I've been at motels & restaurants that cannot handle the 200Kbps videos - and what about mobile phone connections?

The other point I was trying to make in the referenced URL ( Low Bit Rate Testing (http://www.jazzythedog.com/testing/lowbitrate.htm) ) is that, after much experimentation, at low bitrates, HandBrake renders produce higher quality than either the Sony or MainConcept h.264 encoders packaged with Sony Vegas.

All-in-all, I really don't think we are in disagreement.

...Jerry

btw: Over at that Sony Creative Software forum, we have group that has been studying the subject of high quality Web delivery and created a project page here: HD Guide for Vegas Users (http://www.jazzythedog.com/testing/DNxHD/HD-Guide.aspx) (note that it's not complete - and still in "Draft" form). If you wish to post comments, there is a reference thread at the Sony Forum.

I've been at motels & restaurants that cannot handle the 200Kbps videos - and what about mobile phone connections?

...Jerry


My original goal was to get better image quality at a lower bitrate than available on YouTube. If you look carefully at the YouTube version (YouTube - (2c Part 1) Physics, maya, and Kriya Yoga (http://www.youtube.com/watch?v=OAQcae2slN0)), you'll see that the image quality is not as good as that observed in the self-hosted version (I uploaded a 2500 kbps .MP4 to YT, knowing that they'd need every bit possible in order to get a semi-clean image).

Moreover, when everyone in my neighborhood gets home in the evening and my DSL connection slows down a lot, I can't play the YT version without some buffering, whereas the self-hosted version never buffers.

Having said that, I think Jerry has a very valid point. My next goal is to work on getting it to play on mobile phones, especially those that can't play Flash. I've been experimenting JW Player's claim that it will role over to HTML5 for players that don't have Flash installed, but without much success (in this case, not a bitrate problem).

If Jerry and the other the smart guys that I've been reading over at Sony forum, or at JW Player, ever get a procedure that actually works, then I'll re-compress at fewer pixels - maybe 360x640, and then seriously try to cut bitrate - placing 2 links on my website (or 4, counting YT & download links), so that those with slow web connections can see the videos.

Incidentally, it's my understanding that HTML5 & WebM etc. are standards that still are in flux. We may just have to wait a bit longer for the dust to settle.

Also, according to Wikipedia, there are several dozen operating systems in current use; we may have to resign ourselves to the fact that perhaps we'll never find a way to play videos on all of them.

Seems there's always a next step to occupy our time . . .

I used GoDaddy years ago, and returned to it for my self-hosted videos (Yogananda, fundamentalism, atheism: A journey toward self-realization (http://www.torealize.net)). You can get 3 years, unlimited bandwidth, unlimited storage, for $48 per year (as I recall; I paid for 10 years).




I quit Godaddy because uploading to them became painfully slow.


Rendering for the web from Vegas is the pits. I want top quality and low bandwidth. Here's a sample at an astonishing 500 kbps:

Physics: The quantum explanation" (http://www.torealize.net/2physics.html)




Video is great quality but long. I quit watching it about one third of the way through it..


Others say they use Vimeo. I tried and tried to use it but I always get jerky motion with my videos. Church services with speakers who like to walk all over the place.


I finally decided to create wmv videos. Render to uncompressed avi and then use a dos batch file to render to wmv.

I then use windows to send the wmv files to zip files and upload them to my site. Users download them, unzip and watch.

In Vegas I use sharp at 0.500 and set Levels from Studio RGB to Computer RGB.

One reason for wmv is many people cannot install a player for other formats. So wmv works best for most.

The videos are approx two hours and most people do not have time to sit and watch the whole thing. So multiple zip files for parts of the video plus they can watch a part now and later on watch another part of it.

Clicking on it to play online means one cannot do that and if it gets too long they quit watching and go somewhere else.

Hope this helps.

Danny, your jerky motion with Vimeo is likely the result of improper encoding. I'm new to Vimeo, but the key is proper project settings, encoding, etc. including proper deinterlacing, etc.

I used wmv files when I began video, and the quality is superior, colors are sharper as is detail. Flv compression sucks in comparison.

On the other hand wmv files, in my business, harken back to the 90's or something, very dated.

For a church audience you have a captive audience, so I suppose it doens't matter in your case.

The magic question is what are the proper settings and encoding?

I tried their suggestions and everything I can come up with and absolutely nothing works!

Oh well, as long as the zipped wmv files work I will let Vimeo be...

The magic question is what are the proper settings and encoding?

I tried their suggestions and everything I can come up with and absolutely nothing works!

Oh well, as long as the zipped wmv files work I will let Vimeo be...

Danny, I know you say you prefer wmv, but if you go here: HD Guide for Vegas Users (http://www.jazzythedog.com/testing/DNxHD/HD-guide.aspx) and use the HandBrake settings (for that matter, follow the entire procedure), I think you'll be happy with the results.

Good Luck!
...Jerry

PS: I've noticed less stuttering in recent Flash Player plugin upgrades.

...I used wmv files when I began video, and the quality is superior, colors are sharper as is detail. Flv compression sucks in comparison.

On the other hand wmv files, in my business, harken back to the 90's or something, very dated...
WMV set the bar for picture quality for the bitrate for many years, since the introduction of the WMV7 codec family.

Early flash video using the Spark codec was horrible - no question about it. Numerous freeware encoders were built on the free Spark codec, they all made horrible video.

Later, the VP6 flash video codec was introduced - this wasn't quite the same picture quality for bitrate that WMV was, but was pretty good, at least it was now in the same ballpark for pq as WMV. However, this codec only came in costly encoding products like Squeeze, Flix, and the Flash authoring app. More recently, a consumer version of Flix with VP6 was available from On2 for $40, then Google bought On2, and Flix went to Wildform, which now has a $50 version of Flix with VP6.

VP6 is a very good codec. Availability of this codec meant FLV could be of acceptable quality at bitrates comperable to WMV.

Most recently, the push is for h.264/MPEG-4/AVC in the flash player. This codec arguably equals or surpasses WMV for pq for the bitrate. However, the decode, especially at higher bitrates, is much more processor intensive than either VP6 or WMV, and so is unsuitable at high bitrate and HD for users of older computers.

...One reason for wmv is many people cannot install a player for other formats. So wmv works best for most...
This statement seems 180-degrees from commonly accepted practice. Most people will tell you that Flash Player has greater market penetration than Windows Media Player (it does!).

However, if you exclude Macs and mobile devices from consideration, WMPlayer has excellent market penetration too. Perhaps this is why wmv seems a better choice for members of Danny's church.

**************************************
Which brings up the most important consideration when we're making these streams or clips available - the audience, their expectations, their level of tech sophistication, their likely viewing platforms, and the sustained bitrate their internet connection can support.

The next consideration might be what tools we can employ. For example, Danny's viewers benefit from a local copy of a long clip. Maybe they would be better served by a WM (or flash) player embedded in a web page, but, as Danny points out, they would need a way to skip ahead to the point they're interested in - possible with a web player, but not commonly implemented, and much more sophisticated html coding, as I understand it.

For another example, somebody who has a (name-your-codec)-based workflow that satisfies the people who care is going to be reluctant to change it, even for the promise of higher quality.

However, if you exclude Macs and mobile devices from consideration, WMPlayer has excellent market penetration too. Perhaps this is why wmv seems a better choice for members of Danny's church.

If you're dedicated to wmv renders, Silverlight is also an option. Here's a sample of a WMV render that works fine in IE, Firefox, Chrome as well as Safari: SilverLight Demo (http://www.jazzythedog.com/testing/Horse-SL.html) However, I doubt that there are many mobile devices that will play it.

That said, if you combine HTML5 & Flash with h.264, Theora & Webm source, you can play on most any platform. I'm still experimenting, but I've got the following to play on pretty much everything except a 'droid phone: Flash/HTML5 Testing (http://www.jazzythedog.com/testing/browsertest.htm) Unfortunately, I don't have a 'droid to test with, so I'm not sure how much further I'll get.

Here's the html:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>Flash/HTML5 Testing</title>
</head>
<body style="background-color: Black;">
<form id="form1" runat="server">
<div style="width: 1024px; margin: 0 auto; background: url(Images/html5.gif) repeat;
text-align: center; padding-bottom: 50px; -moz-border-radius: 15px; border-radius: 15px;">
<h1 style="text-align: center">
Flash/HTML5 Testing</h1>
<video style="-moz-border-radius: 15px; border-radius: 15px;" width="480" height="270"
autoplay controls>
<source src="Videos/HandHelds/Horse.mp4" />
<source src="Videos/HandHelds/Horse.webmvp8.webm" type='video/webm; codecs="vp8, vorbis"' />
<source src="Videos/HandHelds/Horse.theora.ogv" type='video/ogg; codecs="theora, vorbis"' />

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="480" height="295"
id="player1" name="player1">
<param name="movie" value="jwplayer54/player.swf">
<param name="allowfullscreen" value="true">
<param name="allowscriptaccess" value="always">
<param name="flashvars" value="file=../Videos/HandHelds/Horse.mp4&autostart=true">
<embed id="player1" name="player1" src="jwplayer54/player.swf" width="480" height="295"
allowscriptaccess="always" allowfullscreen="true" flashvars="file=../Videos/HandHelds/Horse.mp4&autostart=true" />
</object>
</video>
</div>
</form>
</body>
</html>
...Jerry

thanks, Jerry - I've always admired your work. I may (again) cut'n'paste your code - just to see if I can get a little traction on this.

I talked to my daughter last night who is a producer in a post-production house in Santa Monica, and she may give me a few leads on tiny hand-held 'droid devices that don't have an included phone (any suggestions?). Then maybe I can test further.

Larry, Feel free to use the code. If you get it to work with 'droids, please post the results back here or to the SCS form. One thing that you should be aware of... I used HandBrake to render the h.264 (.mp4) clips. And Miro: Miro Video Converter FREE - Convert any video to MP4, WebM (vp8), iPhone, Android, iPod, iPad, and more. (http://www.mirovideoconverter.com/) to transcode the Theora & Webm.

Good Luck!
...Jerry

PS: Here's a very valuable resource: Dive Into HTML5 (http://diveintohtml5.org/)

Jerry, thanks for posting that code sample. I look forward to working with it. Also, yes, the diveintoHTML5 looks great too.

For those wondering why html5 video code looks so friggin' weird, the problem is that there isn't agreement between the html5 browser manufacturers as to what is an appropriate video codec, which is very irritating to content producers wanting to use it. Actually, it's a small tragedy, that the "next big standard" isn't a standard at all. Apple appears to have been the big spoiler - I guess the point is that they're more concerned with icing competition in their mobile market than serving customers. That's just my slightly informed opinion, they probably see it differently, and their competitors aren't lily-white either... Here's some commentary from The Economist (http://www.economist.com/node/15927112), I find it interesting, don't know if you will.

The result is what you see in Jerry's code snippet - a whole series of video sources in various formats, the intention being that a particular browser will ignore the code & codecs it doesn't understand, and execute the first code that it does understand. This isn't quite the same thing as sniffing out the browser and delivering code customized for that browser... which is another approach that is popular among coders.

For me, this has mostly been theory for html5, one of these days it's gonna' be important.

The way I read the JW Player propaganda, it is supposed to be able to "sniff out" the browser's capability and roll over to HTML5 as needed; but I haven't had much success with that so far - but my time is tight and I haven't really done justice to this project.

@Jerry:
"I used HandBrake to render the h.264 (.mp4) clips. And Miro: Miro Video Converter FREE - Convert any video to MP4, WebM (vp8), iPhone, Android, iPod, iPad, and more. to transcode the Theora & Webm."

Yes, me too, but I vaguely recall someone arguing that Miro had limitations and that maybe we should be looking at ?? (I can't remember the other one, but I think it was somewhere in that HTML5 thread)

I just ran my first tests on the code Jerry supplied in post #20 above...

Testing across iPad, Safari/Mac Firefox/Mac, and on the PC in IE8, IE9, Chrome, and Firefox, I seemed to have more luck nesting the html5 video code inside of the object, instead of as written.

But, I'm not sure I'm doing this the best way... Jerry, have you continued with this, or are you aware of others who are continuing this approach to multi-browser support?

Seth,

I've "kinda abandoned this" as I need to have a cadre of devices in order to test - and all I have are Windows computers and a Viewsonic gTablet.

However, my direction in posting to the web has taken a different turn. I'm now using the JW Player javascript api (rather than embedded objects).

I'll post some html tomorrow. It's all based on h.264 (mp4) videos, but it plays on many devices/browsers.

...Jerry

As mentioned in the previous post, I have no means to test this, but here's my latest venture into hosting video for multiple devices based upon JWPlayer. It has some "fluff" in it as it uses lighbox techniques based upon SimpleModal (http://www.ericmmartin.com/projects/simplemodal/) - not necessary and you can strip it out of the code.

Cutting to the chase, here's the URL of the test page: Autumn in Delaware (http://www.jazzythedog.com/testing/autumn.html) I'd be very interested if folks in DVInfo-land with various devices/browsers could feedback its playability.

Here's the html:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Autumn in Delaware</title>
<meta name="title" content="Autumn in Delaware" />
<meta name="description" content="An Autumn Day in Northern Delaware, featuring the Wilmington and Western Railroad" />
<link rel="image_src" href="http://www.jazzythedog.com/testing/images/Jazzy-Cartoon.jpg " />
<link href="http://fonts.googleapis.com/css?family=Copse:regular" rel="stylesheet"
type="text/css" />
<script src="http://ajax.microsoft.com/ajax/jquery/jquery-1.4.4.min.js" type="text/javascript"></script>
<script src="js/jquery.simplemodal-1.4.1.js" type="text/javascript"></script>
<script src="JWPlayer/jwplayer.js" type="text/javascript"></script>
<script type="text/javascript">
function playIt(divID, vid, width, height) {
var pct = .70;
var aspect = width / height;
var w;
var h;
//video names for lower bitrates/framesize
// we have 3 video files at three different bitrates
// base file is 960x540, lower bitrate folders are 640x360 and 320x180
var vid640 = vid.split(".")[0] + "640.mp4";
var vid320 = vid.split(".")[0] + "320.mp4";
//Logic to size the player based upon the browser size
if ($(window).width() / $(window).height() > aspect) {
h = Math.round($(window).height() * pct);
w = Math.round($(window).height() * pct * aspect);
// alert("h=" + h + "\r\n" + "w=" + w + "\r\n" + "Ratio =" + w / h);
}
else {
w = Math.round($(window).width() * pct);
h = Math.round($(window).width() * pct / aspect);
// alert("h=" + h + "\r\n" + "w=" + w + "\r\n" + "ratio =" + w / h);
}
//Don't make the Player larger than the source footage
if (h > height) {
h = height;
w = width;
};
// setup the jwplayer & use the levels param to switch bitrates
// use MediaInfo to get the bitrates of each video file
jwplayer('container').setup({
// 'file': vid,
'levels': [
{ bitrate: 1235, file: vid },
{ bitrate: 660, file: vid640 },
{ bitrate: 241, file: vid320 }
],

'height': h,
'width': w,
'modes': [
{ 'type': 'flash',
'src': 'JWPlayer/player.swf'
},
{ 'type': 'html5',
'config': {
'provider': 'video'
}
},
{ 'type': 'download', config: {
'provider': 'video'
}
}],
'events': {
'onComplete': function () {
$.modal.close();
}
}
});

$(divID).modal({
opacity: 80,
overlayCss: { backgroundColor: "#342826" },
containerCss: { height: h, width: w },
onClose: function () {
$.modal.close();
}
});

jwplayer('container').play();
}
</script>
<style type="text/css">
#simplemodal-container a.modalCloseImg
{
background: url(images/x.png) no-repeat;
width: 50px;
height: 58px;
display: inline;
position: absolute;
top: -20px;
right: -20px;
cursor: pointer;
z-index: 3200;
overflow: hidden;
}
div.divmain
{
background: url(images/JazzyEmboss.jpg);
background-color: Gray;
width: 1024px;
height: 768px;
margin: 0 auto;
}

.vidbutton
{
margin-left: 50px;
}
</style>
</head>
<body style="background-color: #686868;" onload="playIt('#player','Videos/Autumn2011.mp4',960,550);">
<div class="divmain">
<h1 style="font-family: Copse, Verdana; color: Orange; text-align: center; padding-top: 20px;">
Autumn in Delaware
</h1>
<div style="height: 200px;">
</div>
<input id="Button1" class="vidbutton" type="button" value="Play" onclick="playIt('#player','Videos/Autumn2011.mp4',960,550)" /><br />
<!-- <input id="Button2" class="vidbutton" type="button" value="Video 2" onclick="playIt('#player','Videos/Parrots.mp4',640,360 )" />-->
</div>
<div id="player" style="display: none; overflow: hidden;">
<div id='container'>
Loading the player ...</div>
</div>
<div style="display: none;">
<img src='Images/x.png' alt='Close' />
</div>
</body>
</html>


Finally, my caveat - I'm not an html/javascript "expert" I just struggle thru the documentation and Google when I get errors.

...Jerry

Most recently, the push is for h.264/MPEG-4/AVC in the flash player. This codec arguably equals or surpasses WMV for pq for the bitrate.

With earlier versions of WMV encode I would agree but with the VC-1 I am getting much better pq for the bit rate and a much smaller file size than with h.264/MPEG-4/AVC.

I now divide the 1.5 to 2 plus hours Church service into related parts, compress them with Vegas in regions to wmv with audio settings being,

Mode: Quality VBR - Format: Windows Media Audio 10 Professional, Attribute: VBR Quality 10, 48 kHz, 2 channel 24 bit VBR,

Video settings are Mode: Quality VBR, Format: Windows Media Video 9 Advanced Profile, Image size custom, width 560, height 320, frame rate 29.970 (NTSC), Quality 83%.

While that gives a good quality video, it is not the best because I am trying to keep the file sizes as small as possible. So I am compromising a bit.

I am using Vegas 11 and have tried the MC AVC and Sony's AVC and I can't get anything close to what WMV gives me!

As for the handbrake method that seems more oriented to shorter and larger frame size videos.

Anyway, the VC-1 makes a huge difference for me.

Finally, I am not closed on this; I am always spending too much time looking for that magic something that will work for as many people as possible.

My target audience is everyone not just the Church members.

Living Hope Restoration Branch (http://www.dannyfye.com/lhrb)

Jerry, complete success viewing the video in IE9. Some success viewing on a Motorola Xoom running Android 3.1, but no transport/volume controls. Worked fine on iPhone3GS.

Hope that's of use. Lovely footage, by the way. Delaware added to the list . . .

Works fine with Safari on a Mac Pro. Progress bar and full screen works as it should. You just can't beat a steam engine...Lovely!

Thanks for the testing! I suspect the reason for no transport controls is that, if all else fails, the video is played as a "download" - and that would be dependent upon the device's download player.

Keep the tests coming!!

...Jerry

autumn.html:

iPad - yes
Chrome/PC - yes
Firefox/PC - yes
Firefox/Mac - yes
Opera/Mac - yes
Safari/Mac - yes

When I flooded my internet connection, I also got a chance to see the adaptive streaming work - it does!

Jerry, thanks for the referral to the latest JWPlayer, I'll check that out one of these days soon!

...

PS: Here's a very valuable resource: Dive Into HTML5 (http://diveintohtml5.org/)

That site seems to be gone now. I found a new link: Dive Into HTML5 (http://diveintohtml5.info/). I trust it's the same site just relocated.

D

Hey Jerry, I'm reviewing your autumn.html code for adaptive jwplayer closely, because I want to use it as a sample in class...

At lines 22 and 23 you're constructing the filenames of the alternate versions of the video? It's a little difficult for me to follow the code, because I don't know the real name of the target files. Is it Autumn2011640.mp4 and Autumn2011320.mp4?

// base file is 960x540, lower bitrate folders are 640x360 and 320x180
var vid640 = vid.split(".")[0] + "640.mp4";
var vid320 = vid.split(".")[0] + "320.mp4";


Thanks!

PS. Where did this adaptive JS come from? Did you write it? I'm not finding it at the jwplayer site, or at least not yet.

Seth,

You've got it right. Here's some more details.

I rendered my project in Vegas to a DNxHD intermediate - 1920x1080 60p. Then used HandBrake to render 3 video files; Autumn2011.mp4 (which was 960x544), Autumn2011640.mp4 (640x368) & Autumn 2011320.mp4 (320x176) {HandBrake likes Mod 16}. Each of these used a HandBrake setting of Constant Quality: RF 30 & 29.97 fps (as I recall).

Using MediaInfo, we can determine that the bitrate for Autumn2011.mp4 is 1235Kbps, Autumn2011640.mp4 is 660Kbps and Autumn2011320.mp4 is 241Kbps. JW Player then uses the following code to determine which file to use based on the available bandwidith.

'levels': [
{ bitrate: 1235, file: vid },
{ bitrate: 660, file: vid640 },
{ bitrate: 241, file: vid320 }
],

Of course, the objective is to adjust the size/quality of playback based on the user's available bandwidth.

Make sense?
...Jerry

Edit: Yes, the JavaScript is mine, based upon the API I found on the www.longtailvideo.com site.

Thanks Jerry!

I had good results this afternoon using the "Levels" block in JWPlayer to rather seamlessly accommodate html5 and flash plugin browsers - it's really working well. I started with the code in the quickstart pdf.

Adaptive to bandwidth? Perhaps tomorrow.

Thanks, this is some good source and really helped me get started fast. JWP has really come a long way in the last year or two, it's been a while since I looked at it.