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

[Alexander Strasser]

Alexander Strasser wrote:
> Xidorn Quan wrote:
> > On Fri, Nov 2, 2012 at 4:56 AM, Reimar Döffinger wrote: 
> > > On Thu, Nov 01, 2012 at 09:51:09PM +0100, Alexander Strasser wrote:
> > > >
> > > >   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.
> 
>   OK, thanks for explaining your motivations. Combined this gives
> good reason to use the name "dummy". Some other name that came
> to my mind is "fake" which probably more accurately describes the
> nature of those "codecs". (But maybe it sounds to negative?) 
> 
>   To restate it I am not against using "dummy". Never was.
> 
>   I also like Xidorn's idea of never choosing the decoder because it
> is flagged "dummy" and having the status set to "working" again for
> null and black. It would eliminate the misuse of the status property.
> 
>   Reimar, what do you think?

  Attached is a *not* very well tested RFC patch to implement the
behavior Xidorn described above. It must be applied incrementally
on top of Xidorn's patch.

  I am unsure if this change of behavior has any additional (high
level) consequences I am not aware of.

  Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-RFC-libmpcodecs-Only-choose-dummy-codecs-if-forced.patch
Type: text/x-diff
Size: 2808 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20121103/69a7b323/attachment.bin>