Hi Tomasz and Laurent, I have commented on the MFC case below. > From: Tomasz Stanislawski [mailto:t.stanislaws@xxxxxxxxxxx] > > Hi Laurent, > > On 09/27/2011 01:17 PM, Laurent Pinchart wrote: > > Hi Tomasz, > > > > On Friday 23 September 2011 17:22:27 Tomasz Stanislawski wrote: > >> On 09/23/2011 03:13 PM, Laurent Pinchart wrote: > > > [snip] > > >>>>> > >>>>> How would an application remove them ? > >>>> > >>>> The application may use memset if it recognizes fourcc. The idea of > >>>> padding target was to provide information about artifacts introduced > the > >>>> hardware. If the image is decoded directly to framebuffer then the > >>>> application could remove artifacts. We could introduce some V4L2 > >>>> control to inform if the padding are is filled with zeros to avoid > >>>> redundant memset. > >>>> What do you think? > >>> > >>> OK, I understand this better now. I'm still not sure how applications > >>> will be able to cope with that. memset'ing the garbage area won't look > >>> good on the screen. > >> > >> The memset is just a simple and usually fast solution. The application > >> could fill the padding area with any pattern or background color. > >> > >>> Does your hardware have different compose and padding rectangles ? > >> > >> I assume that you mean active and padded targets for composing, right? > >> The answer is yes. The MFC inserts data to the image that dimensions are > >> multiples of 128x32. The movie inside could be any size that fits to the > >> buffer. The area that contains the movie frame is the active rectangle. > >> The padded is filled with zeros. For MFC the bounds and padded rectangle > >> are the same. > >> > >> Hmm... > >> > >> Does it violate 'no margin requirement', doesn't it? > > > > Seems so :-) > > > > For S5P MFC is it not possible to satisfy 'no margin' requirement in all > cases. The default rectangle is not equal to the bound rectangle in all > cases. BTW, the MFC is mem2mem device so its API may change. > To sum up for MFC following inequalities are satisfied: > > active <= padded == bound > > Do you think that 'no margin' requirement should be downgraded to a > recommendation status? In case of MFC it will be active == padded <= bound as MFC does not fill the region outside the active zone with zeroes. That pixels are not modified. The 'no margin requirement' as I understand should not be imposed. I can imagine other hardware than MFC that may have the default crop other than the full buffer size. This will be especially common in case of various tiled image formats. In MFC we have 128x32 tiles, but the movie size can be any number (If I remember correctly). [snip] Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
