[FFmpeg-devel] [RFC] Split libavformat

Víctor Paesa wzrlpy
Fri Dec 7 01:55:22 CET 2007


Hi,

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
>> 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.

Probably you meant "doesn't build out of the box", as it does build:
http://ffmpeg.mplayerhq.hu/general.html#SEC16

> 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)
http://cygwin.com/ml/cygwin-developers/2007-11/msg00021.html

> 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.

Regards,
V?ctor






More information about the ffmpeg-devel mailing list