[FFmpeg-devel] [PATCH] libmpcodecs support
Sun Jan 16 11:43:08 CET 2011
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.
>>> 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?
> 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 ;-).
- 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
More information about the ffmpeg-devel