You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are considering packaging this project for Fedora as an alternative to intel/safestringlib, which in turn is an effort to debundle the original cisco implementation that we saw in svt-av1 and svt-av1-psy. My understanding is that all of these projects are compatible with each other and follow the api in cppreference other than the #include needed. Are there anything that we should look out for otherwise?
What are your thoughts on this effort, and can we bother you if we find some issues in the build? While building intel/safestringlib we encountered some issues when running the unittests and we are edging our bets if we should continue with that project or move on to this one. We also saw numerous issues in the CMake implementation there, so it would be nice if you would consider the feedback from the packagers when tackling #137 (I am happy to offer my support in form of reviews and discussions).
The text was updated successfully, but these errors were encountered:
Great. This one has much more functionality than the original Cisco. But my tests are also much stricter. Curious how much passes on unknown platforms.
Hi @rurban,
We are considering packaging this project for Fedora as an alternative to intel/safestringlib, which in turn is an effort to debundle the original cisco implementation that we saw in
svt-av1
andsvt-av1-psy
. My understanding is that all of these projects are compatible with each other and follow the api in cppreference other than the#include
needed. Are there anything that we should look out for otherwise?What are your thoughts on this effort, and can we bother you if we find some issues in the build? While building
intel/safestringlib
we encountered some issues when running the unittests and we are edging our bets if we should continue with that project or move on to this one. We also saw numerous issues in the CMake implementation there, so it would be nice if you would consider the feedback from the packagers when tackling #137 (I am happy to offer my support in form of reviews and discussions).The text was updated successfully, but these errors were encountered: