[vlc-devel] [PATCH 4/4] direct3d11: align I420 buffers on 64 bits so that direct rendering is used
remi at remlab.net
Wed Dec 13 16:59:57 CET 2017
Le 13 décembre 2017 17:52:20 GMT+02:00, Steve Lhomme <robux4 at gmail.com> a écrit :
>On Wed, Dec 13, 2017 at 10:58 AM, Rémi Denis-Courmont <remi at remlab.net>
>> What I originally meant is that the pitch alignment should ne defined
>as a pseudo-constant in a public header, not hard-coded in the core
>It depends on the decoder and should be handled there. There's also
>the pixel format alignment which hopefully is less restrictive than
>the decoder. But if a decoder has (supposedly) no requirement we still
>need to ensure all picture in the format meet the plane requirements.
>For now we have hardcoded a value of 16 bytes because it works most of
>the time but it seems that it's not enough anymore.
>The log mentioned is specific to avcodec but IMO the same should apply
>to all decoders.
>> I am not sure if the unit should be samples, pixels or bytes though.
>It depends where we would use that value. If it's just memory
>allocation it should be bytes. If it's dimension alignment then
>probably pixels. But that means we'd still need to process the plane
>alignment before deciding the actual byte alignment we need. A lookup
>for vlc_fourcc_GetChromaDescription() each time is probably too heavy.
>32 bytes ought to be enough for everyone.
>> Remi Denis-Courmont
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
It does not depend on the decoder, rather not only. Filters can have alignment constraints too. So it can't be done inside the decoder. And because filters are added or removed sometimes in live video output, we can also not ask the filters during setup.
So I can't see any pragmatic alternative to a "dumb" fixed value.
More information about the vlc-devel