A Video for the Question.

I wanted to sit and understand something

I was reading about a software stack and kept encountering names whose relationships I did not understand. vart-x, vart-ml, flexmlrt, voe, onnxruntime-vitisai. I could identify them as software packages. That was not the information I was missing.

I wanted to know what they did. Which one prepared an image? Which one ran a model? Were these alternatives, or layers that all had to be used together? Where would I encounter them in a program I was writing?

The original investigation stays private. The examples here use public documentation and newly written material.

Rather than keep reading increasingly long answers in the terminal, I asked the agent to turn the material into a narrated video. It already had the context of my questions. It could consult documentation, write an HTML presentation, synthesize speech and render the result. Why not have it make a little programme specifically for the thing I was trying to understand?

The first version was technically successful

The agent made a substantial slide deck and a glossary. Then it read them to me. The resulting video was thirty-seven minutes long.

It had chapters. It had a transcript. It decoded without errors. It also had the atmosphere of mandatory training. A pleasant voice cannot make a sequence of definitions acquire a reason to be watched.

“this is very unengaging. I still feel like I don't understand what e.g., vart-x, artifactory, etc, are.”

Me, responding to the first video

I asked for normal-speed speech and something shorter. The agent produced a version under five minutes. This improved the duration, but it was still answering the wrong question: it explained why programs need dependencies, then described vart-x as a package containing headers and libraries. I already understood dependencies. The contents were still a black box.

“what I wanted to know is that all these packages are. as in, what they do. what are they for.”

Me, trying again

This was familiar from my first PetaLinux note. An explanation can be accurate at the level it has chosen and almost useless at the level where I am stuck. “It is a runtime library” sounds like an answer until you ask what happens when something calls it.

Getting the subject matter into focus

The agent went back to the public documentation and inspected package contents. That produced a more useful distinction. VART-X provides operations around inference: preparing frames, handling buffers, interpreting outputs and drawing results. VART-ML provides an interface for executing compiled models. ONNX Runtime offers another application-facing inference route. The remaining names concern supporting model-processing and execution machinery.

That is only a compact orientation, not a complete description of the stack. But now there was something to explain visually. We could follow an image into the expected tensor representation, through a runner, and back out as results that still needed interpretation.

The agent rendered another video. Its content was more relevant. Its delivery was still a row of diagrams accompanied by rather evenly paced speech.

“Information should answer wondering, not be presented so fully ‘here it is’.”

Me, describing the missing structure

I suggested the kind of transition I wanted: “How does the compiled model actually run? That brings us to…” The question creates a need for the name. Without it, I am being handed a vocabulary list and left to invent the connections myself.

Follow the frame

We changed the unit of production from a slide to a short explanatory beat. Each beat needed a question, an answer and a visible change. A persistent diagram was more useful than replacing the entire screen at every heading.

The first animated preview was about forty-nine seconds long. It began with the compiled model and asked how an application invokes it. Then it backed up: where does that properly formatted input tensor come from? An image changed representation, data moved between stages, and detections appeared on the output image.

That preview was good enough for me to want more. I asked for a reusable process, tighter transitions, different typography and a less conspicuous music bed. We also kept a version without music, because “the audio file contains music” and “I can hear music on these speakers” are different observations.

What the agent actually built

I was directing and reviewing the experiment. The agent wrote the renderer, prepared the scripts, drew the programmatic graphics and ran the synthesis and encoding. I did not hand-animate the sequence or record a voice-over. My work was deciding what I needed to understand, watching the attempts, identifying where they missed, and changing the brief.

The pipeline is local. A JSON manifest holds the narration, beats, pauses, source references and audio settings. An HTML Canvas renderer draws the scene at a specified timestamp. Playwright drives Chrome; a speech backend produces the narration; FFmpeg combines animation and audio. We began with Piper and later added Kokoro and Qwen. The background music was synthesized locally rather than taken from a recording.

question + evidence
        ↓
script + visual beats
        ↓
cached speech + measured timing
        ↓
timestamp-driven animation + audio mix
        ↓
video + captions + transcript + provenance

The agent moved the reusable machinery into a user-wide installation and registered an authoring skill, so another subject need not start with another renderer. The renderer is reusable. The thinking that makes a particular explanation work is still specific to the question.

Reproducible, within useful limits

Speech takes are cached by text, voice settings, model and configuration hashes, and engine version. Changing a diagram does not require generating the voice again. Frame generation is driven by time rather than by how quickly the browser happens to run.

Each render retains its transcript, captions, audio stems and provenance: source hashes, versions, settings and the encoding command. This is enough to inspect what produced an artifact and rerender it with the same inputs. It is not a claim that fresh speech synthesis will be bit-identical on a different installation. Keeping the actual generated takes is important.

One intermediate film ran for seventeen and a half minutes. Rendering and validation took about ten and a half minutes with speech already cached. That excluded the earlier speech generation, research and authoring.

When I asked about cost, though, I meant tokens and agent effort. The expensive part had been misunderstanding the brief and repeatedly making the wrong thing. Local rendering does not need the language model to generate a response for every video frame. Research, scriptwriting, custom graphics and revision are where the model work goes. We did not have reliable session token totals, so there is no measured monetary saving to report.

The long version exposed another problem

My reaction to the full version was “much better,” followed by the observation that it became hard to watch after about five minutes. The diagrams moved, but often in the same way. The voice was clear, but emphasis and pacing were too uniform.

A short preview had tested whether I liked the direction. It had not tested whether that direction could sustain attention for several minutes.

More animation is not quite the requirement either. I want the image to do explanatory work: reveal the relevant line of code, follow a buffer, show where two paths differ, stop at the point where an assumption fails. A dot travelling through three boxes can become as monotonous as a static bullet list.

For the voice, we reached the limits of what adjusting Piper’s speed and punctuation could reliably achieve. “More expressive” should mean that the sentence communicates its meaning better, not that the narrator sounds perpetually excited. We needed a comparison in which the words stayed the same.

Same passage, different delivery

The agent generated one passage with the existing Piper setup, Kokoro, and Qwen3-TTS with an instruction to make the questions and contrasts audible without adopting an announcer’s delivery. Four samples are included below. The passage follows the frame-processing example above. These are actual generated samples, not vendor demonstrations. Playback levels have been approximately matched.

“The model is compiled. So what actually runs it? … But that is not the whole video pipeline. … Vart X prepares that input. Vart M L runs the model.”

The same public-safe audition passage across these samples

On this machine, each Kokoro sample took about nine seconds to generate roughly thirty-one to thirty-five seconds of speech. Qwen’s instruction-directed sample produced about thirty-nine seconds of speech in six minutes nineteen seconds on the CPU, excluding model loading. Its initial load and download phase took another seven minutes twenty-three seconds. Those figures describe this run, not a general engine benchmark.

Listening settled something that the timings could not. The Qwen-directed sample had much more colour in its delivery: changes in tone and emphasis made it substantially easier for me to follow. That is the direction I want to pursue. Kokoro makes repeated experiments inexpensive, but the performance matters more than generation speed when the result is something I have to watch. Chatterbox remains untested; this is a preference among the samples I heard, not a universal ranking.

The CPU run was an unnecessarily limited first test on a machine with an AMD GPU. We subsequently reused the existing ROCm PyTorch environment supplied with Lemonade rather than replacing its managed installation. An unrestricted attempt was disruptive; the cause was not established, and the GPU logs showed queue timeouts and resets. After competing workloads were paused, we used a monitored, memory-bounded probe instead of immediately repeating a long run.

Profiling exposed an audio-decoder bottleneck in this particular setup. A short test spent about twenty-seven seconds in the MIOpen decoding path. Disabling that path, while keeping the computation on the GPU, reduced the decoder phase to about 0.13 seconds in a comparable short run. That was a local workaround, not a claim about every AMD GPU or every Qwen installation. A longer passage then completed, and we generated the narration in bounded, cached takes. Model loading alone had not established that the whole pipeline was efficient.

An intermediate public example

This five-minute-nineteen-second Qwen film is an earlier attempt. It still has the speaker-continuity and pacing problems we subsequently worked on. Keep it in mind when you reach the later example under Mr-Beastification.

The script below was written separately from public component descriptions. The diagram develops through more visual stages than the first attempts, but the repeated pattern was still too much like a presentation.

With narration cached, this public video rendered and validated in about seventy-seven seconds. Speech generation was substantially longer—typically around one-and-a-half to two times playback duration in these runs. Rendering and speech generation are separate costs.

A good voice sample is not a consistent narrator

The longer Qwen film had more expressive speech, but the joins between passages were jarring. Eventually the speaker identity changed conspicuously. We had generated each passage independently with VoiceDesign, reusing the description and random seed. That had not fixed the identity of the narrator. We had confused asking for similar characteristics with conditioning every take on the same voice.

The next experiment used Qwen’s Base model with the approved synthetic sample and its exact transcript as a reusable reference prompt. Two independent takes were generated from that same reference: one posed a question about an unlisted package, and the other answered it. They produced about eight seconds of speech each in fourteen and sixteen seconds of generation. At that point, we had established that the reference-conditioned path ran on the GPU. Listening still had to settle whether the joins worked.

There is a useful distinction between designing a voice and continuing one. The generated reference is now an explicit input to the experiment, rather than an identity we hope the model will independently invent again.

The pictures needed a different experiment too

I also found the film too slow and the music soporific. The measured narration was around 144–147 words a minute. That number did not explain away the experience: the writing repeatedly introduced a component, defined it, restated its role, and moved to another similar diagram. Changing the voice had left much of the lecture rhythm intact.

I wanted the kind of visual reasoning that makes a technical explanation absorbing: something happens on screen, it seems surprising, and the explanation resolves the surprise. More moving arrows were not going to do it.

We stopped producing full films and made a seventeen-second, music-free pilot around a worked HTTP example. An illustrative browser page omits a project name; a request for that name directly returns a page. The screen shows the two requests and what each response establishes. This is a newly authored demonstration, not a capture of the underlying investigation. It uses the two reference-conditioned takes, so the narrative and speaker joins can be judged together.

With narration cached, that pilot rendered and validated in about six seconds. The costly part remains generating speech and deciding what is worth showing. The next listening and viewing test has a much smaller scope: is the speaker continuous, is the question resolved, and does the picture carry some of the reasoning? If not, another twenty-minute render would merely multiply the problem.

This time, the listening test worked: I found the narration continuous and the worked-example visuals much more effective. My next request was to make the speaking quicker—roughly 1.33×. The agent time-compressed the existing audio, preserving pitch, and accelerated the animation to match. It was cheap, but sounded like speech that had been sped up. That was exactly what it was.

I wanted someone speaking briskly, not the same performance squeezed into less time. Natural fast delivery changes articulation, emphasis and the placement of pauses, rather than shortening everything equally. We needed a newly generated reference performance, then a check that conditioning subsequent takes on it retained that delivery. The time-compressed version remains a useful failed comparison, not the chosen production pace.

We then tried asking directly for an “enthusiastic, fast-paced and engaging” performance. That overshot in a different direction: the delivery sounded like a children’s presenter. I did not want a binary choice between exaggerated excitement and flat obligation. I meant the interest of someone sharing an elegant construction with a colleague—the energy comes from noticing why the idea works.

A further audition aimed for that intellectual delight, with connected speech and controlled emphasis. This was close enough that I approved it as the reference for the full rebuild.

The reusable narration worker now supports that distinction explicitly: it builds one Base-model conditioning prompt from the approved synthetic audio and its exact transcript, then reuses it across passages. The reference audio hash and transcript are part of the cache identity. The new full-film script is shorter and its visual sequences are written around operations—image normalization, graph grouping, code execution and file staging—rather than a recurring component diagram.

The rebuild produced an eleven-minute-thirty-four-second, music-free film, with speech around 156 words a minute. GPU narration took about twenty-two and a half minutes; rendering and validation took another two minutes fifty-two seconds with the speech cached. This time, I watched it.

Mr-Beastification

Watching the longer private film, I was absorbed. The narration had urgency: the distinctions felt consequential, and I wanted to follow where the explanation was going. The feeling of importance finally matched the enthusiasm I already felt for the subject.

“This is gripping.”

Me, watching the rebuilt private film

More importantly, I could now make sense of the roles of VART-X, VART-ML, flexmlrt and VOE. Those were the names that had started this. Following the work through the system had given them something to mean. I was no longer trying to remember four definitions and construct their relationships afterwards.

I noticed that I could not hear any music, and did not care. There was none. The explanation and delivery carried the momentum without it.

Leaving it running made the difference even clearer. I could have opened Twitter. Instead, my attention kept landing on the explanation. The narrator’s tone made the drama and action of computing feel appropriately interesting: things were being transformed, invoked, retrieved and discovered. That is how cool this work feels to me in real life. Finally, the video felt that way too.

There was one clear flaw: during transitions, on-screen text appeared significantly before the corresponding narration. It revealed things before the voice reached them. A few small visual imperfections remained too. Those reveals need to follow the spoken explanation more closely.

Where this leaves the experiment

I now have a working way to request and revise a private informational film using material I am already investigating. That seems worth keeping. It is adjacent to my interest in making mathematical explanations, except that here I am also the intended viewer, and the explanation can be revised around my immediate confusion.

The useful result was an explanation that followed my questions closely enough to get me unstuck. The agent had the context, could inspect public documentation and artifacts, and could do the mechanical production work. I could interrupt when the account was technically accurate but still explained nothing I was wondering about. It took several such interruptions to get here.

This note was drafted with the agent from that recorded exchange. I supplied the direction, the criticism and the decision to document the experiment. The final viewing held my attention and left me understanding relationships I had struggled with at the start. Whether I retain that understanding and can use it in practice is still to come. For now, I am tickled pink.

My next reaction was to want thousands of these—not a literal production quota, but a way to learn like this whenever I get stuck. That changes the engineering question. We need to preserve the actual reference performance, transcript, model revision and accepted takes, rather than merely save an adjective-filled voice prompt. The agent archived a hash-verified production snapshot and added the beginnings of resumable batch execution. Caching avoids generating the same speech twice. Making new explanations this good, cheaply and repeatedly enough to become an everyday learning tool, is the next experiment.

We checked the first part rather than just calling it reproducible: replaying the archived sources and narration on the same setup produced an MP4 with exactly the same SHA-256 hash as the accepted film. That preserves this performance. It does not establish that fresh stochastic speech on another topic or machine will sound identical. The reusable profile pins the model revision and reference; the next useful test is whether several different explanations retain what made this one work.

I want to use this when an unfamiliar software boundary or processing path stops making sense: make an explanation around that question, then return to building and testing. Embedded Linux and computer vision give me plenty of opportunities to find out whether it helps.

□

Public references

AMD: VART-X and VART-ML — public descriptions of the component roles used in the stripped-down example.

Piper · Playwright · FFmpeg — the local production tools.

Kokoro · Qwen3-TTS — the additional synthesis candidates exercised here. Chatterbox remains untested.