rfc: add ttaas transcription rfc proposal#2185
Conversation
|
|
||
| ### Opt-in (per video) | ||
|
|
||
| TTaaS is opt-in, disabled by default. Since users may supply their own subtitles, transcription must never run implicitly or contend with a user-provided transcript. |
There was a problem hiding this comment.
Given that users rarely upload them, I would invert this and make it an opt-out feature instead.
|
|
||
| ### Subtitle provenance | ||
|
|
||
| TTaaS output is machine-generated and must be distinguishable from user-provided files so a re-run never clobbers a corrected transcript. Tag stored files with e.g. `generated_by=ttaas`. TTaaS also exposes an editor (`GET /editor/{media_id}/` → `editUrl`/`viewUrl`); edits made there can be re-fetched on a later poll or manual refresh if we choose to surface that. |
There was a problem hiding this comment.
we have already tagged these in the system as "autogenerated", there is a tag for these files (@zubeydecivelek knows more) . I think it would be nice to distinguish them in the upload form from the user uploaded e.g indicate that one is autogenerated if not done already. If we have this distinction I would not make the system strict and allow only one type of subtitle, what do you think?
There was a problem hiding this comment.
Yes, exactly we already have this distinction as object tag on subtitle files: autogenerated=true. I think we can use the same tag.
Existing autogenerated tag handling:
- Commit: 9993035
- Script to upload autogenerated subtitles: https://gitlab.cern.ch/cds-team/production_scripts/-/blob/master/videos/upload_subtitles.py?ref_type=heads#L72
I also agree that we should not make the system too strict. Autogenerated subtitles and user-uploaded subtitles should be exist together, and users can choose which subtitle to display
|
|
||
| ### Polling strategy | ||
|
|
||
| Poll interval, backoff, and hard timeout; scheduling that survives worker restarts without pinning a worker (recurrent self-re-enqueuing task vs blocking loop). |
There was a problem hiding this comment.
The task should probably follow a similar approach to the Transcoding task i.e lets users publish and the recurrent task polls the TTaaS service and uploads the files to the draft or published video depending on the case.
|
|
||
| ### Token and account model | ||
|
|
||
| Single Bearer token tied to a service account. One shared account for all transcriptions vs per-context; provisioning, rotation, storage. Confirm quota limits. |
There was a problem hiding this comment.
This I guess is enough to have a service account and the token provided by the TTaaS service
|
|
||
| ### Reprocessing and editing ownership | ||
|
|
||
| Checksum dedup means re-ingesting the same master returns the existing TTaaS media. Define the re-run policy and ownership once a transcript can also be edited in the TTaaS editor; guarantee user-edited subtitles are never overwritten. |
There was a problem hiding this comment.
I am not sure I understand the question/concern here...
|
|
||
| ### Weblectures multi-video records | ||
|
|
||
| Presenter vs presentation track: which is transcribed, and how it maps when videos are stored as additional files. |
There was a problem hiding this comment.
We will support this only for the master file (we need to decide what is the minimum efficient video quality they need to extract the transcription or even send the audio only). Presenter/presentation are added as additional files and for these we dont provision to support automatic transcription
3 participants
RFC proposal for the implementation of ttaas transcription.
addresses #2182