| Message ID | 1464611363-14936-4-git-send-email-tiffany.lin@mediatek.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 05/30/2016 02:29 PM, Tiffany Lin wrote: > Add V4L2_PIX_FMT_MT21 documentation > > Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com> > --- > Documentation/DocBook/media/v4l/pixfmt.xml | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml > index 5a08aee..d40e0ce 100644 > --- a/Documentation/DocBook/media/v4l/pixfmt.xml > +++ b/Documentation/DocBook/media/v4l/pixfmt.xml > @@ -1980,6 +1980,12 @@ array. Anything what's in between the UYVY lines is JPEG data and should be > concatenated to form the JPEG stream. </para> > </entry> > </row> > + <row id="V4L2_PIX_FMT_MT21"> > + <entry><constant>V4L2_PIX_FMT_MT21</constant></entry> > + <entry>'MT21'</entry> > + <entry>Compressed two-planar YVU420 format used by Mediatek MT8173 > + codec driver.</entry> Can you give a few more details? The encoder driver doesn't seem to produce this format, so who is creating this? Where is this format documented? Regards, Hans > + </row> > </tbody> > </tgroup> > </table> >
Hi Hans, On Fri, 2016-07-08 at 12:23 +0200, Hans Verkuil wrote: > On 05/30/2016 02:29 PM, Tiffany Lin wrote: > > Add V4L2_PIX_FMT_MT21 documentation > > > > Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com> > > --- > > Documentation/DocBook/media/v4l/pixfmt.xml | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml > > index 5a08aee..d40e0ce 100644 > > --- a/Documentation/DocBook/media/v4l/pixfmt.xml > > +++ b/Documentation/DocBook/media/v4l/pixfmt.xml > > @@ -1980,6 +1980,12 @@ array. Anything what's in between the UYVY lines is JPEG data and should be > > concatenated to form the JPEG stream. </para> > > </entry> > > </row> > > + <row id="V4L2_PIX_FMT_MT21"> > > + <entry><constant>V4L2_PIX_FMT_MT21</constant></entry> > > + <entry>'MT21'</entry> > > + <entry>Compressed two-planar YVU420 format used by Mediatek MT8173 > > + codec driver.</entry> > > Can you give a few more details? The encoder driver doesn't seem to produce this > format, so who is creating this? Where is this format documented? > It can be as input format for encoder, MDP and display drivers in our platform. This private format is only available in our platform. So I put it in "Reserved Format Identifiers" sections. best regards, Tiffany > Regards, > > Hans > > > + </row> > > </tbody> > > </tgroup> > > </table> > >
On Mon, Jul 11, 2016 at 10:56 AM, tiffany lin <tiffany.lin@mediatek.com> wrote: > Hi Hans, > > On Fri, 2016-07-08 at 12:23 +0200, Hans Verkuil wrote: >> On 05/30/2016 02:29 PM, Tiffany Lin wrote: >> > Add V4L2_PIX_FMT_MT21 documentation >> > >> > Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com> >> > --- >> > Documentation/DocBook/media/v4l/pixfmt.xml | 6 ++++++ >> > 1 file changed, 6 insertions(+) >> > >> > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml >> > index 5a08aee..d40e0ce 100644 >> > --- a/Documentation/DocBook/media/v4l/pixfmt.xml >> > +++ b/Documentation/DocBook/media/v4l/pixfmt.xml >> > @@ -1980,6 +1980,12 @@ array. Anything what's in between the UYVY lines is JPEG data and should be >> > concatenated to form the JPEG stream. </para> >> > </entry> >> > </row> >> > + <row id="V4L2_PIX_FMT_MT21"> >> > + <entry><constant>V4L2_PIX_FMT_MT21</constant></entry> >> > + <entry>'MT21'</entry> >> > + <entry>Compressed two-planar YVU420 format used by Mediatek MT8173 >> > + codec driver.</entry> >> >> Can you give a few more details? The encoder driver doesn't seem to produce this >> format, so who is creating this? Where is this format documented? Decoder hardware produces MT21 (compressed). Image processor can convert it to a format that can be input of display driver. Tiffany. When do you plan to upstream image processor (mtk-mdp)? > > It can be as input format for encoder, MDP and display drivers in our > platform. I remember display driver can only accept uncompressed MT21. Right? Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque format. It's not usable until it's decompressed and converted by image processor. > This private format is only available in our platform. > So I put it in "Reserved Format Identifiers" sections. > > > best regards, > Tiffany > >> Regards, >> >> Hans >> >> > + </row> >> > </tbody> >> > </tgroup> >> > </table> >> > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit : > Decoder hardware produces MT21 (compressed). Image processor can > convert it to a format that can be input of display driver. Tiffany. > When do you plan to upstream image processor (mtk-mdp)? > > > > It can be as input format for encoder, MDP and display drivers in > our > > platform. > I remember display driver can only accept uncompressed MT21. Right? > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque > format. It's not usable until it's decompressed and converted by > 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 this pixel format really is. Is that right ? The main reason why I keep asking, is that we often find similarities between what vendor like to call their proprietary formats. Doing the proper research helps not creating a mess like in Android where you have a lot of formats that all point to the same format. I believe there was the same concern when Samsung wanted to introduce their Z- flip-Z NV12 tile format. In the end they simply provided sufficient documentation so we could document it and implement software converters for test and validation purpose. regards, Nicolas
Le mardi 12 juillet 2016 à 15:08 -0400, Nicolas Dufresne a écrit : > Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit : > > Decoder hardware produces MT21 (compressed). Image processor can > > convert it to a format that can be input of display driver. > > Tiffany. > > When do you plan to upstream image processor (mtk-mdp)? > > > > > > It can be as input format for encoder, MDP and display drivers in > > our > > > platform. > > I remember display driver can only accept uncompressed MT21. Right? > > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque > > format. It's not usable until it's decompressed and converted by > > 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 > this pixel format really is. Is that right ? > > The main reason why I keep asking, is that we often find similarities > between what vendor like to call their proprietary formats. Doing the > proper research helps not creating a mess like in Android where you > have a lot of formats that all point to the same format. I believe > there was the same concern when Samsung wanted to introduce their Z- > flip-Z NV12 tile format. In the end they simply provided sufficient > 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 o_types.h#40 // MediaTek proprietary format. MT21 is similar to NV21 except the memory // layout and pixel layout (swizzles). 12bpp with Y plane followed by a 2x2 // interleaved VU plane. Each image contains two buffers -- Y plane and VU // plane. Two planes can be non-contiguous in memory. The starting addresses // of Y plane and VU plane are 4KB alignment. // Suppose image dimension is (width, height). For both Y plane and VU plane: // 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. > > regards, > Nicolas
On 12/07/16 20:14, Nicolas Dufresne wrote: > Le mardi 12 juillet 2016 à 15:08 -0400, Nicolas Dufresne a écrit : >> Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit : >>> Decoder hardware produces MT21 (compressed). Image processor can >>> convert it to a format that can be input of display driver. >>> Tiffany. >>> When do you plan to upstream image processor (mtk-mdp)? >>>> It can be as input format for encoder, MDP and display drivers in >>> our >>>> platform. >>> I remember display driver can only accept uncompressed MT21. Right? >>> Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque >>> format. It's not usable until it's decompressed and converted by >>> 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 >> this pixel format really is. Is that right ? >> >> The main reason why I keep asking, is that we often find similarities >> between what vendor like to call their proprietary formats. Doing the >> proper research helps not creating a mess like in Android where you >> have a lot of formats that all point to the same format. I believe >> there was the same concern when Samsung wanted to introduce their Z- >> flip-Z NV12 tile format. In the end they simply provided sufficient >> 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 > o_types.h#40 > > // MediaTek proprietary format. MT21 is similar to NV21 except the memory > // layout and pixel layout (swizzles). 12bpp with Y plane followed by a 2x2 > // interleaved VU plane. Each image contains two buffers -- Y plane and VU > // plane. Two planes can be non-contiguous in memory. The starting addresses > // of Y plane and VU plane are 4KB alignment. > // Suppose image dimension is (width, height). For both Y plane and VU plane: > // 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. Not sure where that chromium comment came from, but if MT21 really is similar to NV21 (a 4:2:0 format) and has 2x2 downsampled chroma, then the combined VU plane will be half the size of the Y plane. Maybe that's not relevant to this discussion. Regards, Ian > >> regards, >> Nicolas > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Nicolas, On Tue, 2016-07-12 at 15:08 -0400, Nicolas Dufresne wrote: > Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit : > > Decoder hardware produces MT21 (compressed). Image processor can > > convert it to a format that can be input of display driver. Tiffany. > > When do you plan to upstream image processor (mtk-mdp)? > > > > > > It can be as input format for encoder, MDP and display drivers in > > our > > > platform. > > I remember display driver can only accept uncompressed MT21. Right? > > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque > > format. It's not usable until it's decompressed and converted by > > 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 > this pixel format really is. Is that right ? > That's not right. Its a compressed format as I document in "[PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver." In MT8173 platform, when using this format, we need Image Processor to cover it to standard format as wucheng mentioned. To prevent this ambiguous, I will change it to V4L2_PIX_FMT_M21C, it means its compressed data. Is it ok? best regards, Tiffany > The main reason why I keep asking, is that we often find similarities > between what vendor like to call their proprietary formats. Doing the > proper research helps not creating a mess like in Android where you > have a lot of formats that all point to the same format. I believe > there was the same concern when Samsung wanted to introduce their Z- > flip-Z NV12 tile format. In the end they simply provided sufficient > documentation so we could document it and implement software converters > for test and validation purpose. > > regards, > Nicolas
Hi Nicolas, On Tue, 2016-07-12 at 15:14 -0400, Nicolas Dufresne wrote: > Le mardi 12 juillet 2016 à 15:08 -0400, Nicolas Dufresne a écrit : > > Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit : > > > Decoder hardware produces MT21 (compressed). Image processor can > > > convert it to a format that can be input of display driver. > > > Tiffany. > > > When do you plan to upstream image processor (mtk-mdp)? > > > > > > > > It can be as input format for encoder, MDP and display drivers in > > > our > > > > platform. > > > I remember display driver can only accept uncompressed MT21. Right? > > > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque > > > format. It's not usable until it's decompressed and converted by > > > 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 > > this pixel format really is. Is that right ? > > > > The main reason why I keep asking, is that we often find similarities > > between what vendor like to call their proprietary formats. Doing the > > proper research helps not creating a mess like in Android where you > > have a lot of formats that all point to the same format. I believe > > there was the same concern when Samsung wanted to introduce their Z- > > flip-Z NV12 tile format. In the end they simply provided sufficient > > 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 > o_types.h#40 > > // MediaTek proprietary format. MT21 is similar to NV21 except the memory > // layout and pixel layout (swizzles). 12bpp with Y plane followed by a 2x2 > // interleaved VU plane. Each image contains two buffers -- Y plane and VU > // plane. Two planes can be non-contiguous in memory. The starting addresses > // of Y plane and VU plane are 4KB alignment. > // Suppose image dimension is (width, height). For both Y plane and VU plane: > // 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. > Because it's finally a compressed format from our codec hw, we cannot describe its swizzling. best regards, Tiffany > > > > regards, > > Nicolas
On Tue, 2016-07-12 at 16:16 +0800, Wu-Cheng Li (李務誠) wrote: > On Mon, Jul 11, 2016 at 10:56 AM, tiffany lin <tiffany.lin@mediatek.com> wrote: > > Hi Hans, > > > > On Fri, 2016-07-08 at 12:23 +0200, Hans Verkuil wrote: > >> On 05/30/2016 02:29 PM, Tiffany Lin wrote: > >> > Add V4L2_PIX_FMT_MT21 documentation > >> > > >> > Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com> > >> > --- > >> > Documentation/DocBook/media/v4l/pixfmt.xml | 6 ++++++ > >> > 1 file changed, 6 insertions(+) > >> > > >> > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml > >> > index 5a08aee..d40e0ce 100644 > >> > --- a/Documentation/DocBook/media/v4l/pixfmt.xml > >> > +++ b/Documentation/DocBook/media/v4l/pixfmt.xml > >> > @@ -1980,6 +1980,12 @@ array. Anything what's in between the UYVY lines is JPEG data and should be > >> > concatenated to form the JPEG stream. </para> > >> > </entry> > >> > </row> > >> > + <row id="V4L2_PIX_FMT_MT21"> > >> > + <entry><constant>V4L2_PIX_FMT_MT21</constant></entry> > >> > + <entry>'MT21'</entry> > >> > + <entry>Compressed two-planar YVU420 format used by Mediatek MT8173 > >> > + codec driver.</entry> > >> > >> Can you give a few more details? The encoder driver doesn't seem to produce this > >> format, so who is creating this? Where is this format documented? > Decoder hardware produces MT21 (compressed). Image processor can > convert it to a format that can be input of display driver. Tiffany. > When do you plan to upstream image processor (mtk-mdp)? > > We are working on this. Will upstream soon. > > It can be as input format for encoder, MDP and display drivers in our > > platform. > I remember display driver can only accept uncompressed MT21. Right? > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque > format. It's not usable until it's decompressed and converted by image > processor. That's right in MT8173 platform. best regards, Tiffany > > This private format is only available in our platform. > > So I put it in "Reserved Format Identifiers" sections. > > > > > > best regards, > > Tiffany > > > >> Regards, > >> > >> Hans > >> > >> > + </row> > >> > </tbody> > >> > </tgroup> > >> > </table> > >> > > > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 13, 2016 at 3:14 AM, Nicolas Dufresne <nicolas.dufresne@gmail.com> wrote: > Le mardi 12 juillet 2016 à 15:08 -0400, Nicolas Dufresne a écrit : >> Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit : >> > Decoder hardware produces MT21 (compressed). Image processor can >> > convert it to a format that can be input of display driver. >> > Tiffany. >> > When do you plan to upstream image processor (mtk-mdp)? >> > > >> > > It can be as input format for encoder, MDP and display drivers in >> > our >> > > platform. >> > I remember display driver can only accept uncompressed MT21. Right? >> > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque >> > format. It's not usable until it's decompressed and converted by >> > 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 >> this pixel format really is. Is that right ? >> >> The main reason why I keep asking, is that we often find similarities >> between what vendor like to call their proprietary formats. Doing the >> proper research helps not creating a mess like in Android where you >> have a lot of formats that all point to the same format. I believe >> there was the same concern when Samsung wanted to introduce their Z- >> flip-Z NV12 tile format. In the end they simply provided sufficient >> 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 > o_types.h#40 That is the documentation of decompressed MT21. Originally MT21 was meant to be a YUV format and we can map it in CPU to use it. The name was changed to mean a compressed format. The current design is only MTK image processor can convert it. Software cannot decompress it. I'm not sure if we should document the format inside if we cannot decompress in software. For chromium, I'll update the code to explain MT21 is an opaque compressed format. > > // MediaTek proprietary format. MT21 is similar to NV21 except the memory > // layout and pixel layout (swizzles). 12bpp with Y plane followed by a 2x2 > // interleaved VU plane. Each image contains two buffers -- Y plane and VU > // plane. Two planes can be non-contiguous in memory. The starting addresses > // of Y plane and VU plane are 4KB alignment. > // Suppose image dimension is (width, height). For both Y plane and VU plane: > // 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. > >> >> regards, >> Nicolas
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: > > Le mardi 12 juillet 2016 à 15:08 -0400, Nicolas Dufresne a écrit : > > > Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit > : > > > > Decoder hardware produces MT21 (compressed). Image processor > can > > > > convert it to a format that can be input of display driver. > > > > Tiffany. > > > > When do you plan to upstream image processor (mtk-mdp)? > > > > > > > > > > It can be as input format for encoder, MDP and display > drivers in > > > > our > > > > > platform. > > > > I remember display driver can only accept uncompressed MT21. > Right? > > > > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque > > > > format. It's not usable until it's decompressed and converted > by > > > > 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 > > > this pixel format really is. Is that right ? > > > > > > The main reason why I keep asking, is that we often find > similarities > > > between what vendor like to call their proprietary formats. Doing > the > > > proper research helps not creating a mess like in Android where > you > > > have a lot of formats that all point to the same format. I > believe > > > there was the same concern when Samsung wanted to introduce their > Z- > > > flip-Z NV12 tile format. In the end they simply provided > sufficient > > > 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 > > o_types.h#40 > > > > // MediaTek proprietary format. MT21 is similar to NV21 except > the memory > > // layout and pixel layout (swizzles). 12bpp with Y plane > followed by a 2x2 > > // interleaved VU plane. Each image contains two buffers -- Y > plane and VU > > // plane. Two planes can be non-contiguous in memory. The > starting addresses > > // of Y plane and VU plane are 4KB alignment. > > // Suppose image dimension is (width, height). For both Y plane > and VU plane: > > // 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. > > > 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).
Hi Nicolas, On Wed, 2016-07-13 at 09:55 -0400, Nicolas Dufresne wrote: > 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: > > > Le mardi 12 juillet 2016 à 15:08 -0400, Nicolas Dufresne a écrit : > > > > Le mardi 12 juillet 2016 à 16:16 +0800, Wu-Cheng Li (李務誠) a écrit > > : > > > > > Decoder hardware produces MT21 (compressed). Image processor > > can > > > > > convert it to a format that can be input of display driver. > > > > > Tiffany. > > > > > When do you plan to upstream image processor (mtk-mdp)? > > > > > > > > > > > > It can be as input format for encoder, MDP and display > > drivers in > > > > > our > > > > > > platform. > > > > > I remember display driver can only accept uncompressed MT21. > > Right? > > > > > Basically V4L2_PIX_FMT_MT21 is compressed and is like an opaque > > > > > format. It's not usable until it's decompressed and converted > > by > > > > > 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 > > > > this pixel format really is. Is that right ? > > > > > > > > The main reason why I keep asking, is that we often find > > similarities > > > > between what vendor like to call their proprietary formats. Doing > > the > > > > proper research helps not creating a mess like in Android where > > you > > > > have a lot of formats that all point to the same format. I > > believe > > > > there was the same concern when Samsung wanted to introduce their > > Z- > > > > flip-Z NV12 tile format. In the end they simply provided > > sufficient > > > > 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 > > > o_types.h#40 > > > > > > // MediaTek proprietary format. MT21 is similar to NV21 except > > the memory > > > // layout and pixel layout (swizzles). 12bpp with Y plane > > followed by a 2x2 > > > // interleaved VU plane. Each image contains two buffers -- Y > > plane and VU > > > // plane. Two planes can be non-contiguous in memory. The > > starting addresses > > > // of Y plane and VU plane are 4KB alignment. > > > // Suppose image dimension is (width, height). For both Y plane > > and VU plane: > > > // 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. > > > > > 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. > What's the Intel compressed formats? Could you provide link so we could reference how they provide this information. > 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. > In MT8173 platform, it has MDP driver, it could convert V4L2_PIX_FMT_MT21 to V4L2_PIX_FMT_NV12M or V4L2_PIX_FMT_YUV420M. MDP is stand alone driver, it is usable outside the display path. NV12M/YUV420M/MT21 -> MDP -> NV12M/YUV420M NV12M/NV21M/YUV420M/YVU420M -> mt8173 Encoder -> H264/VP8 H264/VP8/VP9 -> mtk8173 Decoder -> MT21 When encode with MT21 source, the pipeline will be: MT21 -> MDP driver-> NV12M/NV21M/YUV420M/YVU420M -> Encoder -> H264/VP8 When playback, the pipeline will be: H264/VP8/VP9 -> Decoder driver -> MT21 -> MDP Driver -> DRM best regards, Tiffany > 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).
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index 5a08aee..d40e0ce 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -1980,6 +1980,12 @@ array. Anything what's in between the UYVY lines is JPEG data and should be concatenated to form the JPEG stream. </para> </entry> </row> + <row id="V4L2_PIX_FMT_MT21"> + <entry><constant>V4L2_PIX_FMT_MT21</constant></entry> + <entry>'MT21'</entry> + <entry>Compressed two-planar YVU420 format used by Mediatek MT8173 + codec driver.</entry> + </row> </tbody> </tgroup> </table>
Add V4L2_PIX_FMT_MT21 documentation Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com> --- Documentation/DocBook/media/v4l/pixfmt.xml | 6 ++++++ 1 file changed, 6 insertions(+)