The webrtc code is actually really well organized, with a layered approach.
We are accessing the code at alow level, and we really don't need any of
the higher levels. If function-level linking is used, this problem
would already be solved and we really wouldn't need to do any work.
Unfortunately, right now webrtc_sdp.cc is a file that straddles layers.
The *functions* themselves are actually layered just fine. But they are
in the same source file, and so when file-level linking is used, you cannot
use only the low level ICE-related functions. You end up bringing in the
full SDP parsing and printing functions, which means you have to know about
media types, and codecs, etc. I think the best way to cut this Gordian
knot is to....um...cut it. See the hacked file for more info.
Right now we are not using DTLS, and so we still have some extra stuff in
the lib that could be removed. But I'm not inclined to make those cuts right
now, because in the future we may want to use their DTLS code. In fact,
we may end up needing to put some of this stuff back, if we want to use
RTP data channels, perhaps for compatibility with the browser.
This function (which performs a FATAL PROGRAM TERMINATION) is really
poorly named and something I don't like about Source/Steam codebase.
But #defining it was even worse. It's currently brekaing protobuf.
Rewrite assert. Previous version was a hacked version from Steam, but there
was too much plumbing, and we have a partner who wants to hook callback so
they get spew before formatting happens. So that means it cannot be done at
the call site.
I let certain allocations go thorugh the CRT on purpose. Specifically,
allocations that happen at static init time must go through. Unfortunately,
MSVC's std::vector and std::map default constructors will allocate memory (!!!!)
with _ITERATOR_DEBUG_LEVEL > 0, so any such object at file scope will, for
now at least, not use the custom allocators.
We want to keep track of what build directories we make and clean them
up, but hardcoding the list is kind of annoying as we add new build
configurations.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
i686 doesn't have it enabled by default, but we need it for our
reference implementation of ed25519/curve25519.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
Makes it easier to add images with weird characters in them, e.g.
"opensuse/tumbleweed:latest" would end up giving the wrong path with the
old config.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
It seems the rawhide compile/link issue is specifically a combination of
clang + sanitizers. Disabling those seems to make it behave.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
It really seems like libsodium (whose entire purpose is to make crypto
idiot-proof) making me mess with these details is a flaw in the API design.
Also, correct Hungarian.
We were trying to be smart and handle a sender sending us unreliable
segments starting at the same offset. Handling this weird situation
is not worth the complexity.
We know for certain the stock arch.h file for WebRTC doesn't know about
those, which also means it's untested with them.
Signed-off-by: Steven Noonan <steven@valvesoftware.com>
Fletcher Dunn
Steven Noonan
Steven Noonan