GNOME Bugzilla – Bug 722587
videotestsrc does not generate correct data for GRAY16_LE and GRAY16_BE
Last modified: 2014-11-24 18:48:45 UTC
Created attachment 266704 [details] [review] the patch file when I tried to process GRAY16_LE/BE data from videotestsrc, I found that LE/BE data is just the same: dump data to file: gst-launch-1.0 videotestsrc num-buffers=1 ! video/x-raw, format=\(string\)GRAY16_LE,width=\(int\)640, height=\(int\)480 ! filesink location=le.bin gst-launch-1.0 videotestsrc num-buffers=1 ! video/x-raw, format=\(string\)GRAY16_BE,width=\(int\)640, height=\(int\)480 ! filesink location=be.bin no difference between them.hex looks like : 0000000: ebeb ebeb ebeb ebeb ebeb ebeb ebeb ebeb ................ actually there's almost no difference when display,since low byte affects very little. after some digging , I found that GRAY code path convert_hline_generic in videotestsrc.c use TO_16 just dump low byte to high byte, I also found that frame->info.finfo->unpack_func seems to do GRAY16_LE/BE->AYUV64 convert which confused me. I tried a small hack , it can output correct GRAY16_LE/BE buffer ,but I didn't follow every line in videotestsrc.c . after this hack, GRAY16_LE dump data looks like :0000000: 00eb 00eb 00eb 00eb 00eb 00eb 00eb 00eb ................ GRAY16_BE dump data looks like :0000000: eb00 eb00 eb00 eb00 eb00 eb00 eb00 eb00 ................ 0001-fix-videotestsrc-generate-GRAY16_LE-BE-data-incorrec.patch From 7779afdb95c8b9243cc72fafb769caace0a937cc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?"Wang=20Xin-yu=20(=E7=8E=8B=E6=98=95=E5=AE=87)"?= <comicfans44@gmail.com> Date: Mon, 20 Jan 2014 16:20:02 +0800 Subject: [PATCH] fix videotestsrc generate GRAY16_LE/BE data incorrectly bug --- gst/videotestsrc/videotestsrc.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gst/videotestsrc/videotestsrc.c b/gst/videotestsrc/videotestsrc.c index 1235782..0d59bdc 100644 --- a/gst/videotestsrc/videotestsrc.c +++ b/gst/videotestsrc/videotestsrc.c @@ -1168,10 +1168,10 @@ convert_hline_generic (paintinfo * p, GstVideoFrame * frame, int y) if (bits == 16) { /* 16 bits */ for (i = 0; i < width; i++) { - p->tmpline_u16[i * 4 + 0] = TO_16 (p->tmpline[i * 4 + 0]); - p->tmpline_u16[i * 4 + 1] = TO_16 (p->tmpline[i * 4 + 1]); - p->tmpline_u16[i * 4 + 2] = TO_16 (p->tmpline[i * 4 + 2]); - p->tmpline_u16[i * 4 + 3] = TO_16 (p->tmpline[i * 4 + 3]); + p->tmpline_u16[i * 4 + 0] = 0xffff; + p->tmpline_u16[i * 4 + 1] = (p->tmpline[i * 4 + 1])<<8; + p->tmpline_u16[i * 4 + 2] = 0x8000; + p->tmpline_u16[i * 4 + 3] = 0x8000; } memcpy (dest, p->tmpline_u16, width * 8); } else { -- 1.7.9.5
Comment on attachment 266704 [details] [review] the patch file This patch is not correct. It discards all components and loses precision on the Y component.
(In reply to comment #0) > Created an attachment (id=266704) [details] [review] > the patch file > > when I tried to process GRAY16_LE/BE data from videotestsrc, I found that > LE/BE data is just the same: > > dump data to file: > gst-launch-1.0 videotestsrc num-buffers=1 ! video/x-raw, > format=\(string\)GRAY16_LE,width=\(int\)640, height=\(int\)480 ! filesink > location=le.bin > gst-launch-1.0 videotestsrc num-buffers=1 ! video/x-raw, > format=\(string\)GRAY16_BE,width=\(int\)640, height=\(int\)480 ! filesink > location=be.bin > > no difference between them.hex looks like : 0000000: ebeb ebeb ebeb ebeb ebeb > ebeb ebeb ebeb ................ > > actually there's almost no difference when display,since low byte affects very > little. Yes, that's correct. videotesrc does not use the full 16 bits of the grey colorspace and thus there is no difference between LE and BE. > > after some digging , I found that GRAY code path > convert_hline_generic in videotestsrc.c use TO_16 just dump low byte to high > byte, > I also found that frame->info.finfo->unpack_func seems to do > GRAY16_LE/BE->AYUV64 convert which confused me. GRAY is like YUV with only the Y component (and usually different range and colormatrix). > I tried a small hack , it can output correct GRAY16_LE/BE buffer ,but I didn't > follow every line in videotestsrc.c . > > after this hack, > GRAY16_LE dump data looks like :0000000: 00eb 00eb 00eb 00eb 00eb 00eb 00eb > 00eb ................ > GRAY16_BE dump data looks like :0000000: eb00 eb00 eb00 eb00 eb00 eb00 eb00 > eb00 ................ > Yes, but it now you don't use the full range of the 16 bits, your components go from 0000 to ff00 (and not 0000 to ffff, as it does with the existing videotestsrc code). What exactly do you think is the problem and what are you trying to achieve?
(In reply to comment #1) > (From update of attachment 266704 [details] [review]) > This patch is not correct. It discards all components and loses precision on > the Y component. sorry I misunderstood the code. (In reply to comment #2) > (In reply to comment #0) > > .... > > after this hack, > > GRAY16_LE dump data looks like :0000000: 00eb 00eb 00eb 00eb 00eb 00eb 00eb > > 00eb ................ > > GRAY16_BE dump data looks like :0000000: eb00 eb00 eb00 eb00 eb00 eb00 eb00 > > eb00 ................ > > > > Yes, but it now you don't use the full range of the 16 bits, your components go > from 0000 to ff00 (and not 0000 to ffff, as it does with the existing > videotestsrc code). > > > What exactly do you think is the problem and what are you trying to achieve? I'm trying to use gstreamer to do some data process,data is GRAY16 liked,but not standard. when using videotestsrc to generate buffer but found low byte and high byte the same,then I came into this. I simply think the GRAY16 buffer output by videotestsrc is just GRAY8-shifted, which is wrong. Thank you for your correction.
Anything left to be done here? I think not? If yes, please re-open. In the mean-time closing as 'is so on purpose'.