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

[Reimar Döffinger]

On 17.01.2014, at 19:46, Stefan Schuermans <stefan at blinkenarea.org> wrote:
> Hello all,
> 
> On 02.01.2014 14:58, Stefan Schuermans wrote:
>> On 29.12.2013 23:29, Reimar Döffinger wrote:
>>> On Sun, Dec 29, 2013 at 08:29:44PM +0100, Stefan Schuermans wrote:
>>>> +               VFCAP_ACCEPT_STRIDE;
>>> 
>>> This seems kind of unrelated?
>> 
>> I added VFCAP_ACCEPT_STRIDE to make mplayer call draw_slice also for RGB
>> format, so I can reuse the code already present in this function.
> 
> [...]
> 
>>> (slightly unrelated): Strangely, it seems that many allocations use a multiplication by a
>>> constant "3" which seems a bit strange.
>> 
>> [...] I have now changed it to just allocate the memory needed.
>> 
>>> Same applies to some memset/memcpys. Completely unrelated, I wonder why flip_page introduces a full 1 frame delay,
>>> and even uses a full memcpy to do so.
>> 
>> I have converted the code to double-buffering.
>> 
>> Double buffering is needed because the file output has to write the
>> duration first and then the frame data. [...]
>> 
>>> I suspect that a bit of code cleanup wouldn't hurt, [...]
>> 
>> I tried to do some cleanup. [...]
> 
> 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.
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.
So I actually did all this.
I expect/hope that your RGB patch should be trivial to implement on top of it now.
I'd do it myself, but the blinkenlights simulator I have at hand does not (yet?) support RGB.
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.