[MPlayer-dev-eng] [PATCH] vd_null to output black frames

[Reimar Döffinger]

On Sun, Oct 07, 2012 at 03:13:32PM +0800, Xidorn Quan wrote:
> On Thu, Oct 4, 2012 at 8:30 PM, Xidorn Quan <quanxunzhen at gmail.com> wrote:
> 
> > On Tue, Oct 2, 2012 at 2:28 AM, Reimar Döffinger <Reimar.Doeffinger at gmx.de
> > > wrote:
> >
> >> On Fri, Sep 28, 2012 at 08:34:38AM +0800, Xidorn Quan wrote:
> >> > On Fri, Sep 28, 2012 at 3:53 AM, Reimar Döffinger
> >> > <Reimar.Doeffinger at gmx.de>wrote:
> >> >
> >> > > On 27 Sep 2012, at 16:35, Xidorn Quan <quanxunzhen at gmail.com> wrote:
> >> > > > Some modifies to this patch.
> >> > > >
> >> > > > On Thu, Sep 27, 2012 at 4:06 PM, Xidorn Quan <quanxunzhen at gmail.com
> >> >
> >> > > wrote:
> >> > > >
> >> > > >> Hi,
> >> > > >>
> >> > > >> This patch makes vd_null return black frames for various image
> >> format
> >> > > >> instead of only NULL.
> >> > >
> >> > > Obvious question: why? The purpose of it is to provide _no_ video, and
> >> > > that as quickly as possible. As far as I can tell, your patch actually
> >> > > "breaks" both of them.
> >> > > I suspect you want to use it for something it was not meant for. In
> >> that
> >> > > case it might be better to add a new decoder.
> >> > >
> >> >
> >> > When you need no video at all, you must always use both -vc null and
> >> > -vo null. It still works this way. And here it staictly creates
> >> > the buffer when initialized, so it wouldn't be slower a lot.
> >>
> >> As far as I can tell you only need -vo null if the goal is to not have
> >> a video window.
> >> However even -vo null doesn't change that if someone has a complex
> >> filter chain "-vc null -vo null" as far as I can see will cause a
> >> significant CPU usage after your patch because the filters will process
> >> every single frame.
> >> We do recommend this combination in quite a few places in the
> >> documentation to do something fast, without video processing,
> >> if it no longer works for that the documentation at the very least
> >> needs to be updated.
> >> Though as I said, I think a separate vd would be preferable.
> >> (as a different example of what changes, -vo png will behave a lot
> >> different after your patch I believe)
> >>
> >> > The description for vd_null is no decoding. It still does no decoding
> >> > in this patch, therefore I do not think it should be divided into a
> >> > separate decoder.
> >>
> >> I guess the little documentation we have isn't much help.
> >> But my point is that "no decoding, producing black output frames" and
> >> "no decoding, no output frames" are two different things that have
> >> different uses.
> >>
> >> > It outputs black frames so that it will not break any other vo besides
> >> > vo_null, and therefore we can insert vfs in to test them without
> >> > decoding video.
> >>
> >> Ok, that is a nice thing to have. It's just that changing vd_null
> >> IMHO isn't quite compatible with our current documented usage
> >> of -vc null -vo null as a workaround for -novideo not working.
> >>
> >
> > Ok, in the patch attached I add a switch in vd_null so that it won't
> > break the current usage, and it also enables it to output black frames
> > when use -vc nullblack instead of -vc null.
> >
> > Btw.: We usually consider better to instead of
> >> > memset(ctx, 0, sizeof(vd_null_ctx));
> >> use
> >> > memset(ctx, 0, sizeof(*ctx));
> >> etc.
> >
> Ping. Is the new patch ok?

Sorry, I'm travelling, and won't be able to apply in the
next few days, but if someone else wants feel free.
I think it's ok, even though I would have slightly preferred to
keep vd_null as a simple trivial example and make a completely
separate vd_black or similar filter.