On Fri, 2004-01-02 at 15:29, Steven M. Schultz wrote: > > If a couple minutes to save hours of encoding time doesn't make it > worth the small amount of time then nothing will.
The actual build, once you got everything right, yes you are right. It's the management of "this depends on that, so build that, which depends on the other so build the other" and so on and so forth (like my current fight with mpeg4ip -- all kinds of gripes from automake/autoconf, etc.). It's just so much easier when the distro vendor takes care of making sure all interdependencies are met. My list of stuff I want to do is just way too long to include software build management. Not even to mention the mess of a system you wind up with when you can't track the origin of a given file (like you can for example when you do an "rpm -qf `which mpeg2enc`"). > Welcome! Uh, mpeg4ip is a big project - useful to have though. So I am discovering. I am going to attempt to build just mp4creator and see if it's useful before I try to build the whole beast. > And neither am I. Current usage differentiates between computer > software playback and a box that sits on top of the TV. Right. I agree. But I want to clarify if you are asserting that mpeg2 only belongs in a (trying very hard to not use the term "STB") dedicated hardware device (and not on a software device) or if that is just the way things are currently (perhaps due to technical and/or patent restrictions). > Go to any > video forum/mailinglist/whatever - you'll see that STB means standalone > unit and not a computer. Right. But are you asserting that mpeg2 should not be used in a "computer" running software to be the equivalent of an STB (i.e. software decoding out to a television)? > If it's clean material that's a bit on the high side. Agree. It's analog cable however, and not very clean at that. > There are > options to ffmpeg/mencoder that will allow the use of a considerably > lower bitrate. Yeah, I know. But unfortunately I don't understand enough about video encoding to understand (some of) them. > Mencoder can do the cropping without a speed penalty > and that would save some bits. Right. ISTR that I lower the bitrate when I crop. I know I do when I inverse-telecine. Hrm. Looking at my script, I don't. I should. For inverse telecining I do: vbitrate=$(($vbitrate * 8 / 10)) I should do a calculation on the amount of frame that is being cropped and reduce the bitrate accordingly. > I've done some encoding at ~1500 > which came out looking more than acceptable for casual viewing. From some sort of digital source? If yes, then I have no doubt. > Yep - but most TV shows are well less than that ~40 minutes per hour if you care to edit commercials before you encode, which for most stuff I do, but for other stuff I don't. It's those few that I don't that are the problems. Like the boy's WWE Raw. The commercial breaks are too plentiful and short and too much like the content for me to go to the trouble of editing. But him not being able to skip commercials and stop and resume playback at a later time (all due to seek difficulties) is a grand PITA. > (most movies > too except for the occasional epic length ones). Hmmm, MPlayer > can handle multiple files I believe so that would be another way to > handle the long movies - use 2 files perhaps. Yes, but I don't think mencoder can produce multiple files. I guess I could split the source files and invoke mencoder multiple times. This is getting more and more yuckky. All due to braindead avi formats. ~sigh~ Hopefully MP4 containers solve my problem. BTW: The tool I needed to use to get the MPEG-ES stream out of the MPEG-PS file I had was tcextract. Seemed to work just fine. Maybe I continue to use mpeg4/avi with content that will ultimately be <2G and use mpeg2 with content that will be >2G. Could be a fair tradeoff. b. -- My other computer is your Microsoft Windows server. Brian J. Murrell
signature.asc
Description: This is a digitally signed message part
