[vlc-devel] [vlc-commits] picture: round the number of visible lines to the upper multiple

[Tristan Matthews]

On Mon, Apr 16, 2018 at 1:19 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le maanantaina 16. huhtikuuta 2018, 20.13.36 EEST Tristan Matthews a écrit :
>> On Mon, Apr 16, 2018 at 12:27 PM, Steve Lhomme <robux4 at ycbcr.xyz> wrote:
>> > Le 16/04/2018 à 16:56, Tristan Matthews a écrit :
>> >> On Mon, Apr 16, 2018 at 10:38 AM, Steve Lhomme <git at videolan.org> wrote:
>> >>> vlc | branch: master | Steve Lhomme <robux4 at ycbcr.xyz> | Mon Apr 16
>> >>> 15:35:23 2018 +0200| [82f649983443292bd893962cac0484b7df8d1c89] |
>> >>> committer: Steve Lhomme
>> >>>
>> >>> picture: round the number of visible lines to the upper multiple
>> >>
>> >> This breaks make check for me:
>> >>
>> >> FAIL: chroma_copy_sse_test
>> >> ==========================
>> >>
>> >> testing: 1 x 1 (vis: 1 x 1) NV12 -> I420
>> >
>> > So if having 1 line of U/V planes is wrong I assume it used 0 before my
>> > patch. How can this be correct ?
>>
>> I believe it makes sense for a 1x1 4:2:0 video to have 0 chroma lines
>> here, otherwise you would be implicitly converting to 4:4:4 in this
>> case, right?
>
> I don't really see how/why one line should be any different than larger odd
> number of lines. Plus, my gut tells me that adding a special case will only
> move the problem.

I wasn't suggesting adding a special case, just giving an example of
how 0 chroma lines for a 1x1 4:2:0 image did not strike me as
"incorrect" as per Steve's question.

> The real question is, what does it mean to have an odd number of lines with
> 4:2:0 sampling. It is valid? And if so, should the chroma be rounded down or
> up?


Yes, I'm not sure what are considered references here. There's
obviously a mismatch between the rounding patch and the chroma copy
test and so it doesn't make sense to change one without the other, but
it's not clear to me what the other ramifications are to rounding up.

Best,
Tristan