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

Steve Lhomme robux4 at ycbcr.xyz
Tue Apr 17 08:47:45 CEST 2018


Le 17/04/2018 à 08:00, Steve Lhomme a écrit :
> 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 (Cb/Cr).
>
> 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.

In fact picture_NewFromFormat() used by the test (or most of the code) 
for a 1x1 visible & coded pixel size YUV creates a 16x18 picture with 
1x1 visible pixel. So in this case discarding the 1 U/V line because we 
don't have it in the coded area is not even an excuse.

> 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
>>> 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
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel



More information about the vlc-devel mailing list