obs-webrtc: Add null terminator to codec array

[kc5nra]

This fixes an issue where when the MAX_CODECS length was equal to the amount of supported codecs (3), it would leave the list without a null terminator and crash when iterating over the elements.

Description

Addresses a bug where a non-null terminated list of strings was iterated over into invalid memory

Motivation and Context

Crashes on some machines depending on if the memory layout had a null accidentally after the list.

How Has This Been Tested?

Tested on Mac and Windows, no longer crashes in release mode.

Types of changes

Bug fix

Checklist:

• [x] My code has been run through clang-format.
• [x] I have read the contributing document.
• [x] My code is not on the master branch.
• [x] The code has been tested.
• [x] All commit messages are properly formatted and commits squashed where appropriate.
• [x] I have included updates to all appropriate documentation.

[kc5nra]

Wrap the commit message body at 72 characters, not 60.

Is this a problem for all other const char *something[] instances across the codebase? Is that type even appropriate here? Should this just be a std vector/array or an enum (as it is elsewhere in the codebase) instead?

I'm fine getting a crash fixed quickly and merging this as-is (after fixing nits). However, I feel like this is not our first problem with this implementation, and I think a few reviewers have expressed discontent with it.

It would be an API breaking change to address it differently.

        info.get_supported_video_codecs = [](void *) -> const char ** {
		return video_codecs;
	};
	info.get_supported_audio_codecs = [](void *) -> const char ** {
		return audio_codecs;
	};

So the services getters would have to change to change the type

[kc5nra]

But yes, it would be a problem for all the API functions that rely on (*next_item == 0) for determining last element

[RytoEX]

Wrap the commit message body at 72 characters, not 60. Is this a problem for all other const char *something[] instances across the codebase? Is that type even appropriate here? Should this just be a std vector/array or an enum (as it is elsewhere in the codebase) instead? I'm fine getting a crash fixed quickly and merging this as-is (after fixing nits). However, I feel like this is not our first problem with this implementation, and I think a few reviewers have expressed discontent with it.

It would be an API breaking change to address it differently.

For what it's worth, I'm not saying to change the return type there. You can build the string however you like (see rtmp-common). I'm suggesting that relying on a raw const char *something[] here and doing strcmp calls is perhaps not ideal, but that is outside the scope of this PR.

But yes, it would be a problem for all the API functions that rely on (*next_item == 0) for determining last element

If there are other places where this is problematic, we would welcome fixes for those.

[kc5nra]

Makes sense - I think I just read your first message too fast, my fault! I'll ponder a better approach for this service in another PR

Thanks!