Re: [xine-devel] libac3 trouble

[Guenter B. <bar...@st...>]

Hi Michel,

On Fri, 4 May 2001, Michel Lespinasse wrote:

sorry for the late reply, got busy with other stuff (xine 0.4.2 release
for example... and we'll have 0.4.3 soon - oh my... )

> > :)) oki, I just realized that I'll have to do the same for libmpg123 ...
> > but, there's no need to hurry with that anyway.
>
> I have some code around that does layer 1 and 2 and is (I think) much
> easier to understand than the mpg123 code. It also has the right
> reentrancy stuff and last time I looked it was actually faster than
> mpg123. But, it does not even try to handle any of the layer 3 stuff,
> and it never will because I think mp3 is a piece of crap, and also
> because none of the video applications (DVD and digital
> satellite/broadcast) use layer 3 anyway, they all limit themselves to
> layer 2.
>
> Do you think that would be good enough for xine ?

sorry, I strongly believe we need mp3 support in xine, because most AVI
files using divx / OpenDivx come with mp3 audio. BTW: we do not use
mpg123's code, but libmpg123 which is a bit cleaner, at least simpler (and
it's GPLed ;)) I've done quite a few bugfixes to that code and added some
features (handling streams that switch sampling rate and other stuff like
that) so I'm quite used to it's architecture - so I don't think it'll be
that much work to make it reentrant.


> Videolan also uses that code, actually that's about the only survivor
> of what I wrote for that project 3+ years ago :)

:)) ... why did you leave that project? I recently visited their homepage
and I was quite impressed what they've put together there - I was
extremely impressed by the wide variety of platforms they support, I guess
that's because they use SDL?

> > > [about test suite]

> Good. I dont have much source material around but if we can do this it
> will really help a lot.

oki, I've extracted some ac3 streams and copied them here:

http://w3studi.informatik.uni-stuttgart.de/~bartscgr/ac3/

ac3test.ac3 - a test stream for the 5 channels
arm.ac3     - a fraction of armageddon that produces audio glitches with
              the new ac3dec
egypt.ac3   - dobly digital "egypt" trailer
thx.ac3     - the thx chord
zorro.ac3   - movie trailer that is likely to overdrive output if not
              properly downmixed (5.1 -> 2)


> > We have a struct of function pointers that libac3 uses for it's audio
> > output. And yes, timestamping (pts) pass-through is one of the things we
> > added, output-mode negotiation (mono, stereo, 4-channel, ac3 raw ...) is
> > the other.
>
> OK. Then I guess the first thing to do should be to adapt ac3dec.new
> so that it uses the same output api as xine and then you could switch
> to use it and we would work on the same codebase.

oki, the question is what we'll do with xine-specific stuff (like
metronom). We could add some #ifdefs or ac3dec.new could use a "lighter"
audio_out.h so it's only source-compatible with xine now, not
binary-compatible .... a nice, extensible solution would be the greatest,
though...

> It still matters to be able to compile ac3dec without xine though. But
> that should not be a big problem to implement.

I too think this is important ... I really hated it when I couldn't
compile ac3dec / mpeg2dec because of "oms.h not found" :>

[ downmixing]

BTW: do you have any ideas about proper ways to do downmixing? simply
adding the channels and dividing isn't always the best solution as it
often results in a very low-volume center playback
(left_channel = l_surr + left + 0.5 center / 2.5 or something like that) -
I guess we'll need some logarithmic scaling here or something of that kind
... I hope this won't harm if we do downmixing first and then do the
imdct...

Cheers,

   Guenter

--
time is a funny concept