ttconv should consider EBU STL format as an output
Vincent-Dabouineau opened this issue · comments
A writer really nice to have. It is difficult to handle / modify a binary format as STL directly. It is easier to deal with the canonical or TTML files (within an automatic subtitling resync process for e.g), then output to the EBU STL « mezzanine » format for next purposes, compliant with the main broadcast workflows at this time.
A writer really nice to have. It is difficult to handle / modify a binary format as STL directly. It is easier to deal with the canonical or TTML files (within an automatic subtitling resync process for e.g), then output to the EBU STL « mezzanine » format for next purposes, compliant with the main broadcast workflows at this time.
@Vincent-Dabouineau Yes, this kind of feature is really helpful and I also thought of this. But as @palemieux mentioned in another issue every input is converted into the internal generic model and then again to all possible output formats. This has to implications:
- An EBU STL writer needs also the handle other input formats like IMSC that have a different or broader feature scope.
- Currently all metadata is discarded.
For 1. you may do something similar was what is currently applied to the SRT writer: you only use very basic features like time, text and colours. But regarding 2.: do you also want to preserve the metadata in the GSI section of the EBU-STL file?
@Vincent-Dabouineau For the time being, you may want to have a look at the Subtitle Conversion Framework. You can translate EBU STL with the STL2STLXML module to an XML representation of STL, manipulate the STLXML and then convert it back to EBU-STL with the STLXML2STL module.
If the processing of the STLXML is too cumbersome you can also translate it to EBU-TT with the STLXML2EBU-TT module, process this TTML form, convert it back to STLXML with the EBU-TT2STLXML module and use as above the STLXML2STL module as last step.
This workflow is used in some operational broadcast workflows.