Handle partial transcript chunks in live transcriptions

[danxuliu]

Follow up to #15696

Originally the live_transcription app sent the transcripts once they were definitive, so each transcript could take several seconds to be received until the app was "confident" enough and settled on a text. Now it will send transcripts as soon as possible instead, and a final attribute is now included in the signaling message to mark whether a transcript is "frozen" or should be replaced with the next transcript.

For backwards compatibility any transcript message without an explicit final attribute is seen as final.

How to test

• Fake having the live_transcription app as described in Add support for live transcriptions in calls #15696
• Create a new conversation
• Start a call
• In a private window, join as another participant
• Execute the following in the browser console:

OCA.Talk.SimpleWebRTC.connection.sendCallMessage({ type: 'transcript', message: 'this', langId: 'en', final: false, speakerSessionId: OCA.Talk.SimpleWebRTC.connection.getSessionId(), to: OCA.Talk.SimpleWebRTC.webrtc.peers[1].id })
OCA.Talk.SimpleWebRTC.connection.sendCallMessage({ type: 'transcript', message: 'this is', langId: 'en', final: false, speakerSessionId: OCA.Talk.SimpleWebRTC.connection.getSessionId(), to: OCA.Talk.SimpleWebRTC.webrtc.peers[1].id })
OCA.Talk.SimpleWebRTC.connection.sendCallMessage({ type: 'transcript', message: 'this is a test', langId: 'en', final: true, speakerSessionId: OCA.Talk.SimpleWebRTC.connection.getSessionId(), to: OCA.Talk.SimpleWebRTC.webrtc.peers[1].id })

Result with this pull request

This is a test is shown in the transcription

Result without this pull request

This this is this is a test is shown in the transcription

TODO

• Test with the live_transcription app
• Ensure that once a message for a new participant is received there will be no updates to partial messages from previous participants As each audio stream is handled separately by the live_transcription app it is possible that an update to a partial transcript of participant 1 is received once a transcript for participant 2 is already received.
  • This seems to work fine, as right now another transcript block would be added for the partial transcript of participant 1 (as it does not have the same author as the last transcript). Although partially repeating a previous transcript in a new block may look a bit strange it could still be better than modifying a previous transcript block when another one is already shown below it, which could be a bit confusing and/or hard to follow (and if a previous transcript block is kept being updated until a final message is received it could also happen that the transcript block is no longer visible if a third speaker appeared in the meantime)
• Maybe set min-height in a wrapper around all the transcript blocks rather than in the last transcript block. This could prevent having blank lines if participant 1 sent a partial message, then updated it with a second message shorter than the previous one that caused a blank line to be added, and then participant 2 sent another message that creates a new transcript block and leaves the previous one with the blank lines. However, this seems to be an uncommon scenario, so for now it is fine if sometimes there are blank lines between blocks.
  • This would require updating the min-height of the wrapper around all transcript blocks when a no longer visible block is removed.
  • That may not work if a transcript block of a previous participant is updated once another transcript block is already shown, although as mentioned above updating a transcript block other than the last one may not be a good approach

[Antreesy]

Looks fine

[danxuliu]

/backport to stable32