[vlc-devel] [vlc-commits] picture: round the number of visible lines to the upper multiple
robux4 at ycbcr.xyz
Tue Apr 17 08:00:00 CEST 2018
Le 16/04/2018 à 19:40, Tristan Matthews a écrit :
> 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.
IMO it is wrong. You can have a red RGB 1x1 pixel converted to 1x1 YUV.
It would end up as green or black if you don't have that one line of U/V
The question is wether a 4:2:0 picture with "coded height" as 1 is
valid. A "visible height" of 1 is correct (see above). Depending how we
answer this means we either round up or down the chroma line.
Given libavcodec is giving us odd coded height for 4:2:0 sources (see
sample in #20290 and many others) I think it's safer to round up on our
side rather than losing the plane information for a whole line.
I will try to fix the tests which are OK with losing data...
>> 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
> 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.
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel