I will be interesting to see what the blip transcoding to AppleTV/ iPod results in. If I upload a 600 kbit/sec file to blip, and the magicians at blip translate that to a 1500-1800 kbits/sec Apple TV file (assuming its the same bitrate as the pre-fab settings here in FCP / Mac OS world) -- then that will be a poor result: all the long download times without any of the high-quality. [once data is thrown away, it cannot be gotten back -- for those of you who believe the TV spy shows that show "zooming in" on video -- that's not possible!]
The debate, to me, is not 640x480 vs. 320x240 -- the debate is 600 kbits/sec data rates vs. 1500 kbit/sec. Using the freevlog advice, I can get files that will start playing immediately (on U.S. 'broadband' connections) and still be the highest quality possible. At 1500, people _would_ have to wait several minutes _if_ they were trying to watch the file from a web browser -- a far too long a wait / most people would give up and leave. BUT I'm not going to stop encoding at 600 kbit/s for the website itself -- I'm just going to add a 1500 kbit/s video for the iTunes feed. People aren't expecting to watch the video right away from the iTunes environment. And a bit rate that is three times wider is going to result in some beautiful footage. I can only expect Apple did all kinds of market research / planning / thinking about wait times vs. files sizes vs. image quality when deciding to move all of their TV shows and movies to this new bitrate. I do love that these files Apple is making look great when blown up to two or three times the original size (to fill the HD screens). You just cannot do that with a 600 bkit/sec file! The biggest disadvantage I think of the wider bitrate is the fact people's harddrives are going to get full 3 times faster. And that Apple TV harddrive is awfully small. But that "problem" comes long after the viewer has already downloaded and watched your show -- it's not going to stop them from subscribing in the first place. I download two to four 45 minute files at 1500-1800 kbits/sec every week from the iTunes store, and I have no problems with "waiting". It all happens in the background, and I'm excited to get the content every time. So I say: let's embrace the Apple settings / 1500-1800 kbit/second! I was avoiding it based on Verdi + Ryanne's advice, but once I poked at the files and started figuring out what Apple is up to, I got excited about Apple's choices. The are trying to get us to all do one thing (not 50,000) and have it work as best as possible. I plan to use this for all iPod / Apple TV feeds. (And NEVER for files that are played straight from the browser.) I just hope the Blip transcoding does not use the higher bitrate, since (if people are uploading 600 kbit/sec source files) the quality will not reflect it. If Blip can get an Apple TV / iPod compatible 640x480 or 640x360 sized video going at the regular 600 kbits/sec rate -- that will be an incredibly useful tool. Small files for those who want it. Larger physical size. Works on the iPod/TV devices -- this is what is not possible right now, at least not from Quicktime / iMovie / FCP. The other option for Blip, I would guess, is to have users upload "high res" videos -- DV? / High-bit rate mpeg-4 files? -- expressly for the transcoding into multiple formats. Including a "normal" Quicktime format at a rate people can watch from the blip site / the creators website without waiting. Jen Jen Simmons [EMAIL PROTECTED] http://jensimmons.com http://milkweedmediadesign.com 267-235-6967 On Apr 23, 2007, at 4:32 pm, Mike Hudack wrote: > Hey Waz, > > I'm afraid the secret sauce includes a dozen pages of signed legal > documents and some custom code :) not sure what kind of file size > we're > talking... > > -----Original Message----- > From: videoblogging@yahoogroups.com > [mailto:[EMAIL PROTECTED] On Behalf Of wazman_au > Sent: Monday, April 23, 2007 1:29 PM > To: videoblogging@yahoogroups.com > Subject: [videoblogging] Re: Apple TV and iPod clash > > Mike, > > Great. How about sharing the secret with those of us who'd like to > encode the vids ourselves??? > > What sort of file size are we talking? Let's talk megabytes per minute > at 640x480. > > Waz > > --- In videoblogging@yahoogroups.com, "Mike Hudack" <[EMAIL PROTECTED]> wrote: > > > > Waz, > > > > Blip pro account holders soon won't have to worry about this :) > We're > > hoping to have transcoding to an Apple TV + iPod compatible format > > available for pro users in our next release (about two weeks away). > > > > Yours, > > > > Mike > > > > -----Original Message----- > > From: videoblogging@yahoogroups.com > > [mailto:[EMAIL PROTECTED] On Behalf Of wazman_au > > Sent: Sunday, April 22, 2007 3:30 PM > > To: videoblogging@yahoogroups.com > > Subject: [videoblogging] Apple TV and iPod clash > > > > Stupid bloody Apple, why do they DO things like this???? > > > > Folks, this is a tough one, and yes, I've read through the > > Casey-initiated thread. Good start > > but sadly optimistic. > > > > The question is, how do we pump out vids that are 640x480 and > have the > > "baseline low- > > complexity" profile, thus being both iPod and (presumably) Apple TV > > compatible? > > > > Baseline can be selected when exporting with your own settings, but > the > > "low-complexity" > > sub-option cannot. According to Apple's developer spec, low- > complexity > > has been defined > > by Apple for the iPod, and it seems to be restricted to the > Export for > > iPod option, which > > cannot be configured. > > > > When exporting an iPod video, QuickTime chooses automatically > whether > to > > use "baseline" > > or "baseline low-complexity" - in a nutshell, anything upwards of > > 320x240 gets low- > > complexity. Gory details here: > > > > http://developer.apple.com/technotes/tn2007/tn2188.html > > > > Three possible workarounds. I am not in front of QTPro right now so > will > > try later: > > > > 1) Use the Export for iPod option with the source vid sized at > 640x480 > - > > this will goad > > QTPro into using low-complexity - and then find some way of > saving the > > resulting video > > _again_ with a chopped-down bitrate, perhaps by doing a "Save > as ..." > > but without re- > > encoding. > > > > 2) Do it the other way round - export at the bitrate etc. that you > want, > > then run it through > > the iPod export. The developer spec suggests QT iPod exporter > using a > > 640x480 source > > file will pick its own bitrate according to a complex formula > ("DR = { > > (nMC * 8 ) / 3 } - 100" > > I kid you not, check out the developer link above) between 700 and > > 1500kbps. But maybe > > if the source file is already lower, it won't jump up the bitrate > too > > shockingly. The MC in > > the equation stands for "macroblock" and if the number of these > can be > > reduced in the > > source file (how? Dunno) then, doing the maths, you are headed for a > > smaller result. > > > > 3) Resize your source video to 640x480, whack it through Export for > iPod > > and hope the > > filesize is not too bloated. As in the formula above, this should > > produce something > > between 700kbps and 1500kbps, although Apple doesn't say whether the > > audio is > > included in that bitrate (AAARGH!). > > > > I found to my horror this afternoon that my carefully crafted > 640x480 > > recipe with > > meticulously pared down video and sound bitrates that delivered a > file > > of 5MB/minute that > > looks alright on the telly via laptop S-Video cable doesn't work on > the > > iPod. > > > > I am just about ready to tell Apple where to shove their TV box ... > and > > all of the above still > > leaves the question unanswered: will the aforementioned oblong > > suppository PLAY H.264 > > BASELINE LOW-COMPLEXITY??? > > > > Anyone got one of these boxes? > > > > That's all for now. I know none of the above is tested but I thought > I'd > > post now while my > > blood is up, and to give others the chance to look for a solution. > > > > Waz from Crash Test Kitchen > > http://www.crashtestkitchen.com > > > > > > > > > > > > Yahoo! Groups Links > > > > Yahoo! Groups Links > > > [Non-text portions of this message have been removed]
