You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Applying offset when 'subtitle zero' is present leads to termination #13
<xsl:iftest="$mediaHours < 0 or $mediaMinutes < 0 or $mediaSeconds < 0 or $mediaFrames < 0">
<xsl:messageterminate="yes">
The chosen offset would result in a negative timestamp for a time value.
</xsl:message>
</xsl:if>
If the source STL file has subtitle zero and the relevant offset is applied this always results in a termination. The preferred behaviour here should be to omit the content elements with negative timestamps from the file and possibly issue a warning message.
Thanks for raising this. There have been a similiar comment, where users wanted to discard the first part of an EBU-TT file using the offsetInSeconcd parameter.
For those who do not know the subtitle zero convention a description can be found in EBU Tech 3350 (page 43) and EBU Tech 3360 (page 9). Subtite zero refers to a convention where programme related metadata is documented in a subtitle but the timecode for this "metadata" subtitle is set outside of the timecodes of the subtitled programm. So for example the begin timecode of this subtitle is set to "00:00:00:00" but the start time code of the related media is "10:00:00:00". This convention is used in some countries like the UK while in other countries (like Germany) it is not used or not used anymore.
There are two questions here:
How a conversion from EBU-TT Part 1 to EBU-TT-D should handle subtitle zero metadata present in a timed p or span element?
What is the processor behaviour if the subtraction of an offset (in seconds or frames) from a begin or end attribute results in a negative value?
To start with the second question. As the other features the offset feature has been implemented based on requirements (by accident the requirements, requirement 337 and 349, have not been added to the documentation but are present now, apologies for that). These requirements define the abortion of the processing if the result is a negative time expression. In a lot of cases this makes sense because often a default offset (or the value from the documentStartOfProgram) is taken and it is not correct for the files where it is applied. Often a default offset of "10:00:00:00" is taken but the start of the related media has a time code below "10:00:00:00".
But there is also the scenario (as you comment) where you want to discard subtitle content. In this case it maybe be good to add a second parameter that does not abort processing if the calculation results in negative timestamps but just omits the content. An alternative would be to have a strict and lax mode of conversion scripts. In the strict mode you would abort processing and lax mode you would omit the content.
Regarding subtitle zero the recommended practice in EBU-TT Tech 3360 version 0.9 is to map the content into metadata in the head of the document (with EBU-TT Tech 3350 version 1.1 there is a dedicated metadata field for it). But as in the context of use subtitles may still be used to carry metadata this new option (to omit subtitle content with negative timestamps) is needed.
As you know, due to the advent of EBU-TT Part 2 v1.0, the method of storing subtitle zero data has changed compared to v0.9. SCF currently targets EBU-TT Part 1 v1.0, but the support could possibly be extended sometime. Hence we will internally discuss how we will address the subtitle zero storage here, and subsequently the way to handle this issue here.
Activity
Resolve issue IRT-Open-Source#13
Merge pull request #1 from bbc/issue-13
andreastai commentedon Jan 10, 2016
Thanks for raising this. There have been a similiar comment, where users wanted to discard the first part of an EBU-TT file using the offsetInSeconcd parameter.
For those who do not know the subtitle zero convention a description can be found in EBU Tech 3350 (page 43) and EBU Tech 3360 (page 9). Subtite zero refers to a convention where programme related metadata is documented in a subtitle but the timecode for this "metadata" subtitle is set outside of the timecodes of the subtitled programm. So for example the begin timecode of this subtitle is set to "00:00:00:00" but the start time code of the related media is "10:00:00:00". This convention is used in some countries like the UK while in other countries (like Germany) it is not used or not used anymore.
There are two questions here:
porspanelement?beginorendattribute results in a negative value?To start with the second question. As the other features the offset feature has been implemented based on requirements (by accident the requirements, requirement 337 and 349, have not been added to the documentation but are present now, apologies for that). These requirements define the abortion of the processing if the result is a negative time expression. In a lot of cases this makes sense because often a default offset (or the value from the documentStartOfProgram) is taken and it is not correct for the files where it is applied. Often a default offset of "10:00:00:00" is taken but the start of the related media has a time code below "10:00:00:00".
But there is also the scenario (as you comment) where you want to discard subtitle content. In this case it maybe be good to add a second parameter that does not abort processing if the calculation results in negative timestamps but just omits the content. An alternative would be to have a strict and lax mode of conversion scripts. In the strict mode you would abort processing and lax mode you would omit the content.
Regarding subtitle zero the recommended practice in EBU-TT Tech 3360 version 0.9 is to map the content into metadata in the head of the document (with EBU-TT Tech 3350 version 1.1 there is a dedicated metadata field for it). But as in the context of use subtitles may still be used to carry metadata this new option (to omit subtitle content with negative timestamps) is needed.
spoeschel commentedon Jun 22, 2017
Sorry for the late answer!
As you know, due to the advent of EBU-TT Part 2 v1.0, the method of storing subtitle zero data has changed compared to v0.9. SCF currently targets EBU-TT Part 1 v1.0, but the support could possibly be extended sometime. Hence we will internally discuss how we will address the subtitle zero storage here, and subsequently the way to handle this issue here.
spoeschel commentedon Oct 5, 2017
Sorry; closed by mistake (internal issue ID)