Possible bug in the vmetric calculation code in telecide()

[jackoneill]

This possible bug is in the vmetric calculation code, in decomb524src.zip/Telecide.cpp, in Telecide::CalculateMetrics(), line 938:

for (y = 0; y < hover2 - 4; y+=4)
{
/* Exclusion band. Good for ignoring subtitles. */
if (y0 == y1 || y < y0/2 || y > y1/2)
{
for (x = 0; x < wover2;)
{
index = (y/BLKSIZE)*xblocks + x/BLKSIZE; // <--- line 938
// Test combination with current frame.
tmp1 = ((long)currbot0[x] + (long)currbot2[x]);
diff = abs((((long)currtop0[x] + (long)currtop2[x] + (long)currtop4[x])) - (tmp1 >> 1) - tmp1);
if (diff > nt)
{
c += diff;


It looks like it's using the same block size of 24×24 both for luma and for chroma. With a common 720×480 image, this results in 600 luma blocks and 150 chroma blocks (per chroma plane). This means that the sums calculated for all 150 chroma blocks each get added to the sums calculated for the first 150 luma blocks, leading to somewhat wrong vmetrics (higher than they should be).

I think adjusting the block size to take subsampling into account should fix this.

[Guest]

Patches welcome. :)

[jackoneill]

--- Telecide.cpp 2012-11-24 10:09:04.000000000 +0200
+++ Telecide.cpp 2014-04-12 11:05:51.433706672 +0300
@@ -935,7 +935,7 @@
{
for (x = 0; x < wover2;)
{
- index = (y/BLKSIZE)*xblocks + x/BLKSIZE;
+ index = (y/(BLKSIZE/2))*xblocks + x/(BLKSIZE/2);
// Test combination with current frame.
tmp1 = ((long)currbot0[x] + (long)currbot2[x]);
diff = abs((((long)currtop0[x] + (long)currtop2[x] + (long)currtop4[x])) - (tmp1 >> 1) - tmp1);

[Guest]

Thanks! I'll slipstream it into 5.2.4 as I don't really have time to make a whole formal release.