Tree videos using Google

[Reg]

I'm trying to get the jist of this web video thing. I understand little bit's but most of the stuff posted on the threads goes totally over my head.

I have highlighted two recent video's which I edited on Windows Movie Maker and then sent to Google videos (for free). They are set at 340 KBPS, which if I understood correctly determine the quality but also the file size.

I'm trying to find an acceptable balance between the two values, so clients who have either Broadband or Dial-up can view video's of reasonable quality without struggling to download.

Please take the time view the videos and comment on whether the overall viewing quality/download time is acceptable.

Any advise would be greatly appreciated, but only in simplistic terms please, I'm not the most modernised bloke in the world. Thanks

1) Poplar felling with crane. 19.2 MB. 7.37 mins

http://video.google.co.uk/videoplay?docid=-9074180283220324208

2) Beech felling. 15.6 MB. 6.10 mins

http://video.google.com/videoplay?docid=-5308215968236826983

You see, I can't even link them like everyone else does. Advise please!

 

[Colin]

Hey

You did great, bit hard on yourself.

The links are fine plus Google converts the video format anyway.

Must have been tough holding that video camera and climbing and cutting at the same time. Unless of course you have a helmet cam that has zoom facilities .... which they dont seem to have available for sale last I checked.

The echo saw did OK.

I try to use WMV format around 700kbps which come in at 5mb per minute. when google converts it, it is a little clearer but what you did was good enough.

Takes a long time to load it up to Google I find, then the validation process and finally 2 days later you can list it as you have. Maybe try Youtube with the same vids and compare the two.

I load mine up to my own server so it plays in your own media player allowing you to fiddle with it and save it. But that's more involved and you must have your own webspace.

Good on you and good shoot'n. Get some more mate.

 

[TheTreeSpyder]

Nice crane picks; good ballasting!

We be on cable, fair speed and quality here.

Google Video uses .FLV; Adobe (jsut bought from Macromedia) Flash Video(right clicking movie brings up Flash Player id) . So uses the top rated Sorenson Squeeze codec (COmpression DECompression algorythm) to give videos the best chance of best compression while maintaining quality. The compression is a lossy (meaning not quality lossless compression strategy) like .jpg's.

This will give you best in the buisness compression and quality ratio. I'm not sure what version they use. You may want to experiment; and make determination if you want to strategize not to compress the vids with MM; then send to Google. Then compare quality and final output size. Generally, it is best not to compress 2x quality wise; especially with 2 lossy compression programs; multiplying each other's quality losses; rather than just adding them. The Sorenson Squeeze may compress uncompressed more; with less quality loss than doing it in MM and then sending to Google. The final output size may be about same, but better quality (not that these are bad; jsut perhaps better strategy).

You may wish to make a higher quality/large file (no compression) and lower quality/smaller file output from MM for seperate customer download offerings/speeds like many sites do.

The file size will also be determined by output size on screen. Vids were larger here than a lot of Google vids i think i've seen. So, smaller screensize output from MM should help. So, file size is Quality x Colors x Size x Length b4 compression. Larger screen size of also high quality would be larger file size for cable. Smaller screensize, of less quality and colors(maybe BW?); could give 2 output file sizes from MM (with a few button pushes after all real work of eiditing and producing is done) to send to Google.

A better / higher MP camera would allow more computer zoom with less quality loss, but higher filesize. Better lens would allow better quality with smaller filesize.