Repository navigation
Support for embedding STL files #39
Description
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.
Reacted by Nigel Megitt
Activity
spoeschel commentedon Oct 5, 2017
Sorry; closed by mistake (internal issue ID)
ianbarrett commentedon May 28, 2020
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 commentedon May 28, 2020
@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 commentedon May 28, 2020
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 commentedon May 28, 2020
@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 commentedon May 29, 2020
@ianbarrett Thanks!
True...I haven't thought of that...
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...
Yes, I can see the use case for it...
spoeschel commentedon Jul 17, 2020
This is correct. We just provide parameters to modify the handling of timecodes (e.g. to apply a specific offset).
This could be done as follows:
/StlXml/StlSource)/StlXml/StlSource/@filename, as Part 2 requires it (in Part M, it is optional)STL2STLXMLStlSourceelementSTLXML2EBU-TTebuttm:binaryDataelement, storing it below the lasttt:divof the resultCD/RD/RNfields have to be stored on theebuttm:binaryDataelement, instead of using the STL fields that Part M provides), as mentioned by @ianbarrettSTLXML-SplitBlocks: keep a presentStlSourceelement unmodifiedSuch 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 commentedon Jul 20, 2020
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 commentedon Jul 21, 2020
To allow for possible future extensions (we currently can't think of), it would be better to instead use separate elements below
/StlXml/StlSourceto store filename (./Filename) and the actual data (./Data).spoeschel commentedon Jul 24, 2020
This is indeed already the case; in general all content is copied unmodified by this module.
spoeschel commentedon Jul 31, 2020
We just released version 1.9.0 that supports optional storage/tunnelling of the STL source file via new parameters, added to the modules
STL2STLXMLandSTLXML2EBU-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).