In 1.5 development, we've hit this issue where the VideoAlignment.stride_align[] would be greater then the allocation params. This was an upstream pipeline bug, but we thought it is nicer to make downstream (the pools) safe to that, specially that it can figure-out and that the strictp values depends on the number of allocation.

In the quick solution to get the release out, we simply maxed out all the alignment to the highest. This is "over" aligning the memory, and we could clean this up to be more strict.

There is two main cases, the basically when there is multiple allocations (1 GstMemory per plane) and when there is a single allocation.

In the single allocation case, the adjustment shall be:

  mem_align = max(mem_align, stride_align[1], ..., stride_align[n] ...)
  stride_align[n] = max(stride_align[n], stride_align[n+1], ...)

The reason of this cascade, is that each alignment impact the initial alignment of the following. Maximizing everything to the biggest is also correct, but would not be strict enough for a verifying the minimum alignment requirement is met.

In the multiple allocation case, it's simplier.

  mem_align = max(mem_align, stride_align[n])
  stride_align[n] = stride_align[n]

This is because with split allocation, a plane have no impact on the alignment of the following plane.

This is a minor enhancement, reducing of only few bytes the allocation. Though, the idea with this enhancement bug is to create a new utility method, similar to gst_video_info_align() that would at once align the GstVideoInfo and the GstAllocationParam, to which the type of allocation is passed (single or multiple). This way we can remove custom code that has been added everywhere, and then have this implemented in a single location.