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

[Xidorn Quan]

On Fri, Nov 2, 2012 at 4:56 AM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de>wrote:

> On Thu, Nov 01, 2012 at 09:51:09PM +0100, Alexander Strasser wrote:
> > Hi,
> >
> > Reimar Döffinger wrote:
> > > On Wed, Oct 31, 2012 at 03:41:53PM +0800, Xidorn Quan wrote:
> > > > On Tue, Oct 16, 2012 at 2:26 PM, Reimar Döffinger wrote:
> > > > > On 15 Oct 2012, at 21:48, Alexander Strasser <eclipse7 at gmx.net>
> wrote:
> > > > > >
> > > > > >  Done and committed.
> > > > >
> > > > > Thanks for taking care of it.
> > > > > Btw. it might make sense to point to the special-case null and
> black
> > > > > strcmp code from the codecs.conf entries, since it is related to
> why a
> > > > > codec entry without any fourccs even makes sense.
> > > > > Alternatively, having a flag in the codec structure to indicate
> such
> > > > > "dummy" codecs might make it more obvious, too.
> > > > >
> > > >
> > > > The patch attached adds a flag for dummy codecs. Is it ok?
> > >
> > > I had actually thought making it a flag in the codec struct in the
> vd_*.c file,
> > > but I think I actually like your idea better :-)
> > > So, looks fine to me.
> >
> >   I was thinking if "dummy" is expressive enough as a name for a
> configuration
> > flag. Would "ignore_fourcc" be easier to understand for someone reading
> codecs.conf?
> >
> >   I do not particularly care about the naming but I do like the patch.
> So please
> > do not understand this as a blocking issue. Just wanted to find out what
> other
> > developers think.
>
> It's more that I thought we might want to use it for other stuff, for
> example not bothering with copying around the actual data of the
> packets, or running a parser in certain cases or such.
> Which is why I'd currently be more in favour of "dummy" than something
> specific.
> But I don't dare to try to predict if that will really make sense in the
> long run.
>

In my opinion, a "dummy" codec is such a codec created for testing,
demonstrating, or whatever, so it should never be chosen if not be
forced by user. For which, we mark them as "crashing" at present, but
actually, both null and black are working as expected accurately.
I prefer to mark them "working" with the flag "dummy", and prevent
a codec flagged that to be chosen when it is not forced.

I agree that "ignore_fourcc" is a more expressive name for the
behavior in my patch. However, if we make the "dummy" flag work as
what I have mentioned above, we do not need the "ignore_fourcc" flag
anymore, since user is responsible for taking care of fourcc if he
forces such codecs.