Re: [xine-devel] Current seeking problem with network protocol

[Diego 'F. <fla...@ge...>]

(my mails should have sent to xine-devel too, sorry :/)

On Monday 11 September 2006 18:09, Thibaut Mattern wrote:
> What's the problem with libnms API ?
Nothing really, the problem is with the way the input plugins work in xine,=
 I=20
should get the raw data out of libnms in the input plugin, and then demux i=
t=20
in the demuxer, still with libnms, which is kinda crazy, but it's also the=
=20
only way I can think to get it to work..
The other solution would be to implement everything inside the demux plugin=
,=20
but I don't think it's a good idea.

> Take a look at my last change to the input_cache plugin.
> The gnome_vfs plugin defines a 32KiB and the input_cache uses this
> size, except if the read request is > 32KiB but that can be changed.
I'm reading it now, but I think this way you're overloading the get_blocksi=
ze=20
method, as it does not check the BLOCK capability this way.

On the other hand, this does not seem to help me with the MMAPped files (as=
 I=20
need to provide the buffer address from within the input plugin rather than=
=20
accepting it from outside, so that it does not really need to memcpy the da=
ta=20
out of the file).

> The more I think about the ring buffer work I've started several
> months ago, the more I think that it's really the way to go.
> Unfortunately, it's a lot of work.
A ring buffer certainly would help in most cases for network/pipe and simil=
ar=20
handling. I still think that for on-disk files it would be more performant,=
=20
as you leave the whole reading affair to the kernel.. it might help even fo=
r=20
dvd/svcd but I'm not that sure for those.

This more or less means that we should delegate the buffer strategy to the=
=20
input plugins rather than the engine itself...

=2D-=20
Diego "Flameeyes" Petten=F2 - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE