After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 722587 - videotestsrc does not generate correct data for GRAY16_LE and GRAY16_BE
videotestsrc does not generate correct data for GRAY16_LE and GRAY16_BE
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.2.2
Other All
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-01-20 08:28 UTC by comicfans44
Modified: 2014-11-24 18:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
the patch file (1.24 KB, patch)
2014-01-20 08:28 UTC, comicfans44
rejected Details | Review

Description comicfans44 2014-01-20 08:28:28 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 1 Wim Taymans 2014-01-20 09:12:28 UTC
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.
Comment 2 Wim Taymans 2014-01-20 09:16:46 UTC
(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?
Comment 3 comicfans44 2014-01-21 01:40:55 UTC
(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.
Comment 4 Tim-Philipp Müller 2014-11-24 18:48:45 UTC
Anything left to be done here? I think not? If yes, please re-open. In the mean-time closing as 'is so on purpose'.