feat: play audio and video in the browser, and open the media formats we only named - #649
Merged
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0bbd7256d3
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
andiwand
force-pushed
the
feat/media-html
branch
from
August 1, 2026 16:38
08d5b25 to
9a8fde7
Compare
andiwand
force-pushed
the
feat/inline-frontend-resources
branch
from
August 1, 2026 16:48
d241f89 to
76f1ada
Compare
andiwand
force-pushed
the
feat/media-html
branch
from
August 1, 2026 16:48
9a8fde7 to
2b9b445
Compare
… we only named odrcore named mp3, mp4, webp and the rest but refused to open them, so OpenDocument.droid carried its own translation for exactly these: a PhotoSwipe page for images and two Plyr players for audio and video, each one a vendored library and the file base64'd or copied next to it. That belongs here, where the format table already knows what the bytes are. Nothing is decoded. `open` wraps the bytes for every image bar the starview metafile, and for all audio and video, and `translate` hands them to the browser: an `<img>` for the images, an `<audio>` or `<video>` with native controls for the rest. No player library ships with it. There is no `AudioFile`/`VideoFile` wrapper to go with them - a wrapper would carry nothing the plain `DecodedFile` does not already have, so the service takes that, and `open_strategy` picks the impl by category rather than by a list of file types it would have to be kept in step with. The media stays an `HtmlResource` (`HtmlResourceType::media`, never embedded) instead of a data URI: `bring_offline` copies a video next to its page and the http server streams it, where base64 would have added a third to a file that is already the largest thing we emit.
andiwand
force-pushed
the
feat/media-html
branch
from
August 1, 2026 22:47
2b9b445 to
84711d2
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
🤖 Generated with Claude Code
Stacked on #648 — it needs
internal/html/frontend.cppfor the page's css.What this is
odrcore already names mp3, mp4, mkv, webp, heic and the rest — it just refused to open them. OpenDocument.droid carried its own translation for exactly that gap:
image.html(vendored PhotoSwipe),audio.htmlandvideo.html(vendored Plyr, ~213 KB each), with the file copied next to the page under a made-up extension. This brings it here, where the format table already knows what the bytes are.How
Nothing is decoded, so nothing needs a decoder:
open_strategypicks the impl by category rather than by a list of file types someone has to keep in step with. Every image bar the starview metafile becomesinternal::ImageFile; audio and video become a newinternal::MediaFile. That is what turns onwebp,tiff,heifandaviftoo.html::translatewrites an<audio>/<video>with native controls — no player library ships with this.open/translate_htmlbits move with it, and theFileTypecomment that called these "detection only" is no longer true.No
AudioFile/VideoFilewrapper. One would carry nothing the plainDecodedFiledoes not already have (the bytes, and the type that names them), socreate_media_servicetakes aDecodedFileandtranslate(const DecodedFile &)dispatches on category. The public surface grows by one enum constant and nothing else.The media is an
HtmlResource, never a data URI. NewHtmlResourceType::media, whichstandard_resource_locatornever embeds.bring_offlinecopies the video next to its page and the http server serves it from the service. base64 would have added a third to the largest thing we emit.Notes
HtmlResourceTypegained a constant, so the three bindings that mirror it by ordinal are updated (jni enum, pybind, ObjC).media_file_test.cppbuilds them from a signature plus a payload in memory — nothing past the signature is ever read.Test plan
odr_test --gtest_filter='media_file.*'— 6 new tests: audio and video pages, the source served and copied as bytes,bring_offline, webp taking the image page.