Version & Maintenance Info

kunaljathal commented 5 years ago

Hi,

I have the following questions about the webrtc prebuilt libraries that you have here on github:

1) How are you choosing what version to provide? Are you simply trying to be as up to date as possible, or is there a particular reason you have offered m73 (and not 72 or m75, for example)

2) How often will the prebuilt libraries be updated here?

3) Do you happen to know what the 'm' stands for in the version info? Currently, the switch in naming seems to have happened from branch 72 to 73 i.e. on the webrtc source page, branch 72 is simply named 72, but branch 73 is m73...

Thanks very much!

ziriax commented 5 years ago

We pick the newest version that still works for us, that just happens to be m73 for now
As soon as the current version Google Chrome requires an update, we will update the libs
I have no idea why, but I did read something about this in the webrtc mailing list, can't find it back.

kunaljathal commented 5 years ago

Thanks for the reply. I'm seeing another issue: peer_connection_factory.h has the line #include "media/sctp/sctp_transport_internal.h

but media/sctp/sctp_transport_internal.h is not present in your repo. Am I missing something here?

ziriax commented 5 years ago

Interesting, let me check this, I might have forgotten to copy some include files.

ziriax commented 5 years ago

Indeed, we didn't use this for our webrtc-dotnet-core project, so we didn't copy the header files.

We might have missed a lot of header files too, simply because these weren't needed for our own project.

Let me fix this for you.

ziriax commented 5 years ago

I just pushed the missing files, can you try again?

Thanks !

kunaljathal commented 5 years ago

Thanks! I had to continue my work yesterday so I circumvented the problem by copying the sctp folder here: https://chromium.googlesource.com/external/webrtc/+/branch-heads/m73/media/

It seems like you did the exact same thing as well -- was that all you did, or were there any extra files you also copied?

kunaljathal commented 5 years ago

And one more question -- is your pre-built library (i.e. webrtc.lib) usable in a Visual Studio 2015 project? Or does it have to be 2017 ?

EDIT: Asking because I'm seeing lots of linker errors of the following kind(s):

error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MTd_StaticDebug' doesn't match value 'MDd_DynamicDebug' in main.obj
error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in main.obj

A quick Google search indicates this might be because of the way in which you built webrtc.lib; namely linking against a different version of the CRT (C Runtime Library) compared to my project ....

ziriax commented 5 years ago

Yes Google builds its WebRTC library against the static versions of the CRT library. This is not the default, so you will have to modify your settings.

Please refer to the webrtc-native project in our webrtc-dotnet-core repository to see these settings

ziriax commented 5 years ago

I am not sure it will work with VS2015, we won't support this old version, but PR is always welcome of course :-)

kunaljathal commented 5 years ago

Yes Google builds its WebRTC library against the static versions of the CRT library. This is not the default, so you will have to modify your settings.

Is it possible for me to modify your windows_build.bat script in order to build WebRTC to link against the dynamic version of the CRT library? Or in other words, to build a shared library version of webrtc.lib ?

ziriax commented 5 years ago

Sure but I don't know how, you would have to do some research for this.

kunaljathal commented 5 years ago

Yes Google builds its WebRTC library against the static versions of the CRT library. This is not the default, so you will have to modify your settings.

To clarify -- you said building against the static version of CRT is not the default? What is the default then?

Please refer to the webrtc-native project in our webrtc-dotnet-core repository to see these settings

I looked at your project but didn't see any settings to build a shared lib, unless I misunderstood why you were asking me to check your webrtc-native project ...

ziriax commented 5 years ago

No sorry, I meant that Google picked linking against the static CRT libs, something that is not the default setting for Visual Studio.

There is nothing in our batch file that allows tweaking this. Actually, I have no idea how to achieve using the dynamic CRT libs with Google's Ninja build system, you will have to do research on your own

kunaljathal commented 5 years ago

Gotcha -- I think I found out how to build a dynamic CRT -- I am able to modify one of the BUILD.gn files to basically set the default crt as dynamic instead of static (for Windows Desktop). I'm able to build a static webrtc.lib that seems to work!

Now, the (hopefully final) issue I'm seeing is that, for some reason, when building with clang, RTC_LOG throws an access violation during runtime. I'm not having that problem when building with MSVS. However, you have stated in your repo that if we want H264 support, we cannot use MSVS and must use only clang. Why is this? And also, is there no way around that (i.e. can we build H264 support with MSVS)?

ziriax commented 5 years ago

Do you also get this error when building the static CRT variant?

Also, maybe msvc is now supported, it has to do with building ffmpeg...

kunaljathal commented 5 years ago

Do you also get this error when building the static CRT variant?

Unfortunately that cannot be answered, because the error is runtime, and I am unable to reach runtime with the static CRT variant because building my project fails at the linking stage.

Also, maybe msvc is now supported, it has to do with building ffmpeg...

Hmm, how do I do this? I tried simply adding the use_openh264=true phrase to the gn args when generating for msvs, but somehow it produces the following error for me:

The variable "use_openh264" was set as a build argument
but never appeared in a declare_args() block in any buildfile.
To view all possible args, run "gn args --list <out_dir>"
The build continued as if that argument was unspecified.

So strange, because I don't get this error when generating for clang (i.e. setting is_clang=true)...

SebastianKunz commented 5 years ago

Do you happen to know what the 'm' stands for in the version info?

It comes from Chrome and matches what WebRTC branch is included in the Milestone versions of Chrome, so branch m74 aligns with Chrome M74.x etc.

iimachines / webrtc-build

Version & Maintenance Info #1