« destiny | Main | flickerbat »
November 11, 2006
codecs++;
joining me this month are the windows build of xvid from koepi.org and a patched ffmpeg build that transcodes to flv.
completely replacing divx with this build of xvid (as recommended by djgrenola) has finally liberated me from the long-standing vdub randomly closing problem. i don't know why it didn't occur to me to try xvid earlier, actually--i guess i was convinced i would lose something in the process of moving over, but that has not happened as far as i can tell. indeed, sda users have been watching xvid-encoded mq and lq avi for a while now without reporting any problems, so i have to consider this codec replacement a resounding success.
the new flv creation process recommended by mike hearn is still under evaluation, but i am encouraged by its fruits thus far. the only major sticking point for me has been that it demands that the input video be upside-down (flipped vertically), and so i must create a distinct .avs file for flv encoding now (as opposed to just using the mq mp4's), but this is really quite minor compared to never again getting shot down by one of the macromedia flash video encoder's myriad avs input bugs or having to set the video and audio bitrate every time i reboot the machine or wondering how much better quality/smaller of a file i could make had i multipass encoding--and i could go on.
the divx codec and the macromedia flash video encoder were dragging me down without a doubt, and i am grateful to the community for their continued support of my work.
Posted by njahnke at November 11, 2006 1:20 PM
Comments
Be careful with multi-pass encoding for streaming applications (embedded flash for example). If you encode using 1-pass CBR at, say, 512Kbps, then somebody with a sightly faster connection will be able to play back it fine (if the server can sustain the speed).
But if you use 2-pass VBR, there's danger that, for example, the first half of the video will be 800Kbps and the second one 200Kbps, causing streaming problems (the user will have to wait for it to download, or it will play in slow-motion with cut sound if the player doesn't wait).
The best solution is what YouTube / Google Video use: VBR but with maximum bitrate cap. So it is (for example) 400Kbps but never goes above 512Kbps - not pure VBR, just a little of it.
I don't have experience with the ON2 VP62 codec so I can't comment on it.
Posted by: Lalalalala 
at November 16, 2006 10:21 PM
that's all true of course. thanks very much for commenting before i roll out this thing. to be honest i hadn't considered this at all. the solution is simple, too--excellent.
Posted by: nate at November 16, 2006 10:27 PM
Post a comment
Thanks for signing in, . Now you can comment. (sign out)
(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)