`Video Combine` stored `video_metadata["prompt"] = json.dumps(prompt)`
while every other field is stored as a raw object. `ffmpeg_process`
then runs `json.dumps` on each value, so `prompt` ends up double-
encoded in the embedded MP4 metadata.
Match the `extra_pnginfo` branch and store the raw object. The PNG
metadata path on line 354 is unchanged.
The original double-wrap was an intentional workaround for JSON's
stricter NaN handling (per @AustinMroz). It predates the
consumer-facing schema introduced in #627 and is no longer needed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Since `prompt` and `workflow` are non-standard metadata fields for mp4
files, they require an additional flag during the audio pass to ensure
the metadata is copied.
Detection may not be the most reliable if one of the duplicates is not
seeing updates and happens to install first. I'll keep pondering a more
reliable way to do this. The only ideas that come to mind are a little
too hacky and unsafe for my current standards.
Code gets a little messy, but this should handle also handle a
hypothetical future with animated previews for concurrent execution,
while still properly cleaning up after itself once a workflow ceases
execution.
Swapping workflows still causes previews to cease display. I don't know
a clean solution for this.
Added rate information for the Wan22 vae. This is only used for the 5b
model and the only change is a slight reduction in the preview rate.
Fixed being unable to quickly update multiple frontend widget values
with tab.
Fixed an incorrect default modulus for which forced inconvenient
dimensions for the Load Image node.
The audio input was changed to be discarded when outputting to the
gifski format since gifs do not support audio and other non-audio
supporting formats will silently ignore audio when it cannot be embedded.
This fix was mistakenly added outside the appropriate conditional block
and instead discarded all audio. This was not intended
Resolves#521
The step calculated from frame rate for start_time on load video ffmpeg
nodes has now been adjusted to not have an unneeded x10 multiplier
TODO: reconsider if this creates overly undesirable breakage if VHS
frontend code is not used.
An extra pass was added to the ffmpeg_frame_generation code to properly
detect and handle alpha when loading vp9 videos. This early commit
allowed for correct detection, but then failed to apply the decoder to
the main pass, so no alpha was output. This has been fixed.
Since the subgraph utils aren't exposed from core, a small stub function
is just re implemented in VHS.
Execution state seems be robust enough to trust core to clear this
state, but it's initially set to 0 by VHS now to ensure the preview
display doesn't race the message that the node is being processed.
Unfortunately, the lack of ability to determine if a node is actually
running means swapping the active workflow once again breaks the display
of previews. I don't see a way to fix this without changes to core.
While disappointing as a maintainer, the fix never being rolled out
means this isn't a loss of functionality to end users.
Resolves#516
This functions so long as multiple nodes aren't providing latent
previews at once. I will need to take time to consider if such
functionality would even be desirable.
Does not resolve subgraphs. Graph traversal functions don't appear to be
exposed, so I'll most likely need to re-implement myself, but I need to
take the time to exhaustively verify first.
z