Nevcairiel / LAVFilters

LAV Filters - Open-Source DirectShow Media Splitter and Decoders
GNU General Public License v2.0
7.34k stars 789 forks source link

Should downstream allocator be told to allocate to 16b boundary? #482

Closed OneOfMany07 closed 2 years ago

OneOfMany07 commented 2 years ago

Saw this bug that identified an oddity in LAVFilters, though they did work around it. Figured you still might want to investigate the issue...

https://github.com/CrendKing/avisynth_filter/issues/63

"The cause is because of this line in LAV: https://github.com/Nevcairiel/LAVFilters/blob/master/decoder/LAVVideo/LAVPixFmtConverter.cpp#L601

It requires the buffer pointer to be aligned to 16. However, it does not request the downstream (i.e. AVSF) allocator to give it aligned buffer: https://github.com/Nevcairiel/LAVFilters/blob/master/decoder/LAVVideo/LAVVideo.cpp#L592

As a result, AVSF may handout unaligned buffers, causing it to deactivate direct mode. Somehow, EVR and madVR would only handout aligned buffer even the cbAlign field is 1. This is not what doc requires. There's probably some historical reason, which I'm not aware of.

So for solution, I think either LAV change the code to request aligned buffer (unless something else forbid it to do so), or I change my code to always return aligned buffer, just as EVR and madVR."

Nevcairiel commented 2 years ago

Unfortunately, requesting alignment from the allocator does not actually work reliably. In many cases the renderer will just refuse the connection when you set cbAlign to 16 and eg. the "Colorspace Converter" filter will be inserted in between, which negates any of the advantages.

As the line you pointed to shows, LAV handles both aligned buffers and non-aligned ones, aligned is just faster. Ideally a downstream should always provide aligned buffers, as its generally always better for both involved filters.