tyan0

This issue may be related to https://github.com/cisco/openh264/pull/3707 Similar glitch in ffplay with openh264 has been fixed.

> Still poor quality with your latest fixes waiting fro review? Yes. The pull request https://github.com/cisco/openh264/pull/3707 fixes only the reordering of the decoded frames. I guess this issue is in...

Isn't this issue simply due to the short timeout? With latest oss-fuzz, the timeout seems to be 25 sec for the command: ```python3 infra/helper.py reproduce openh264 decoder_fuzzer clusterfuzz-testcase-minimized-decoder_fuzzer-6315387293597696``` When I...

This errror handling was added by the commit https://github.com/cisco/openh264/commit/e90068c234a8f93df01b30b0d3de9ca8d8915c1d mearged from PR https://github.com/cisco/openh264/pull/2070. What situation is this necessary? And does the above code change break this fix?

I have confirmed that this issue also occurs in cygwin 3.4.6, but not in the latest cygwin 3.5.0 (Test). This issue seems to be due to a long-standing limitation of...

I'll look into it. Please wait a while.

I found the code removed in the commit c0e5ea286c31 affects the issue. I create new pull request https://github.com/cisco/openh264/pull/3868 Sorry for inconvenience.

I could not reproduce the problem. https://github.com/tyan0/openh264/actions/runs/10181727155/job/28162603960 What differs between your environment and mine?

I could reproduce the issue using artifact in https://github.com/cisco/openh264/actions/runs/10176042462/artifacts/1763247810 This issue is due to a typo in WelsReorderRefList2(). My bug_fix_2 branch has been updated with this fix.

If you could provide sample video which can reproduce the issue, it would help.