Great post, you raise some very important points. Its certainly true that sites that offer transcoding to multiple formats, should encourage the user to encode & upload the highest quality/bitrate/resolution version of the video, and all the lower quality/res/bitrate versions are then created from that high-quality version.
Uploading DV has always been very far from ideal, too large, and whilst in many countries the download rate of broadband has been increasing, upload rates are still relatively slow for most. You are right to point out that if blip use a higher bitrate for certain new transcoded formats, much higher than the bitrate the user has uploaded video to blip as, then its a pointless waste. But this is also extremely true of resolution which you didnt mention as much - mostly the 600kbps files that people may currently upload to blip, are likely to be at 320x240 or equivalent widescreen res, and then it would be really pointless for these to be converted to 640x480 files. For me it would make more sense, if the 640x480 apple-tv is the highest quality & largest filesize offered, that this is the format the user encodes to ontheir compuer, then uploads that to blip. Then blip can make a slightly smaller 640x480 version for the ipod, and the various 320x240 versions in mp4 and flash format. All of these are then available. Strictly speaking for the absolute best quality you would encode all of the formats yourself, straiht from the master edited DV or equivalent, without using any intermediate formats, but obviously this has to be balanced against the extreme convenience of hosted transcoding services, and the fact these quality issues arent dramatic enough for everyone to need to worry about in this depth. But then as Mike has pointed out (I think), blip does already give the flexibility to go down this route if you want to. Cheers Steve Elbows --- In videoblogging@yahoogroups.com, Jen Simmons <[EMAIL PROTECTED]> wrote: > > 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" <mike@> 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] >
