[FFmpeg-devel] [PATCH] libmpcodecs support

[Luca Barbato]

On 1/16/11 4:21 AM, Stefano Sabatini wrote:
> On date Sunday 2011-01-16 02:11:04 +0100, Luca Barbato encoded:
>> On 1/16/11 1:45 AM, Michael Niedermayer wrote:
>>> Diego, ping! you are in CC
>>> i suggest we leave it at the tab removial and continue as soon as luca and
>>> ronald agree.
>>> comments?
>>> a lack of a comment within 48h i will interpret as approval though would
>>> prefer an explicit ok from you.
>>
>> I still think the best for this is having a topic branch made public.
>
> I tend to be against having multiple branches, as this get things very
> complicated for users, and partly for developers. And, if the features
> are not implemented in the main repo, users will simply don't use it,
> at least most of them (indeed most users apparently still miss the
> existence of the gsoc libavfilter repo, although it is advertised on
> the libavfilter.html page).

we are talking about git branches

git branch -R
[list of branches]

git checkout branchiminterestedin

./configure && make && stuff

there we are.

It's way easier than svn since you get better tools.

> Also, do you honestly think that having delayed the libswscale
> integration into FFmpeg would have helped either FFmpeg or libswscale?

Yes.

> libswscale was a bloody mess, and still it is, but it would have been
> even worse if it was not integrated into the main FFmpeg, and what's
> even worse we and our users wouldn't have had all the features that
> libswscale allows.

Instead of spending the time I'm spending now (or even less) to get into 
shape before unleashing it? The whole experience with swscale had been a 
quite though lesson for me, that's why I'm wary of going through the 
same path again.

> And note that the libmpcodecs wrapper case is a little different, as
> it is not integrated into the ff* tools neither in the libraries, but
> it's just a libavfilter module, and is not going to touch the FFmpeg
> core, so I don't think it is "dangerous" to include it.

libmpcodecs wrapper has the same rationale and pros-cons mixture of the 
dllloader or gst-bridge with the added value of being just that bit of 
code instead of some more code somebody will see in the tree with 
errors/bad style open to be copied within the rest of ffmpeg (happens 
every damn time, to me and to others as well).

> But I'm mildly in favor of keeping the imported libmpcodecs code
> experimental, that is to disable its compilation by default, so that
> users get aware that they can't rely on its stability.

That concerned also Aurel.

> Avoiding tabs should be done, as we shouldn't disallow SVN rules just
> for this commit, but it should be done with the less possible burden
> on who is doing the work, at this point I consider libmpcodecs dead
> code so I think that spending too much work on it is worthless so an
> automatic tab-removal script is perfectly enough.

If the code is dead you can put it in a separate branch or even tree and 
put it as external dependence. so you have

configure --with-libmpcodec-filters --with-libmpcodec-filters-dir=

We do not bundle libvpx or libx264 even it is something our users want 
and yet they manage to get the feature.

> And having it in the main repo means more users ->  more testers ->
> more contributions ->  more money&glory ->  world domination, which I
> remember is our final goal ;-).

So:

- add the wrapper code (and only it) to libavfilter: ok
- add all the libmpcodecs dir to libavfilter: no
- put the libmpcodecs-hacked dir in a tree so people can fetch it as 
submodule: ok

lu