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 785384 - video-format: Add a new 10bit depth format packed into 20 bytes
video-format: Add a new 10bit depth format packed into 20 bytes
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-07-25 06:48 UTC by kevin
Modified: 2018-11-03 11:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description kevin 2017-07-25 06:48:38 UTC
Hi,

Currently only have GST_VIDEO_FORMAT_P010_10LE video format. The Y of one pixel will be 16 bits for one pixel. We need NV12 10 bits LE with packed, not 0 pading. The Y of one pixel should be 10 bits for one pixel.

Can you help?
Comment 1 Sebastian Dröge (slomo) 2017-07-25 06:59:16 UTC
What is this new format used for and where? Someone with access to the (I assume it's hardware?) would need to implement that for proper testing.

Is this basically in 8 values / 10 bytes group, or... ?
Comment 2 kevin 2017-07-25 08:12:24 UTC
Yes, hardware video decoder and video render use this format. The size of the 10 bits NV12 video frame buffer is 1.25 times of 8 bits NV12 video frame buffer.
Comment 3 Sebastian Dröge (slomo) 2017-07-25 08:18:19 UTC
That's not enough information to implement this though.
Comment 4 Nicolas Dufresne (ndufresne) 2017-07-25 12:26:36 UTC
Please, provide a complete layout iformation.
Comment 5 kevin 2017-07-26 02:41:21 UTC
Our video frame buffer need 16 pixel alignment. It is 16 values / 20 bytes group. All 16 values need reverse if convert from little endian to big endian.

Is it common video format? Or I need add it as our private format?
Comment 6 Nicolas Dufresne (ndufresne) 2017-11-02 01:33:52 UTC
It does not seem common in the sense I haven't seen it documented anywhere. The "reversing" isn't clear to me yet though, so this still need information.
Comment 7 Nicolas Dufresne (ndufresne) 2017-11-02 01:34:38 UTC
Maybe you could provide a sample yuv image, reference in well known format, and one packed the way you described ?
Comment 8 kevin 2017-11-17 09:16:41 UTC
8 bit NV12:

Y plane:

pixel:   1     2     3     4     5
bytes:   1     2     3     4     5

10 bit NV12:

Y plane:

P010:

pixel:        1           2          3         4          5
bytes:   1    2     3     4     5    6    7    8    9    10

Our 10 bit format:

pixel:     1     2     3       4
bytes:   1    2    3     4     5
Comment 9 Nicolas Dufresne (ndufresne) 2017-11-17 15:42:54 UTC
Again, can you attach couple of RAW samples for that format, so we can test with. In general you can attach a ref in a known format (like P010) and one in your new format. Otherwise, propose a patch that implements what you need.

If the helps, here's one of my submission for similar format, which is packed over 32bit (with 2 bit padding / lost).

  https://bugzilla.gnome.org/show_bug.cgi?id=789876
Comment 10 GStreamer system administrator 2018-11-03 11:58:05 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/368.