search

CrendKing / avisynth_filter

DirectShow filters that put AviSynth and VapourSynth into video playing
MIT License
107 stars 8 forks source link

Possible to implement support for 'd3d11 cb direct' from LAV Filters? #63

Closed sofakng closed 2 years ago

sofakng commented 2 years ago

If I understand correctly, right now AVISynth Filter doesn't support 'd3d11 cb direct' mode when using LAV Filters. This is supposedly a bit faster and more efficient than 'd3d11 cb' (non-direct) mode but it requires this filter to support compatible video buffers/format.

EVR/EVR-CP appears to support this method but when AVISynth Filter is added to the chain, "direct" support is removed due to it not being supported.

CrendKing commented 2 years ago

I didn't know this until you mention here. I'll take a look at it.

CrendKing commented 2 years ago

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.

CrendKing commented 2 years ago

I identified a way to solve probably 99% of all the cases, without requiring LAV to do anything, or having to hard coding some special logic in AVSF. Please try the artifacts of https://github.com/CrendKing/avisynth_filter/actions/runs/1475957293.

If you encounter the problem again, please reopen the issue with details. Thanks!

sofakng commented 2 years ago

I'll give that a try. Thank you so much for updating this (and so quickly!)

I'm not sure if it will make a big difference, but faster/more efficient is always better! :)

sofakng commented 2 years ago

I've only tested a few videos but it looks to be working. It correctly indicates 'd3d11 cb direct' and plays perfectly.

Thanks so much!

OneOfMany07 commented 2 years ago

Reply from Nevcairiel... "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."

And don't know how much searching you did for good ways to get aligned memory buffers, but it seemed like this should just be a keyword for the compiler. Here is a 5 year old answer with some details...

https://stackoverflow.com/questions/16376942/best-cross-platform-method-to-get-aligned-memory

"... _mm_malloc works for Visual Studio 2012, GCC, MinGW, and the Intel C++ compiler so it seems to be the most convenient solution in general. It also requires using its own _mm_free function, although on some implementations you can pass pointers from _mm_malloc to the standard free / delete."

CrendKing commented 2 years ago

I just tested. The current version of AVSF seems to work fine with current version of LAV Filters. Do you experience otherwise? If so please report. If not, I added the alignment macro in https://github.com/CrendKing/avisynth_filter/commit/772f223ae2638a942d3cdf971b25558434159344. I'm not actively using it unless the upstream requests aligned buffer.

I understand LAV hard codes the alignment for better compatibility, but AVSF has different target audience. Until there is actually a reasonable problem, I'll try to keep the code simple and spec abiding as much as possible.

OneOfMany07 commented 2 years ago

No issue on my side. Just wanted both parties to know about the possible issue, and to see the replies.

I thought they might change their system to how you'd expected (I would by reading through the documentation and your results). But I guess they're working around other tools that require these parameters and give the wrong response. Such is life in technology ;-)