I am writing code to transcode .dv files to .ogg and upload to
blip.tv.  one blip requirement is the files have to be under 1gig.  I
am generally working with 30-45 min of ntsc, which results in .ogg
about 600mb.  sometimes a talk goes long, like hour or so, and using
the same bitrates I get  1.1gig, which gets rejected, and so I have to
go fix it.

What I would like is an option to cap the file size so that no matter
what, the file gets accepted.  I am uploading technical talks, and as
long as the audio is understandable, the video can suffer quite a bit
without significantly effecting the value of the upload.  What does
effect the value is if it doesn't get uploaded, and given I do this in
my spare time, 'simple' problems often never get fixed, and I end up
deleting the files to make space for new files.

How it is implemented, and what is sacrificed is up for discussion.

I do not mind making 2 or 3 passes.  I have plenty of CPU for this process.

I do not mind if it adjusts the quality up and down as the file is
created and resulting size is estimated using crystal ball code.  I
would prefer if only the video was adjusted - The audio is already
somewhat optimized (well, i have found that 64k is barely good enough,
and 96 is just fine. )

I do not mind if it just closes the file when it hits the limit,
provided the file is not corrupted.  but I would think this would only
happen after the last bit was severely adjusted, but somehow the
crystal ball was broken.

I do not mind if fps is dropped to 1fps, or if only keyframes are set,
and all the i-frames are just 0 delta (or something)

I don't mind if the adjusting doesn't take place until much of the
file has been encoded with the initial parameters - often people stop
watching 1/2 way though.  an option to set where the adjusting starts
would be good.

I can of course wrap the transcode command in a loop and drop the
bitrates each iteration until the file is small enough, which is kinda
like a multi pass encoding, but seems so brutish.  crystal ball seems
so much more.. planned ?

-- 
Carl K

Reply via email to