[MPlayer-dev-eng] [PATCH] Color Support for Blinkenlights Output Module

[Reimar Döffinger]

On Sat, Jan 18, 2014 at 07:31:31PM +0100, Stefan Schuermans wrote:
> Hello Reimar,
> 
> On 18.01.2014 15:13, Reimar Döffinger wrote:
> > On 17.01.2014, at 19:46, Stefan Schuermans <stefan at blinkenarea.org> wrote:
> >> [...]
> >> Are there any further comments regarding my patch?
> > 
> > I admit I didn't say this (too used to it), but I really didn't want it
> > all in one patch.
> 
> Oh, sorry, my mistake. Now as you mention it, I completely understand
> that it did not make much sense to pack everything into one patch.
> 
> > Also it didn't really go as far as I wanted, in particular things like
> > supporting the proper draw_image API and requesting luma-only instead of YV12.
> 
> Hm, I do not have a very deep understanding of the MPlayer structure and
> the APIs. I have to admit that I just looked up how vo_gif is getting
> the RGB data. Maybe this is not the best example.

There are a lot of bad examples around.
And I didn't really expect you to figure this out, but since I didn't
have any time I decided it wouldn't hurt to try and see what comes out
of it ;-)
Hope I didn't waste your time.

> http://stefan.blinkenarea.org/BlinkenStreamView/BlinkenStreamView-0.1.2_20140118.tar.xz
> I'm afraid you won't like the code (I wrote it in 2005, I do not like it
> myself anymore), but it is still compiling and working (at least on
> Debian wheezy). If you want to use it with MPlayer, please ignore the
> stuff about "requests" in the GUI, it is not used with MPlayer.

For code I don't have to maintain it's enough if it works :-)
But I won't have time, there are a lot of other things to fix,
and blinkenlights is not exactly the most used part of MPlayer.

> I think the double buffering as I tried to implement it should not have
> changed the behaviour concerning frame dropping or insertion at the
> beginning or end. At least the example videos I tried wrote identical
> bml files, but I did not try -fixe-vo and multiple videos at once. I
> appreciate your decision to delay this.

Yeah, it should only happen in this combination. Well, I am not sure,
but at least in theory the current code could display the last frame
of the previous video when it starts playing the next one.
Though honestly the whole thing is an API issue: if it could get the
amount of time a frame should be shown it wouldn't need to have this
one-frame delay.
Yet again, if the UDP packet wouldn't have to contain the _current_
frame's duration it wouldn't be an issue, and requiring the current
frame duration is an issue since e.g. in case of a live slide show it
would never be known.
So I kind of blame blinkenlights for deciding on an API that needs
information that just isn't available in general.

> I have attached 3 patch files:
> comment_bpp_fix - fixes a comment line about bits-per-component/pixel
> copyright_fix - fixes the copyright, Rik wrote most of the file, not me
> rgb_support - adds RGB support

All committed (the fixed one for RGB of course).