Package: v4l-utils / 1.6.0-2

Metadata

Package Version Patches format
v4l-utils 1.6.0-2 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
dont gererate treeview.diff | (download)

doxygen_libdvbv5.cfg | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 disable treeview to suppress embedded jsquery
man section.diff | (download)

utils/dvb/dvbv5-zap.1.in | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

---
man ellipsis.diff | (download)

utils/dvb/dvbv5-scan.1.in | 5 3 + 2 - 0 !
1 file changed, 3 insertions(+), 2 deletions(-)

---
fix jpeg subsampling.diff | (download)

lib/libv4lconvert/jpeg.c | 37 24 + 13 - 0 !
1 file changed, 24 insertions(+), 13 deletions(-)

 v4lconvert: fix decoding of jpeg data with no vertical sub-sampling

Our YUV output is always 2x subsampled in both vertical and horizontal
direction, but some cameras generate JPEG data which is only subsampled in
the horizontal direction.

Since averaging the extra UV data these JPEGs contains is somewhat slow,
and UV data is not all that important anyways, we simple take every other
line. Or at least that is the intent.

But before this commit the code was not doing this properly, for each 16
Y input lines 1 - 16 we also get 16 UV input lines 1 - 16, but we only need
8 output lines. so we should store input line 1 or 2 in output line 1, input
line 3 or 4 in output line 2, etc. Instead we were storing input lines
9 - 16 into output lines 1 - 8, which leads to some unwanted color bleeding.

More over this also leads for 1920x1080 JPEG to us writing (1080 / 8 + 1) / 2
* 8 = 544 UV output lines rather then 540, this means that the last 4 U output
lines overwrite the first 4 V output lines, and worse that the last 4 V output
lines overrun the output buffer.

So far this only lead to some wrong colors in various places, but since that
we dynamically allocate the output buffer to just the right size this actually
causes a crash.

This commit fixes both the crash, and the wrong colors.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>