Cisco-hosted 2.4.1 library reports version 2.4.0

[torokati44]

The WelsGetCodecVersion function, when called in libopenh264-2.4.1-linux64.7.so file - as linked from https://github.com/cisco/openh264/releases/tag/v2.4.1 -, returns version 2.4.0.2310.
Was that built before #3724 perhaps?
This makes it difficult to check/verify that the appropriate version got deployed and loaded.

To make sure the dynamic linker and loader don't pick up any other file with a different version installed on my system, I tested it like this:

Expand...

// openh264versiontest.c
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

#include "codec_api.h"

int main() {
    void *handle = dlopen("./libopenh264-2.4.1-linux64.7.so", RTLD_LAZY);
    OpenH264Version (*WelsGetCodecVersion)(void) = dlsym(handle, "WelsGetCodecVersion");
    OpenH264Version ver = WelsGetCodecVersion();
    printf("OpenH264 version: %d.%d.%d.%d\n", ver.uMajor, ver.uMinor, ver.uRevision, ver.uReserved);
    dlclose(handle);
}

clang openh264versiontest.c -I Downloads/openh264-2.4.1/codec/api/wels/ -o openh264versiontest

[BenzhengZhang]

Sorry for confusion, it was actually built behind #3707 and before #3724. The official package of 2.4.1 will be temporarily set to Pre-release until the correct version information is included in the release. Thank you for discovering this issue.

[mcatanzaro]

Is this why the 2.4.1 binaries have changed? Can you please confirm that the changes I observed in #909 (comment) are expected and not malicious?

It's causing problems; in the future, it would be better to just release 2.4.2 instead rather than respin existing releases. At the very least, please provide some notice so that we know it's not malicious.

[torokati44]

... in the future, it would be better to just release 2.4.2 instead rather than respin existing releases. At the very least, please provide some notice so that we know it's not malicious.

Again, I agree 100%.

[torokati44]

Also, could you please confirm that the current 2.4.1 binaries are the final hosted ones, and the release should no longer be marked as "pre-release", @BenzhengZhang?

[mcatanzaro]

It's causing problems;

I am downgrading freedesktop-sdk back to 2.3.1 until Cisco confirms what has happened here (additional context).

[torokati44]

FWIW it was Chinese New Year just the other day, which may explain the delay in response.

[BenzhengZhang]

I can confirm that binary has been officially replaced by Cisco. Please feel free to use it. I have marked it as the latest release and there will be no new changes. @torokati44
@mcatanzaro You can see if there is still a problem of checksum and size not matching.

[torokati44]

Closing as supposedly fixed. Thank you!

[mcatanzaro]

OK, thanks Benzheng. I will update freedesktop-sdk and GNOME runtimes.

That said, it would be nice if you don't do this again since it breaks existing users. End user systems download the binary directly from Cisco, expecting it to match the original size and hash. We got lucky this time only because we hadn't released the updated OpenH264 to users yet, avoiding a flood of complaints. In the future, it would be better to just bump the version number and re-release.

[BenzhengZhang]

OK, thanks Benzheng. I will update freedesktop-sdk and GNOME runtimes.

That said, it would be nice if you don't do this again since it breaks existing users. End user systems download the binary directly from Cisco, expecting it to match the original size and hash. We got lucky this time only because we hadn't released the updated OpenH264 to users yet, avoiding a flood of complaints. In the future, it would be better to just bump the version number and re-release.

Yes, I agree with your suggestion.