guerreiroluc@ Thanks for the issue.

Tested this issue on Windows 10 on the latest Stable 65.0.3325.181 and Canary 67.0.3379.0 by following the below steps.

1. Launched Chrome and navigated to site(http://g33ktricks.blogspot.in/2016/04/list-of-hls-streaming-video-sample-test.html) for sample HLS files with subtitles.
2. Downloaded a file, but unable to open the file on Chrome/IE.

Request you to provide a test HLS file where this issue can be reproduced, which will help in further triaging of the issue.

Thanks..

Hi Susan, thanks for working on it.
I do not have a HLS available right now, but I can show you the problem on a VOD, which presents exactly the same behavior.
By 14 seconds the first subtitle should be exhibited but there is no subtitles at all (the files are downloaded normally). On older versions it works just fine.
You may see it at https://siriustranslate.com/jw3.html

Thank you!

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

guerreiroluc@ Thanks for the update.

Tested this issue on Windows 10 and Mac OS 10.12.6 on latest Stable 65.0.3325.181 and Canary 67.0.3382.0 as per comment #4.

On navigating to the given link and playing the video, can observe that the subtitles are not seen.
The same behavior is observed on M-60 chrome builds as well.

Attached are the screen casts for reference.

Can you please check and confirm if this is the issue you are seeing?

Thanks..

Deleted: 825798-M60.mp4 1.2 MB

	825798-M60.mp4 1.2 MB View Download

Deleted: 825798-M65.mp4 1.3 MB

	825798-M65.mp4 1.3 MB View Download

Thank you for the reply, Susan.
Yes, this is the problem. I guess the subtitles were not automatically selected although they are being forced to do it.
I am attaching screens on versions 64 and 65 to clarify what I'm experiencing.

Thank you!

Deleted: 825798_user_M64.mp4 1.6 MB

	825798_user_M64.mp4 1.6 MB View Download

Deleted: 825798_user_M65.mp4 2.8 MB

	825798_user_M65.mp4 2.8 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

guerreiroluc@ Thanks for the feedback.

Able to reproduce this issue on Windows 10, Mac OS 10.12.6 and Ubuntu 14.04 on the latest Canary 67.0.3382.0 and Stable 65.0.3325.181 as per comment #7.

Bisect Information:
===================
Good Build: 65.0.3319.0 (Revision - 528844)
Bad Build : 65.0.3320.0 (Revision - 529150)

On executing the per-revision bisect script, below is the Changelog URL:

https://chromium.googlesource.com/chromium/src/+log/bcb82a4d7976e358dcaccb88ae29e55e634fae99..53f1c0f95e568d4b6b184904f98cfde2833c603c

From the above Changelog, suspecting the below change:
Reviewed-on: https://chromium-review.googlesource.com/863270

srirama.m@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.
CC'ing the reviewer Fredrik Söderquist <fs@opera.com> as the author is away since 15 days.

Adding ReleaseBlock-Stable as this is a recent regression. Please feel free to remove it if it is not applicable.

Thanks.

M65 has been out since 03/06 and we're NOT planning any further M65 stable releases unless EXTREMELY critical issue arise, pls target fix for M66 which is going to stable in few weeks. Thank you.

Couldn't load the test url in my linux build.
Got the webvtt file through inspector tools and there are no negative timestamps.
**********************************************************
WEBVTT
X-TIMESTAMP-MAP=MPEGTS:900000,LOCAL:00:00:00.000

00:00:14.156 --> 00:00:20.653
a very good evening person because 
today is Monday in Is 

00:00:20.653 --> 00:00:24.057
Let's go to another 
class starting the week 
***********************************************

So not sure if the bisect change is the culprit here, anyway will try to reproduce the issue locally and look into it.

Not able to check in my linux local build and even the bisect is not working. The url displays "Error loading player: No playable sources found".
The url is working in official chrome for linux though.

Just a heads up, M66 Stable cut is on April 12th, 10 days away. This issue is marked as RB-Stable for 66. Please make sure to address this issue prior to stable cut. Thanks! 

c#12, did you try to enable "proprietary codecs" (proprietary_codecs=1 and probably also ffmpeg_branding=Chrome)?

Also: since this change only removed a(n artificial) restriction (widening the criteria of "valid cue") it's quite likely that it exposed a bug in JW player somehow (seeing more cues than before or something like that.) So regardless of what we end up doing here it might be good to report this to JW player as well so it can be fixed there (because this may be affecting other UAs such as Firefox.)

c#14, thanks, i will try those options.

I am able to see the issue now with the above build commands.
What I observed from the logs is that the cues were created with positive timestamps initially which are available from the webvtt files and later they have been overwritten with negative values using setStartTime and setEndTime.
Probably there is some internal mapping for these negative timestamps in JWPlayer framework.
One more observation is even Firefox and Edge are not displaying these subtitles.

As fs@ pointed out, it might be good to report it to JW player rather than going back to the previous behaviour of chrome which is not inline with other browsers (Firefox and Edge)

We're not planning any more M65 releases. Pls target fix for M66.

Friendly ping to get an update on this issue as it is marked as stable blocker & M66 Stable cut is on April 12th.

Thanks..! 

Reminder: Please note that M66 Stable is only 7 days away. This bug has been marked as ReleaseBlock Stable for M66. So please take a look and appropriately address this bug. 

@fs, shall we mark this as won't fix or do we need to fix it for backward compatibility?

Seeing that behavior is now more interoperable, WontFix does seem reasonable. We should make sure we know what causes the change though, and report our findings to JWPlayer (I think they have a GitHub repo at least for their "free" version.)

From our side as I mentioned in #17, previously we are ignoring negative timestamps in setStartTime and setEndTime set through js, so the subtitles are having the positive timestamps and are displayed properly.
After the patch which supported negative timestamps, the cue starttime and endtime of all cues are changed to negative because of which they are not displayed.

From JWPlayer framework side I tried adding console logs by saving the javascript locally to find out how exactly these timestamps are becoming negative but couldn't get any useful logs as the script is a bit cryptic.

I have reported the issue in JWPlayer framework github https://github.com/jwplayer/jwplayer/issues/2838

Marking it as won't fix as the behavior is more inline with other browsers.

Update from jsplayer team.
**************************************
This might have something to do with mapping cues to stream time. However, I opened your stream in Safari and do not see captions rendered there. If your stream does not work properly in Safari, it is likely an issue with your stream or captions and not something we would support.

@srirama179 Is the #EXT-X-PLAYLIST-TYPE:EVENT in your subtitles manifest intentional? That causes the manifest to be reloaded every 10 seconds. I'm not sure that hls.js supports live subtitle manifests over VOD video.

The #EXTINF:10 tag over each webvtt file does not match the range of time covered by the cues in the file. For example seq_1.webvtt has two cues with the last one ending at 24.057 so I would expect the first #EXTINF tag to have a value of at least 24.057, but no more than the start time of the first cue in seq_2.webvtt

It looks related to jwplayer/hls.js#143. We've been holding back on merging this until we had more test streams, but again I think if captions are not showing up in Safari it's like an issue with your m3u8 or webvtt files (maybe the issues I pointed out above). cc @johnBartos
*********************************************

Hi everybody, thanks for the feedbacks and work on it.

Actually I was trying to workaround on this with my Broadcast team. We got to display the subtitles when having a "pure HLS streaming" (Brodcast's team quotes). The issue with the request only happens when the streaming is original from a RTMP streaming and then converted to HLS. The thing here is that the subtitles were shown on Chrome previously and never on other browsers. However with this solution of using purely HLS (which does not impact me at all) works for every browser. Therefore my issue maybe does not make sense anymore, even though the problem did not happen only on JwPlayer, but also with other HLS players.
I am ok with closing the issue since with this set up cited above the subtitles are displayed in every browser.
Thanks again and I appreciate all the work on this issue.