You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Probe real WebCodecs encoder output before advertising H.264, VP8, VP9, AAC, or Opus; cache successful capability probes for the page lifetime.
Carry the asynchronous capability checks through the ParparVM worker/host bridge.
Select a container-compatible video/audio pair in VideoIORoundTripTest instead of selecting video and audio independently.
Reject incompatible JavaScript writer requests explicitly (for example, Opus in MP4) instead of silently substituting a different codec.
Preserve the failing encoder stage in diagnostics so video, audio, muxer, and flush failures are distinguishable.
Root cause
Linux Chromium supports VP8/VP9 plus Opus but not the AAC configuration used by the HTML5 writer. The test preferred H.264 for MP4, then independently selected the available Opus encoder. The JavaScript writer ignored that requested Opus codec and silently attempted AAC because the container was MP4. Chromium correctly rejected AAC, and the test reported an encode-unavailable skip.
The test now prefers complete compatible pairs (H.264/AAC for MP4, then VP8/Opus or VP9/Opus for WebM) and falls back to video-only only when no compatible audio encoder exists. The writer now rejects mismatched container/codec requests rather than changing codecs behind the caller's back.
Compared 146 screenshots: 146 matched.
Native Windows port (x64 / Intel-AMD): full hellocodenameone screenshot suite rendered offscreen with Direct2D/DirectWrite, plus the real benchmarks (base64 native/CN1/SIMD, image createMask/applyMask/modifyAlpha/PNG/JPEG, SSE2 SIMD kernels). Compared against the in-repo baseline in scripts/windows/screenshots.
Compared 146 screenshots: 146 matched.
Native Windows port, REAL shipping pipeline: the hellocodenameone screenshot suite rendered by a binary CROSS-COMPILED on Linux (clang-cl + xwin, WebView2 linked) and RUN on a Windows x64 runner. Compared against the in-repo baseline in scripts/windows/screenshots.
Compared 147 screenshots: 147 matched.
Native Linux port (x64), GTK3/Cairo/Pango, ParparVM bytecode-to-C (no JVM): the hellocodenameone screenshot suite rendered by a native ELF built + run on the GitHub x64 runner. Baseline: scripts/linux/screenshots.
Compared 147 screenshots: 147 matched.
Native Linux port (arm64), GTK3/Cairo/Pango, ParparVM bytecode-to-C (no JVM): the hellocodenameone screenshot suite rendered by a native ELF built + run on the GitHub arm64 runner. Baseline: scripts/linux/screenshots-arm.
Compared 146 screenshots: 146 matched.
Native Windows port (arm64 / Apple Silicon - Arm): full hellocodenameone screenshot suite rendered offscreen with Direct2D/DirectWrite, plus the real benchmarks (base64 native/CN1/SIMD, image createMask/applyMask/modifyAlpha/PNG/JPEG, NEON SIMD kernels). Compared against the in-repo baseline in scripts/windows/screenshots.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
VideoIORoundTripTestinstead of selecting video and audio independently.Root cause
Linux Chromium supports VP8/VP9 plus Opus but not the AAC configuration used by the HTML5 writer. The test preferred H.264 for MP4, then independently selected the available Opus encoder. The JavaScript writer ignored that requested Opus codec and silently attempted AAC because the container was MP4. Chromium correctly rejected AAC, and the test reported an encode-unavailable skip.
The test now prefers complete compatible pairs (H.264/AAC for MP4, then VP8/Opus or VP9/Opus for WebM) and falls back to video-only only when no compatible audio encoder exists. The writer now rejects mismatched container/codec requests rather than changing codecs behind the caller's back.
Validation
node --check Ports/JavaScriptPort/src/main/webapp/port.jsnode --check vm/ByteCodeTranslator/src/javascript/browser_bridge.jsgit diff --checkHTML5VideoIO.javaandVideoIORoundTripTest.javawith JDK 17 against the current built classes.VideoIORoundTripTestwrote and reopened a 27,328-byte WebMCN1SS:INFO:test=VideoIORoundTripTest status=ROUNDTRIP_OK platform=HTML5