[FFmpeg-devel] [RFC] Split libavformat
Fri Dec 7 01:55:22 CET 2007
Diego Biurrun said:
> 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
>> > > >
>> > > > I don't think FFmpeg should enter into the operating system
>> > >
>> > > 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.
Probably you meant "doesn't build out of the box", as it does build:
> 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.
Actually, not gcc but the next major Cygwin release (maybe 1.7.0)
> 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.
More information about the ffmpeg-devel