[FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()

[Nicolas George]

Le quintidi 5 messidor, an CCXXIII, wm4 a écrit :
> I think you're alone with this.

I do not intend to push for it, it was just an extreme example. I do maths,
and there is one thing we learn: if you want to know how solid an argument
is, push it to the extreme. If you suspect f is monotonic and want to know
whether it is increasing or decreasing, look at its asymptotic behaviour. If
you want to know if libavremotefileoperations makes sense, wonder about
libspellcheck.

> libav* are for (de)muxing and decoding/encoding.

libav* are for what developers want to make them for.

> It wouldn't be much of a problem to add a separate git repo that
> contains libavspellchecker. This would be truly independent. But I know
> what would happen... you'd add subtitle support to libavfilter, and the
> spell checker would be implemented as a filter.

Yes, exactly. We want everything in FFmpeg because multimedia is an
entangled topic: if you want to do anything non-trivial, you need
everything.

> We could have libavremotefileoperations too, but no, it will just end
> up in libavformat.

Please give us ONE GOOD REASON to split the libraries. I myself advocate for
one single libffmpeg.so, because the only practical consequences I see to
the split is the hassle of intra-project ABI stability, with all the
avpriv_frobnicate() stuff. Even libavformat and libavcodec belong together:
demuxers require parsers, and parsers share code with decoders. The rest is
peanuts.

By having all together, we can have a common testing framework.

Look at what happens in the Linux kernel: even for modules that could be
shipped separately, the policy is to have it all in one huge repository. The
FFmpeg code base is not nearly as big as the Linux code base.

> is different and usually terrible.

For your information, I consider the paragraphs that contain that kind of
gratuitous abuse non-existent.

> I'm also not sure why you think maintaining essentially dead code is
> hard.

That is exactly the opposite, I think it is easy: just run the bulldozer on
the oldest parts of the graveyard once in a while.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150623/50a47765/attachment.asc>