Complete partial video generation foundation#217
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## trunk #217 +/- ##
============================================
+ Coverage 87.45% 87.54% +0.09%
- Complexity 1194 1201 +7
============================================
Files 60 60
Lines 3858 3878 +20
============================================
+ Hits 3374 3395 +21
+ Misses 484 483 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
gziolo
left a comment
There was a problem hiding this comment.
All checks pass locally (tests, PHPCS clean, PHPStan clean).
Verified the implementation follows the established patterns for speech/image generation:
VideoGenerationModelInterfaceandVideoGenerationOperationModelInterfacematch the existing interface pairs (sync + async)PromptBuilderadditions (generateVideoResult,generateVideo,generateVideos) follow the same flow: set output modality → delegate togenerateResultwith the correct capability- Capability inference works from both the model interface and explicit output modality, consistent with other modalities
- The old "video not yet supported" throw is replaced with proper delegation, and the unsupported modality test now uses
documentinstead - Test coverage is thorough — mirrors the existing speech/image test structure across all code paths (result generation, error cases, shorthand helpers, capability inference,
isSupportedcheck)
Based on my research, the two-interface split (sync ModelInterface + async OperationModelInterface) is a good fit for providers like OpenAI/Sora where video generation is inherently asynchronous (job submission + polling), while the sync interface can wrap create_and_poll + download for simpler usage.
No issues found.
While we partially had the required pieces for video generation already present, for some reason we were missing part of the foundation. This PR fixes that.
This does not actually implement any video generation features - it just completes the API. It will allow providers to implement video support in the future.
Nothing special here, this entirely follows the existing patterns we already use for e.g. text generation, image generation, speech generation, ...