{"action":"created","issue":{"url":"https://api.github.com/repos/videojs/videojs-contrib-hls/issues/279","labels_url":"https://api.github.com/repos/videojs/videojs-contrib-hls/issues/279/labels{/name}","comments_url":"https://api.github.com/repos/videojs/videojs-contrib-hls/issues/279/comments","events_url":"https://api.github.com/repos/videojs/videojs-contrib-hls/issues/279/events","html_url":"https://github.com/videojs/videojs-contrib-hls/pull/279","id":80952851,"number":279,"title":"Fixes for HLS","user":{"login":"mikrohard","id":133844,"avatar_url":"https://avatars.githubusercontent.com/u/133844?v=3","gravatar_id":"","url":"https://api.github.com/users/mikrohard","html_url":"https://github.com/mikrohard","followers_url":"https://api.github.com/users/mikrohard/followers","following_url":"https://api.github.com/users/mikrohard/following{/other_user}","gists_url":"https://api.github.com/users/mikrohard/gists{/gist_id}","starred_url":"https://api.github.com/users/mikrohard/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mikrohard/subscriptions","organizations_url":"https://api.github.com/users/mikrohard/orgs","repos_url":"https://api.github.com/users/mikrohard/repos","events_url":"https://api.github.com/users/mikrohard/events{/privacy}","received_events_url":"https://api.github.com/users/mikrohard/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-05-26T13:01:49Z","updated_at":"2015-05-29T08:54:49Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/videojs/videojs-contrib-hls/pulls/279","html_url":"https://github.com/videojs/videojs-contrib-hls/pull/279","diff_url":"https://github.com/videojs/videojs-contrib-hls/pull/279.diff","patch_url":"https://github.com/videojs/videojs-contrib-hls/pull/279.patch"},"body":"Let me explain what (and why) these fixes are necessary.\r\n\r\nAll these issues can be reproduced and checked with this sample content:\r\nhttps://dl.dropboxusercontent.com/u/8261657/hls-vod-sample.zip\r\n\r\n1.) There could be content with only one program (PMT) and with a non-standard network PID (NIT). In these cases there can be more than one PAT entry and I don't see why we shouldn't be able to play such content. In the first commit I check wether the PAT entry is a PMT or NIT pid and throw an error only if there are multiple PMT-s.\r\n\r\n2.) I'm not sure why... but it appears that finishFrame can be called when the stream extraData hasn't been parsed yet. The issue has been introduced with the commit https://github.com/videojs/videojs-contrib-hls/commit/ce689aec49cc4e4234f98e3fdf0a501c6104be5d The additional check for existing extra data prevents crashing at playback start.\r\n\r\n3.) If playlists contain \"\\r\\n\" line endings or even whitespace lines the m3u8 parser falsely detects those lines as \"empty\" segment URI-s. This results in faulty duration calculation and possible failure at playback start. By trimming line data before feeding it into the parser this issue is fixed.\r\n\r\n4.) Once again... I'm not sure why. But sometimes during seeking within the sample content provided above there are no tags with desired pts values. This commit prevents crashing and fixes seeking in the provided sample. But there may be a problem in the logic somewhere else."},"comment":{"url":"https://api.github.com/repos/videojs/videojs-contrib-hls/issues/comments/106748666","html_url":"https://github.com/videojs/videojs-contrib-hls/pull/279#issuecomment-106748666","issue_url":"https://api.github.com/repos/videojs/videojs-contrib-hls/issues/279","id":106748666,"user":{"login":"mikrohard","id":133844,"avatar_url":"https://avatars.githubusercontent.com/u/133844?v=3","gravatar_id":"","url":"https://api.github.com/users/mikrohard","html_url":"https://github.com/mikrohard","followers_url":"https://api.github.com/users/mikrohard/followers","following_url":"https://api.github.com/users/mikrohard/following{/other_user}","gists_url":"https://api.github.com/users/mikrohard/gists{/gist_id}","starred_url":"https://api.github.com/users/mikrohard/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mikrohard/subscriptions","organizations_url":"https://api.github.com/users/mikrohard/orgs","repos_url":"https://api.github.com/users/mikrohard/repos","events_url":"https://api.github.com/users/mikrohard/events{/privacy}","received_events_url":"https://api.github.com/users/mikrohard/received_events","type":"User","site_admin":false},"created_at":"2015-05-29T08:54:49Z","updated_at":"2015-05-29T08:54:49Z","body":"Ok... I did a little digging about issue no. 4.\r\n\r\nI found out that seek always fails if seeking in between two segments where the preciseDuration of the segment is shorter of the duration provided by the playlist.\r\n\r\nHere is a list of preciseDuration vs. duration reported by playlist for the above sample:\r\nvod-01.ts: 9.548822222221643 vs. 9.873\r\nvod-02.ts: 9.664244444443845 vs. 9.706\r\nvod-03.ts: 9.70351111111138 vs. 9.707\r\nvod-04.ts: 9.081799999999815 vs. 9.124\r\nvod-05.ts: 9.473755555556156 vs. 9.457\r\nvod-06.ts: 9.54339999999944 vs. 9.54\r\nvod-07.ts: 9.914911111112684 vs. 9.915\r\nvod-08.ts: 9.613066666666418 vs. 9.623\r\nvod-09.ts: 9.891711111110636 vs. 9.873\r\nvod-10.ts: 9.86848888888862 vs. 9.873\r\nvod-11.ts: 6.246177777779288 vs. 6.248\r\n\r\nWhat happens:\r\n1.) User seeks to 19.3 seconds (this is between the preciseDuration 19.213 and playlist duration 19.579)\r\n2.) The previous logic downloaded the segment at index 1 (because the seek time is below 19.579)\r\n3.) The logic expected to find the PTS for time 19.3 (which was in segment at index 2 because the seek time is above 19.213)\r\n4.) It crashed in the while loop\r\n\r\nWhat I did to fix this:\r\n1.) Use preciseDuration whenever possible. This selects a correct seek media index if preciseDurations are already known.\r\n2.) Fallback to closest timestamp if desired PTS not found. I think this is a reasonable fallback because the error should never exceed a few hundred milliseconds. We could correct the mediaIndex and load the correct segment... but this would unnecessarily increase the seeking time."}}