DASH-IF player cannot properly render ttml with multiple lines

[faiyeah]

Issue observed:
In 1.5.1 player, 2 out of 4 lines are rendered in the player. (as attached as 1_5_1_2_lines_only)
In 2.1.0 player, 1 and a half lines out of 4 lines are rendered in the player. (as attached as 2_1_0_1_and_a_half_line_only)

Expected behavior:
All 4 lines are fully rendered and displayed in the player.

Player that can reproduce the issue:
http://dashif.org/reference/players/javascript/v1.5.1/samples/dash-if-reference-player/
http://dashif.org/reference/players/javascript/v2.1.0/samples/dash-if-reference-player/

Content that can reproduce the issue:
(as attached as 4lines.zip)

Thanks!
Ryan Chan


4lines.zip

[davemevans]

dash.js certainly can render multi-line TTML:

• http://irtdashreference-i.akamaihd.net/dash/live/901161/bfs/manifestARD.mpd
• http://rdmedia.bbc.co.uk/dash/ondemand/elephants_dream/1/client_manifest-all.mpd

However, the TTML parser in dash.js was originally designed as an EBU-TT-D [1] parser which means its only supports a constrained subset of TTML. I assume something in your TTML does not meet these constraints.

[1] https://tech.ebu.ch/docs/tech/tech3380.pdf

[nigelmegitt]

Can you give us access to the TTML content? [Update: I see that it's visible in the zip file]

[faiyeah]

Hi Nigel,

The generated dash content is already attached and submitted with the ticket. Please review.

We are pretty sure the content conforms to specification, just the decoder has some limitations in properly rendering the ttml. Please advise.

Many thanks.

Best regards,
Ryan Chan

• sent from my iPhone

On 19 Apr 2016, at 16:39, Nigel Megitt notifications@github.com wrote:

Can you give us access to the TTML content?

―
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

[nigelmegitt]

Thanks Ryan, I've found it.

It certainly is non-compliant against EBU-TT-D and doesn't validate against the schema, and this is related to the symptom in this case.

The TTML here defines region style attributes on a style element that is then referenced from the region using the style's xml:id. Strictly in EBU-TT-D this is not permitted, because region-only style attributes are prohibited from being placed in style elements; the code acts strictly here and prunes out the prohibited style attributes so they never get through to the region.

This is an area where EBU-TT-D is stricter than TTML; this syntactical approach (of referencing style elements from a region and putting region-applicable style elements in those style elements) is permitted in TTML.

Arguably a more forgiving implementation would not prune out the prohibited style attributes but would honour them anyway, thus making it more broadly applicable to TTML in general.

However I don't understand why the behaviour you're seeing is occurring - the default/initial values for extent and origin would apply in the absence of other style attributes, and text should not fall off the bottom in that case. There's possibly something else at play too.

[faiyeah]

Thanks for fixing the issue, David.
I have ported the fix to master branch and verified the fix is working for me.
Do you have plan to merge it to master branch, so that the fix would appear in nightly build of DASH-IF player?

Thanks for quick resolution of the issue.

Ryan Chan

[davemevans]

Great, thanks for the confirmation.

Assuming no one else howls, @AkamaiDASH will need to do the merge. I imagine it will happen once 2.1.1 has been released which will probably be in the next couple of days.

[faiyeah]

Got it. Thanks a lot :)