I have been very skeptical about adding options for other codecs in undvd, purely because of the test burden. With a single combination of container and pair of audio/video codecs I can be reasonably confident that I've done enough manual testing (and judging video quality doesn't trivially lend itself to automated testing, sadly) to account for most potential problems.
But at the end of the day it's a question of priorities, and having scratched all the important technical itches by now, if anything this is the right time for it. I got some user feedback recently that set me onto this path. The user was having trouble playing the files encoded in the classical avi+h264+mp3 format on other platforms, and that's when I asked myself how important is it really to have a single format? As long as the default still works well, what's the harm in offering a little customization?
Testing is a huge problem, which is why this new feature is considered to be experimental. The most common seems to be bad a/v sync. There is just no way to account for all the possible combinations of codecs and containers, and to maintain an up-to-date document for this as things evolve. So the burden of testing is squarely on the user here (which is quite unfortunate).
The new functionality is available in undvd 0.5 and up. Here's a shot of the new goodness. All these files were encoded from the same dvd title. A 22 minute title was ripped with different containers (represented with different filenames). The audio codec is mostly the same in all cases (mad = mp3), except for 1.mp4
(faad = aac). The video codec is also mostly the same (h264 = avc1), except for 1.flv
. The only variation here is the container being set to different values, all the other settings are defaults. You can also witness that some containers are more wasteful than others (given the same a/v streams), but not by a huge amount. (The audio bitrates shown are actually misleading, mplayer seems to give the lowest bitrate in a vbr setting.)
This demo is by no means exhaustive of the full collection of codecs that can be used, for that see the user guide. There is also an option to use the copy codec, which just copies the audio/video stream as is.
Getting a/v properly synced has always been my worst encoding nightmare, which is why I just gave up and left my DVDs in MPEG2 and AC3. Sure, it takes space, but saves time (which is ultimately more valuable).
However, one thing that I actually ended up doing with syncs on playback was just setup my remote to modify it using mplayer ( + and - ) by .1 ms. That was also much simpler than spending a lot of time trying to get every file correctly fixed.
[...] BSD, a matter of sustainability 9mo (1) [...] GPL vs BSD, a matter of sustainability .. » of codecs and containers 2d (1) Getting a/v properly synced has al.. -Steve Dibb » coast to coast 3d (5) You [...]
[...] BSD, a matter of sustainability 9mo (1) [...] GPL vs BSD, a matter of sustainability .. » of codecs and containers 1w (1) Getting a/v properly synced has al.. -Steve Dibb » coast to coast 1w (6) You [...]