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

[Xidorn Quan]

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?