Edge is not able to parse VTT file generated by AMS v3 RRS feed

  • Question

  • The VTT generated by AMS v3 has some “NOTE” in the top of the vtt file. Edge and IE11 Browsers are complaining about it. It throws below parsing error. Same VTT files works fine in Chrome and firefox.

    MEDIA12608: WebVTT Text Track: Timestamp signature should be '-->'. hr=80004004. 

    If we remove the following “NOTE” from top, the same vtt works fine on Edge and IE11.




    NOTE Confidence: 0.911574065685272

    It seems like multiple line comment is causing problem here. Below are different permutations I've tried cases where we get errors. In 1st and 3rd case I'm getting error but in 2nd and 4th case I'm not getting any error. So it seems like if we are having multiline comment in VTT file Edge and IE11 is throwing error.



    NOTE duration:”00:10:07.0110000” language:en-US

    NOTE Confidence: 0.911574065685272



    NOTE Confidence: 0.911574065685272



    NOTE duration:"00:10:07.0110000" language:en-US

    NOTE Confidence: 0.911574065685272



    NOTE duration:"00:10:07.0110000"

    NOTE language:en-US

    NOTE Confidence: 0.911574065685272

    Please let me know if someone have nny suggestions or work around to fix the issue in Edge and IE11?

    • Edited by avikumar8747 Wednesday, May 8, 2019 11:19 PM Updated
    Wednesday, May 8, 2019 11:14 PM

All replies

  • Hi, 

    This is a known bug in the older VTT parsers for Edge and IE11.   The VTT parser in those versions did not support the multiline comment format in the WebVTT specification. (It may have been added in a later revision)

    The comment type of NOTE  is an allowed comment type in section 1.5 of the WebVTT spec – and the Video Indexer output is using it correctly - but the built in parser on Edge and IE do not handle the multiline comment. 

    The VTT file appears to work fine in other browsers and Player frameworks.  For example the Azure Media Player has it's own parser and does not rely on the one in Edge or IE and can handle the comment. 

    We are going to fix this issue by modifying our pipeline to output the comment without the multiline and use single line comments for those sections. 

    For example, the updated output will look like the following when we fix the issue in our pipeline. Once this is fixed we can update this thread on the forum.  For now, you would have to make this edit on your own, or just strip out the multiline comments from the output. 

    NOTE duration:"00:10:07.0110000"
    NOTE language:en-US
    NOTE Confidence: 0.911574065685272
    Unfortunately, the bug bar on Edge and IE is far to high for us to get a fix directly in the Browser, but you can always submit an issue on the Edge browser team directly.  Since they are moving to Chromium in Edge, this issue should not be a concern and match the Chrome behavior.  Although, we will solve it by fixing the comments as noted above. 

    Spec reference is here for others information : ://w3c.github.io/webvtt/#introduction-comments

                  Comments are just blocks that are preceded by a blank line, start with the word "NOTE" (followed by a space or newline), and end at the first blank line.”

    See Example 10 for a reference in the spec.  




    This file was written by Jill. I hope

    you enjoy reading it. Some things to

    bear in mind:

    - I was lip-reading, so the cues may

    not be 100% accurate

    - I didn’t pay too close attention to

    when the cues should start or end.


    00:01.000 --> 00:04.000

    Never drink liquid nitrogen.


    NOTE check next cue


    00:05.000 --> 00:09.000

    Wednesday, May 8, 2019 11:25 PM
  • Hello, I just wanted to point out that .vtt parsing for edge based on chromium is still different from Google chrome and Firefox. I have recently ran into the problem where some cues are not being shown or triggered by the cuechange event of its track element. Investigating the 'in-memory' cuelist showed that edge/ie just skips cues when the specified time interval is 0. This makes me think that those Microsoft products have their own faulty parsing engine. :-(

    See a more detailed problem description here:


    Sunday, April 26, 2020 12:45 AM