From patchwork Sun Apr 10 13:45:22 2005
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Patchwork-Submitter: Luca Olivetti <luca@ventoso.org>
X-Patchwork-Id: 11853
Received: from 232.red-213-97-27.pooles.rima-tde.net ([213.97.27.232])
	by www.linuxtv.org with esmtp (Exim 4.34) id 1DKclI-0007G3-0B
	for vdr@linuxtv.org; Sun, 10 Apr 2005 15:46:04 +0200
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1])
	by 232.Red-213-97-27.pooles.rima-tde.net (Postfix) with ESMTP id
	8F49018A338B
	for <vdr@linuxtv.org>; Sun, 10 Apr 2005 15:45:32 +0200 (CEST)
Message-ID: <42592DF2.9040704@ventoso.org>
Date: Sun, 10 Apr 2005 15:45:22 +0200
From: Luca Olivetti <luca@ventoso.org>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Klaus Schmidinger's VDR <vdr@linuxtv.org>
X-Enigmail-Version: 0.89.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Subject: [vdr] [PATCH] dxr3 better (hopefully) color management
X-BeenThere: vdr@linuxtv.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Klaus Schmidinger's VDR <vdr@linuxtv.org>
List-Id: Klaus Schmidinger's VDR <vdr.linuxtv.org>
List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>,
	<mailto:vdr-request@linuxtv.org?subject=unsubscribe>
List-Archive: <http://www.linuxtv.org/pipermail/vdr>
List-Post: <mailto:vdr@linuxtv.org>
List-Help: <mailto:vdr-request@linuxtv.org?subject=help>
List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>,
	<mailto:vdr-request@linuxtv.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2005 13:46:04 -0000
Status: O
X-Status: 
X-Keywords: 
X-UID: 1511

Hi,
try the attached patch.
Note that the number of regions is arbitrary, the real limit is the 
total spu data (see 
http://web.archive.org/web/20020309020308/http://members.aol.com/mpucoder/DVD/spu.html), 
but that's more difficult to foresee (anyway, in case it's reached the 
dxr3 plugin won't send any data to the spu).
Note also that the plugin doesn't check the maximum number of sections 
(I've added a warning but it will probably segfault in case too many 
sections are added).
I still couldn't find the cause of color bleeding: both the color 
manager (apart from the error fixed by the patch) and the spu encoder 
seems ok to me.

Bye

--- dxr3colormanager.c.orig	2005-04-10 15:32:25.322780808 +0200
+++ dxr3colormanager.c	2005-04-10 15:33:13.146114757 +0200
@@ -67,13 +67,16 @@
 // ==================================
 cColorManager::~cColorManager()
 {
+//printf("NrOfRegions %d ",NrOfRegions);
 	for (int i = 0; i < NrOfRegions; i++)
 	{
 		if (hlr[i])
 		{
+		        //printf("%d ",hlr[i]->N);
 			delete(hlr[i]);
 		}
 	}
+//printf("\n");	
 }
 
 // ==================================
@@ -103,7 +106,7 @@
 
 	if (hlr[NrOfRegions]->N != 0)		// skip this region if there is no section defined
 	{
-		if (NrOfRegions < MAX_NO_OF_SECTIONS -1)
+		if (NrOfRegions < MAX_NO_OF_REGIONS -1)
         {
 			NrOfRegions++;
    		}
@@ -306,6 +309,7 @@
 {
 	xSection* sec = new xSection(x);
     int N = hlr[NrOfRegions]->N;
+    if (N>=MAX_NO_OF_SECTIONS-1) printf("Bummer, too many sections\n");
 
 	hlr[NrOfRegions]->Section[hlr[NrOfRegions]->N] = sec;
 	if (N > 0)
--- dxr3colormanager.h.orig	2005-04-10 15:22:25.995573817 +0200
+++ dxr3colormanager.h	2005-04-10 15:22:25.999572591 +0200
@@ -48,7 +48,7 @@
 #define OSD_SPU_CM_DUMP 0
 
 #define MAX_NO_OF_SECTIONS	15
-#define MAX_NO_OF_REGIONS	30
+#define MAX_NO_OF_REGIONS	60
 
 
 // ==================================