Re: [xine-devel] use a probing function for the demuxers

[Marco <M.Z...@fr...>]

On Tuesday 03 June 2003 20:56, Mike Melanson wrote:
> On 3 Jun 2003, Thibaut Mattern wrote:
> > I'm not conviced by the performance gain, but like this kind of cleanup.
> > Mike, remember what was the demuxer loop when you started to rewrite the
> > quicktime demuxer...
>
> 	Yeah, I certainly remember. And cleanup/simplification is a good
> thing.

Maybe I stressed the performance gain to much and forgot the impact of the 
caching. But the cleanup of the demuxer would be a goal that is in my opinion 
worth the effort. But I'll wait for comments from other core developer before 
starting. 

> But I have recently been wondering what it would take to possibly
> adapt xine to use ffmpeg's libavformat codebase. Currently, xine's demuxer
> API has a variety of advantages over libavformat. But in the spirit of
> inter-project cooperation and harmony, I wonder if it is worth
> investigating. Plus, there is the fact that I am putting all of my current
> and future decoders into libavcodec. So it makes sense to have demuxers
> for certain specialized formats in the same codebase.

But if the xine demuxer API has some advantages, why not use it. If I'm not 
mistaken ffmpeg is mostly a huge and very well maintained collection of 
fileformats and codecs. But wouldn't it be possiible to implement ffmpeg and 
ffserver on top of libxine  and the (much more flexible) plugins instead of 
libavformat and libavcodec. xine-lib is now a very cappable multimedia 
library. There's still the problem that xine only contains (at the moment) 
demuxer and decoder. But with the help of enix, it could be solved and 
encoder and muxer could make up new plugins.

> 	I have a little influence in the ffmpeg project now. If I have
> some reasonable ideas for improving the demuxer layer, they will likely be
> accepted. One notable lacking feature is any kind of sane seeking API.
> Then there is the probe() detection API which is a good, simple idea, but
> not flexible enough for all types of QT files, at least. Then there's the
> fact that the demuxer API is integrated into ffmpeg and needs the input
> layer and other facilities to function. Hmm...still, is a unified,
> cross-project demuxer (and muxer) API that difficult to attain?

A while ago there was a project called UCI (universal codec interface) which 
tries to provide a unified access to decoder and encoder. There was also 
discussion to extend it with a common interface to (de)muxer but neither of 
both achieved anything so far.

cu Marco