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

[Xidorn Quan]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer_vd_null.patch
Type: application/octet-stream
Size: 5284 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20121004/15fbc9ad/attachment.obj>