On Wed, Feb 10, 2010 at 9:36 PM, Tim Starling <tstarling(a)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.