Le mercredi 13 juillet 2016 ? 10:00 +0800, tiffany lin a ?crit?:

Hi Nicolas,

On Tue, 2016-07-12 at 15:14 -0400, Nicolas Dufresne wrote:

quoted

Le mardi 12 juillet 2016 ? 15:08 -0400, Nicolas Dufresne a ?crit :

quoted

Le mardi 12 juillet 2016 ? 16:16 +0800, Wu-Cheng Li (???) a ?crit

:

quoted

quoted

quoted

Decoder hardware produces MT21 (compressed). Image processor

can

quoted

quoted

quoted

convert it to a format that can be input of display driver.
Tiffany.
When do you plan to upstream image processor (mtk-mdp)?

quoted

?
It can be as input format for encoder, MDP and display

drivers in

quoted

quoted

quoted

our

quoted

platform.

I remember display driver can only accept uncompressed MT21.

Right?

quoted

quoted

quoted

Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque
format. It's not usable until it's decompressed and converted

by

quoted

quoted

quoted

image
processor.

?
Previously it was described as MediaTek block mode, and now as a
MediaTek compressed format. It makes me think you have no idea

what

quoted

quoted

this pixel format really is. Is that right ?
?
The main reason why I keep asking, is that we often find

similarities

quoted

quoted

between what vendor like to call their proprietary formats. Doing

the

quoted

quoted

proper research helps not creating a mess like in Android where

you

quoted

quoted

have a lot of formats that all point to the same format. I

believe

quoted

quoted

there was the same concern when Samsung wanted to introduce their

Z-

quoted

quoted

flip-Z NV12 tile format. In the end they simply provided

sufficient

quoted

quoted

documentation so we could document it and implement software
converters
for test and validation purpose.

?
Here's the kind of information we want in the documentation.
?
https://chromium.googlesource.com/chromium/src/media/+/master/base/

vide

quoted

o_types.h#40
?
?? // MediaTek proprietary format. MT21 is similar to NV21 except

the memory

quoted

?? // layout and pixel layout (swizzles). 12bpp with Y plane

followed by a 2x2

quoted

?? // interleaved VU plane. Each image contains two buffers -- Y

plane and VU

quoted

?? // plane. Two planes can be non-contiguous in memory. The

starting addresses

quoted

?? // of Y plane and VU plane are 4KB alignment.
?? // Suppose image dimension is (width, height). For both Y plane

and VU plane:

quoted

?? // Row pitch = ((width+15)/16) * 16.
?? // Plane size = Row pitch * (((height+31)/32)*32)
?
Now obviously this is incomplete, as the swizzling need to be

documented of course.

quoted

?

Because it's finally a compressed format from our codec hw, we cannot
describe its swizzling.

Can you clarify why it cannot be described ? I don't buy any argument
that it's impossible to convert without hardware. Intel did document
their compressed formats.

Debugging an integration with such format that we have literally
decided to no make public is a pain. A lot of decoder got abandoned or
never used because of that.

It would be nice to explain the architecture you are suggesting to make
this decoder useful. How will userspace application be able to use your
decoder. Will the image processor usable outside the display path ?
People might want to do transcoding, or other relatively common task
that does not imply a display.

regards,
Nicolas

p.s.
A small note to Wu-Cheng, the definition of the DRM format in your
Chromium branch is not correct. DRM uses format modifier, such that the
format is the family, in your case it's most likely NV21, and the
modifier is the compression or tiling algorithm in place (or both as
needed).