I just re-read the title of this thread - "rendering for streaming servers" If you are rendering for true streaming rather than progressive download, the "web optimize" option may or may-not need to be checked. I can't remember and can't check because my free trial of Cloudfront has expired (and my ISP doesn't support rttp streaming). A couple things I'm pretty sure of: 1) "Web Optimize" will not hurt, and 2) h.264 mp4 renders will work nicely for either progressive download or streaming.
There is a subtle difference between "streaming" and "progressive download" Many people use the term "streaming" when they mean "progressive download" (I sometimes slip myself). With "streaming" can you jump forward to a point that has not yet been downloaded. see: Streaming vs. progressive download: Understanding the difference The issue with "streaming" is... if you don't have the bandwidth, the online video just won't play. YouTube uses a concept called "pseudo streaming" which "progressively downloads", but still allows the user to click the progress bar to jump ahead.
Now the caveat. I'm pretty the above paragraph is still true. It was 6 months ago, but things change mighty fast in the wild wild web.
sounds like its the same as encoding for progessive
from wowza support
You have to encode multiple files for multi-bitrate streaming. Each has to be key frame aligned. I'm not sure about Handbrake, but we know that Expression 4 Encoder is capable of creating multiple key frame aligned encodes. Take a look at this article
We have experience with Expression 4 Encoder and we know it produces key frame aligned sets as required for switching in multi-bitrate streaming You can try it with Handbrake, I have not tested it.
--
OK what are key frame aligned sets?
I take that to mean that sets mean sets of videos
anyway on the hb forum they said hb "should" produce aligned