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

[The Wanderer]

Reimar Döffinger wrote:

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

...I suppose I could sort of understand that perception, but I find that
they're frequently essential (or at least extremely convenient) in any
extended discussion, and it seems impolite to not indicate who said what
(if only because then there's the risk of having it be thought that
someone else said it). Still, it's probably not a major issue...

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

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

Yes, you're right, I had misunderstood you. In point of fact, from the
few things I remember from the various reports I've seen of problems
with the OpenDML support, I think it likely that the main problem (and
perhaps the only problem) is in MEncoder - specifically in the muxing
code somewhere.

>> 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 don't remember that, myself... OpenDML support hasn't been a runaway
hit, but except for a few cases where it was being used (in muxing) when
it didn't need to be and problems were arising from that, I don't
remember any reports of problems until the crash thing you referenced.

>>> 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? ;-)

...Probably not, no. I suppose your point is taken.

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

...maybe I should get into the habit of reading the Bugzilla... I've
never really been comfortable with things like that, for no really good
reason.

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

That and my philosophical differences with you about where the default
"unchanged volume" should be, but that wouldn't interfere with my own
ability to use the plugin.

I seem to remember having tried various different combinations and not
succeeded in getting anything acceptable... but the details escape me,
so I suppose I'll have to try it again when I'm up to concentrating that
much on something non-frivolous.

(I also don't see how the presence of the plugins would help in being
able to test the filters... but that's a side note. 1.0pre6 would
certainly do as a thing to fall back to if I don't like the results of
updating, since it's almost identical to my current CVS tree anyway.)

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