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

[Reimar Döffinger]

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.

Btw.: We usually consider better to instead of
> memset(ctx, 0, sizeof(vd_null_ctx));
use
> memset(ctx, 0, sizeof(*ctx));
etc.