Discussion:
[PATCH] libmpcodecs support
(too old to reply)
Michael Niedermayer
2011-01-14 04:37:45 UTC
Permalink
Hi

Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.

I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.

Please dont bikeshed this to death.

Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab & trailing whitespace checkin scripts.
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
Luca Barbato
2011-01-14 07:04:01 UTC
Permalink
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
In order to keep things sane, please DO NOT.
The swscale experience is fresh again for me and I'd rather not.
Post by Michael Niedermayer
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Mind keeping that in a branch so people interested may get it and people
scared can live w/out? I'm not sure if that code is less scary than
swscale BUT your following comment says much.
Post by Michael Niedermayer
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab& trailing whitespace checkin scripts.
Are you joking? If you are _really_ serious I'd suggest (or even I'd do
myself) to clean it up at least to be properly indented in mplayer.

So in short, to cut all the bikeshed and in the as calm as possible tone:

since directly importing code from mplayer collides with:
- coding style
- basic respect for structured code
- people that might be interested in contribute optimizations

I'd rather have it polished before, either in mplayer or here, if you
are itching to commit it, make a branch and advertise it so before it
hits the master those 3 points might be addressed already.

lu
Stefano Sabatini
2011-01-14 11:32:01 UTC
Permalink
Post by Luca Barbato
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
In order to keep things sane, please DO NOT.
The swscale experience is fresh again for me and I'd rather not.
Post by Michael Niedermayer
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Mind keeping that in a branch so people interested may get it and
people scared can live w/out? I'm not sure if that code is less
scary than swscale BUT your following comment says much.
Post by Michael Niedermayer
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab& trailing whitespace checkin scripts.
Are you joking? If you are _really_ serious I'd suggest (or even I'd
do myself) to clean it up at least to be properly indented in
mplayer.
- coding style
- basic respect for structured code
- people that might be interested in contribute optimizations
I'd rather have it polished before, either in mplayer or here, if
you are itching to commit it, make a branch and advertise it so
before it hits the master those 3 points might be addressed already.
Before to pronounce I would like to know which is the long term plan.
Do we want to keep an unsynched branch of MPlayer in FFmpeg?, will
MPlayer get rid of libmpcodecs filters and use libavfilter instead?,
or we'll have to keep this code and burden duplication forever?

I suppose the plan of the MPlayer crew was to start to support
libavfilter through libmpcodecs, and eventually switch completely to
libavfilter.

Some considerations:

* pros: having libmpcodecs in libavfilter through a wrapper will
greatly help to test and port them as "native" filters

* pros: having libmpcodecs in libavfilter *right now* would be a big
enhancement, and may help the adoption of FFmpeg+libavfilter.

* cons: the burden of code duplication, code will have to be
maintained both in MPlayer and in ffmpeg/libavfilter/libmpcodecs.

* cons: libmpcodecs code is generally unformatted, neither
particularly readable and maintainable nor well documented, having
that into FFmpeg is a little scary for me.

* cons: people will consider to use (and eventually fix) the
libmpcodecs filters rather than port them into libavfilter (which
usually results in much cleaner and readable and maintainable code),
thus hindering the long term plan. This consideration is just
hypotetical, as the external contributions to libavfilter (apart
GSOC and GCI) have been practically neglectable.

As I already said, I'm not motivated to maintain libmpcodecs code and
I *won't*, and I'm rather for a clean altough possibly slow port. If
the long term plan is to get rid of the libmpcodecs filters (both from
MPlayer and libavfilter) in favor of libavfilter, then I'm not against
this patchset.
--
FFmpeg = Fierce and Fiendish Miracolous Pitiless Ecstatic Gem
Michael Niedermayer
2011-01-14 12:58:15 UTC
Permalink
Post by Stefano Sabatini
Post by Luca Barbato
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
In order to keep things sane, please DO NOT.
The swscale experience is fresh again for me and I'd rather not.
Post by Michael Niedermayer
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Mind keeping that in a branch so people interested may get it and
people scared can live w/out? I'm not sure if that code is less
scary than swscale BUT your following comment says much.
Post by Michael Niedermayer
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab& trailing whitespace checkin scripts.
Are you joking? If you are _really_ serious I'd suggest (or even I'd
do myself) to clean it up at least to be properly indented in
mplayer.
- coding style
- basic respect for structured code
- people that might be interested in contribute optimizations
I'd rather have it polished before, either in mplayer or here, if
you are itching to commit it, make a branch and advertise it so
before it hits the master those 3 points might be addressed already.
Before to pronounce I would like to know which is the long term plan.
Do we want to keep an unsynched branch of MPlayer in FFmpeg?, will
MPlayer get rid of libmpcodecs filters and use libavfilter instead?,
or we'll have to keep this code and burden duplication forever?
We will try to keep the libmpcodecs code as similar to mplayers as possible
and update our copy whenever there are significant changes in mplayers
libmpcodecs. This makes cleanup inside our libmpcodecs impossible, it would
conflict with future merges.

If you, luca or someone else want to do cleanup in libmpcodecs thats possible
inside MPlayers libmpcodecs and discussion about that should go to mplayer-dev


The long term plan is definitly to have all libmpcodecs filters changed to
native libavfilter filters but that depends alot on volunteers, and i dont
consider it high priority for myself to do such work

Either way, every filter that becomes fully portet can be droped from our
libmpcodecs copy.
Post by Stefano Sabatini
I suppose the plan of the MPlayer crew was to start to support
libavfilter through libmpcodecs, and eventually switch completely to
libavfilter.
* pros: having libmpcodecs in libavfilter through a wrapper will
greatly help to test and port them as "native" filters
* pros: having libmpcodecs in libavfilter *right now* would be a big
enhancement, and may help the adoption of FFmpeg+libavfilter.
* cons: the burden of code duplication, code will have to be
maintained both in MPlayer and in ffmpeg/libavfilter/libmpcodecs.
Ill do that maintaince
Post by Stefano Sabatini
* cons: libmpcodecs code is generally unformatted, neither
particularly readable and maintainable nor well documented, having
that into FFmpeg is a little scary for me.
its unfortunatly unavoidable unless libmpcodecs becomes compileable into a
lib from mplayers svn and headers needed to interface become installed similarly
Post by Stefano Sabatini
* cons: people will consider to use (and eventually fix) the
libmpcodecs filters rather than port them into libavfilter (which
I wont accept any changes in our libmpcodecs copy relative to mplayers original
unless they are needed for our wraper to work. Such changes belong in mplayer
svn
Post by Stefano Sabatini
usually results in much cleaner and readable and maintainable code),
thus hindering the long term plan. This consideration is just
hypotetical, as the external contributions to libavfilter (apart
GSOC and GCI) have been practically neglectable.
As I already said, I'm not motivated to maintain libmpcodecs code and
I *won't*, and I'm rather for a clean altough possibly slow port. If
the long term plan is to get rid of the libmpcodecs filters (both from
MPlayer and libavfilter) in favor of libavfilter, then I'm not against
this patchset.
Its of course the long term plan to get rid of it

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please
Janne Grunau
2011-01-14 14:55:31 UTC
Permalink
Post by Michael Niedermayer
Post by Stefano Sabatini
Post by Luca Barbato
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
In order to keep things sane, please DO NOT.
The swscale experience is fresh again for me and I'd rather not.
Post by Michael Niedermayer
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Mind keeping that in a branch so people interested may get it and
people scared can live w/out? I'm not sure if that code is less
scary than swscale BUT your following comment says much.
Post by Michael Niedermayer
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab& trailing whitespace checkin scripts.
Are you joking? If you are _really_ serious I'd suggest (or even I'd
do myself) to clean it up at least to be properly indented in
mplayer.
- coding style
- basic respect for structured code
- people that might be interested in contribute optimizations
I'd rather have it polished before, either in mplayer or here, if
you are itching to commit it, make a branch and advertise it so
before it hits the master those 3 points might be addressed already.
Before to pronounce I would like to know which is the long term plan.
Do we want to keep an unsynched branch of MPlayer in FFmpeg?, will
MPlayer get rid of libmpcodecs filters and use libavfilter instead?,
or we'll have to keep this code and burden duplication forever?
We will try to keep the libmpcodecs code as similar to mplayers as possible
and update our copy whenever there are significant changes in mplayers
libmpcodecs. This makes cleanup inside our libmpcodecs impossible, it would
conflict with future merges.
I'm very much convinced that copying source files and maintaining them in
more than one place is a sure path to insanity. And I'm coming from a project
which makes unfortunately heavy use of that technique. It's just not going to
work, is much more effort than expected and I would expect that the copy will
stay there for ever.

Janne
Michael Niedermayer
2011-01-14 16:20:23 UTC
Permalink
Post by Janne Grunau
Post by Michael Niedermayer
Post by Stefano Sabatini
Post by Luca Barbato
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
In order to keep things sane, please DO NOT.
The swscale experience is fresh again for me and I'd rather not.
Post by Michael Niedermayer
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Mind keeping that in a branch so people interested may get it and
people scared can live w/out? I'm not sure if that code is less
scary than swscale BUT your following comment says much.
Post by Michael Niedermayer
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab& trailing whitespace checkin scripts.
Are you joking? If you are _really_ serious I'd suggest (or even I'd
do myself) to clean it up at least to be properly indented in
mplayer.
- coding style
- basic respect for structured code
- people that might be interested in contribute optimizations
I'd rather have it polished before, either in mplayer or here, if
you are itching to commit it, make a branch and advertise it so
before it hits the master those 3 points might be addressed already.
Before to pronounce I would like to know which is the long term plan.
Do we want to keep an unsynched branch of MPlayer in FFmpeg?, will
MPlayer get rid of libmpcodecs filters and use libavfilter instead?,
or we'll have to keep this code and burden duplication forever?
We will try to keep the libmpcodecs code as similar to mplayers as possible
and update our copy whenever there are significant changes in mplayers
libmpcodecs. This makes cleanup inside our libmpcodecs impossible, it would
conflict with future merges.
I'm very much convinced that copying source files and maintaining them in
more than one place is a sure path to insanity. And I'm coming from a project
which makes unfortunately heavy use of that technique. It's just not going to
work, is much more effort than expected and I would expect that the copy will
stay there for ever.
So in the very worst case predictions its still the best we can do to move
forward.
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
compn
2011-01-14 18:11:10 UTC
Permalink
Post by Michael Niedermayer
Post by Janne Grunau
Post by Michael Niedermayer
Post by Stefano Sabatini
Before to pronounce I would like to know which is the long term plan.
Do we want to keep an unsynched branch of MPlayer in FFmpeg?, will
MPlayer get rid of libmpcodecs filters and use libavfilter instead?,
or we'll have to keep this code and burden duplication forever?
We will try to keep the libmpcodecs code as similar to mplayers as possible
and update our copy whenever there are significant changes in mplayers
libmpcodecs. This makes cleanup inside our libmpcodecs impossible, it would
conflict with future merges.
I'm very much convinced that copying source files and maintaining them in
more than one place is a sure path to insanity. And I'm coming from a project
which makes unfortunately heavy use of that technique. It's just not going to
work, is much more effort than expected and I would expect that the copy will
stay there for ever.
So in the very worst case predictions its still the best we can do to move
forward.
we could always move libmpcodecs into a seperate repo like swscale.

-compn
Michael Niedermayer
2011-01-14 18:49:56 UTC
Permalink
Post by compn
Post by Michael Niedermayer
Post by Janne Grunau
Post by Michael Niedermayer
Post by Stefano Sabatini
Before to pronounce I would like to know which is the long term plan.
Do we want to keep an unsynched branch of MPlayer in FFmpeg?, will
MPlayer get rid of libmpcodecs filters and use libavfilter instead?,
or we'll have to keep this code and burden duplication forever?
We will try to keep the libmpcodecs code as similar to mplayers as possible
and update our copy whenever there are significant changes in mplayers
libmpcodecs. This makes cleanup inside our libmpcodecs impossible, it would
conflict with future merges.
I'm very much convinced that copying source files and maintaining them in
more than one place is a sure path to insanity. And I'm coming from a project
which makes unfortunately heavy use of that technique. It's just not going to
work, is much more effort than expected and I would expect that the copy will
stay there for ever.
So in the very worst case predictions its still the best we can do to move
forward.
we could always move libmpcodecs into a seperate repo like swscale.
There are differences between mplayers libmpcodecs and libavfilters libmpcodecs
libswscale was a seperate and selfcontained lib, libmpcodecs as used by mplayer
has far reaching dependancies into half of all of mplayer. The code does NOT
compile without changes outside mplayer.

I have no interrest at all in spending weeks working on turning libmpcodecs
into a seperate lib. And then redoing the whole integration
libmpcodecs is outdated technology Its insane to waste time on improving it
And id like to ask others to also spend their time on usefull things, port
filters to become native libavfilter filters, there are performance advantages
under some circumstances to the closer integration. And replacing mplayers
libmpcodecs with a libavfilter that has all the libmpcodecs filters natively
would also be a huge step forward for mplayer, the arbitrary filter graphs
are just one nice feature ...

If people have so much energy as to make libmpcodecs become an independant lib
its much better spend porting a dozen filters from libmpcodecs to libavfilter.

OTOH if you suggest to just drop the libavfilter/libmpcodecs as is in a
seperate repo then i dont see the point, it just makes things harder to work
with while the code could not be used by anything but libavfilter

anyway if there are constructive suggestions left i very much would like to
hear them if not id like to apply this, and if people want with tabs removed
and reindented but later requires this to be approved by reimar and also
reindented in mplayer svn

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
Ronald S. Bultje
2011-01-14 18:53:59 UTC
Permalink
Hi,
Post by Michael Niedermayer
OTOH if you suggest to just drop the libavfilter/libmpcodecs as is in a
seperate repo then i dont see the point, it just makes things harder to work
with while the code could not be used by anything but libavfilter
So basically what you're saying is that we cannot possibly disagree with this?

I think this is similarly stupid as adding a DLL loader to lavcodec
because that gives us access to codecs that will take years to RE, but
have working DLLs using mplayer's DLL loader. How is that different?
This is great as a debug tool but should not be applied to main git
(oh: let's please switch today; thanks!).

Ronald
Michael Niedermayer
2011-01-14 19:49:31 UTC
Permalink
Post by Ronald S. Bultje
Hi,
Post by Michael Niedermayer
OTOH if you suggest to just drop the libavfilter/libmpcodecs as is in a
seperate repo then i dont see the point, it just makes things harder to work
with while the code could not be used by anything but libavfilter
So basically what you're saying is that we cannot possibly disagree with this?
You can disagree!
What is it that you disagre with?
Do you want libavfilter to not move forward, get 3 times as many filters?
Do you want libmpcodecs to be reindented?
Do you want libmpcodecs in an external repository?
Do you think a libavfilter without libmpcodecs support would be more successfull
used by more users, would cause more developers to join the effort?
Do you think a project that doesnt care what its users want should be forked?
Do you think we should care about what our users want?
Do you think our users would prefer to have all the libmpcodecs filters
available?
Something else?

Personally as maintainer of libavfilter, i want it to move forward, the FF in
ffmpeg also stands for "fast forward" not for filosophical bikeshed
filibustering.

If people dont clearly say what they want, its difficult for me to act in line
of what the people want.
I see several vocal people who express their dislike of this patchset but i
dont really see what they do want. The comments are negative "do not do" not
"please do instead because"

and a seperate branch, i dont mind a "full_featured" branch with libmpcodecs
ffmpeg-mt and dll loader. and leave trunk without these features.
But please when you calmly thought about it explain me what we would gain?
users want features they will, if they know about it use the most feature packed
branch. And this is the branch most developers will likely work on as well i
suspect but i might be wrong.
And we have no right to hide from our users which is the most feature packed
branch IMO
Post by Ronald S. Bultje
I think this is similarly stupid as adding a DLL loader to lavcodec
because that gives us access to codecs that will take years to RE, but
have working DLLs using mplayer's DLL loader. How is that different?
I always wanted a DLL loader, its mere historic that we didnt get one many years
ago. (years ago noone would have objected i suspect)

now lets please try to work toward a solution.

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
Stefano Sabatini
2011-01-14 20:47:37 UTC
Permalink
Post by Ronald S. Bultje
Hi,
Post by Michael Niedermayer
OTOH if you suggest to just drop the libavfilter/libmpcodecs as is in a
seperate repo then i dont see the point, it just makes things harder to work
with while the code could not be used by anything but libavfilter
So basically what you're saying is that we cannot possibly disagree with this?
I think this is similarly stupid as adding a DLL loader to lavcodec
because that gives us access to codecs that will take years to RE, but
have working DLLs using mplayer's DLL loader. How is that different?
This is great as a debug tool but should not be applied to main git
I'm against having many repositories for no strong reasons, that's
just complicating the maintainance and the burden on users which want
a specific feature, it makes sense where there are regressions or for
experimental code which may have bad interactions with the rest of the
codebase. I don't think these conditions apply for the present case.
Post by Ronald S. Bultje
(oh: let's please switch today; thanks!).
+1, and please give clear indications about which operations need to
be done by developers for migrating to the new repo.
--
FFmpeg = Freak and Foolish Mysterious Perennial Evil Gorilla
Michael Niedermayer
2011-01-15 11:26:58 UTC
Permalink
On Fri, Jan 14, 2011 at 01:53:59PM -0500, Ronald S. Bultje wrote:
[...]
Post by Ronald S. Bultje
This is great as a debug tool but should not be applied to main git
Same for your rt*p work, i request you move it all out of trunk and into
another branch

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
Luca Barbato
2011-01-15 20:16:13 UTC
Permalink
Post by Michael Niedermayer
[...]
Post by Ronald S. Bultje
This is great as a debug tool but should not be applied to main git
Same for your rt*p work, i request you move it all out of trunk and into
another branch
Because the rt*p:

- breaks coding style
- is known to cause insanity by staring it long enough
- is scheduled to be removed within a short time
- has really few users
- the original authors are lost in time and space

lu - getting pissed off a little.
compn
2011-01-15 22:33:24 UTC
Permalink
Post by Luca Barbato
Post by Michael Niedermayer
[...]
Post by Ronald S. Bultje
This is great as a debug tool but should not be applied to main git
Same for your rt*p work, i request you move it all out of trunk and into
another branch
- breaks coding style
- is known to cause insanity by staring it long enough
- is scheduled to be removed within a short time
- has really few users
- the original authors are lost in time and space
i'm confused, if no one but michael is even going to work on the
libmpcodecs filters, why does it matter if the code is not up to style?
or insane? or if it has few users?

those video game formats have very few users, and yet we have a ton of
support for them.

those reasons arent very good for objecting to this. i'm not trying to
fight or troll here. just that if you have actual good reasons to
object please speak them.

original author? have you talked to fabrice recently? eheh

-compn
Michael Niedermayer
2011-01-15 22:59:10 UTC
Permalink
Post by compn
Post by Luca Barbato
Post by Michael Niedermayer
[...]
Post by Ronald S. Bultje
This is great as a debug tool but should not be applied to main git
Same for your rt*p work, i request you move it all out of trunk and into
another branch
- breaks coding style
Yes it breaks every style except the one it uses
Post by compn
Post by Luca Barbato
- is known to cause insanity by staring it long enough
google rtsp insanity
67,400 hits
google libmpcodecs insanity
9 hits

probably this is even representative of the truth
Post by compn
Post by Luca Barbato
- is scheduled to be removed within a short time
/me considers to write a mail to the RFC authors but then decides against
Post by compn
Post by Luca Barbato
- has really few users
libmpcodecs doesnt have few users, nor has RTSP
Post by compn
Post by Luca Barbato
- the original authors are lost in time and space
ill wager a bet that arpi reads this list more frequently than fabrice
not that it would make a difference
Post by compn
i'm confused, if no one but michael is even going to work on the
libmpcodecs filters, why does it matter if the code is not up to style?
or insane? or if it has few users?
those video game formats have very few users, and yet we have a ton of
support for them.
good that you mention this, some of them also have bad style.

pitty irclogs are dead
but i can invent some:

user: i started ffmpeg and it said it cant find the decoder???
dev: You need to compile ffmpeg from the old_messy_game_formats branch
user: ok did that now it complains that it cant find the encoder???
dev: You need to compile ffmpeg from the external_h264_encoder branch
user: yeah but i want to transcode from that game format
dev: idiot, compile both use a pipe
user: i get AV desync now
dev: well known issue, patch welcome
user: i can send a patch to merge the branches
dev: ban user
Post by compn
those reasons arent very good for objecting to this. i'm not trying to
fight or troll here. just that if you have actual good reasons to
object please speak them.
original author? have you talked to fabrice recently? eheh
let me think .... how many years do count as recently?

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle
Ronald S. Bultje
2011-01-15 23:49:00 UTC
Permalink
Hi,
Post by Michael Niedermayer
google rtsp insanity
   67,400 hits
google libmpcodecs insanity
   9 hits
google rtsp
3,2M hits
google libmpcodecs
3,8k hits

rtsp bug
146k
libmpcodecs bug
9,9k

Then again, rtsp is a protocol, libmpcodecs is a lib, but ohwell...
Let's see who can think of the best google fight query.

Ronald
Michael Niedermayer
2011-01-16 00:25:15 UTC
Permalink
Post by Michael Niedermayer
Hi,
Post by Michael Niedermayer
google rtsp insanity
   67,400 hits
google libmpcodecs insanity
   9 hits
google rtsp
3,2M hits
google libmpcodecs
3,8k hits
so 2.1% of the pages that mention RTSP also mention insanity
and 0.2% of the pages that mention libmpcodecs also mention insanity



[...]
Post by Michael Niedermayer
Let's see who can think of the best google fight query.
yes


[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
Ronald S. Bultje
2011-01-16 00:35:52 UTC
Permalink
Hi,
Post by Michael Niedermayer
Hi,
Post by Michael Niedermayer
google rtsp insanity
   67,400 hits
google libmpcodecs insanity
   9 hits
google rtsp
3,2M hits
google libmpcodecs
3,8k hits
so  2.1% of the pages that mention RTSP also mention insanity
and 0.2% of the pages that mention libmpcodecs also mention insanity
The top hit for each is this thread. Browse a couple and you'll see
the rtsp/libmpcodecs have nothing to do with insanity in the majority
of pages.

Unfortunately Google doesn't select for "intention of page" relevance yet.

Ronald
Michael Niedermayer
2011-01-16 01:00:12 UTC
Permalink
Post by Ronald S. Bultje
Hi,
Post by Michael Niedermayer
Hi,
Post by Michael Niedermayer
google rtsp insanity
   67,400 hits
google libmpcodecs insanity
   9 hits
google rtsp
3,2M hits
google libmpcodecs
3,8k hits
so  2.1% of the pages that mention RTSP also mention insanity
and 0.2% of the pages that mention libmpcodecs also mention insanity
The top hit for each is this thread.
RTP/RTSP is insane because it uses a different encapsulation for every codec.
There is technically no sense at all for that. its just slices and frames with
timestamps no matter if a 20 year old codec or the latest and greatest.

Then prebuffering doesnt work, if i belive the recent discussions ...
And more generally it lacks a buffering model that would alow variable
bitrate to work halfway reasonable. other standards have that since MPEG-1
times
Also the RFCs are absolutely huge for the little bit of clear and unambigous
information in them.
Post by Ronald S. Bultje
Browse a couple and you'll see
the rtsp/libmpcodecs have nothing to do with insanity in the majority
of pages.
iam changing this with this mail i hope ;)

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
Luca Barbato
2011-01-16 00:02:54 UTC
Permalink
Post by Michael Niedermayer
user: i started ffmpeg and it said it cant find the decoder???
dev: You need to compile ffmpeg from the old_messy_game_formats branch
user: ok did that now it complains that it cant find the encoder???
dev: You need to compile ffmpeg from the external_h264_encoder branch
user: yeah but i want to transcode from that game format
dev: idiot, compile both use a pipe
user: i get AV desync now
dev: well known issue, patch welcome
user: i can send a patch to merge the branches
dev: ban user
You clearly miss how git works...
Post by Michael Niedermayer
Post by compn
original author? have you talked to fabrice recently? eheh
let me think .... how many years do count as recently?
I'm not sure there is still that much of fabrice code in rt*p*.c ...

lu
Michael Niedermayer
2011-01-16 00:16:28 UTC
Permalink
Post by Luca Barbato
Post by Michael Niedermayer
user: i started ffmpeg and it said it cant find the decoder???
dev: You need to compile ffmpeg from the old_messy_game_formats branch
user: ok did that now it complains that it cant find the encoder???
dev: You need to compile ffmpeg from the external_h264_encoder branch
user: yeah but i want to transcode from that game format
dev: idiot, compile both use a pipe
user: i get AV desync now
dev: well known issue, patch welcome
user: i can send a patch to merge the branches
dev: ban user
You clearly miss how git works...
no doubt i do, ive used git-svn but thats not really excercising all features
if you could elaborate on what you mean?
Post by Luca Barbato
Post by Michael Niedermayer
Post by compn
original author? have you talked to fabrice recently? eheh
let me think .... how many years do count as recently?
I'm not sure there is still that much of fabrice code in rt*p*.c ...
/me imagins a few lines of fraktal compressed self expanding code of an ancient
civilization that was wiped out by robots only waiting to be triggered by
mistake

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
Luca Barbato
2011-01-16 01:05:43 UTC
Permalink
Post by Michael Niedermayer
Post by Luca Barbato
Post by Michael Niedermayer
user: i started ffmpeg and it said it cant find the decoder???
dev: You need to compile ffmpeg from the old_messy_game_formats branch
user: ok did that now it complains that it cant find the encoder???
dev: You need to compile ffmpeg from the external_h264_encoder branch
user: yeah but i want to transcode from that game format
dev: idiot, compile both use a pipe
user: i get AV desync now
dev: well known issue, patch welcome
user: i can send a patch to merge the branches
dev: ban user
You clearly miss how git works...
no doubt i do, ive used git-svn but thats not really excercising all features
if you could elaborate on what you mean?
That if you keep that code in a branch and the branch is public
interested users can just rebase it to master (since the changes in the
mpcodec branch would/should have nothing that couldn't be
fast-forward+the patches only present in that branch) so it should not
have much impact on the development while if the users are this
interested they could take it and use it easily.

Topic branches are spawn and once ready merge-squashed to master in many
projects.
Post by Michael Niedermayer
/me imagins a few lines of fraktal compressed self expanding code of an ancient
civilization that was wiped out by robots only waiting to be triggered by
mistake
that is next to the copy of tcc whitespace encoded within the original
ffmpeg sources probably. =)

lu
Michael Niedermayer
2011-01-16 01:17:37 UTC
Permalink
Post by Luca Barbato
Post by Michael Niedermayer
Post by Luca Barbato
Post by Michael Niedermayer
user: i started ffmpeg and it said it cant find the decoder???
dev: You need to compile ffmpeg from the old_messy_game_formats branch
user: ok did that now it complains that it cant find the encoder???
dev: You need to compile ffmpeg from the external_h264_encoder branch
user: yeah but i want to transcode from that game format
dev: idiot, compile both use a pipe
user: i get AV desync now
dev: well known issue, patch welcome
user: i can send a patch to merge the branches
dev: ban user
You clearly miss how git works...
no doubt i do, ive used git-svn but thats not really excercising all features
if you could elaborate on what you mean?
That if you keep that code in a branch and the branch is public
interested users can just rebase it to master (since the changes in the
mpcodec branch would/should have nothing that couldn't be
fast-forward+the patches only present in that branch) so it should not
have much impact on the development while if the users are this
interested they could take it and use it easily.
Topic branches are spawn and once ready merge-squashed to master in many
projects.
if it works in practice i wouldnt mind a branch but do the following work?
have main + a few branches checked out in a single compileable tree
do development
run fate
pull in new changes
push own commits

all without extra work relative to having all in main ?
Post by Luca Barbato
Post by Michael Niedermayer
/me imagins a few lines of fraktal compressed self expanding code of an ancient
civilization that was wiped out by robots only waiting to be triggered by
mistake
that is next to the copy of tcc whitespace encoded within the original
ffmpeg sources probably. =)
OMG, i just realize it, mplayers whitespace formating encodes something its
not random, you can clearly see this from the entropy distribution. All along
thouse years the whitespace just tried to say one thing, "i am alive, please
dont kill me"


[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
Reimar Döffinger
2011-01-15 12:01:23 UTC
Permalink
Post by Michael Niedermayer
anyway if there are constructive suggestions left i very much would like to
hear them if not id like to apply this, and if people want with tabs removed
and reindented but later requires this to be approved by reimar and also
reindented in mplayer svn
Anyone may feel free to do reindentation on libmpcodecs.
Though it might be good to talk to Diego, he had reindentation plans for
MPlayer for a long time and maybe he can just do what he had planned.
Would also make libmpcodecs serve as a test case for this.
Michael Niedermayer
2011-01-15 13:04:37 UTC
Permalink
Post by Reimar Döffinger
Post by Michael Niedermayer
anyway if there are constructive suggestions left i very much would like to
hear them if not id like to apply this, and if people want with tabs removed
and reindented but later requires this to be approved by reimar and also
reindented in mplayer svn
Anyone may feel free to do reindentation on libmpcodecs.
Though it might be good to talk to Diego, he had reindentation plans for
MPlayer for a long time and maybe he can just do what he had planned.
Would also make libmpcodecs serve as a test case for this.
What i need to know is when people are done and there _certainly_ will be no
further cosmetic changes to libmpcodecs.
At this point then i can update this patchset and commit.

Also we can either commit now and update once the cosmetics are done in mplayer
or wait until they are done before commiting anything.
The choice depends on how long this unneeded cosmetic cleanup will take
I prefer to commit now and update things once the cosmetics are done

Also id like to point out that all this is causing me alot of extra work and
thats not fixng bugs and not adding features but useless bikeshed.

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is not what we do, but why we do it that matters.
Reimar Döffinger
2011-01-15 19:56:47 UTC
Permalink
Post by Michael Niedermayer
Post by Reimar Döffinger
Post by Michael Niedermayer
anyway if there are constructive suggestions left i very much would like to
hear them if not id like to apply this, and if people want with tabs removed
and reindented but later requires this to be approved by reimar and also
reindented in mplayer svn
Anyone may feel free to do reindentation on libmpcodecs.
Though it might be good to talk to Diego, he had reindentation plans for
MPlayer for a long time and maybe he can just do what he had planned.
Would also make libmpcodecs serve as a test case for this.
What i need to know is when people are done and there _certainly_ will be no
further cosmetic changes to libmpcodecs.
At this point then i can update this patchset and commit.
Also we can either commit now and update once the cosmetics are done in mplayer
or wait until they are done before commiting anything.
The choice depends on how long this unneeded cosmetic cleanup will take
I prefer to commit now and update things once the cosmetics are done
Also id like to point out that all this is causing me alot of extra work and
thats not fixng bugs and not adding features but useless bikeshed.
Please do not complain to me, I just wanted to help resolving the objections.
My idea in principle was that Diego has a fairly nice config for some indent-like
(but hopefully less buggy) tool, and if you ran it over MPlayer's libmpcodecs
and your modifications hopefully you'd have almost no extra work, code that
others don't complain that much anymore (and got rid of tabs in the process) and
libmpcodecs and the FFmpeg copy being in sync.
I'm also fine if you (or someone else) would just like to remove the tabs.
We can also avoid cosmetic changes to libmpcodecs and/or discuss them with you
first, if that is what you want.
Michael Niedermayer
2011-01-15 22:37:25 UTC
Permalink
Post by Reimar Döffinger
Post by Michael Niedermayer
Post by Reimar Döffinger
Post by Michael Niedermayer
anyway if there are constructive suggestions left i very much would like to
hear them if not id like to apply this, and if people want with tabs removed
and reindented but later requires this to be approved by reimar and also
reindented in mplayer svn
Anyone may feel free to do reindentation on libmpcodecs.
Though it might be good to talk to Diego, he had reindentation plans for
MPlayer for a long time and maybe he can just do what he had planned.
Would also make libmpcodecs serve as a test case for this.
What i need to know is when people are done and there _certainly_ will be no
further cosmetic changes to libmpcodecs.
At this point then i can update this patchset and commit.
Also we can either commit now and update once the cosmetics are done in mplayer
or wait until they are done before commiting anything.
The choice depends on how long this unneeded cosmetic cleanup will take
I prefer to commit now and update things once the cosmetics are done
Also id like to point out that all this is causing me alot of extra work and
thats not fixng bugs and not adding features but useless bikeshed.
Please do not complain to me, I just wanted to help resolving the objections.
My idea in principle was that Diego has a fairly nice config for some indent-like
(but hopefully less buggy) tool, and if you ran it over MPlayer's libmpcodecs
and your modifications hopefully you'd have almost no extra work, code that
others don't complain that much anymore (and got rid of tabs in the process) and
libmpcodecs and the FFmpeg copy being in sync.
I'm also fine if you (or someone else) would just like to remove the tabs.
We can also avoid cosmetic changes to libmpcodecs and/or discuss them with you
first, if that is what you want.
I prefer if its only de-tab but its not a major thing
What is really important to me is that theres a point after which you wont
accept further cosmetics from diego in libmpcodecs. I know diego will always
find more that needs cleanup once he starts looking. And its not fun if 50% of
commits are useless cosmetics and one has to merge that by hand.

Also even more important is that luca and ronald agree, otherwise i would have
to either commit against the wishes of 2 ffmpeg developers or drop the patch.
I like neither.
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
Reimar Döffinger
2011-01-15 22:52:59 UTC
Permalink
Post by Michael Niedermayer
What is really important to me is that theres a point after which you wont
accept further cosmetics from diego in libmpcodecs. I know diego will always
find more that needs cleanup once he starts looking. And its not fun if 50% of
commits are useless cosmetics and one has to merge that by hand.
That is fine by me, but Diego needs to get a say in that.
Actually I'd prefer if you two could discuss this directly, since I
don't really intend to object to anything you can agree on I'd consider
it only overhead for me to be involved (but I can do it if desired).
Michael Niedermayer
2011-01-16 00:45:06 UTC
Permalink
Post by Reimar Döffinger
Post by Michael Niedermayer
What is really important to me is that theres a point after which you wont
accept further cosmetics from diego in libmpcodecs. I know diego will always
find more that needs cleanup once he starts looking. And its not fun if 50% of
commits are useless cosmetics and one has to merge that by hand.
That is fine by me, but Diego needs to get a say in that.
Actually I'd prefer if you two could discuss this directly, since I
Ok, lets try.

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.

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.
Luca Barbato
2011-01-16 01:11:04 UTC
Permalink
Post by Michael Niedermayer
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.

lu
Stefano Sabatini
2011-01-16 03:21:32 UTC
Permalink
Post by Luca Barbato
Post by Michael Niedermayer
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).

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.

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.

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.

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.

Final note, I have already something like 40 branches in my local
repo, so I don't like the idea to work on more external repos and
synch and merge back and forward, having all the goods in the main
repo is an incentive for me to work on them, or I'll just don't care.

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 ;-).
--
FFmpeg = Fast & Freak Mythic Peaceful Evanescent Genius
Carl Eugen Hoyos
2011-01-16 08:39:26 UTC
Permalink
Post by Stefano Sabatini
I tend to be against having multiple branches
+1

Carl Eugen
Luca Barbato
2011-01-16 10:43:08 UTC
Permalink
Post by Stefano Sabatini
Post by Luca Barbato
Post by Michael Niedermayer
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.
Post by Stefano Sabatini
Also, do you honestly think that having delayed the libswscale
integration into FFmpeg would have helped either FFmpeg or libswscale?
Yes.
Post by Stefano Sabatini
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.
Post by Stefano Sabatini
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).
Post by Stefano Sabatini
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.
Post by Stefano Sabatini
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.
Post by Stefano Sabatini
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
Janne Grunau
2011-01-16 15:51:14 UTC
Permalink
Post by Luca Barbato
Post by Michael Niedermayer
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.
see libmpcodecs_wrapper in http://git.jannau.net/git/ffmpeg/

it uses a git submodule for libavfilter/libmpcodecs which I have
published at http://git.jannau.net/git/libmpcodecs-ffmpeg/

That repo contains Michael's patches on top of mplayer/libmpcodecs
filtered history. This will make syncing changes from mplayer much
easier. I've already rebased the patches on top of the tab cleanup.

Janne
Michael Niedermayer
2011-01-17 00:55:20 UTC
Permalink
Post by Janne Grunau
Post by Luca Barbato
Post by Michael Niedermayer
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.
see libmpcodecs_wrapper in http://git.jannau.net/git/ffmpeg/
it uses a git submodule for libavfilter/libmpcodecs which I have
published at http://git.jannau.net/git/libmpcodecs-ffmpeg/
That repo contains Michael's patches on top of mplayer/libmpcodecs
filtered history. This will make syncing changes from mplayer much
easier. I've already rebased the patches on top of the tab cleanup.
using a submodule would tie it to the git switch.
also if i understand git correctly (i havnt really done development in
submodules yet) is that each change to the submodule would need 2 commits
and generate 2 svnlog mails
or is it possible to avoid this? Make ffmpeg just link to HEAD of the submodule
like svn supports

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
Ronald S. Bultje
2011-01-16 02:35:44 UTC
Permalink
Hi,
Post by Michael Niedermayer
i suggest we leave it at the tab removial and continue as soon as luca and
ronald agree.
I guess I can't hide in silence continuously.

My opinion: I think this is a bad idea. But you're smart enough, so if
you truly believe this will aid the continued development and adoption
of lavfilter, then fine, go for it. In the end, I will judge the
success of this commit by these two measures.

I saw some interesting suggestions on IRC (seriously, you should read
the backlogs) to threaten to commit this unless the most important
filters are ported in X days. Make a list on multimediawiki; I have no
idea which need to be ported, where there source in mplayer is, what
the license is, who authors are for relicensing, what the filter does,
etc.

Ronald
Michael Niedermayer
2011-01-16 03:46:45 UTC
Permalink
Post by Ronald S. Bultje
Hi,
Post by Michael Niedermayer
i suggest we leave it at the tab removial and continue as soon as luca and
ronald agree.
I guess I can't hide in silence continuously.
My opinion: I think this is a bad idea.
ive heared this often enough now to put garlic and holy water on my shopping
list. Anyone has a few silver bullets just in case that doesnt work?
Post by Ronald S. Bultje
But you're smart enough, so if
you truly believe this will aid the continued development and adoption
of lavfilter, then fine, go for it.
i truely belive it makes no difference at all.
But the time wasted on libmpcodecs makes a difference.
So ill wait the 48h and if someone comes forth with a patch then ill wait
until that is applied and done otherwise and assuming the absence of
disagreements ill update my patch to what is in mplayer
Post by Ronald S. Bultje
In the end, I will judge the
success of this commit by these two measures.
I saw some interesting suggestions on IRC
(seriously, you should read
the backlogs)
Seriously i should have the backlogs first
More seriously there should be public backlogs
Most seriously the log bot should still be running
Post by Ronald S. Bultje
to threaten to commit this unless the most important
filters are ported in X days. Make a list on multimediawiki; I have no
idea which need to be ported, where there source in mplayer is, what
the license is, who authors are for relicensing, what the filter does,
etc.
license is in the file headers (i know that without checking as diego has
commit rights there), license should be GPL for most if not all
my wrapper is GPL too and is based on GPL code from vf.c
Iam against relicensing without the benefiting companies donating to the
foundation and the author.

about the wiki i can help if you remind me once the code is in and the dust
has settled

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
Diego Biurrun
2011-01-16 14:53:52 UTC
Permalink
Post by Michael Niedermayer
Post by Reimar Döffinger
Post by Michael Niedermayer
What is really important to me is that theres a point after which you wont
accept further cosmetics from diego in libmpcodecs. I know diego will always
find more that needs cleanup once he starts looking. And its not fun if 50% of
commits are useless cosmetics and one has to merge that by hand.
That is fine by me, but Diego needs to get a say in that.
Actually I'd prefer if you two could discuss this directly, since I
Ok, lets try.
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?
This libmpcodecs thing is the stupidest idea I have heard in a long time.
Sorry to be blunt, but you are not exactly known for mincing words
yourself. However, I do not expect to have the slightest say in this,
same as the other devs in this thread. Apparently all that counts are
a few voices on the ffmpeg-users mailing list.

Temporary hacks like this have never had a lifetime smaller than infinity
in the past, this one will not be an exception. If this gets committed,
it will stay with ffmpeg until the heat death of the universe. Nothing
reduces motivation to work on an improved system more than one that is
more or less good enough; witness libfaad2 or Flash player.

If this is supposed to help porting filters, publish a branch and write
a filter porting HOWTO that instructs people where to pull that branch
from. There is absolutely no need to have this code in trunk/master.


I also see that Carl Eugen just committed the tab removal that directly
conflicts with my uncrustify work without any previous discussion, even
though Reimar mentioned that I am working on something related.

I vividly remember a certain flamewar caused by rewording Doxygen
comments without previous discussion. But apparently the rules have
been momentarily disabled or they never applied to everybody equally
in the first place.

Don't tell me that the tab removal was discussed here previously.
Obviously the place to discuss MPlayer changes cannot be an FFmpeg
mailing list, else I will just run FFmpeg through uncrustify after
I have done it to MPlayer. I'm sure I can find a mailing list where
nobody will find my announcement within the 24h timeframe between
commit threat and execution.

Diego

P.S.: *Not* having a DLL loader was one of the earliest policy decisions
made by Fabrice, he added it to the FAQ in r145. It has stood ever
since and nobody except you ever contested it.
Carl Eugen Hoyos
2011-01-16 15:22:17 UTC
Permalink
Post by Diego Biurrun
This libmpcodecs thing is the stupidest idea I have heard in a long time.
Sorry to be blunt, but you are not exactly known for mincing words
yourself. However, I do not expect to have the slightest say in this,
same as the other devs in this thread. Apparently all that counts are
a few voices on the ffmpeg-users mailing list.
?
I believe I read ffmpeg-users regularly, but I don't remember any such "voices".

[...]
Post by Diego Biurrun
I also see that Carl Eugen just committed the tab removal that directly
just?
As in "soeben, vor kurzem" or "einfach so"?
Post by Diego Biurrun
conflicts with my uncrustify work without any previous discussion, even
though Reimar mentioned that I am working on something related.
When, where did anybody mention you are working on this?
Last time I asked you to just commit cosmetic changes to mplayer-svn, you
answered you are NOT going to do it because Nico objects for the files he
maintains.

And I will of course revert the cosmetics if Reimar asks me to.

CE
Diego Biurrun
2011-01-16 15:52:06 UTC
Permalink
Post by Carl Eugen Hoyos
Post by Diego Biurrun
This libmpcodecs thing is the stupidest idea I have heard in a long time.
Sorry to be blunt, but you are not exactly known for mincing words
yourself. However, I do not expect to have the slightest say in this,
same as the other devs in this thread. Apparently all that counts are
a few voices on the ffmpeg-users mailing list.
?
I believe I read ffmpeg-users regularly, but I don't remember any such "voices".
Then why are you saying this libmpcodecs thing is the #1 requested
feature?
Post by Carl Eugen Hoyos
Post by Diego Biurrun
I also see that Carl Eugen just committed the tab removal that directly
just?
As in "soeben, vor kurzem" or "einfach so"?
all of the above
Post by Carl Eugen Hoyos
Post by Diego Biurrun
conflicts with my uncrustify work without any previous discussion, even
though Reimar mentioned that I am working on something related.
When, where did anybody mention you are working on this?
Reimar, in this thread.

Diego
Carl Eugen Hoyos
2011-01-16 17:26:16 UTC
Permalink
Post by Diego Biurrun
Post by Carl Eugen Hoyos
Post by Diego Biurrun
conflicts with my uncrustify work without any previous discussion, even
though Reimar mentioned that I am working on something related.
When, where did anybody mention you are working on this?
Reimar, in this thread.
You are just trolling realising he wrote that 24h after I applied my changes?

And why did you cut the only important part of my message?

CE
Diego Biurrun
2011-01-16 17:59:06 UTC
Permalink
Post by Carl Eugen Hoyos
Post by Diego Biurrun
Post by Carl Eugen Hoyos
Post by Diego Biurrun
conflicts with my uncrustify work without any previous discussion, even
though Reimar mentioned that I am working on something related.
When, where did anybody mention you are working on this?
Reimar, in this thread.
You are just trolling realising he wrote that 24h after I applied my changes?
I'm currently very busy and my time is limited. I cannot follow all
mailing lists in realtime and to be honest, nowadays I don't know if
I wanted to even if I could.

I read the messages in this thread out of order and I only saw your
second commit on mplayer-cvslog. The second one done 24h before I
just noticed now when manually looking at 'svn log'. Apparently the
diff is too big and got stuck in the moderation queue.

So my apologies if I got things mixed up and wrongly accused you of
doing those changes despite Reimar telling you I had related stuff
in the queue.

However, this is only a secondary point. The main point is that you
breached MPlayer project policy. Making potentially controversial
changes - completely unannounced - is unacceptable, period.

You were one of my harshest critics when I refused to close an account
for policy violations and not a meeting between us goes by without you
reminding me of that incident.

Do you realize that you have put me in a position where, if I were to
follow the principles that you want me to follow, I have to close your
account now?

Maybe I'm being a bit quick to anger right now, but if you put yourself
in my shoes you should see that a "WTF?!?" is the least thing you could
expect.
Post by Carl Eugen Hoyos
And why did you cut the only important part of my message?
I see nothing else that needs to be answered, at least not taking
into account this email...

Diego
Carl Eugen Hoyos
2011-01-16 17:56:34 UTC
Permalink
Post by Carl Eugen Hoyos
Post by Diego Biurrun
I also see that Carl Eugen just committed the tab removal that directly
conflicts with my uncrustify work without any previous discussion, even
though Reimar mentioned that I am working on something related.
When, where did anybody mention you are working on this?
Never mind, I found it:
http://thread.gmane.org/gmane.comp.video.mplayer.devel/55528/focus=55596

Carl Eugen
Reimar Döffinger
2011-01-16 15:23:44 UTC
Permalink
Post by Diego Biurrun
If this is supposed to help porting filters, publish a branch and write
a filter porting HOWTO that instructs people where to pull that branch
from. There is absolutely no need to have this code in trunk/master.
Well, it would allow testing reimplementations against the libmpcodecs
versions via FATE. Also it has exposed some significant performance
differences already, so there's some suspicion that this might make
people actually bother to compare performance.
Post by Diego Biurrun
I also see that Carl Eugen just committed the tab removal that directly
conflicts with my uncrustify work without any previous discussion, even
though Reimar mentioned that I am working on something related.
I have to say I didn't expect there to be any conflict, while suboptimal
with concern to history, does this kind of change cause issues for your
work?
Diego Biurrun
2011-01-16 16:15:10 UTC
Permalink
Post by Reimar Döffinger
Post by Diego Biurrun
If this is supposed to help porting filters, publish a branch and write
a filter porting HOWTO that instructs people where to pull that branch
from. There is absolutely no need to have this code in trunk/master.
Well, it would allow testing reimplementations against the libmpcodecs
versions via FATE. Also it has exposed some significant performance
differences already, so there's some suspicion that this might make
people actually bother to compare performance.
Michael wrote the code already, devs working on filters know where to
find it. There is no need to bloat FFmpeg with libmpcodecs.
Post by Reimar Döffinger
Post by Diego Biurrun
I also see that Carl Eugen just committed the tab removal that directly
conflicts with my uncrustify work without any previous discussion, even
though Reimar mentioned that I am working on something related.
I have to say I didn't expect there to be any conflict, while suboptimal
with concern to history, does this kind of change cause issues for your
work?
It does not cause direct issues for my work, but Carl Eugen could not know
that. The least thing he could do is ask, in the appropriate forum. On
top of that I remember him being against cosmetic changes in the past.

Then there is the issue of bloating the history with huge and completely
pointless commits and causing conflicts for every single developer with
changes in one of the affected files.

How this kind of unannounced change can suddenly be taken for granted
without discussion just boggles my mind. Had somebody else done it in
a different context, I'm sure the mob would already be calling for
accounts to be closed.

Diego
Reimar Döffinger
2011-01-16 16:32:45 UTC
Permalink
Post by Diego Biurrun
Post by Reimar Döffinger
Post by Diego Biurrun
If this is supposed to help porting filters, publish a branch and write
a filter porting HOWTO that instructs people where to pull that branch
from. There is absolutely no need to have this code in trunk/master.
Well, it would allow testing reimplementations against the libmpcodecs
versions via FATE. Also it has exposed some significant performance
differences already, so there's some suspicion that this might make
people actually bother to compare performance.
Michael wrote the code already, devs working on filters know where to
find it. There is no need to bloat FFmpeg with libmpcodecs.
They knew that before, and it still seems nobody bothered.
Sometimes convenience is the only thing that matters in the end.
Post by Diego Biurrun
Post by Reimar Döffinger
Post by Diego Biurrun
I also see that Carl Eugen just committed the tab removal that directly
conflicts with my uncrustify work without any previous discussion, even
though Reimar mentioned that I am working on something related.
I have to say I didn't expect there to be any conflict, while suboptimal
with concern to history, does this kind of change cause issues for your
work?
It does not cause direct issues for my work, but Carl Eugen could not know
that. The least thing he could do is ask, in the appropriate forum. On
top of that I remember him being against cosmetic changes in the past.
Then there is the issue of bloating the history with huge and completely
pointless commits and causing conflicts for every single developer with
changes in one of the affected files.
I agree it wasn't optimal, and I don't disagree that you are justified
to complain. I just see the agressiveness as neither helping not justified.
Post by Diego Biurrun
How this kind of unannounced change can suddenly be taken for granted
without discussion just boggles my mind. Had somebody else done it in
a different context, I'm sure the mob would already be calling for
accounts to be closed.
Honestly I think that's mostly because "the mob" has gone or become tired.
I never considered closing an account as anything other than either an
emergency reaction or after you just see no way of discussing with anyone
reasonable.
And I just can't imagine that you and Carl Eugen can't come to an agreement
concerning this, he already said he will revert it if asked, and he wasn't really aware
of your work, and I gave my ok before mentioning what you are working on, and
I did not CC you or the MPlayer list (I thought about it, but I assumed that
the discussion would go on for a while before anything was going to happen
and thus it should not be necessary, my fault).
Michael Niedermayer
2011-01-16 18:56:50 UTC
Permalink
Post by Reimar Döffinger
Post by Diego Biurrun
Post by Reimar Döffinger
Post by Diego Biurrun
If this is supposed to help porting filters, publish a branch and write
a filter porting HOWTO that instructs people where to pull that branch
from. There is absolutely no need to have this code in trunk/master.
Well, it would allow testing reimplementations against the libmpcodecs
versions via FATE. Also it has exposed some significant performance
differences already, so there's some suspicion that this might make
people actually bother to compare performance.
Michael wrote the code already, devs working on filters know where to
find it. There is no need to bloat FFmpeg with libmpcodecs.
They knew that before, and it still seems nobody bothered.
Sometimes convenience is the only thing that matters in the end.
also my patch as posted contains bugs, at least one ive fixed locally and some
that need investigating
It would be tremendously helpfull to have the code available over the main
checkout to everyone for people to help working on it

I remember myself often hearing of various RE efforts and other out of main
branch work. And i practically never bothered to check them out. Theres a
good chance i would have contributed minor fixes here and there had the code
been easier available
Thats also why i always wanted the mplayer docs team to have write access to
ffmpeg, so they could just fix minor uncontroversal typos ...
Post by Reimar Döffinger
Post by Diego Biurrun
Post by Reimar Döffinger
Post by Diego Biurrun
I also see that Carl Eugen just committed the tab removal that directly
conflicts with my uncrustify work without any previous discussion, even
though Reimar mentioned that I am working on something related.
I have to say I didn't expect there to be any conflict, while suboptimal
with concern to history, does this kind of change cause issues for your
work?
It does not cause direct issues for my work, but Carl Eugen could not know
that. The least thing he could do is ask, in the appropriate forum. On
top of that I remember him being against cosmetic changes in the past.
Then there is the issue of bloating the history with huge and completely
pointless commits and causing conflicts for every single developer with
changes in one of the affected files.
I agree it wasn't optimal, and I don't disagree that you are justified
to complain. I just see the agressiveness as neither helping not justified.
I cant say more than i agree.
The lack of having this discussed at the appropriate list was a unfortunate
mistake.

Id also like to make it clear that iam perfectly fine if it is reverted


[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once" - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
Diego Biurrun
2011-01-16 19:12:33 UTC
Permalink
Post by Reimar Döffinger
Post by Diego Biurrun
Post by Reimar Döffinger
Post by Diego Biurrun
I also see that Carl Eugen just committed the tab removal that directly
conflicts with my uncrustify work without any previous discussion, even
though Reimar mentioned that I am working on something related.
I have to say I didn't expect there to be any conflict, while suboptimal
with concern to history, does this kind of change cause issues for your
work?
It does not cause direct issues for my work, but Carl Eugen could not know
that. The least thing he could do is ask, in the appropriate forum. On
top of that I remember him being against cosmetic changes in the past.
Then there is the issue of bloating the history with huge and completely
pointless commits and causing conflicts for every single developer with
changes in one of the affected files.
I agree it wasn't optimal, and I don't disagree that you are justified
to complain. I just see the agressiveness as neither helping not justified.
It surely is not helping, maybe it is not even justified, but maybe it
is at least somewhat understandable. Carl Eugen and Michael have neither
forgiven nor forgotten what happened almost four years ago, on the
contrary, I get reminded at every possible occasion.

So forgive me if I get triggered more than I should, but from my point of
view it looks like just the kind of behavior they were so critical of,
only now it's OK because, well, no reason comes to mind except applying
different rules to different people.

So this is inconsistent behavior, to put it mildly, from my point of view
and I get triggered more than I should. But it's not like the other side
has ever done anything to pour oil on troubled water, it was always poured
on the fire.

I will shut up now and don't mention it again, but I just had to state
my side of the matter.
Post by Reimar Döffinger
Post by Diego Biurrun
How this kind of unannounced change can suddenly be taken for granted
without discussion just boggles my mind. Had somebody else done it in
a different context, I'm sure the mob would already be calling for
accounts to be closed.
Honestly I think that's mostly because "the mob" has gone or become tired.
I never considered closing an account as anything other than either an
emergency reaction or after you just see no way of discussing with anyone
reasonable.
And I just can't imagine that you and Carl Eugen can't come to an agreement
concerning this, he already said he will revert it if asked,
Note that he said he would revert if you asked, not if asked.
Post by Reimar Döffinger
and he wasn't really aware of your work, and I gave my ok before
mentioning what you are working on, and I did not CC you or the
MPlayer list (I thought about it, but I assumed that the discussion
would go on for a while before anything was going to happen and thus
it should not be necessary, my fault).
OK, but I don't think it's your fault that this premature commit caught
you by surprise.

Diego
Stefano Sabatini
2011-01-16 15:37:15 UTC
Permalink
Post by Diego Biurrun
Post by Michael Niedermayer
Post by Reimar Döffinger
Post by Michael Niedermayer
What is really important to me is that theres a point after which you wont
accept further cosmetics from diego in libmpcodecs. I know diego will always
find more that needs cleanup once he starts looking. And its not fun if 50% of
commits are useless cosmetics and one has to merge that by hand.
That is fine by me, but Diego needs to get a say in that.
Actually I'd prefer if you two could discuss this directly, since I
Ok, lets try.
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?
This libmpcodecs thing is the stupidest idea I have heard in a long time.
Sorry to be blunt, but you are not exactly known for mincing words
yourself. However, I do not expect to have the slightest say in this,
same as the other devs in this thread. Apparently all that counts are
a few voices on the ffmpeg-users mailing list.
Temporary hacks like this have never had a lifetime smaller than infinity
in the past, this one will not be an exception. If this gets committed,
it will stay with ffmpeg until the heat death of the universe. Nothing
reduces motivation to work on an improved system more than one that is
more or less good enough; witness libfaad2 or Flash player.
If this is supposed to help porting filters, publish a branch and write
a filter porting HOWTO that instructs people where to pull that branch
from. There is absolutely no need to have this code in trunk/master.
It may simplify the work of the developers which work on the porting,
and the users which want to have that feature *right now* (without to
rely on another branch). The code may/should be disabled by
default. Having more users means more testers and more contributors.

And we can run a GSOC and/or funding for porting the filters, we can
realistically expect all the filters to be ported in two years, at
that point we may remove the hack.

Also consider that libmpcodecs is GPL, when porting we may change
licensing when applicable to be LGPL, this may be an incentive for
companies to sponsor filter native integration.
Post by Diego Biurrun
I also see that Carl Eugen just committed the tab removal that directly
conflicts with my uncrustify work without any previous discussion, even
though Reimar mentioned that I am working on something related.
How much time will it take for your uncrustify work to be applied? If
it is along the lines of one/two weeks I suppose we can wait, if it
may take months then I don't think it is worthful to block development
for that. After all libmpcodecs code stands there since almost ten
years, and nobody felt the need to cleanup up it before.
Post by Diego Biurrun
I vividly remember a certain flamewar caused by rewording Doxygen
comments without previous discussion. But apparently the rules have
been momentarily disabled or they never applied to everybody equally
in the first place.
Don't tell me that the tab removal was discussed here previously.
Obviously the place to discuss MPlayer changes cannot be an FFmpeg
mailing list, else I will just run FFmpeg through uncrustify after
I have done it to MPlayer. I'm sure I can find a mailing list where
nobody will find my announcement within the 24h timeframe between
commit threat and execution.
Diego
P.S.: *Not* having a DLL loader was one of the earliest policy decisions
made by Fabrice, he added it to the FAQ in r145. It has stood ever
since and nobody except you ever contested it.
Let me say again: libmpcodecs import in FFmpeg won't affect the
developers of other areas of FFmpeg and will be disabled by default,
so I believe that's fair this to be a decision of the libavfilter
maintainer and contributors as stated by the policy.

If many developers are strongly against libmpcodecs in FFmpeg for
philosophical reasons (it hurts my eyes, it's ugly, it scares me),
then I'm not against using a git topic branch (so we'll have to wait
for proper git migration I suppose?), but I'd prefer to keep it in the
main branch, as this means less work *for me* and for potential
contributors.
--
FFmpeg = Fabulous and Fundamentalist Multipurpose Pure Ecumenical Ghost
Diego Biurrun
2011-01-16 16:11:35 UTC
Permalink
Post by Stefano Sabatini
Post by Diego Biurrun
Post by Michael Niedermayer
Post by Reimar Döffinger
Post by Michael Niedermayer
What is really important to me is that theres a point after which you wont
accept further cosmetics from diego in libmpcodecs. I know diego will always
find more that needs cleanup once he starts looking. And its not fun if 50% of
commits are useless cosmetics and one has to merge that by hand.
That is fine by me, but Diego needs to get a say in that.
Actually I'd prefer if you two could discuss this directly, since I
Ok, lets try.
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?
This libmpcodecs thing is the stupidest idea I have heard in a long time.
Sorry to be blunt, but you are not exactly known for mincing words
yourself. However, I do not expect to have the slightest say in this,
same as the other devs in this thread. Apparently all that counts are
a few voices on the ffmpeg-users mailing list.
Temporary hacks like this have never had a lifetime smaller than infinity
in the past, this one will not be an exception. If this gets committed,
it will stay with ffmpeg until the heat death of the universe. Nothing
reduces motivation to work on an improved system more than one that is
more or less good enough; witness libfaad2 or Flash player.
If this is supposed to help porting filters, publish a branch and write
a filter porting HOWTO that instructs people where to pull that branch
from. There is absolutely no need to have this code in trunk/master.
It may simplify the work of the developers which work on the porting,
I very much doubt it will make a difference to a branch.
Post by Stefano Sabatini
and the users which want to have that feature *right now* (without to
rely on another branch).
They will never care about libmpcodecs removal once they have something
that is barely good enough.
Post by Stefano Sabatini
And we can run a GSOC and/or funding for porting the filters, we can
realistically expect all the filters to be ported in two years, at
that point we may remove the hack.
Also consider that libmpcodecs is GPL, when porting we may change
licensing when applicable to be LGPL, this may be an incentive for
companies to sponsor filter native integration.
Your optimism is enviable. Unfortunately I see no past experience that
supports your plans/wishes to become reality, much less in the timeframe
you expect.
Post by Stefano Sabatini
Post by Diego Biurrun
I also see that Carl Eugen just committed the tab removal that directly
conflicts with my uncrustify work without any previous discussion, even
though Reimar mentioned that I am working on something related.
How much time will it take for your uncrustify work to be applied? If
it is along the lines of one/two weeks I suppose we can wait, if it
may take months then I don't think it is worthful to block development
for that.
I planned to work on it this weekend, but now I'm busy flaming.

I don't see why I should adjust my work schedule to FFmpeg's needs in
this case. I'm currently plenty busy and don't want to commit to any
timeframes during which I will get such work done. Certainly I will
not accept a ban on libmpcodecs changes of any kind, including cosmetic
ones, due to an inclusion in FFmpeg.

Diego
Reimar Döffinger
2011-01-16 16:36:13 UTC
Permalink
Post by Diego Biurrun
Post by Stefano Sabatini
Post by Diego Biurrun
I also see that Carl Eugen just committed the tab removal that directly
conflicts with my uncrustify work without any previous discussion, even
though Reimar mentioned that I am working on something related.
How much time will it take for your uncrustify work to be applied? If
it is along the lines of one/two weeks I suppose we can wait, if it
may take months then I don't think it is worthful to block development
for that.
I planned to work on it this weekend, but now I'm busy flaming.
I don't see why I should adjust my work schedule to FFmpeg's needs in
this case. I'm currently plenty busy and don't want to commit to any
timeframes during which I will get such work done. Certainly I will
not accept a ban on libmpcodecs changes of any kind, including cosmetic
ones, due to an inclusion in FFmpeg.
I'd like to point out that Michael's request was for there to me no
more than one "huge cosmetics" change, not a specific time-frame.
But could we please get this back on trying to find a solution instead
of trying to shoot down as many possible solutions as possible?
compn
2011-01-16 21:13:21 UTC
Permalink
Post by Diego Biurrun
P.S.: *Not* having a DLL loader was one of the earliest policy decisions
made by Fabrice, he added it to the FAQ in r145. It has stood ever
since and nobody except you ever contested it.
the dll loader in mplayer is heavily used for RE'ing/testing
codecs in ffmpeg. if ffmpeg had the loader and wrappers for other
codecs, mencoder would probably never have been made. and we wouldnt
have had to reinvent so many wheels or split up so many developers.

if you want to bring up dates, would you say that generally, following a
10-year-old plan, is a good idea in a multimedia software project?

sorry, i know the flames are over, but i had this mail written
already!

-compn
Diego Biurrun
2011-01-16 21:07:22 UTC
Permalink
Post by compn
Post by Diego Biurrun
P.S.: *Not* having a DLL loader was one of the earliest policy decisions
made by Fabrice, he added it to the FAQ in r145. It has stood ever
since and nobody except you ever contested it.
the dll loader in mplayer is heavily used for RE'ing/testing
codecs in ffmpeg. if ffmpeg had the loader and wrappers for other
codecs, mencoder would probably never have been made. and we wouldnt
have had to reinvent so many wheels or split up so many developers.
if you want to bring up dates, would you say that generally, following a
10-year-old plan, is a good idea in a multimedia software project?
Having the codec loader around helped bootstrapping a free software
multimedia environment, but it reduced the pain threshold for replacing
all components with free software. I'm not sure if it helped or not in
the 10+ year long run. But it's a done deal, speculation is pointless.

Diego
compn
2011-01-14 14:53:30 UTC
Permalink
Post by Stefano Sabatini
Before to pronounce I would like to know which is the long term plan.
Do we want to keep an unsynched branch of MPlayer in FFmpeg?, will
MPlayer get rid of libmpcodecs filters and use libavfilter instead?,
or we'll have to keep this code and burden duplication forever?
swscale is shared between the projects. burden? heh
Post by Stefano Sabatini
I suppose the plan of the MPlayer crew was to start to support
there is no plan. only reimar is left to review mplayer patches.
michael is probably the only one motivated enough to add libavfilter to
mplayer.
Post by Stefano Sabatini
* cons: people will consider to use (and eventually fix) the
libmpcodecs filters rather than port them into libavfilter (which
nah. companies are lgpl-crazy and libmpcodecs are gpl. they will be
rewritten for sure.

-compn
Michael Niedermayer
2011-01-14 14:19:24 UTC
Permalink
Post by Luca Barbato
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
In order to keep things sane, please DO NOT.
I cannot maintain the code if changed cosmetically relative to mplayers so
its technically not possible. (noone else would maintain it either then so its
also not just me ...)

Also noone of the ffmpeg team is supposed to add optimizations in there nor
debug it nor anything so its also not needed to fit our style.
its part of mplayer ...

Of course if someone wants to optimize that code anyway or change its style
its a matter that belongs to mplayer-dev ...
Post by Luca Barbato
The swscale experience is fresh again for me and I'd rather not.
Post by Michael Niedermayer
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Mind keeping that in a branch so people interested may get it and people
scared can live w/out? I'm not sure if that code is less scary than
swscale BUT your following comment says much.
its much more scary ;)
There are 10 times more people who vanished without a trace there than in the
bermuda triangle

and even more scary is gnu libc there noone ever came out alive and still sane.
Should we drop useage of libc as a result and place all calls to libc in a
branch until libc source has been cleaned up?
Post by Luca Barbato
Post by Michael Niedermayer
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab& trailing whitespace checkin scripts.
Are you joking? If you are _really_ serious I'd suggest (or even I'd do
myself) to clean it up at least to be properly indented in mplayer.
- coding style
- basic respect for structured code
- people that might be interested in contribute optimizations
I'd rather have it polished before, either in mplayer or here, if you
are itching to commit it, make a branch and advertise it so before it
hits the master those 3 points might be addressed already.
If you want to do cleanup, you can do it in mplayer svn if the mplayer devels
agree
i can just merge the changes in, but IMHO if it takes you more than a few days
to run indent or sed over the code and get it approved then waiting longer has
zero sense. Because indent takes seconds, and getting it approved either will
happen or will not happen. And its twice as much code than there is in swcale so
doing anything by hand is (from experience of swscale) something taking years
and i think we all agree that blocking 80% of functionality of libavfilter
for years is not worth the style changes to code that is semantically not even
part of ffmpeg.


[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
Luca Barbato
2011-01-15 02:17:24 UTC
Permalink
Post by Michael Niedermayer
Of course if someone wants to optimize that code anyway or change its style
its a matter that belongs to mplayer-dev ...
I have uses for swscale so I'll do something.
Post by Michael Niedermayer
Post by Luca Barbato
The swscale experience is fresh again for me and I'd rather not.
Post by Michael Niedermayer
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Mind keeping that in a branch so people interested may get it and people
scared can live w/out? I'm not sure if that code is less scary than
swscale BUT your following comment says much.
its much more scary ;)
There are 10 times more people who vanished without a trace there than in the
bermuda triangle
Ouch...
Post by Michael Niedermayer
and even more scary is gnu libc there noone ever came out alive and still sane.
Should we drop useage of libc as a result and place all calls to libc in a
branch until libc source has been cleaned up?
libc has a clean interface to add optimized/specialized versions and
overall there isn't much to be scared if you stay away from the public
headers machineries =P
Post by Michael Niedermayer
If you want to do cleanup, you can do it in mplayer svn if the mplayer devels
agree
I'll check soon, swscale first ^^
Post by Michael Niedermayer
i can just merge the changes in, but IMHO if it takes you more than a few days
to run indent or sed over the code and get it approved then waiting longer has
zero sense. Because indent takes seconds, and getting it approved either will
happen or will not happen. And its twice as much code than there is in swcale so
doing anything by hand is (from experience of swscale) something taking years
and i think we all agree that blocking 80% of functionality of libavfilter
for years is not worth the style changes to code that is semantically not even
part of ffmpeg.
I'd rather have clean and maintainable code in ffmpeg. I could accept
this kind of devils deal only if it gets first a full regression test so
trying to clean it up later would be half of the work.

lu
Michael Niedermayer
2011-01-15 04:30:52 UTC
Permalink
Post by Luca Barbato
Post by Michael Niedermayer
Of course if someone wants to optimize that code anyway or change its style
its a matter that belongs to mplayer-dev ...
I have uses for swscale so I'll do something.
Post by Michael Niedermayer
Post by Luca Barbato
The swscale experience is fresh again for me and I'd rather not.
Post by Michael Niedermayer
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Mind keeping that in a branch so people interested may get it and people
scared can live w/out? I'm not sure if that code is less scary than
swscale BUT your following comment says much.
its much more scary ;)
There are 10 times more people who vanished without a trace there than in the
bermuda triangle
Ouch...
Post by Michael Niedermayer
and even more scary is gnu libc there noone ever came out alive and still sane.
Should we drop useage of libc as a result and place all calls to libc in a
branch until libc source has been cleaned up?
libc has a clean interface to add optimized/specialized versions and
overall there isn't much to be scared if you stay away from the public
headers machineries =P
Post by Michael Niedermayer
If you want to do cleanup, you can do it in mplayer svn if the mplayer devels
agree
I'll check soon, swscale first ^^
Post by Michael Niedermayer
i can just merge the changes in, but IMHO if it takes you more than a few days
to run indent or sed over the code and get it approved then waiting longer has
zero sense. Because indent takes seconds, and getting it approved either will
happen or will not happen. And its twice as much code than there is in swcale so
doing anything by hand is (from experience of swscale) something taking years
and i think we all agree that blocking 80% of functionality of libavfilter
for years is not worth the style changes to code that is semantically not even
part of ffmpeg.
I'd rather have clean and maintainable code in ffmpeg. I could accept
this kind of devils deal only if it gets first a full regression test so
trying to clean it up later would be half of the work.
We should work on libavfilter NOT libmpcodecs. Filters should be ported
to libavfilters not cleaned up in libmpcodecs thats time wasted on a "going
to be removed" system.
thats then even adding more burden on me to merge idiotic cleanup back and
forth between libavfilter/libmpcodecs and mplayer


About regression tests, the idea is not bad if someone wants to do it. But
Asking to do that (unrelated) work as condition for this patch feels a bit
offensive IMHO. Ive not seen others make unrelated requests since a long time
and i have even asked for help many times and there are
important issues id like to work on like the malloc/free speed issue.

I prefered the past where comments where based on technical issues and not
philosophical ones. And where maintainers could work on their code without
everyone bikesheding every change.
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
Luca Barbato
2011-01-15 15:44:08 UTC
Permalink
Post by Michael Niedermayer
About regression tests, the idea is not bad if someone wants to do it. But
Asking to do that (unrelated) work as condition for this patch feels a bit
offensive IMHO. Ive not seen others make unrelated requests since a long time
and i have even asked for help many times and there are
important issues id like to work on like the malloc/free speed issue.
I think we are probably misunderstanding your purpose for this wrapper.

If The idea is to have it to ease the porting to libavfilter I think
makes sense keep it in a separate branch and not work on it if you think
we can't get that code clean enough to be merged as libavfilter.

I, and probably others, considered that as a quick route to give
features to our users. And reacted on this idea. Having had experience
with swscale peculiarities I'm more than wary about such imports.
Post by Michael Niedermayer
I prefered the past where comments where based on technical issues and not
philosophical ones. And where maintainers could work on their code without
everyone bikesheding every change.
If you think that is useful have it on master and we can make clear that
this code will disappear it could stay for that time. But I will have it
removed within this year at most (an hard limit helps avoiding eternal
temporary solutions) and have it depend on flag experimental so it would
not crawl to our userbase that easily.

I hope that helps clear why I'm this against this code import.

lu
Carl Eugen Hoyos
2011-01-15 16:40:21 UTC
Permalink
Post by Luca Barbato
But I will have it
removed within this year at most (an hard limit helps avoiding eternal
temporary solutions) and have it depend on flag experimental so it would
not crawl to our userbase that easily.
Does that mean you will port all remaining filters this year?

Carl Eugen
Michael Niedermayer
2011-01-15 17:21:21 UTC
Permalink
Post by Carl Eugen Hoyos
Post by Luca Barbato
But I will have it
removed within this year at most (an hard limit helps avoiding eternal
temporary solutions) and have it depend on flag experimental so it would
not crawl to our userbase that easily.
Does that mean you will port all remaining filters this year?
I strongly support that. And id also vote in favor of our foundation funding
that. maybe a 100euro for every filter ported ? (more is hard due to the number
of filters being large)


[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Incandescent light bulbs waste a lot of energy as heat so the EU forbids them.
Their replacement, compact fluorescent lamps, much more expensive, dont fit in
many old lamps, flicker, contain toxic mercury, produce a fraction of the light
that is claimed and in a unnatural spectrum rendering colors different than
in natural light. Ah and we now need to turn the heaters up more in winter to
compensate the lower wasted heat. Who wins? Not the environment, thats for sure
Michael Niedermayer
2011-01-15 17:57:35 UTC
Permalink
Post by Luca Barbato
Post by Michael Niedermayer
About regression tests, the idea is not bad if someone wants to do it. But
Asking to do that (unrelated) work as condition for this patch feels a bit
offensive IMHO. Ive not seen others make unrelated requests since a long time
and i have even asked for help many times and there are
important issues id like to work on like the malloc/free speed issue.
I think we are probably misunderstanding your purpose for this wrapper.
If The idea is to have it to ease the porting to libavfilter I think
makes sense keep it in a separate branch and not work on it if you think
we can't get that code clean enough to be merged as libavfilter.
I, and probably others, considered that as a quick route to give
features to our users. And reacted on this idea. Having had experience
with swscale peculiarities I'm more than wary about such imports.
Post by Michael Niedermayer
I prefered the past where comments where based on technical issues and not
philosophical ones. And where maintainers could work on their code without
everyone bikesheding every change.
If you think that is useful have it on master and we can make clear that
this code will disappear it could stay for that time. But I will have it
removed within this year at most (an hard limit helps avoiding eternal
temporary solutions) and have it depend on flag experimental so it would
not crawl to our userbase that easily.
I hope that helps clear why I'm this against this code import.
To elaborate on what my ideas behind this patch are.

Its for libavfilter to be successfull, to have a competetive feature set and
not be an academic toy without features, not used by anyone because it lacks
the most basic filters. I want to give these features to our users ...

But i dont want this code to stay like this in SVN for ever, i do have eyes
and i do too see its not pretty but for me the cosmetic aspect is very minor.
The much bigger aspect or me is that using these filters through the wraper
is technically annoying, the APIs are far from mapping 1:1 onto each other
porting filters to libavfilter is technically a good idea not only cosmetically
and i want it to happen. But i do want to make the features available to our
users during all the time and not keep 50 filters that are ready but ugly
away from our users for 2 years. That really would be very nasty from us to do
to our users

If you want the filters ported to native quickly, theres SOC, theres code in,
theres funding by the foundation, theres contributing patches yourself or
talking other people into helping.
But i dont think a big "we will remove it in a year" is going to achive anything
a fork is easier than porting the filters. And in FOSS its "you want it, you do
it" not "you dont want it, you can prevent others from doing it"
And once someone of us is fed up enough and just forks, the official tree of
libavfilter will perish, no users, no bugreports, noone will port anything in
it. I also would leave and contribute where i can work freely without these
philosophically loaded discussions.

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
Luca Barbato
2011-01-15 21:26:25 UTC
Permalink
Post by Michael Niedermayer
To elaborate on what my ideas behind this patch are.
Its for libavfilter to be successfull, to have a competetive feature set and
not be an academic toy without features, not used by anyone because it lacks
the most basic filters. I want to give these features to our users ...
But i dont want this code to stay like this in SVN for ever, i do have eyes
and i do too see its not pretty but for me the cosmetic aspect is very minor.
The much bigger aspect or me is that using these filters through the wraper
is technically annoying, the APIs are far from mapping 1:1 onto each other
porting filters to libavfilter is technically a good idea not only cosmetically
and i want it to happen. But i do want to make the features available to our
users during all the time and not keep 50 filters that are ready but ugly
away from our users for 2 years. That really would be very nasty from us to do
to our users
If you want the filters ported to native quickly, theres SOC, theres code in,
theres funding by the foundation, theres contributing patches yourself or
talking other people into helping.
But i dont think a big "we will remove it in a year" is going to achive anything
a fork is easier than porting the filters. And in FOSS its "you want it, you do
it" not "you dont want it, you can prevent others from doing it"
And once someone of us is fed up enough and just forks, the official tree of
libavfilter will perish, no users, no bugreports, noone will port anything in
it. I also would leave and contribute where i can work freely without these
philosophically loaded discussions.
My idea is the following, let's use swscale or proto2 as example.

I need certain features (neon yuv2rgb and rgb2yuv, network protocols
with polling threads), those feature require some work that might be
controversial and will require another pair of eyes while it should have
no impact, forcing it on master isn't uncalled, putting it on a branch
to make the interesting parties contribute on it while the rest would be
involved once the branch is ready (e.g. the swscale x86 template code
rewritten in yasm, no function duplication etc).

That's why I'd rather have to this mpcodecs import on a topic branch,
having it worked on w/out adding code that would require whitelisting
even on our normal style checks.

lu - still with spotty networking on a random non-home-place in a random
non-home-region of Italy
Michael Niedermayer
2011-01-15 23:13:09 UTC
Permalink
Post by Luca Barbato
Post by Michael Niedermayer
To elaborate on what my ideas behind this patch are.
Its for libavfilter to be successfull, to have a competetive feature set and
not be an academic toy without features, not used by anyone because it lacks
the most basic filters. I want to give these features to our users ...
But i dont want this code to stay like this in SVN for ever, i do have eyes
and i do too see its not pretty but for me the cosmetic aspect is very minor.
The much bigger aspect or me is that using these filters through the wraper
is technically annoying, the APIs are far from mapping 1:1 onto each other
porting filters to libavfilter is technically a good idea not only cosmetically
and i want it to happen. But i do want to make the features available to our
users during all the time and not keep 50 filters that are ready but ugly
away from our users for 2 years. That really would be very nasty from us to do
to our users
If you want the filters ported to native quickly, theres SOC, theres code in,
theres funding by the foundation, theres contributing patches yourself or
talking other people into helping.
But i dont think a big "we will remove it in a year" is going to achive anything
a fork is easier than porting the filters. And in FOSS its "you want it, you do
it" not "you dont want it, you can prevent others from doing it"
And once someone of us is fed up enough and just forks, the official tree of
libavfilter will perish, no users, no bugreports, noone will port anything in
it. I also would leave and contribute where i can work freely without these
philosophically loaded discussions.
My idea is the following, let's use swscale or proto2 as example.
I need certain features (neon yuv2rgb and rgb2yuv, network protocols
with polling threads), those feature require some work that might be
controversial and will require another pair of eyes while it should have
no impact, forcing it on master isn't uncalled, putting it on a branch
to make the interesting parties contribute on it while the rest would be
involved once the branch is ready (e.g. the swscale x86 template code
rewritten in yasm, no function duplication etc).
That's why I'd rather have to this mpcodecs import on a topic branch,
having it worked on w/out adding code that would require whitelisting
even on our normal style checks.
tabs are long gone on mplayers side in all critical files and i could detab
them before git commit
Post by Luca Barbato
lu - still with spotty networking on a random non-home-place in a random
non-home-region of Italy
phaseing out of reality to avoid my flames is cheating ;)

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
Michael Niedermayer
2011-01-15 11:25:12 UTC
Permalink
[...]
Post by Luca Barbato
Post by Michael Niedermayer
i can just merge the changes in, but IMHO if it takes you more than a few days
to run indent or sed over the code and get it approved then waiting longer has
zero sense. Because indent takes seconds, and getting it approved either will
happen or will not happen. And its twice as much code than there is in swcale so
doing anything by hand is (from experience of swscale) something taking years
and i think we all agree that blocking 80% of functionality of libavfilter
for years is not worth the style changes to code that is semantically not even
part of ffmpeg.
I'd rather have clean and maintainable code in ffmpeg. I could accept
this kind of devils deal only if it gets first a full regression test so
trying to clean it up later would be half of the work.
dont forget the full regression test for swscale as condition to your
cleanup there

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
Luca Barbato
2011-01-15 15:47:56 UTC
Permalink
Post by Michael Niedermayer
[...]
Post by Luca Barbato
Post by Michael Niedermayer
i can just merge the changes in, but IMHO if it takes you more than a few days
to run indent or sed over the code and get it approved then waiting longer has
zero sense. Because indent takes seconds, and getting it approved either will
happen or will not happen. And its twice as much code than there is in swcale so
doing anything by hand is (from experience of swscale) something taking years
and i think we all agree that blocking 80% of functionality of libavfilter
for years is not worth the style changes to code that is semantically not even
part of ffmpeg.
I'd rather have clean and maintainable code in ffmpeg. I could accept
this kind of devils deal only if it gets first a full regression test so
trying to clean it up later would be half of the work.
dont forget the full regression test for swscale as condition to your
cleanup there
I'm assuming the one currently present covers everything, point me to
what's missing if I'm wrong, I didn't check while running it so far ^^;

lu
Michael Niedermayer
2011-01-15 17:29:07 UTC
Permalink
Post by Luca Barbato
Post by Michael Niedermayer
[...]
Post by Luca Barbato
Post by Michael Niedermayer
i can just merge the changes in, but IMHO if it takes you more than a few days
to run indent or sed over the code and get it approved then waiting longer has
zero sense. Because indent takes seconds, and getting it approved either will
happen or will not happen. And its twice as much code than there is in swcale so
doing anything by hand is (from experience of swscale) something taking years
and i think we all agree that blocking 80% of functionality of libavfilter
for years is not worth the style changes to code that is semantically not even
part of ffmpeg.
I'd rather have clean and maintainable code in ffmpeg. I could accept
this kind of devils deal only if it gets first a full regression test so
trying to clean it up later would be half of the work.
dont forget the full regression test for swscale as condition to your
cleanup there
I'm assuming the one currently present covers everything, point me to
what's missing if I'm wrong, I didn't check while running it so far ^^;
missing -> fate

but me writing 50+ regression tests for filters, some of which need
external image files, some need interlaced or telecined material some need
keypresses once pasing that is implemenzted ...
is really hard and a shitload of work which is why iam a little upset
about your requesting me to do that, its close to saying "never commit this"

swscale in fate is fun too, iam not sure its all binary identical accross
platforms, iam not sure what should be tested, there are too many cases to
test all ...
so a subset has to be selected that is quick to test but covers as much as
possible

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
Luca Barbato
2011-01-15 23:55:44 UTC
Permalink
Post by Luca Barbato
Post by Michael Niedermayer
[...]
Post by Luca Barbato
Post by Michael Niedermayer
i can just merge the changes in, but IMHO if it takes you more than a few days
to run indent or sed over the code and get it approved then waiting longer has
zero sense. Because indent takes seconds, and getting it approved either will
happen or will not happen. And its twice as much code than there is in swcale so
doing anything by hand is (from experience of swscale) something taking years
and i think we all agree that blocking 80% of functionality of libavfilter
for years is not worth the style changes to code that is semantically not even
part of ffmpeg.
I'd rather have clean and maintainable code in ffmpeg. I could accept
this kind of devils deal only if it gets first a full regression test so
trying to clean it up later would be half of the work.
dont forget the full regression test for swscale as condition to your
cleanup there
I'm assuming the one currently present covers everything, point me to
what's missing if I'm wrong, I didn't check while running it so far ^^;
missing -> fate
Ah, it might be tricky I'll add to the todo =)
but me writing 50+ regression tests for filters, some of which need
external image files, some need interlaced or telecined material some need
keypresses once pasing that is implemenzted ...
I wasn't aware you wanted to implement/import even those that need
external input. I thought that you already had something that you used
to check the interesting filters were ok with the wrapper.
is really hard and a shitload of work which is why iam a little upset
about your requesting me to do that, its close to saying "never commit this"
swscale in fate is fun too, iam not sure its all binary identical accross
platforms, iam not sure what should be tested, there are too many cases to
test all ...
so a subset has to be selected that is quick to test but covers as much as
possible
I see I'll look into it soon, once I'm home I'll make the
swscale-cleanup branch public.

lu
Michael Niedermayer
2011-01-16 01:05:25 UTC
Permalink
Post by Luca Barbato
Post by Luca Barbato
Post by Michael Niedermayer
[...]
Post by Luca Barbato
Post by Michael Niedermayer
i can just merge the changes in, but IMHO if it takes you more than a few days
to run indent or sed over the code and get it approved then waiting longer has
zero sense. Because indent takes seconds, and getting it approved either will
happen or will not happen. And its twice as much code than there is in swcale so
doing anything by hand is (from experience of swscale) something taking years
and i think we all agree that blocking 80% of functionality of libavfilter
for years is not worth the style changes to code that is semantically not even
part of ffmpeg.
I'd rather have clean and maintainable code in ffmpeg. I could accept
this kind of devils deal only if it gets first a full regression test so
trying to clean it up later would be half of the work.
dont forget the full regression test for swscale as condition to your
cleanup there
I'm assuming the one currently present covers everything, point me to
what's missing if I'm wrong, I didn't check while running it so far ^^;
missing -> fate
Ah, it might be tricky I'll add to the todo =)
but me writing 50+ regression tests for filters, some of which need
external image files, some need interlaced or telecined material some need
keypresses once pasing that is implemenzted ...
I wasn't aware you wanted to implement/import even those that need
external input. I thought that you already had something that you used
to check the interesting filters were ok with the wrapper.
theres a logo removial filter that loads a picture from the disk,
and the screenshot filter that needs keypresses pushed as control codes
through the chain and various telecine filters that need telecined material

I dont know if any of these filters fully works currently but they compile and
dont crash and i dont expect it to be much work to get them working.
Post by Luca Barbato
is really hard and a shitload of work which is why iam a little upset
about your requesting me to do that, its close to saying "never commit this"
swscale in fate is fun too, iam not sure its all binary identical accross
platforms, iam not sure what should be tested, there are too many cases to
test all ...
so a subset has to be selected that is quick to test but covers as much as
possible
I see I'll look into it soon, once I'm home I'll make the
swscale-cleanup branch public.
thats a good idea

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
compn
2011-01-14 13:00:58 UTC
Permalink
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
\o/

well done. after months and months and months of everyone refusing to
make a wrapper. you've done it! :)
Post by Michael Niedermayer
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab & trailing whitespace checkin scripts.
i think its ok? to remove tabs and trailing whitespace in
mplayer first. unless you wanted to keep history?
Post by Michael Niedermayer
+ .description = NULL_IF_CONFIG_SMALL("libmpcodecs wraper."),
wrapper :)

-compn
Michael Niedermayer
2011-01-14 13:14:12 UTC
Permalink
Post by compn
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
\o/
well done. after months and months and months of everyone refusing to
make a wrapper. you've done it! :)
in less than 3 days to add, i thought it would be harder ...
Post by compn
Post by Michael Niedermayer
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab & trailing whitespace checkin scripts.
i think its ok? to remove tabs and trailing whitespace in
mplayer first. unless you wanted to keep history?
I dont really care, mplayer history has been messed up with cosmetics already
enough to make it pretty useless
just as example the m_option/m_struct code albeu added to filters would make
them depend on many more (unrelated) headers in mplayer. It should have been a
matter of reverting these commits but they didnt apply due to lots of cleanup
by diego done afterwards. I had to apply them by hand as no single hunk applied
automatically no matter what options i fed into patch
Post by compn
Post by Michael Niedermayer
+ .description = NULL_IF_CONFIG_SMALL("libmpcodecs wraper."),
wrapper :)
i just tried to make the patch smaller ;)
updated locally though


[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
Carl Eugen Hoyos
2011-01-14 13:21:59 UTC
Permalink
Post by compn
Post by Michael Niedermayer
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab & trailing whitespace checkin scripts.
i think its ok? to remove tabs and trailing whitespace in
mplayer first.
If you don't beat me (and Reimar doesn't object), I will remove trailing
whitespace and tabs from libmpcodecs/vf_*
(How do I find them with grep?)

Carl Eugen
Michael Niedermayer
2011-01-14 14:08:37 UTC
Permalink
Post by Carl Eugen Hoyos
Post by compn
Post by Michael Niedermayer
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab & trailing whitespace checkin scripts.
i think its ok? to remove tabs and trailing whitespace in
mplayer first.
If you don't beat me (and Reimar doesn't object), I will remove trailing
whitespace and tabs from libmpcodecs/vf_*
thats not enough, i need the headers tab free too
tabs:
libavfilter/libmpcodecs/mp_msg.h
libavfilter/libmpcodecs/mp_image.h
libavfilter/libmpcodecs/vf.h
libavfilter/libmpcodecs/mp_image.c
libavfilter/libmpcodecs/img_format.c
libavfilter/libmpcodecs/vf_test.c
libavfilter/libmpcodecs/vf_2xsai.c
libavfilter/libmpcodecs/vf_blackframe.c
libavfilter/libmpcodecs/vf_delogo.c
libavfilter/libmpcodecs/vf_boxblur.c
libavfilter/libmpcodecs/vf_eq.c
libavfilter/libmpcodecs/vf_cropdetect.c
libavfilter/libmpcodecs/vf_decimate.c
libavfilter/libmpcodecs/vf_denoise3d.c
libavfilter/libmpcodecs/vf_detc.c
libavfilter/libmpcodecs/vf_dint.c
libavfilter/libmpcodecs/vf_divtc.c
libavfilter/libmpcodecs/vf_down3dright.c
libavfilter/libmpcodecs/vf_dsize.c
libavfilter/libmpcodecs/libvo/fastmemcpy.h
libavfilter/libmpcodecs/libvo/video_out.h
libavfilter/libmpcodecs/vf_field.c
libavfilter/libmpcodecs/vf_fil.c
libavfilter/libmpcodecs/vf_filmdint.c
libavfilter/libmpcodecs/vf_framestep.c
libavfilter/libmpcodecs/vf_fspp.c
libavfilter/libmpcodecs/vf_mcdeint.c
libavfilter/libmpcodecs/vf_harddup.c
libavfilter/libmpcodecs/vf_hqdn3d.c
libavfilter/libmpcodecs/vf_hue.c
libavfilter/libmpcodecs/vf_il.c
libavfilter/libmpcodecs/vf_ilpack.c
libavfilter/libmpcodecs/vf_ivtc.c
libavfilter/libmpcodecs/vf_kerndeint.c
libavfilter/libmpcodecs/vf_mirror.c
libavfilter/libmpcodecs/vf_noise.c
libavfilter/libmpcodecs/vf_palette.c
libavfilter/libmpcodecs/vf_perspective.c
libavfilter/libmpcodecs/vf_phase.c
libavfilter/libmpcodecs/vf_pp7.c
libavfilter/libmpcodecs/pullup.c
libavfilter/libmpcodecs/vf_pullup.c
libavfilter/libmpcodecs/vf_qp.c
libavfilter/libmpcodecs/vf_rectangle.c
libavfilter/libmpcodecs/vf_remove_logo.c
libavfilter/libmpcodecs/vf_rgbtest.c
libavfilter/libmpcodecs/vf_rotate.c
libavfilter/libmpcodecs/vf_sab.c
libavfilter/libmpcodecs/vf_smartblur.c
libavfilter/libmpcodecs/vf_softpulldown.c
libavfilter/libmpcodecs/vf_softskip.c
libavfilter/libmpcodecs/vf_spp.c
libavfilter/libmpcodecs/vf_swapuv.c
libavfilter/libmpcodecs/vf_telecine.c
libavfilter/libmpcodecs/vf_tile.c
libavfilter/libmpcodecs/vf_tinterlace.c
libavfilter/libmpcodecs/vf_unsharp.c
libavfilter/libmpcodecs/vf_uspp.c
libavfilter/libmpcodecs/pullup.h
libavfilter/libmpcodecs/vf_yuvcsp.c
libavfilter/libmpcodecs/vf_yvu9.c

And that are just the filters we currently support, there are more filters
and more dependancies vf_*c, cmmx.h vd.h come to mind too here
Post by Carl Eugen Hoyos
(How do I find them with grep?)
you grep for a tab under '' (ctrl-v + tab)

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
Carl Eugen Hoyos
2011-01-14 22:11:30 UTC
Permalink
Post by Michael Niedermayer
libavfilter/libmpcodecs/mp_msg.h
libavfilter/libmpcodecs/mp_image.h
(and many more)

done for those listed, tell me if some are still missing.

Carl Eugen
Baptiste Coudurier
2011-01-14 19:45:48 UTC
Permalink
Hi Michael,
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab& trailing whitespace checkin scripts.
[...]
From fcd1ad739d7c36473813ee0d9c495a57bf2df268 Mon Sep 17 00:00:00 2001
Date: Fri, 14 Jan 2011 05:06:30 +0100
Subject: [PATCH 6/7] Add libmpcodecs wraper for libavfilter, still disabled
---
libavfilter/vf_mp.c | 913 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 913 insertions(+), 0 deletions(-)
create mode 100644 libavfilter/vf_mp.c
diff --git a/libavfilter/vf_mp.c b/libavfilter/vf_mp.c
The other filters may be kept intact, but the libavfilter wrapper should
be reformatted and cleaned up.

[...]
--
Baptiste COUDURIER
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
Michael Niedermayer
2011-01-14 19:57:57 UTC
Permalink
Post by Baptiste Coudurier
Hi Michael,
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab& trailing whitespace checkin scripts.
[...]
From fcd1ad739d7c36473813ee0d9c495a57bf2df268 Mon Sep 17 00:00:00 2001
Date: Fri, 14 Jan 2011 05:06:30 +0100
Subject: [PATCH 6/7] Add libmpcodecs wraper for libavfilter, still disabled
---
libavfilter/vf_mp.c | 913 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 913 insertions(+), 0 deletions(-)
create mode 100644 libavfilter/vf_mp.c
diff --git a/libavfilter/vf_mp.c b/libavfilter/vf_mp.c
The other filters may be kept intact, but the libavfilter wrapper should
be reformatted and cleaned up.
Iam undecided about that a bit, i really dont like how it looks either.
The problem is that the code in the wrapper is to a large extend based and in
some cases exactly copied from libmpcodecs/vf.c
so iam not sure what to do. Its easier to maintain if the copied/based code
stays formated like the original


[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
Baptiste Coudurier
2011-01-14 21:14:12 UTC
Permalink
Hi Michael,
Post by Michael Niedermayer
Post by Baptiste Coudurier
Hi Michael,
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab& trailing whitespace checkin scripts.
[...]
From fcd1ad739d7c36473813ee0d9c495a57bf2df268 Mon Sep 17 00:00:00 2001
Date: Fri, 14 Jan 2011 05:06:30 +0100
Subject: [PATCH 6/7] Add libmpcodecs wraper for libavfilter, still disabled
---
libavfilter/vf_mp.c | 913 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 913 insertions(+), 0 deletions(-)
create mode 100644 libavfilter/vf_mp.c
diff --git a/libavfilter/vf_mp.c b/libavfilter/vf_mp.c
The other filters may be kept intact, but the libavfilter wrapper should
be reformatted and cleaned up.
Iam undecided about that a bit, i really dont like how it looks either.
The problem is that the code in the wrapper is to a large extend based and in
some cases exactly copied from libmpcodecs/vf.c
so iam not sure what to do. Its easier to maintain if the copied/based code
stays formated like the original
I see.
I consider this file native libavfilter code and I believe native
libavfilter code should follow libavfilter coding style and guidelines,
It could serve as an example for people implementing wrappers as well.
So IMHO it would be really better if this code was clean and nice.
--
Baptiste COUDURIER
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
Aurelien Jacobs
2011-01-14 22:34:28 UTC
Permalink
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab & trailing whitespace checkin scripts.
From 34072e13989ebed5e76a425b886b5b17756e6d5d Mon Sep 17 00:00:00 2001
Date: Fri, 14 Jan 2011 05:07:39 +0100
Subject: [PATCH 7/7] Enable libmpcodecs support.
---
libavfilter/Makefile | 65 ++++++++++++++++++++++++++++++++++++++++++++++
libavfilter/allfilters.c | 1 +
2 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fdb181e..0db4750 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -30,6 +30,7 @@ OBJS-$(CONFIG_FREI0R_FILTER) += vf_frei0r.o
OBJS-$(CONFIG_GRADFUN_FILTER) += vf_gradfun.o
OBJS-$(CONFIG_HFLIP_FILTER) += vf_hflip.o
OBJS-$(CONFIG_HQDN3D_FILTER) += vf_hqdn3d.o
+OBJS-$(CONFIG_MP_FILTER) += vf_mp.o
OBJS-$(CONFIG_NOFORMAT_FILTER) += vf_format.o
OBJS-$(CONFIG_NULL_FILTER) += vf_null.o
OBJS-$(CONFIG_OCV_FILTER) += vf_libopencv.o
@@ -54,6 +55,70 @@ OBJS-$(CONFIG_NULLSRC_FILTER) += vsrc_nullsrc.o
OBJS-$(CONFIG_NULLSINK_FILTER) += vsink_nullsink.o
+
+OBJS += libmpcodecs/mp_image.o
+OBJS += libmpcodecs/img_format.o
+OBJS [...]
I guess all those libmpcodecs files should also be added to
OBJS-$(CONFIG_MP_FILTER). I don't think we want them compiled
unconditionally.
Post by Michael Niedermayer
+OBJS += libmpcodecs/vf_2xsai.o
+OBJS += libmpcodecs/vf_blackframe.o
+OBJS += libmpcodecs/vf_boxblur.o
+OBJS += libmpcodecs/vf_cropdetect.o
+OBJS += libmpcodecs/vf_decimate.o
+OBJS += libmpcodecs/vf_delogo.o
+OBJS += libmpcodecs/vf_denoise3d.o
+OBJS += libmpcodecs/vf_detc.o
+OBJS += libmpcodecs/vf_dint.o
+OBJS += libmpcodecs/vf_divtc.o
+OBJS += libmpcodecs/vf_down3dright.o
+OBJS += libmpcodecs/vf_dsize.o
+OBJS += libmpcodecs/vf_eq2.o
+OBJS += libmpcodecs/vf_eq.o
+OBJS += libmpcodecs/vf_field.o
+OBJS += libmpcodecs/vf_fil.o
+#OBJS += libmpcodecs/vf_filmdint.o
+OBJS += libmpcodecs/vf_fixpts.o
+OBJS += libmpcodecs/vf_framestep.o
+OBJS += libmpcodecs/vf_fspp.o
+OBJS += libmpcodecs/vf_geq.o
+OBJS += libmpcodecs/vf_gradfun.o
+OBJS += libmpcodecs/vf_harddup.o
+OBJS += libmpcodecs/vf_hqdn3d.o
+OBJS += libmpcodecs/vf_hue.o
+OBJS += libmpcodecs/vf_il.o
+OBJS += libmpcodecs/vf_ilpack.o
+OBJS += libmpcodecs/vf_ivtc.o
+OBJS += libmpcodecs/vf_kerndeint.o
+OBJS += libmpcodecs/vf_mcdeint.o
+OBJS += libmpcodecs/vf_mirror.o
+OBJS += libmpcodecs/vf_noise.o
+OBJS += libmpcodecs/vf_ow.o
+OBJS += libmpcodecs/vf_palette.o
+OBJS += libmpcodecs/vf_perspective.o
+OBJS += libmpcodecs/vf_phase.o
+OBJS += libmpcodecs/vf_pp7.o
+OBJS += libmpcodecs/vf_pullup.o
+OBJS += libmpcodecs/vf_qp.o
+OBJS += libmpcodecs/vf_rectangle.o
+OBJS += libmpcodecs/vf_remove_logo.o
+OBJS += libmpcodecs/vf_rgbtest.o
+OBJS += libmpcodecs/vf_rotate.o
+OBJS += libmpcodecs/vf_sab.o
+OBJS += libmpcodecs/vf_screenshot.o
+OBJS += libmpcodecs/vf_smartblur.o
+OBJS += libmpcodecs/vf_softpulldown.o
+OBJS += libmpcodecs/vf_softskip.o
+OBJS += libmpcodecs/vf_spp.o
+OBJS += libmpcodecs/vf_swapuv.o
+OBJS += libmpcodecs/vf_telecine.o
+OBJS += libmpcodecs/vf_test.o
+OBJS += libmpcodecs/vf_tile.o
+OBJS += libmpcodecs/vf_tinterlace.o
+OBJS += libmpcodecs/vf_unsharp.o
+OBJS += libmpcodecs/vf_uspp.o
+OBJS += libmpcodecs/vf_yuvcsp.o
+OBJS += libmpcodecs/vf_yvu9.o
+OBJS += libmpcodecs/pullup.o
IIUC you said that the ultimate goal is to have all those filters
converted to native libavfilter so that we can drop all the libmpcodecs
filters. If so, why does this libmpcodecs filter list includes some
filters which have already a native libavfilter version ?? Namely:
vf_blackframe.o
vf_cropdetect.o
vf_dsize.o
vf_mirror.o
vf_rectangle.o
vf_rotate.o
Also vf_yvu9 is documented as "Deprecated in favor of the software
scaler". So I doubt it is a good idea to keep it.
I also suspect vf_palette might already be handled by libavfilter.
It might also be worth double checking vf_yuvcsp but I guess this one
is not yet supported by libavfilter.

I didn't check the code carefully yet, but I wonder how did you handle
filters like vf_screenshot or vf_hue which require some external
control/command to trigger some actions ?
I don't think there is any clean API to handle this in libavfilter.
And I don't think vf_screenshot can have any kind of usefullness inside
libavfilter.

And how did you handle filters like vf_remove_logo which fopen()
an image file and decode it internally, totally ingnoring several layers
of abstraction ?
I guess it should be handled by simply having a second input pad
allowing the application to feed it with any kind of decoded picture.

Overall I don't think we should import a whole bunch of filters like
this, without even trying all of them to check if they actually work
and they actally make any sens at all in the libavfilter context.

Aurel
Stefano Sabatini
2011-01-14 23:30:31 UTC
Permalink
[...]
Post by Aurelien Jacobs
IIUC you said that the ultimate goal is to have all those filters
converted to native libavfilter so that we can drop all the libmpcodecs
filters. If so, why does this libmpcodecs filter list includes some
vf_blackframe.o
vf_cropdetect.o
I confirm for these ones.
Post by Aurelien Jacobs
vf_dsize.o
vf_mirror.o
I suppose this is hflip?
Post by Aurelien Jacobs
vf_rectangle.o
vf_rotate.o
libavfilter implementation is only in gsoc (and I discussed another
variant in ffmpeg-devel some months ago).

[...]
--
FFmpeg = Fundamentalist & Funny Merciless Patchable Exxagerate God
Aurelien Jacobs
2011-01-15 00:38:40 UTC
Permalink
Post by Stefano Sabatini
[...]
Post by Aurelien Jacobs
IIUC you said that the ultimate goal is to have all those filters
converted to native libavfilter so that we can drop all the libmpcodecs
filters. If so, why does this libmpcodecs filter list includes some
vf_blackframe.o
vf_cropdetect.o
I confirm for these ones.
Post by Aurelien Jacobs
vf_dsize.o
This should be the same as setdar.
Post by Stefano Sabatini
Post by Aurelien Jacobs
vf_mirror.o
I suppose this is hflip?
yes.
Post by Stefano Sabatini
Post by Aurelien Jacobs
vf_rectangle.o
vf_rotate.o
libavfilter implementation is only in gsoc (and I discussed another
variant in ffmpeg-devel some months ago).
Nope... vf_rotate seems to have the same feature set as lavfi/transpose
which is in master.

Aurel
Michael Niedermayer
2011-01-14 23:44:26 UTC
Permalink
Post by Aurelien Jacobs
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab & trailing whitespace checkin scripts.
From 34072e13989ebed5e76a425b886b5b17756e6d5d Mon Sep 17 00:00:00 2001
Date: Fri, 14 Jan 2011 05:07:39 +0100
Subject: [PATCH 7/7] Enable libmpcodecs support.
---
libavfilter/Makefile | 65 ++++++++++++++++++++++++++++++++++++++++++++++
libavfilter/allfilters.c | 1 +
2 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fdb181e..0db4750 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -30,6 +30,7 @@ OBJS-$(CONFIG_FREI0R_FILTER) += vf_frei0r.o
OBJS-$(CONFIG_GRADFUN_FILTER) += vf_gradfun.o
OBJS-$(CONFIG_HFLIP_FILTER) += vf_hflip.o
OBJS-$(CONFIG_HQDN3D_FILTER) += vf_hqdn3d.o
+OBJS-$(CONFIG_MP_FILTER) += vf_mp.o
OBJS-$(CONFIG_NOFORMAT_FILTER) += vf_format.o
OBJS-$(CONFIG_NULL_FILTER) += vf_null.o
OBJS-$(CONFIG_OCV_FILTER) += vf_libopencv.o
@@ -54,6 +55,70 @@ OBJS-$(CONFIG_NULLSRC_FILTER) += vsrc_nullsrc.o
OBJS-$(CONFIG_NULLSINK_FILTER) += vsink_nullsink.o
+
+OBJS += libmpcodecs/mp_image.o
+OBJS += libmpcodecs/img_format.o
+OBJS [...]
I guess all those libmpcodecs files should also be added to
OBJS-$(CONFIG_MP_FILTER). I don't think we want them compiled
unconditionally.
i had hoped other people would help but ok fixed locally


[...]
Post by Aurelien Jacobs
IIUC you said that the ultimate goal is to have all those filters
converted to native libavfilter so that we can drop all the libmpcodecs
filters. If so, why does this libmpcodecs filter list includes some
vf_blackframe.o
vf_cropdetect.o
vf_dsize.o
vf_mirror.o
vf_rectangle.o
vf_rotate.o
they can be droped after a quick speed & feature comparission
Post by Aurelien Jacobs
Also vf_yvu9 is documented as "Deprecated in favor of the software
scaler". So I doubt it is a good idea to keep it.
why is it not droped from mplayer?
Post by Aurelien Jacobs
I also suspect vf_palette might already be handled by libavfilter.
It might also be worth double checking vf_yuvcsp but I guess this one
is not yet supported by libavfilter.
I didn't check the code carefully yet, but I wonder how did you handle
filters like vf_screenshot or vf_hue which require some external
control/command to trigger some actions ?
vf_hue worked when i did a quick test

vf_screensot needs some API amendments on our side, so its WIP
Post by Aurelien Jacobs
I don't think there is any clean API to handle this in libavfilter.
And I don't think vf_screenshot can have any kind of usefullness inside
libavfilter.
taking screenshoots is useful
Post by Aurelien Jacobs
And how did you handle filters like vf_remove_logo which fopen()
an image file and decode it internally, totally ingnoring several layers
of abstraction ?
i dont know what you mean by handle, the filter does what it does. ive not
changed that. Changeing this is completely outside the scope of this patchset
Post by Aurelien Jacobs
I guess it should be handled by simply having a second input pad
allowing the application to feed it with any kind of decoded picture.
Not only would it be alot of work to implement this, it would also make
the use of the filter much more complex.
Post by Aurelien Jacobs
Overall I don't think we should import a whole bunch of filters like
this, without even trying all of them to check if they actually work
and they actally make any sens at all in the libavfilter context.
I tried all before submitting this patchset, i did not spend an hour per filter
for testing.
What i can say is none crashed, none failed assert and filters produced the
expected effect where one was expected which was for many filters without
finding specific input material and and and, no effect so its possible some
do not work completely

What i had hoped was that other people would help me with this and be happy that
i implemented one of the most asked for and important things for libavfilter.


[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
Aurelien Jacobs
2011-01-15 01:26:40 UTC
Permalink
Post by Michael Niedermayer
Post by Aurelien Jacobs
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab & trailing whitespace checkin scripts.
From 34072e13989ebed5e76a425b886b5b17756e6d5d Mon Sep 17 00:00:00 2001
Date: Fri, 14 Jan 2011 05:07:39 +0100
Subject: [PATCH 7/7] Enable libmpcodecs support.
---
libavfilter/Makefile | 65 ++++++++++++++++++++++++++++++++++++++++++++++
libavfilter/allfilters.c | 1 +
2 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fdb181e..0db4750 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -30,6 +30,7 @@ OBJS-$(CONFIG_FREI0R_FILTER) += vf_frei0r.o
OBJS-$(CONFIG_GRADFUN_FILTER) += vf_gradfun.o
OBJS-$(CONFIG_HFLIP_FILTER) += vf_hflip.o
OBJS-$(CONFIG_HQDN3D_FILTER) += vf_hqdn3d.o
+OBJS-$(CONFIG_MP_FILTER) += vf_mp.o
OBJS-$(CONFIG_NOFORMAT_FILTER) += vf_format.o
OBJS-$(CONFIG_NULL_FILTER) += vf_null.o
OBJS-$(CONFIG_OCV_FILTER) += vf_libopencv.o
@@ -54,6 +55,70 @@ OBJS-$(CONFIG_NULLSRC_FILTER) += vsrc_nullsrc.o
OBJS-$(CONFIG_NULLSINK_FILTER) += vsink_nullsink.o
+
+OBJS += libmpcodecs/mp_image.o
+OBJS += libmpcodecs/img_format.o
+OBJS [...]
I guess all those libmpcodecs files should also be added to
OBJS-$(CONFIG_MP_FILTER). I don't think we want them compiled
unconditionally.
i had hoped other people would help but ok fixed locally
[...]
Post by Aurelien Jacobs
IIUC you said that the ultimate goal is to have all those filters
converted to native libavfilter so that we can drop all the libmpcodecs
filters. If so, why does this libmpcodecs filter list includes some
vf_blackframe.o
vf_cropdetect.o
vf_dsize.o
vf_mirror.o
vf_rectangle.o
vf_rotate.o
they can be droped after a quick speed & feature comparission
It is usually the opposite. Code can *get in* after a speed & feature
comparison.
But as you want, as long as those duplicate filters don't stay in the
repository for months.
Post by Michael Niedermayer
Post by Aurelien Jacobs
Also vf_yvu9 is documented as "Deprecated in favor of the software
scaler". So I doubt it is a good idea to keep it.
why is it not droped from mplayer?
Probably because libmpcodec is mostly un-maintained since years, and
that the few person touching it fear removing anything, just in case
somebody might still be using it.
And maybe also to avoid breaking old scripts using "mplayer -vf yvu9".

While we are on the subject, this libmpcodecs warper will probably
also get used in all kinds of scripts. Maybe we should make it clear
from the begining in the user documentation that those filters are
bound to disapear, so people should be prepared to adapt their scripts
later on.
Post by Michael Niedermayer
Post by Aurelien Jacobs
I also suspect vf_palette might already be handled by libavfilter.
It might also be worth double checking vf_yuvcsp but I guess this one
is not yet supported by libavfilter.
I didn't check the code carefully yet, but I wonder how did you handle
filters like vf_screenshot or vf_hue which require some external
control/command to trigger some actions ?
vf_hue worked when i did a quick test
Yes, I guess you can set hue at the begining with a parameter and then
you can't change it dynamically. This is certainly OK for now.
Post by Michael Niedermayer
vf_screensot needs some API amendments on our side, so its WIP
So it's not ready to go in ffmpeg's repository...
Post by Michael Niedermayer
Post by Aurelien Jacobs
I don't think there is any clean API to handle this in libavfilter.
And I don't think vf_screenshot can have any kind of usefullness inside
libavfilter.
taking screenshoots is useful
Yes, it is definitely useful !
But it has nothing to do inside libavfilter !
An application which want to take a screenshot will just grab the
current picture out of the desired sink of the filter graph and encode
it to png (or any codec) using lavc/lavf.
This is much more flexible.
Post by Michael Niedermayer
Post by Aurelien Jacobs
And how did you handle filters like vf_remove_logo which fopen()
an image file and decode it internally, totally ingnoring several layers
of abstraction ?
i dont know what you mean by handle, the filter does what it does. ive not
changed that. Changeing this is completely outside the scope of this patchset
Hum... OK. Just wanted to note that such a filter (or
codec/demuxer/whatever) trying to access directly to a file, bypassing
the avio/protocole layer would never be accepted in any other part of
FFmpeg. But I guess this patchset is a bit special.
Post by Michael Niedermayer
Post by Aurelien Jacobs
I guess it should be handled by simply having a second input pad
allowing the application to feed it with any kind of decoded picture.
Not only would it be alot of work to implement this, it would also make
the use of the filter much more complex.
Probably a bit more complex (but not that much IMHO). But it would also
be much more flexible, allowing any image format (instead of just the
uncommon PGM/PPM), and allowing not only static image but also video
to suppress animated logo.
But I guess it is out of the scope of this patchset and shoud instead be
a goal when porting this filter to native libavfilter.
Post by Michael Niedermayer
Post by Aurelien Jacobs
Overall I don't think we should import a whole bunch of filters like
this, without even trying all of them to check if they actually work
and they actally make any sens at all in the libavfilter context.
I tried all before submitting this patchset, i did not spend an hour per filter
for testing.
What i can say is none crashed, none failed assert
Great ! That's already quite impressive.
Post by Michael Niedermayer
and filters produced the
expected effect where one was expected which was for many filters without
finding specific input material and and and, no effect so its possible some
do not work completely
It would be better to really test if all those filters are working, but
I know it's a huge task. So I guess it is OK to leave to work to
FFmpeg's users...
Post by Michael Niedermayer
What i had hoped was that other people would help me with this and be happy that
i implemented one of the most asked for and important things for libavfilter.
I'm not sure who asked so much for this ?
I guess there is not many ffmpeg developpers excited about the inclusion
of thousands ugly lines of code from MPlayer, with the long term goal
(and huge task) of removing them.
So you may find more happy people about this on FFmpeg-user than on
FFmpeg-devel.

I honestly don't like this patchset much, but I understand the reason
for it, and I have to admit that overall it is quite reasonable (as long
as we make sure that nobody looses his time working on cleaning/fixing
libmpcodecs instead of implementing native libavfilters).

Aurel
Michael Niedermayer
2011-01-15 02:45:09 UTC
Permalink
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Aurelien Jacobs
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab & trailing whitespace checkin scripts.
From 34072e13989ebed5e76a425b886b5b17756e6d5d Mon Sep 17 00:00:00 2001
Date: Fri, 14 Jan 2011 05:07:39 +0100
Subject: [PATCH 7/7] Enable libmpcodecs support.
---
libavfilter/Makefile | 65 ++++++++++++++++++++++++++++++++++++++++++++++
libavfilter/allfilters.c | 1 +
2 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fdb181e..0db4750 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -30,6 +30,7 @@ OBJS-$(CONFIG_FREI0R_FILTER) += vf_frei0r.o
OBJS-$(CONFIG_GRADFUN_FILTER) += vf_gradfun.o
OBJS-$(CONFIG_HFLIP_FILTER) += vf_hflip.o
OBJS-$(CONFIG_HQDN3D_FILTER) += vf_hqdn3d.o
+OBJS-$(CONFIG_MP_FILTER) += vf_mp.o
OBJS-$(CONFIG_NOFORMAT_FILTER) += vf_format.o
OBJS-$(CONFIG_NULL_FILTER) += vf_null.o
OBJS-$(CONFIG_OCV_FILTER) += vf_libopencv.o
@@ -54,6 +55,70 @@ OBJS-$(CONFIG_NULLSRC_FILTER) += vsrc_nullsrc.o
OBJS-$(CONFIG_NULLSINK_FILTER) += vsink_nullsink.o
+
+OBJS += libmpcodecs/mp_image.o
+OBJS += libmpcodecs/img_format.o
+OBJS [...]
I guess all those libmpcodecs files should also be added to
OBJS-$(CONFIG_MP_FILTER). I don't think we want them compiled
unconditionally.
i had hoped other people would help but ok fixed locally
[...]
Post by Aurelien Jacobs
IIUC you said that the ultimate goal is to have all those filters
converted to native libavfilter so that we can drop all the libmpcodecs
filters. If so, why does this libmpcodecs filter list includes some
vf_cropdetect.o
quick test says same speed
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Aurelien Jacobs
vf_dsize.o
vf_rectangle.o
not in svn
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Aurelien Jacobs
vf_blackframe.o
vf_mirror.o
vf_rotate.o
wraped libmpcodec is faster than libavfilter

testing done by looking at the fps value from ffmpeg, differences where
significant (on the order of 5%)
Post by Aurelien Jacobs
Post by Michael Niedermayer
they can be droped after a quick speed & feature comparission
It is usually the opposite. Code can *get in* after a speed & feature
comparison.
But as you want, as long as those duplicate filters don't stay in the
repository for months.
benchmarked them, results are not pretty as above, there is something wrong
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Aurelien Jacobs
Also vf_yvu9 is documented as "Deprecated in favor of the software
scaler". So I doubt it is a good idea to keep it.
why is it not droped from mplayer?
Probably because libmpcodec is mostly un-maintained since years, and
that the few person touching it fear removing anything, just in case
somebody might still be using it.
And maybe also to avoid breaking old scripts using "mplayer -vf yvu9".
suggest on mplayer-dev to remove it, if its really useless it should be
removed from mplayer not just our copy
Post by Aurelien Jacobs
While we are on the subject, this libmpcodecs warper will probably
also get used in all kinds of scripts. Maybe we should make it clear
from the begining in the user documentation that those filters are
bound to disapear, so people should be prepared to adapt their scripts
later on.
All the filters from this are going to disapear one by one as they are ported
to libavfilter
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Aurelien Jacobs
I also suspect vf_palette might already be handled by libavfilter.
It might also be worth double checking vf_yuvcsp but I guess this one
is not yet supported by libavfilter.
I didn't check the code carefully yet, but I wonder how did you handle
filters like vf_screenshot or vf_hue which require some external
control/command to trigger some actions ?
vf_hue worked when i did a quick test
Yes, I guess you can set hue at the begining with a parameter and then
you can't change it dynamically. This is certainly OK for now.
Post by Michael Niedermayer
vf_screensot needs some API amendments on our side, so its WIP
So it's not ready to go in ffmpeg's repository...
Post by Michael Niedermayer
Post by Aurelien Jacobs
I don't think there is any clean API to handle this in libavfilter.
And I don't think vf_screenshot can have any kind of usefullness inside
libavfilter.
taking screenshoots is useful
Yes, it is definitely useful !
But it has nothing to do inside libavfilter !
An application which want to take a screenshot will just grab the
current picture out of the desired sink of the filter graph and encode
it to png (or any codec) using lavc/lavf.
This is much more flexible.
how many applications support it without a explicit filter?
does ffplay?
[...]
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Aurelien Jacobs
Overall I don't think we should import a whole bunch of filters like
this, without even trying all of them to check if they actually work
and they actally make any sens at all in the libavfilter context.
I tried all before submitting this patchset, i did not spend an hour per filter
for testing.
What i can say is none crashed, none failed assert
Great ! That's already quite impressive.
thanks :)
Post by Aurelien Jacobs
Post by Michael Niedermayer
and filters produced the
expected effect where one was expected which was for many filters without
finding specific input material and and and, no effect so its possible some
do not work completely
It would be better to really test if all those filters are working, but
of course

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
Michael Niedermayer
2011-01-15 03:04:00 UTC
Permalink
Post by Michael Niedermayer
Post by Michael Niedermayer
Post by Aurelien Jacobs
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab & trailing whitespace checkin scripts.
From 34072e13989ebed5e76a425b886b5b17756e6d5d Mon Sep 17 00:00:00 2001
Date: Fri, 14 Jan 2011 05:07:39 +0100
Subject: [PATCH 7/7] Enable libmpcodecs support.
---
libavfilter/Makefile | 65 ++++++++++++++++++++++++++++++++++++++++++++++
libavfilter/allfilters.c | 1 +
2 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fdb181e..0db4750 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -30,6 +30,7 @@ OBJS-$(CONFIG_FREI0R_FILTER) += vf_frei0r.o
OBJS-$(CONFIG_GRADFUN_FILTER) += vf_gradfun.o
OBJS-$(CONFIG_HFLIP_FILTER) += vf_hflip.o
OBJS-$(CONFIG_HQDN3D_FILTER) += vf_hqdn3d.o
+OBJS-$(CONFIG_MP_FILTER) += vf_mp.o
OBJS-$(CONFIG_NOFORMAT_FILTER) += vf_format.o
OBJS-$(CONFIG_NULL_FILTER) += vf_null.o
OBJS-$(CONFIG_OCV_FILTER) += vf_libopencv.o
@@ -54,6 +55,70 @@ OBJS-$(CONFIG_NULLSRC_FILTER) += vsrc_nullsrc.o
OBJS-$(CONFIG_NULLSINK_FILTER) += vsink_nullsink.o
+
+OBJS += libmpcodecs/mp_image.o
+OBJS += libmpcodecs/img_format.o
+OBJS [...]
I guess all those libmpcodecs files should also be added to
OBJS-$(CONFIG_MP_FILTER). I don't think we want them compiled
unconditionally.
i had hoped other people would help but ok fixed locally
[...]
Post by Aurelien Jacobs
IIUC you said that the ultimate goal is to have all those filters
converted to native libavfilter so that we can drop all the libmpcodecs
filters. If so, why does this libmpcodecs filter list includes some
vf_cropdetect.o
quick test says same speed
Post by Michael Niedermayer
Post by Aurelien Jacobs
vf_dsize.o
vf_rectangle.o
not in svn
Post by Michael Niedermayer
Post by Aurelien Jacobs
vf_blackframe.o
vf_mirror.o
vf_rotate.o
wraped libmpcodec is faster than libavfilter
testing done by looking at the fps value from ffmpeg, differences where
significant (on the order of 5%)
at least for rotate/transpose this is caused by free/malloc
This likely also is part of why our yadif is slower
i could fix that, well that is if i could finally commit this patchset and be
rid of it

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is not what we do, but why we do it that matters.
Reimar Döffinger
2011-01-15 11:57:50 UTC
Permalink
Post by Michael Niedermayer
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Aurelien Jacobs
Also vf_yvu9 is documented as "Deprecated in favor of the software
scaler". So I doubt it is a good idea to keep it.
why is it not droped from mplayer?
Probably because libmpcodec is mostly un-maintained since years, and
that the few person touching it fear removing anything, just in case
somebody might still be using it.
And maybe also to avoid breaking old scripts using "mplayer -vf yvu9".
suggest on mplayer-dev to remove it, if its really useless it should be
removed from mplayer not just our copy
I do not know about this specifially, but usually there is one very special
corner-case that is not 100% (or only in a suboptimal way) implementable
using the other filter.
Usually that kind of thing is only changed if there is an issue with that filter,
otherwise there's not that much reason to make an effort to remove it.
Post by Michael Niedermayer
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Aurelien Jacobs
I also suspect vf_palette might already be handled by libavfilter.
It might also be worth double checking vf_yuvcsp but I guess this one
is not yet supported by libavfilter.
I didn't check the code carefully yet, but I wonder how did you handle
filters like vf_screenshot or vf_hue which require some external
control/command to trigger some actions ?
vf_hue worked when i did a quick test
Yes, I guess you can set hue at the begining with a parameter and then
you can't change it dynamically. This is certainly OK for now.
Not sure what exactly you meant to say, but within MPlayer VFCTRL_SET_EQUALIZER
handles setting hue.
For a player such a control that is handled by whatever filter can handle it
has the advantage that runtime changes will be handled in the most efficient
way possible without the need for user configuration, for libavfilter that
approach is likely too unpredictable though.
Michael Niedermayer
2011-01-15 13:11:28 UTC
Permalink
[...]
Post by Reimar Döffinger
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Aurelien Jacobs
I also suspect vf_palette might already be handled by libavfilter.
It might also be worth double checking vf_yuvcsp but I guess this one
is not yet supported by libavfilter.
I didn't check the code carefully yet, but I wonder how did you handle
filters like vf_screenshot or vf_hue which require some external
control/command to trigger some actions ?
vf_hue worked when i did a quick test
Yes, I guess you can set hue at the begining with a parameter and then
you can't change it dynamically. This is certainly OK for now.
Not sure what exactly you meant to say, but within MPlayer VFCTRL_SET_EQUALIZER
handles setting hue.
For a player such a control that is handled by whatever filter can handle it
has the advantage that runtime changes will be handled in the most efficient
way possible without the need for user configuration, for libavfilter that
approach is likely too unpredictable though.
i see nothing unpredictable on it

A command can just be sent through the filter graph like in mplayer
a split filter would sent it down both ways, a merge filter would just pass
commands from the main source or would have to inteligently combine them
a TTL value in a command would prevent loops

It also should be easy to implement this

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
Reimar Döffinger
2011-01-15 20:01:42 UTC
Permalink
Post by Michael Niedermayer
[...]
Post by Reimar Döffinger
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Aurelien Jacobs
I also suspect vf_palette might already be handled by libavfilter.
It might also be worth double checking vf_yuvcsp but I guess this one
is not yet supported by libavfilter.
I didn't check the code carefully yet, but I wonder how did you handle
filters like vf_screenshot or vf_hue which require some external
control/command to trigger some actions ?
vf_hue worked when i did a quick test
Yes, I guess you can set hue at the begining with a parameter and then
you can't change it dynamically. This is certainly OK for now.
Not sure what exactly you meant to say, but within MPlayer VFCTRL_SET_EQUALIZER
handles setting hue.
For a player such a control that is handled by whatever filter can handle it
has the advantage that runtime changes will be handled in the most efficient
way possible without the need for user configuration, for libavfilter that
approach is likely too unpredictable though.
i see nothing unpredictable on it
Let me explain: hue adjustments could be done for free for yuv<->rgb conversions.
This combined with above approach means that the results of the VFCTRL_SET_EQUALIZER will
mean that if you have
-vf swapuv
the behaviour off hue adjustment will be completely different for a RGB vs. a YUV
codec because for RGB you have the filters
scale(convert to yuv), swapuv, output
here hue adjustement would be done in scale, before swapuv.
With YUV input you'd only have
swapuv, output
and thus hue would be adjusted in output, i.e. after swapuv.
Michael Niedermayer
2011-01-15 22:10:36 UTC
Permalink
Post by Reimar Döffinger
Post by Michael Niedermayer
[...]
Post by Reimar Döffinger
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Aurelien Jacobs
I also suspect vf_palette might already be handled by libavfilter.
It might also be worth double checking vf_yuvcsp but I guess this one
is not yet supported by libavfilter.
I didn't check the code carefully yet, but I wonder how did you handle
filters like vf_screenshot or vf_hue which require some external
control/command to trigger some actions ?
vf_hue worked when i did a quick test
Yes, I guess you can set hue at the begining with a parameter and then
you can't change it dynamically. This is certainly OK for now.
Not sure what exactly you meant to say, but within MPlayer VFCTRL_SET_EQUALIZER
handles setting hue.
For a player such a control that is handled by whatever filter can handle it
has the advantage that runtime changes will be handled in the most efficient
way possible without the need for user configuration, for libavfilter that
approach is likely too unpredictable though.
i see nothing unpredictable on it
Let me explain: hue adjustments could be done for free for yuv<->rgb conversions.
This combined with above approach means that the results of the VFCTRL_SET_EQUALIZER will
mean that if you have
-vf swapuv
the behaviour off hue adjustment will be completely different for a RGB vs. a YUV
codec because for RGB you have the filters
scale(convert to yuv), swapuv, output
here hue adjustement would be done in scale, before swapuv.
With YUV input you'd only have
swapuv, output
and thus hue would be adjusted in output, i.e. after swapuv.
yes but where is the difference between mplayer-libmpcodec and ffplay-libavfilter
here?
you said "for libavfilter that approach is likely too unpredictable though."

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
Reimar Döffinger
2011-01-15 22:23:23 UTC
Permalink
Post by Michael Niedermayer
Post by Reimar Döffinger
Post by Michael Niedermayer
i see nothing unpredictable on it
Let me explain: hue adjustments could be done for free for yuv<->rgb conversions.
This combined with above approach means that the results of the VFCTRL_SET_EQUALIZER will
mean that if you have
-vf swapuv
the behaviour off hue adjustment will be completely different for a RGB vs. a YUV
codec because for RGB you have the filters
scale(convert to yuv), swapuv, output
here hue adjustement would be done in scale, before swapuv.
With YUV input you'd only have
swapuv, output
and thus hue would be adjusted in output, i.e. after swapuv.
yes but where is the difference between mplayer-libmpcodec and ffplay-libavfilter
here?
you said "for libavfilter that approach is likely too unpredictable though."
That libavfilter is supposed to be more general.
I realize that I forgot that it is possible to send a VFCTRL to a specific
filter if you know you want to change exactly that one.
Still, since libavfilter is a reimplementation thinking of a design that
allows avoiding this issue would make sense I'd say.
Anyway, that has nothing to do with the original issue, for which we
can just say at least inside MPlayer the hue etc. filters can be adjusted
dynamically (I haven't looked at your patch I admit).
Michael Niedermayer
2011-01-15 23:15:03 UTC
Permalink
Post by Reimar Döffinger
Post by Michael Niedermayer
Post by Reimar Döffinger
Post by Michael Niedermayer
i see nothing unpredictable on it
Let me explain: hue adjustments could be done for free for yuv<->rgb conversions.
This combined with above approach means that the results of the VFCTRL_SET_EQUALIZER will
mean that if you have
-vf swapuv
the behaviour off hue adjustment will be completely different for a RGB vs. a YUV
codec because for RGB you have the filters
scale(convert to yuv), swapuv, output
here hue adjustement would be done in scale, before swapuv.
With YUV input you'd only have
swapuv, output
and thus hue would be adjusted in output, i.e. after swapuv.
yes but where is the difference between mplayer-libmpcodec and ffplay-libavfilter
here?
you said "for libavfilter that approach is likely too unpredictable though."
That libavfilter is supposed to be more general.
I realize that I forgot that it is possible to send a VFCTRL to a specific
filter if you know you want to change exactly that one.
Still, since libavfilter is a reimplementation thinking of a design that
allows avoiding this issue would make sense I'd say.
Any suggestions?

To me the mplayer system seems quite solid and simple

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is not what we do, but why we do it that matters.
Reimar Döffinger
2011-01-15 23:24:28 UTC
Permalink
Post by Michael Niedermayer
Post by Reimar Döffinger
Still, since libavfilter is a reimplementation thinking of a design that
allows avoiding this issue would make sense I'd say.
Any suggestions?
To me the mplayer system seems quite solid and simple
Just going through in reverse direction and testing for support of it might work,
then filters like swapuv could signal something like "sorry, I'm not
commutative with that, try further below in the chain at your own risk".
However it seems like quite some effort for all filters to signal that
correctly.
Aurelien Jacobs
2011-01-15 20:29:28 UTC
Permalink
Post by Michael Niedermayer
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Aurelien Jacobs
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Please dont bikeshed this to death.
Ahh before i can commit this, libmpcodecs and subdirectories must not get
blocked by the tab & trailing whitespace checkin scripts.
From 34072e13989ebed5e76a425b886b5b17756e6d5d Mon Sep 17 00:00:00 2001
Date: Fri, 14 Jan 2011 05:07:39 +0100
Subject: [PATCH 7/7] Enable libmpcodecs support.
---
libavfilter/Makefile | 65 ++++++++++++++++++++++++++++++++++++++++++++++
libavfilter/allfilters.c | 1 +
2 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fdb181e..0db4750 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -30,6 +30,7 @@ OBJS-$(CONFIG_FREI0R_FILTER) += vf_frei0r.o
OBJS-$(CONFIG_GRADFUN_FILTER) += vf_gradfun.o
OBJS-$(CONFIG_HFLIP_FILTER) += vf_hflip.o
OBJS-$(CONFIG_HQDN3D_FILTER) += vf_hqdn3d.o
+OBJS-$(CONFIG_MP_FILTER) += vf_mp.o
OBJS-$(CONFIG_NOFORMAT_FILTER) += vf_format.o
OBJS-$(CONFIG_NULL_FILTER) += vf_null.o
OBJS-$(CONFIG_OCV_FILTER) += vf_libopencv.o
@@ -54,6 +55,70 @@ OBJS-$(CONFIG_NULLSRC_FILTER) += vsrc_nullsrc.o
OBJS-$(CONFIG_NULLSINK_FILTER) += vsink_nullsink.o
+
+OBJS += libmpcodecs/mp_image.o
+OBJS += libmpcodecs/img_format.o
+OBJS [...]
I guess all those libmpcodecs files should also be added to
OBJS-$(CONFIG_MP_FILTER). I don't think we want them compiled
unconditionally.
i had hoped other people would help but ok fixed locally
[...]
Post by Aurelien Jacobs
IIUC you said that the ultimate goal is to have all those filters
converted to native libavfilter so that we can drop all the libmpcodecs
filters. If so, why does this libmpcodecs filter list includes some
vf_cropdetect.o
quick test says same speed
Good, so no need to include it.
Post by Michael Niedermayer
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Aurelien Jacobs
vf_dsize.o
vf_rectangle.o
not in svn
I havn't compared the feature set in detail, but vf_dsize looks similar
to setdar, and vf_rectangle looks similar to drawbox.
Post by Michael Niedermayer
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Aurelien Jacobs
vf_blackframe.o
vf_mirror.o
vf_rotate.o
wraped libmpcodec is faster than libavfilter
testing done by looking at the fps value from ffmpeg, differences where
significant (on the order of 5%)
That way you can already show one concrete interest about libmpcodecs
wrapper. It allows to detect some week points in libavfilter. Good !
Post by Michael Niedermayer
Post by Aurelien Jacobs
Post by Michael Niedermayer
Post by Aurelien Jacobs
Also vf_yvu9 is documented as "Deprecated in favor of the software
scaler". So I doubt it is a good idea to keep it.
why is it not droped from mplayer?
Probably because libmpcodec is mostly un-maintained since years, and
that the few person touching it fear removing anything, just in case
somebody might still be using it.
And maybe also to avoid breaking old scripts using "mplayer -vf yvu9".
suggest on mplayer-dev to remove it, if its really useless it should be
removed from mplayer not just our copy
I won't waste any of my time trying to fix/cleanup/improve libmpcodecs.
If I had time to work on filters, I would spend it on native
libavfilter.
That's also what makes me fear that this libmpcodecs wrapper will rot
here forever.
Post by Michael Niedermayer
Post by Aurelien Jacobs
Post by Michael Niedermayer
vf_screensot needs some API amendments on our side, so its WIP
So it's not ready to go in ffmpeg's repository...
Post by Michael Niedermayer
Post by Aurelien Jacobs
I don't think there is any clean API to handle this in libavfilter.
And I don't think vf_screenshot can have any kind of usefullness inside
libavfilter.
taking screenshoots is useful
Yes, it is definitely useful !
But it has nothing to do inside libavfilter !
An application which want to take a screenshot will just grab the
current picture out of the desired sink of the filter graph and encode
it to png (or any codec) using lavc/lavf.
This is much more flexible.
how many applications support it without a explicit filter?
does ffplay?
Most probably none.
But AFAIU vf_screenshot don't support it either in current libavfilter
framework, so it's not better in any way...

Aurel
Carl Eugen Hoyos
2011-01-15 09:26:03 UTC
Permalink
Post by Aurelien Jacobs
Post by Michael Niedermayer
What i had hoped was that other people would help me with this and be happy
that i implemented one of the most asked for and important things for
libavfilter.
I'm not sure who asked so much for this ?
(That's the problem with developers not reading every userlist)
I can confirm that this is exactly what users asked for, I haven't seen a
request for a win32 library loader in a long time.

Carl Eugen
Benjamin Larsson
2011-01-16 02:37:42 UTC
Permalink
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Ok, here is my take on this.

Add a new configure flag that must be explicitly enabled. Whenever a
libmpcodecs filter is enabled print out that it is unsupported and might
change at any time (ie filter ported to libavfilter). Just add a subset
of the filters (ie the most commonly used ones). Then for GSoC we can
have filter porting as projects or qualification tasks. This will give
most users what they want and developers will have a quantifiable amount
of code that we have to take care of. And we get a plan for moving the
code to libavfitler.

MvH
Benjamin Larsson
Michael Niedermayer
2011-01-16 03:20:20 UTC
Permalink
Post by Benjamin Larsson
Post by Michael Niedermayer
Hi
Attached patchset makes libavfilter support most libmpcodecs filters
The libmpcodecs filters are practically unmodified and for keeping it
maintainable id like to keep them unmodified.
I will commit this soon but wont enable it yet. That way others can help
cleanup the wraper (minus code that for maintainability should stay identical
to the original), fix bugs, rename all global functions so they wont conflict
with mplayers if they ever include this and generally help.
Ok, here is my take on this.
Add a new configure flag that must be explicitly enabled. Whenever a
Iam thinking the existing --enable flag for the avfilter is reliable working
anyway my first patch was planned to omit the makefile part so i think
this is not applicable
Post by Benjamin Larsson
libmpcodecs filter is enabled print out that it is unsupported and might
Ill do customer support (for a fee)
Post by Benjamin Larsson
change at any time (ie filter ported to libavfilter).
Will add appropriate message
Post by Benjamin Larsson
Just add a subset
of the filters (ie the most commonly used ones).
will do


[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
Michael Niedermayer
2011-01-21 00:40:50 UTC
Permalink
On Fri, Jan 14, 2011 at 05:37:45AM +0100, Michael Niedermayer wrote:

A variant of this patchset has been applied

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
compn
2011-01-21 02:50:20 UTC
Permalink
Post by Michael Niedermayer
A variant of this patchset has been applied
does it have to be marked gpl in the configure?

-compn
Michael Niedermayer
2011-01-21 13:22:17 UTC
Permalink
Post by compn
Post by Michael Niedermayer
A variant of this patchset has been applied
does it have to be marked gpl in the configure?
oops yes, fixed

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
Continue reading on narkive:
Loading...