Closed vpa1977 closed 1 year ago
The CI runs the decoder with a large set of teststreams: https://github.com/strukturag/libde265/actions/workflows/decode.yml
It is fuzzed indirectly through libheif (CI and oss-fuzz): https://bugs.chromium.org/p/oss-fuzz/issues/list?q=libheif
What other kind of tests do you propose?
I was considering a small smoke test that can run during package build in Ubuntu or Debian - something similar to aom test suite, or just an autopkgtest that runs over some small (a few frames) streams.
The streams used in the decode workflow can not be included in the packaging due to the license concerns.
I can generate a small public domain video for the test. Could you then do the autopkgtest script? I have no experience with that.
This is already merged on salsa =)
I was wondering if it would be ok to add a small bitreader (and any other subsystems that you consider relevant) google test to detect issues with big endian systems?
This is already merged on salsa =)
Ok, I didn't see this as @fancycode does the Debian packaging.
I was wondering if it would be ok to add a small bitreader google test to detect issues with big endian systems?
This or simply decoding the video on big endian systems should also show the error.
We can run the video output through md5sum
to check whether everything is correct.
h265 guarantees that decoding is pixel exact.
I have encoded a small video clip. You can test for correct decoding by passing the output through md5sum
like this:
$ ./dec265 ../testdata/girlshy.h265 -q -o - 2>/dev/null|md5sum -
b81538fa33a67278e5263e231e43ca98 -
Thank you!!! I will add PR on salsa to use it in autopkgtest/build smoke test when the new version is available.
PS: see the last lines in scripts/ci-run.sh
. I've also added the test there.
MIR review for Libde265 noted the absence of the unit tests [1]. Would it be possible to consider adding a set of tests for the library? I am happy to work on this issue.
[1] https://bugs.launchpad.net/ubuntu/+source/libde265/+bug/2004449