On Wed, Feb 10, 2010 at 9:36 PM, Tim Starling tstarling@wikimedia.org wrote:
Gregory Maxwell wrote:
Looks like this change removed both the Oggthumb support as well as the code that handles the cases where ffmpeg fails.
The usual problem with deploying new solutions for equivalent tasks is that you substitute known issues with unknown ones.
I've looked at oggThumb now, I downloaded the latest tarball. Here are some of the ways in which it sucks:
So a couple months back mdale suggested using oggThumb, with the old installed ffmpeg was making spaghetti of some files (old ffmpeg not completely implementing the Theora spec) and the new one that (whomever) tried installing mage spaghetti in a different way (failing to thumb because ffmpeg didn't take your seeking patch eons ago).
I'd never heard of it, went to look, and recoiled in horror. Then I sent a patch.
- Unlike the current version of FFmpeg, it does not implement
bisection seeking. It scans the entire input file to find the relevant frames. For an 85MB test file, it was 30 times slower than FFmpeg.
Of the issues I raised, seeking was the only I didn't fix. Unfortunately oggvideotools reimplements libogg in C++ so it could use C++ memory management, my patience ran out before I got around to implementing it.
If you search the archive you can see how strongly opposed I am to tools that linear scan unnecessarily. But 30x slower on a file that small sounds a bit odd.
- The output filename cannot be specified on the command line, it is
generated from the input filename. OggHandler uses a -n option for destination path which just gives an error for me. I don't know if it's a patch or an alpha version feature, but it's not documented either way.
It's in SVN.
After the author of the package applied my patches (on the same day I sent them) Mdale asked if he should delay Wikimedia deployment until the fixes I sent in went in, the author offered to simply do a new release. No one took him up on the author.
- It unconditionally writes a progress message to stdout on every
frame in the input file.
- It unconditionally pollutes stderr with verbose stream metadata
information.
- It ignores error return values from libtheora functions like
th_decode_packetin(), meaning that essentially the *only* thing on stdout/stderr is useless noise.
I'm also not especially keen on its rather non-unixy style. Then again, I think C++ is pretty much crap too, so you can see what my opinion is worth. What I can say is that speaking from personal experience the author of this package is friendly, pleasant to work with, and responsive. Though 'submit patches' takes me out of the 'one line fix' I advertised, — sorry, I'd assumed that Mdale had already worked out the operational angles and my only concerns were correct output and not allowing it to be an enormous DOS vector.
Cheers.