[Bug 761607] video: add support for P010 video format

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Mar 22 17:41:52 UTC 2016


https://bugzilla.gnome.org/show_bug.cgi?id=761607

--- Comment #16 from Scott D Phillips <scott.d.phillips at intel.com> ---
(In reply to sreerenj from comment #15)
> Few questions:
> 
> -- What is "HI" in DPTH10_10_10_HI ?

Short for 'high' because the pixel data is in the high bits of the bytes as
opposed to DPTH10_10_10 which has pixel data in the low bits.

> -- Since bits are packed in high 10 bits, we have to do the shifting while
> unpacking to AYUV64..right? With the current code the each component values
> are residing in the high 10 bits of each unpacked 16 bits component 

If you compare with unpack_I420_10LE it seems the conversion to AYUV64 should
expand the 10-bit value to a 16-bit value. Because P010 pixel data is in the
high bits no shift is required to expand 10 bits to 16 bits.

> What is the actual memory layout for the I420_10LE ? seems like it is using
> memory layout of pixel values in lower 10 bits unlike P010_LE

Right, I420_10LE and P010_10LE store the pixel data in different parts of
bytes, low bits and high bits respectively.

> -- What will we do with 9 bits per component hevc format, IIRC Scot was
> testing 9bit streams too,,, ?  Adding one more format similar to P010 except
> shifting fields set to 7???

I'm not totally sure what the right solution is for that. One additional
complication is that HEVC can have independent bit depths for luma and chroma
(bit_depth_luma_minus8 and bit_depth_chroma_minus8 in the sps). I don't think
creating formats for each variation is the right approach.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list