[FFmpeg-cvslog] Support changing pixel formats on avfilter input.

[Michael Niedermayer]

On Mon, Apr 04, 2011 at 12:21:12PM +0200, Stefano Sabatini wrote:
> On date Monday 2011-04-04 11:52:43 +0200, Michael Niedermayer wrote:
> > On Mon, Apr 04, 2011 at 10:59:50AM +0200, Stefano Sabatini wrote:
> > > On date Monday 2011-04-04 03:15:04 +0200, Michael Niedermayer wrote:
> > > > On Sun, Apr 03, 2011 at 08:11:40PM +0200, Stefano Sabatini wrote:
> > > > > On date Sunday 2011-04-03 18:20:09 +0200, Michael Niedermayer wrote:
> > > > > > ffmpeg | branch: master | Michael Niedermayer <michaelni at gmx.at> | Wed Mar  9 15:13:59 2011 +0100| [7d948dc424c3620e351d27afdf933c99f9435467] | committer: Michael Niedermayer
> > > > > > 
> > > > > > Support changing pixel formats on avfilter input.
> > > > > > Fix issue2217
> > > > > > Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> > > > > > 
> > > > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=7d948dc424c3620e351d27afdf933c99f9435467
> > > > > > ---
> > > > > > 
> > > > > >  ffmpeg.c                  |    5 ++-
> > > > > >  libavfilter/vsrc_buffer.c |   53 +++++++++++++++++++++++++++++++++++++++++++-
> > > > > >  libavfilter/vsrc_buffer.h |    4 +++
> > > > > >  3 files changed, 58 insertions(+), 4 deletions(-)
> > > > > 
> > > > > Please revert this, this is not the proper way to fix it (and is
> > > > > introducing several design problems).
> > > > 
> > > > elaborate please
> > > > i know this isnt ideal but ideal is not going to happen anytime soon
> > > > and this works the code before crashed
> > > 
> > > It is adding a dependency on libswscale to vsrc_buffer
> > 
> > Is libavfilter usefull without swscale?
> 
> It depends on what you mean by "useful". If you are on Mars, your life
> depends on this tiny micro device with 200KB of RAM doing its
> filtering work (and no need for fancy libswscale), yes libavfilter
> with no scale is useful.

my tiny usb stick has 8gb
and once ffspaceship is ready all tiny devices should have more


> 
> But the point here is different, vsrc_buffer is no special so if you
> add a scale there then you should add the same in the other
> sources. The proper solution is fixing the problem at the framework
> level, rather than in each source.
> 
> > That is a video filter framework without the ability to convert between
> > pixel formats and thus without the ability to connect some filters
> > when they dont support a common format?
> > 
> > We can of course put the code under #if CONFIG_SWSCALE ...
> 
> > 
> > 
> > > 
> > > It is extending a problematic API (and thus breaking my vsrc_buffer patches)
> > 
> > yes, that can be fixed though
> > 
> > 
> > > 
> > > It's not the proper way to fix it, this should be done by implementing
> > > filterchain re-configuration rather than adding an hack in a random
> > 
> > 
> > > source. I don't mind if you add the code to ffmpeg.c, but extending a
> > > public interface this way is not acceptable IMO.
> > 
> > All applications need this code, ffplay for example needs it too and
> > doesnt have it currently.
> > So whichever way it is implemented, IMHO it should be in libavfilter
> > and not duplicated in each application
> > 
> > Also filter chain reconfiguration alone
> > does not solve the bug, applications still would need to inject a
> > scale filter to ensure the output doesnt change.
> 
> This can be easily done by adding a fixed scale at the end of the
> filterchain.

this has a problem, you can have a heap of jpeg images and they can
have differing colorspaces, you might want to have a fade filter fade
from one to the next. This doesnt work if the whole chain is
reconfigured as the filter state (containing the previous image) is
lost.
The second issue is once we have multiple inputs one input might
frequently change, lets say its a picture in picture filter and a
video of a commentator that comments various "news videos"
if in this scenario the filter graph is reconfigured each time the
video changes it will break every filter that has some state, like
deinterlace filters, ...
making the format consistent on input without reconfig works better in
this use case



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

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-cvslog/attachments/20110404/a243f13f/attachment.asc>