Re: [xine-devel] [PATCH] crash in ac3 and dts demuxers

[Matthias K. <Mat...@ur...>]

On Monday 19 March 2007 16:33, Diego 'Flameeyes' Petten=F2 wrote:
> On Monday 19 March 2007, Matthias Kretz wrote:
> > I just realized that it should be enough to simply read PEAK_SIZE and l=
et
> > input_cache handle the details of blocksize, no?
>
> I think this is a moot point right now, the code seems to be quite old.
> input_cdda, referenced in the comment just above it, returns 0 without any
> effect when using read() function, while read_block() is used to read a
> block..
>
> So the code can be simplified even more from one side, even though this
> means that the block reading mode is not working anymore.
>
> I'm quite not sure where this comes from sincerely, is ac3 used in CD-DA?
> Or was it a refuse in the first place?

You mean where the crash came from? I just opened an mp3 file and xine went=
=20
though the list of demuxers to find the correct one and it crashed in those=
=20
two demuxers before the correct demuxer could claim the stream.

Ah, you probably wonder what input plugin I'm using. :) It's my hack to str=
eam=20
the input data from the main thread of the application. I'm using this to=20
feed the data from KIO into xine. (You don't want to know how many deadlock=
s=20
I had to debug.) Anyway, as a source for inspiration I looked at the=20
gnome_vfs input source and it specified a blocksize of 32kB; and as I have=
=20
blocks of the same size from some of my KIO sources I thought it would make=
=20
sense to set the blocksize to 32kB, too. And then the crashes on mp3 files=
=20
started...

=2D-=20
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
Mat...@gm..., kr...@kd...,
Mat...@ur...