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

[Stefan Schuermans]

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.

> So I actually did all this.
> I expect/hope that your RGB patch should be trivial to implement on
> top of it now.

Wow, you did all of the work, I only had to extend the properties array
and change one line - besides testing. Thanks a lot.

> I'd do it myself, but the blinkenlights simulator I have at hand does not
> (yet?) support RGB.

I do not know if the official Blinkenlights simulator will ever support
that, but there's a bunch of people using those protocols for their
small Blinkenlights replicas built with LEDs. You can find a very simple
Blinkenlights protocol simulator accepting all resolutions in both color
and grayscale here:
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.

> About the double-buffering change it might be better to delay it, I have
> some concerns it might cause issues if trying to seamlessly play multiple
> files (requires -fixed-vo of course), it's easy to end up with a dropped
> frame or a black frame that should not be there.

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.

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

Best regards,
Stefan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: MPlayer-svn20140118-bl_copyright_fix.diff
Type: text/x-patch
Size: 542 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20140118/99b5398d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MPlayer-svn20140118-bl_rgb_support.diff
Type: text/x-patch
Size: 979 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20140118/99b5398d/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MPlayer-svn20140118-bl_comment_bpp_fix.diff
Type: text/x-patch
Size: 410 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20140118/99b5398d/attachment-0002.bin>