On Thu, May 13, 2010 at 01:05:58PM -0700, Baptiste Coudurier wrote:
Hi,
On 05/12/2010 02:33 PM, Michael Niedermayer wrote:
On Wed, May 12, 2010 at 09:00:46AM +0200, Vitor Sessak wrote:
Baptiste Coudurier wrote:
On 12/06/2009 08:12 AM, Vitor Sessak wrote:
Hi and sorry for the delay.
Artur Bodera wrote:
On Tue, Dec 1, 2009 at 12:50 AM, Vitor Sessakvitor1...@gmail.com
wrote:
While I normally oppose making non-committed code more complex, I
think
this feature is so often requested that it is worth the extra work in
the
future. Stefano, Michael, any strong opinion about this?
I think the vf_overlay should be modified altogether. Although
mathematically alpha-blending is more expensive than opaque pixel
replacement, I think that it should be automatically decided by
analyzing
the overlay format.
So the alpha-blending should be a built-in functionality (not a
switchable
parameter) and should be implicitly functional with any overlay
stream/image
that has alpha channel (i.e. rgba). If there is no alpha channel, then
pixel
overriding would be used. This makes much more sense.
I agree that this would be nice, but there is no way to make it work
with the current format negotiation in libavfilter. For example, there
is no way to have a filter that accepts either input: rgb, output
rgba
or input: yuv, output: yuva, so I suggest you just do as your present
patch for the time been.
How much harm does doing yuv - yuva or rgb - rgba in all cases ?
To my knowledge it would only be a matter of adding one component and
memset it to 0xff.
This wouldn't do much harm, but there is no way of asking for such kind
of
inputs in lavfi (i.e., either rgb,rgba or yuv,yuva). And changing
lavfi
to accept such constraints would probably make colospace negotiation a NP
problem.
finding a solution with a minimum of convertion could become NP, finding
any
solution wont
heres a quick option (i do not know how good / bad this suggestion is,
if someone like loren could look at this before its implemented this
would probably be a good idea)
1. we extend query_format to query_format(int alternative) where
alternative
selects which of several (small number normally and for most filters just
1)
alternative colorspace lists each link supports.
Euch such alternative is like the current case that is 2 links either must
have the same list of possible pixelformats/colorspaces or they are
independant.
2. we run the current avfiltergraph.c query_formats() over the graph
skiping
all filters that have alternatives.
3. we go over all filters that have alternatives
for each such filter we find the 2 best alterantives, best based on
score= (A32) + B;
A= the number of scale filters the specific alterantive would require
B= the number of degrees of freedom lost (aka fewer colorspaces)
we then calculate a score2 that is the difference of the scores of
the best 2 alterantives.
And last lock in filter alterantives iteratively based on best score2
The idea here is that we lock in the filter with the most clearly
supperior
alterantive first. That is if we have a filter that has 2 alterantives and
neither on its own would require an additional convertion filter and
another
filter that also has 2 alternatives and one of these would require 1
convertion and the other case would require 2 convertions then the 1
convertion alternative would be locked in and we would restart from the
begin
This is not optimal, not even for a simple linear filter chain with 2
filters.
But it might be an acceptable heuristic for real filter graphs.
For a single linear chain its possible to find the optimal case with
viterbi
Another method would be to only use avfiltergraph.c query_formats() and
consider all the alternative values inputs to it and the number of
convertions
and degrees of freedom left over the whole graph its score. And then use
some
generic optimization technique that minimizes this score.
btw, off topic a little but simply favoring the first colorspace in each
list like its done in svn is not a good idea, it likely would make more
sense to favor a colorspace that preserves all information that is there
and is simple. that is if either upstream or downstream is greyscale we
shouldnt select yuv similar issues exist with 16/8 bit and rgb/yuv and
alpha
Question, why not using a pull paradigm from the output filter ?
Its not enough on its own.
it has exponential complexity per graph size for some filter graphs.
the issue is that a filter with multiple inputs cant just pull each
idenpandantly. They might very well have a common source filter or a
feedback path which can lead to complex dependancies.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
signature.asc
Description: Digital
