MediaArea / MediaConch_SourceCode

Media conformance checker
https://MediaArea.net/MediaConch
BSD 2-Clause "Simplified" License
29 stars 18 forks source link

Feature Request: Max count of visible lines for TTML when there are 2 p elements + </br> elements with same time stamp. #722

Closed jsciame closed 2 years ago

jsciame commented 2 years ago

Currently, in MediaConch, we have these values:

What we are missing is Max count of visible lines for TTML when there are 2 p elements + </br> elements with same time stamp.

Max number of lines per event. I see there is a MaxCountPerEvent which is per literal <p>, but what we would want to include is MaxCountPerEvent based on being on screen at the same time. i.e. if you had the below with two <p> elements and two <br/> elements and the same begin and end, these are on screen at the same time and would generally be offset using origin / extent to define the locations. I would count something like this as 4 lines and would be a rejection or at least something we’d want an operator to look closer at. Longer term, as we look at QC tools surrounding the qc of timed text files, we’d want to not only know the max number of linese but time values of all lines over a certain length so we can have qc review those spots specifically.

Can this check be added? Any thoughts about adding ability to return time values where those checks fail and not just max? Max is good for a summary view but what we are really after is places where an operator needs to review.

JeromeMartinez commented 2 years ago

but what we would want to include is MaxCountPerEvent based on being on screen at the same time.

Implemented with https://github.com/MediaArea/MediaInfoLib/pull/1505. Note that it also supports overlapping or nested elements e.g. 1 to 3 and 2 to 4, or 1 to 4 and 2 to 3, the max will be computed with the sum of both elements because both are displayed between 2 to 3.

Any thoughts about adding ability to return time values where those checks fail and not just max? Max is good for a summary view but what we are really after is places where an operator needs to review.

In practice it is technically different, the current implementation is a report without flagging an error (you'll flag it as an error based on the policy feature), the time values are valid from the spec point of view, so there is the need to add an option dedicated to your own limit. The option would accept a max e.g. 3 and time values above this max would be listed in a dedicated field. This ticket is dedicated to the reporting part and is closed due to the implementation of the feature, please open a ticket dedicated to the implementation of the option.