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

[Reimar Döffinger]

Hi,
On Tue, Dec 28, 2004 at 09:18:02AM -0500, The Wanderer wrote:
> 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...)

Well, I find them annoying, that's why I removed them... But I can
change that easily...

> >>>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.

I think you misunderstood what I meant: It seems the odml code in
MPlayer seems to fail mostly (only?) on files created with mencoder so I
suspect there is something broken there...

> 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.

What I seem to remember is that at least at some point odml support
broke more than it fixed...

> >>>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.)

No, your reply was enough to keep me from removing it, but would you
have answered so fast if I hadn't threatened a bit? ;-)
Also there are already some fixes at the bugzilla entry, but I very much
dislike them all. It would be nice to get some discussion about them
(e.g. if it is a good idea to rely on a libc sort implementation).

> >>>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.

So the main problem is the crackling? Maybe you should enable
soft-clipping then? No idea, but the software volume control seems to
work fine with me. Well, you can use pre6 to test, it still has the aops
;-)

Greetings,
Reimar Döffinger