Sentioscope

Speech and voice controls, as each vendor documents them

PixVerse: lip sync is the endpoint's name, not its method

Lip sync is what the endpoint is called, and the speaker id from the voice list is passed on its request. That is a routing detail rather than a mechanism: it says which voice, and not what the mouth follows. From 2 source pages, read 2026-10-25; no maker pays to be listed.

A voice named, and a mechanism still missingPassing a speaker id on the lip-sync request identifies the voice, which is half of the two-speaker problem. What happens to the second face, and what the movement is generated from, are both unaddressed.AnsweredNot answeredWhich voiceThe speaker id on the requestWhat the second face doesHow many at onceOne id, so one speaking partHow a conversation is assembledWhat drives itNothing statedAudio, text, or a later passHow longLimits exist, per endpointWhere they sit, or whether alignmentdegradesAn endpoint name is the weakest kind of claim
Fig. 1 A product can call an endpoint anything, so treating the name as documentation would put this cell on a footing it has not earned.
PixVerse on lip-sync, statement by statement. Read from the vendor's lip-sync reference and voice pages on 2026-10-25.
What the documentation settlesWhat it leaves to a take
The endpoint is documented for lip sync, with uploaded audio or text read by a voiceWhat the movement is generated from
A speaker id taken from the TTS list is passed on the lip-sync requestWhether more than one speaker can be handled in one generation
Each downstream endpoint sets its own duration and file-size limitsWhether alignment degrades towards the end of a long take

Inclusion rule. Only statements found on the vendor page named in the caption, and only ones bearing on this one field. Nothing here is filled in from generated output. Order. In the order the statements arrive on the vendor's page.

1A voice named, a face still unaddressed

Most entries that name lip-sync say nothing about which voice is involved. Passing a speaker id on the request at least identifies the speaker, which is half of the two-speaker problem. The other half, what happens to a second face in the frame, is not addressed.

One id per request suggests one speaking part per generation, so a conversation is assembled from alternating calls. That is a workable pattern and it means the shot list carries the turn-taking rather than the prompt.

2An endpoint name is the weakest kind of claim

A product can call an endpoint anything. Treating the name as documentation of a capability would put this cell on the same footing as one that describes a driver, and the two are not comparable: a name cannot be tested against a mechanism.

So the cell records the endpoint's purpose and marks the driver absent. Combined with the unpublished limits and the two audio modes, it is enough to plan a short piece and not enough to predict how the face will behave in it.

3The others that name the feature and stop

Three more entries name lip-sync and leave the driver out. This is the only one where the claim is carried by the name of the endpoint itself.

  • HeyGen — named, alongside translation.
  • Kling AI — named, with nothing driving it.
  • Sora 2 — named only where it fails.
  • Audio source
    Audio on a lip-sync request is either the id of an uploaded audio file or both text-to-speech fields, a speaker id and the text, and the two modes are not mixeda supplied recording or text read by a voicePixVerse, Lipsync reference / recorded 2026-10-25
  • Per-character binding
    A speaker id taken from the TTS list is passed as the lip-sync speaker id on the request, beside the text to be reada speaker id per callPixVerse, Lipsync reference / recorded 2026-10-25
  • Containers accepted
    Uploads accept MP4, MOV or WebM video and MP3, WAV, M4A or AAC audio, and each downstream endpoint sets its own duration, codec, dimension and file-size limitslimits left to each endpointPixVerse, Upload Media reference / recorded 2026-10-25

4Speech, generated with the picture

For the speech side of “PixVerse, lip-sync”, SceneMixer's guides describe how lines are spoken:

The final cut ends on an end card: your main image plus four lines — Brand, Product name, Tagline, Call to action. The first two are read from your photo and your brief; the tagline and call to action are written with the script.

SceneMixer, The End Card (read 2026-10-13)

The new name is written everywhere the old one stood: storyboard lines, episode titles and summaries, the scene lists and already-parsed dialogue.

SceneMixer, Reusing a Character, Scene or Voice Across Projects — “What happens to the old name in the storyboard?” (read 2026-10-13)

5Sources

Read from the lip-sync reference and voice pages at docs.platform.pixverse.ai on 2026-10-25. The same column across every entry is on lip-sync; everything this vendor publishes about speech is on PixVerse. What counts as documented is on how read.