Support for embedding STL files

[braincoded]

It would be a very useful feature for SCF to add support for handling embedded STL files (BASE64 encoding) during the conversion from STL to EBU-TT and to be able to extract embedded files.

http://bbc.github.io/subtitle-guidelines/#Embedded-STL

[spoeschel]

Sorry; closed by mistake (internal issue ID)

[ianbarrett]

Hi,

At Channel4 we have our entire history of subtitles in EBU-STL format, and our new media services provider (who will maintain our repository of subtitles) will be storing, and expect new subtitles to be delivered in EBU-TT format. We need to have the source STL file embedded within this, to enable simplistic extract and delivery to our playout provider who are still working in EBU-STL.

Tools that we use for authoring subtitles don't current support this format, so we are looking to export STL files still, and then convert them (ideally using this SCF) to deliver them to our media services provider with the STL embedded so that they have a consistent way of receiving and processing subtitle files.

Thanks,

Ian

[andreastai]

@ianbarrett makes sense and thanks for your request and does also match the request from @braincoded.

Tunneling of binary data is defined now in EBU Tech 3390 (EBU-TT Metadata). It was before defined in EBU Tech 3350 (EBU-TT Part 1). @ianbarrett and @braincoded Please have a look at Tech 3390 Chapter 3.5 if this match your requirement.

We should follow also Tech 3360 which is the guideline to convert EBU STL to EBU TT Part 1. See Chapter 2.3 of Tech 3360. One implementation question is where to place the tunneled data. It may be good to follow the recommendation of Tech 3360 to place it at the end.

[andreastai]

For the implementation this might be an option when converting STL to STLXML with the stl2stlxml Python Script. From there it can be added to the EBU-TT Part 1 file.

Another interesting question is about roundtripping. SCF provides a way to convert Part 1 (i.e. STLXML) back to STL. If a Part 1 document has an embedded STL the question is if the user needs an option so that he can decide if he wants to convert the EBU-TT file or the embedded STL file back to the binary STL file.

[ianbarrett]

@TairT I'd be very happy to follow the guidance in the Tech 3360 and Tech 3390.

I think putting it at the end is the best option here. We should also try and follow the other rules in these specifications

eg: Removing the following fields :
ebuttm:stlCreationDate
ebuttm:stlRevisionDate
ebuttm:stlRevisionNumber

and instead populating the attributes of the ebuttm:binaryData field.

Ideally we would also include the relevant fields/section in the head/metadata:
ebuttm:documentOriginatingSystem
ebuttm:conformsToStandard
ebuttm:appliedProcessing
ebuttm:stlConversion/*
ebuttm:subtitleZero

In terms of the roundtripping question, I think having the option about which you would like to use is a good idea. I see in the spec, that the expected behaviour over time is that if the XML is updated, so the STL is no longer valid, the binaryData should be removed.... but it may be an interesting way to track changes since conversion if you were to restore both the XML, and the embedded STL, and compare them. It's a bit academic, but could be useful.

[andreastai]

@ianbarrett Thanks!

I think putting it at the end is the best option here. We should also try and follow the other rules in these specifications
eg: Removing the following fields :
ebuttm:stlCreationDate
ebuttm:stlRevisionDate
ebuttm:stlRevisionNumber

True...I haven't thought of that...

Ideally we would also include the relevant fields/section in the head/metadata:
ebuttm:documentOriginatingSystem
ebuttm:conformsToStandard
ebuttm:appliedProcessing
ebuttm:stlConversion/*
ebuttm:subtitleZero

At the moment there is no option to populate EBU-TT files with other data than that is in the STL file itself (@spoeschel correct me if I am wrong). You may have to add an additional step to include this data...

In terms of the roundtripping question, I think having the option about which you would like to use is a good idea. I see in the spec, that the expected behaviour over time is that if the XML is updated, so the STL is no longer valid, the binaryData should be removed.... but it may be an interesting way to track changes since conversion if you were to restore both the XML, and the embedded STL, and compare them. It's a bit academic, but could be useful.

Yes, I can see the use case for it...

[spoeschel]

At the moment there is no option to populate EBU-TT files with other data than that is in the STL file itself (@spoeschel correct me if I am wrong). You may have to add an additional step to include this data...

This is correct. We just provide parameters to modify the handling of timecodes (e.g. to apply a specific offset).

For the implementation this might be an option when converting STL to STLXML with the stl2stlxml Python Script. From there it can be added to the EBU-TT Part 1 file.

This could be done as follows:

• extend our STLXML format
  • contain the source STL file (encoded as Base64; e.g. below an optional element /StlXml/StlSource)
  • this also includes the source STL filename as /StlXml/StlSource/@filename, as Part 2 requires it (in Part M, it is optional)
• STL2STLXML
  • store the source STL file in the StlSource element
  • this behaviour has to be enabled via parameter, as not required by every user and consuming a significant amount of space
• STLXML2EBU-TT
  • (if present) copy the source STL file to a ebuttm:binaryData element, storing it below the last tt:div of the result
  • in that case, STL's CD/RD/RN fields have to be stored on the ebuttm:binaryData element, instead of using the STL fields that Part M provides), as mentioned by @ianbarrett
• STLXML-SplitBlocks: keep a present StlSource element unmodified
• all other modules with STLXML or EBU-TT as source format will ignore/discard any present source STL file

Another interesting question is about roundtripping. SCF provides a way to convert Part 1 (i.e. STLXML) back to STL. If a Part 1 document has an embedded STL the question is if the user needs an option so that he can decide if he wants to convert the EBU-TT file or the embedded STL file back to the binary STL file.

Such an option would have to be added to `EBU-TT2STLXML" then. However, it would change the output format from STLXML to plain STL. So I think this is a task a simple helper XSLT (or XQuery?) module could handle instead, as this would be simply extracting/decoding the binary payload.

@braincoded / @ianbarrett - would all this work for you?

[andreastai]

if present) copy the source STL file to a ebuttm:binaryData element, storing it below the last tt:div of the result

Note that the recommended practice is to add the <ebuttm:binaryData> element inside a <tt:metadata> element that is a child of the last <div> element. This <div> element has no further <p> element as children.

See also Tech Tech 3360 page 28 and Tech 3390 page 21.

[spoeschel]

• extend our STLXML format
  • contain the source STL file (encoded as Base64; e.g. below an optional element /StlXml/StlSource)
  • this also includes the source STL filename as /StlXml/StlSource/@filename, as Part 2 requires it (in Part M, it is optional)

To allow for possible future extensions (we currently can't think of), it would be better to instead use separate elements below /StlXml/StlSource to store filename (./Filename) and the actual data (./Data).

[spoeschel]

• STLXML-SplitBlocks: keep a present StlSource element unmodified

This is indeed already the case; in general all content is copied unmodified by this module.

[spoeschel]

We just released version 1.9.0 that supports optional storage/tunnelling of the STL source file via new parameters, added to the modules STL2STLXML and STLXML2EBU-TT. Note that the overall conversion from EBU STL to EBU-TT is done according to EBU Tech 3360 v0.9, as well as the newly added STL source file processing (which is slightly different compared to v1.0).