[MPlayer-dev-eng] What is odml good for??

[The Wanderer]

Reimar Döffinger wrote:

> Hi,

(Grr. Why is it that so many people not only don't attribute, but snip
out attributions which were already there? Not meaning to single you out
specifically, it's just that I see this often enough that it's starting
to get annoying...)

>>> Hi, I'd like to know what ODML is good for, because the only
>>> thing I heard about it up to now is that it is very good at
>>> crashing MPlayer (see
>>> http://bugzilla.mplayerhq.hu/show_bug.cgi?id=86).
>> 
>> It does two things that I know of: it allows vaguely proper
>> handling of AVI files greater than 2GB in size (there were, once
>> upon a time, quite a number of requests for this; if OpenDML
>> support were removed, I suspect there would be again), and it
>> allows proper seeking in AVI files of any size which have OpenDML
>> indices. The former of these is more commonly important than the
>> latter, judging by the discussions and requests I've seen, but it
>> is the latter which matters to me because I have a number of AVI
>> files which use OpenDML even though they're small enough that they
>> don't need to - and I'd very much rather be able to seek in them
>> than not.
> 
> It seems that at least with files that mencoder created -forceidx is
> just as fast... Maybe mencoder should be fixed as well...

For one thing, I'd prefer not to have to run every file like this
through MEncoder to be able to play it. For another thing, due to some
apparent idiocy on someone's part, there is a 'stream' in the files
(which I can get at by other means)which is neither audio nor video and
I think I'd be surprised if MEncoder did in fact copy it across even
with -oac copy -ovc copy. For a third thing, before the addition of
OpenDML support, seeking in those AVIs (even, IIRC, after generating
such an index) was just plain *wrong*; MPlayer would routinely (and
almost exclusively) seek to non-keyframes.

Regardless, this doesn't address the question of >2GB AVIs - and there
is apparently more demand for ability to deal with those than you might
think. I thought you were around at the time, but maybe not; if you read
through the archives from before support was added, you should find that
questions about how to handle such files were coming in on a fairly
routine basis.

>>> I'd say either this feature is important enough to somebody that
>>> he/she/it will fix or I'll just remove it.
>> 
>> Don't, please. It may, perhaps, be worthwhile to make OpenDML
>> non-automatic and/or non-default (and I don't mean at compile time)
>> - but it took long enough to get support added in the first place
>> that I feel that even comparatively buggy support is better than no
>> support at all, especially since while there's buggy support
>> there's the chance of someone deciding to go in and fix it.
> 
> You know, maybe the threat alone motivates somebody to do something
> about it ;-)

Yes, but what happens if it doesn't? I don't want to wind up with no
OpenDML support at all just because no one happened to be inspired to go
in and try to figure the thing out on this particular occasion. (And no,
I'm not about to try to fix the thing myself; based on the last time I
tried to investigate that code, I don't think I could even understand
it, much less figure out what's wrong with it, much less fix it.)

>>> I'm quite fed up with stupid, useless code in MPlayer.
>> 
>> ...on principle I'd agree with you, but I'm a little sore right now
>> over the fact that I'm not sure I want to update to the latest CVS
>> because I'd lose volume-control functionality because AFAIRBATT at
>> last check the volume filter *still* did not provide functionality
>> equivalent to what was provided by the volume plugin...
> 
> I don't think that is the case anymore - it should actually provide
> more functionality... You will of course have to find out how to use
> it of course ;-)

...have there been more changes since the last time we were discussing
it on-list? At that point, as best I remember being able to tell, I
still could not get on-the-fly software volume control with the filter
which could go up to a maximum comparable to that available with the
plugin without producing any more audio distortion (crackling, etc.)
than was produced by the plugin.

It's faintly possible that this is just my misremembering, but I think
that if I'd been able to do that I'd have switched over to using the
filter at the time (since I don't *want* to be an obstacle to Doing
Things Right), and I've certainly still been using the plugin.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

A government exists to serve its citizens, not to control them.