Jeff Hyche wrote:

There are only two parameters that you need to feed the script. The –s <size> option to tell it the size of the file you want it to put out, and then the file(s) that you want it to work on.

I'm intrigued. This is along the lines of the very thing I need.

However, what *I* am after is something that will let me transcode all of the various vids that I have collected over the years. Some of them require some old codecs that aren't stable enough for me (like angelpotion or divx 3.11-alpha) and some use just really old ones (cinepack, indeo, etc.). In the case of your script, I guess I could just tell it that I want the target file to be the same size as the source.

There are a few roadblocks that I'm currently stuck on, however. I'm wondering if your script avoids them. 1 - I've found a few cases where, if transcode can't figure out the container or if it doesn't know how to decode a certain video encoding (I forget which), it defaults to using /dev/zero and ends up running forever... or until the disk fills up or I kill it. 2 - If transcode doesn't recognize the audio encoding (as opposed to *no* audio being there), it just tosses the audio and continues to transcode the video. I would prefer that it didn't even bother. 3 - Of course, if the audio track is already in a format that I accept (ie, mp3 128kbps or something), then I'd want transcode to just pass-through it, if it can.

How much checking does your script do to deal with these issues?

- Joe

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to