[FFmpeg-devel] [RFC] Split libavformat

[Diego Biurrun]

On Wed, Nov 28, 2007 at 02:03:33AM +0100, Michael Niedermayer wrote:
> On Wed, Nov 28, 2007 at 01:01:22AM +0100, Diego Biurrun wrote:
> > On Tue, Nov 27, 2007 at 06:46:56PM +0100, Michael Niedermayer wrote:
> > > On Tue, Nov 27, 2007 at 04:24:08PM +0100, Diego Biurrun wrote:
> > > > On Tue, Nov 27, 2007 at 04:21:04PM +0100, Luca Abeni wrote:
> > > > > 
> > > > > Ronald S. Bultje wrote:
> > > > > >> Anyway, for the moment the only ffmpeg code that should be moved to
> > > > > >> libossupport
> > > > > >> is libavformat/os_support.* (and maybe some part of network.h?), right?
> > > > > > 
> > > > > > I think the question is: do we need/want libossupport?
> > > > > 
> > > > > I think yes, unless we want to cause big regressions for some OSs...
> > > > 
> > > > I don't think FFmpeg should enter into the operating system business.
> > > 
> > > if you want ffmpeg to be useable only on linux then i think you should
> > > remove yourself from the list of people who have write access to ffmpeg
> > > svn
> > > its definitly not my intent to make ffmpeg run only on 1-3 Platforms
> > > for no reason beyond that we can
> > > also i dont think our users or the other developers want that ...
> > > 
> > > if support requires changes which would lead to less readable or harder
> > > to maintain code (VC++ for example) droping that is fine
> > > 
> > > but arguing that the code doesnt belong into lavf and then arguing that
> > > we should not create a proper place for such code is very unprofessional
> > > and egoistic
> > 
> > I never said anything remotely similar to what you imply.
> 
> well you definitly did remove various OS related hacks from lavf, and it
> didnt seem like you were in favor of moving them somewhere else, if that isnt
> so then iam sorry for the missunderstanding

FFmpeg currently does not build on Cygwin.  I am the only dev who really
cared about this and inquired whether Cygwin is going to implement llrint
and/or where would be the place to implement llrint for Cygwin.  The
next gcc upgrade is going to pull in llrint.  This may still be some
months away, but it's good enough for me, I don't care about Cygwin
enough to try hastening the proces.

Years ago I suggested to the Cygwin people that they should implement
inttypes.h, which was missing.  They did and we no longer carry an
inttypes.h around in FFmpeg and MPlayer.

In 2005 I got myself a PPC and the MPlayer/FFmpeg PPC support has
improved since.

I have cleaned up much of the build system and preprocessor directives
to be more, not less, portable.

Last not least I am the one reviewing and committing most build system
patches, many of which are related to platform support.

So all in all being suspected of not caring about portability is
patently absurd.  The contrary is the case.

That said, I don't think that the best strategy for portability is to
add missing pieces for certain systems to every program.  Instead those
missing pieces should be added to the system directly, even if this is a
little harder to achieve.  Short term pain, long term gain.

Diego