{"action":"created","issue":{"url":"https://api.github.com/repos/video-dev/hls.js/issues/1894","repository_url":"https://api.github.com/repos/video-dev/hls.js","labels_url":"https://api.github.com/repos/video-dev/hls.js/issues/1894/labels{/name}","comments_url":"https://api.github.com/repos/video-dev/hls.js/issues/1894/comments","events_url":"https://api.github.com/repos/video-dev/hls.js/issues/1894/events","html_url":"https://github.com/video-dev/hls.js/pull/1894","id":352776297,"node_id":"MDExOlB1bGxSZXF1ZXN0MjEwMDAzMzk0","number":1894,"title":"Handle buffer-stall on seek with accurate fragment loading (without nudging playhead)","user":{"login":"tchakabam","id":1480052,"node_id":"MDQ6VXNlcjE0ODAwNTI=","avatar_url":"https://avatars2.githubusercontent.com/u/1480052?v=4","gravatar_id":"","url":"https://api.github.com/users/tchakabam","html_url":"https://github.com/tchakabam","followers_url":"https://api.github.com/users/tchakabam/followers","following_url":"https://api.github.com/users/tchakabam/following{/other_user}","gists_url":"https://api.github.com/users/tchakabam/gists{/gist_id}","starred_url":"https://api.github.com/users/tchakabam/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tchakabam/subscriptions","organizations_url":"https://api.github.com/users/tchakabam/orgs","repos_url":"https://api.github.com/users/tchakabam/repos","events_url":"https://api.github.com/users/tchakabam/events{/privacy}","received_events_url":"https://api.github.com/users/tchakabam/received_events","type":"User","site_admin":false},"labels":[{"id":827397662,"node_id":"MDU6TGFiZWw4MjczOTc2NjI=","url":"https://api.github.com/repos/video-dev/hls.js/labels/Needs%20review","name":"Needs review","color":"58d8d2","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2018-08-22T02:17:14Z","updated_at":"2018-09-11T23:07:08Z","closed_at":null,"author_association":"COLLABORATOR","pull_request":{"url":"https://api.github.com/repos/video-dev/hls.js/pulls/1894","html_url":"https://github.com/video-dev/hls.js/pull/1894","diff_url":"https://github.com/video-dev/hls.js/pull/1894.diff","patch_url":"https://github.com/video-dev/hls.js/pull/1894.patch"},"body":"### This PR will...\r\n\r\nIntroduce a more accurate and correct way to handle buffer-stalls on seeking.\r\n\r\nThe problem:\r\n\r\n- seek is done to a position X\r\n- fragment-finder is resolving to fragment N\r\n- fragment N doesn't contain position X (timestamps shifted for some reason or another)\r\n- Playback stalls at seek target with data buffered in time-range very near (but not at target)\r\n\r\nReproduce:\r\n\r\n- Use our default BigBuckBunny test video\r\n- Set `highBufferWatchdogPeriod` to 300\r\n- Before loading data, set media currentTime to 129.9\r\n- Playback will stall\r\n\r\nCurrent behavior:\r\n\r\n- Gap-controller detects the stall, and after the configurable time `highBufferWatchdogPeriod` we attempt a \"nudge\", which means we actually seek into the buffered range.\r\n\r\nIssues: \r\n* We actually don't seek accurately to the initially requested position\r\n* There is a delay in seeking depending on `highBufferWatchdogPeriod`, and the whole process is fuzzy, as the watchdog time has to be balanced against normally expectable seek latencies, which are in principle not predictable.\r\n\r\nOur solution:\r\n\r\n- Actually attempt load the correct fragment! Thus we manage to optimize seek-time to best-effort in any case, as we are trying to resolve the correct fragment with normal means, and when this fails handle it by the following method.\r\n(- We are estimating the shift in timestamps that occured so that our initial seek went wrong) -> using a constant with minimal expected segment duration for now, as we need some buffer state evaluation for the first one\r\n- With this value, we are resetting the load position of the next fragment (we re-init loading with startLoad) and actually get the correct fragment to be loaded\r\n\r\nNotes:\r\n\r\n* The gap-controller based handling would still have grip if after the watchdog-time the buffer is still stalling. This isn't a replacement but more-off a better first way to handle this. The gap-controller nudge-method is still there in case of emergency.\r\n\r\n* The default watch-dog period should be raised probably.\r\n\r\n* Afaics there is no case where this shouldn't work, except if there are very weird gaps in the stream and we don't manage to resolve the seek-time with straight-forward logic (but this is also then a missing information in the stream, like PDT stamps e.g).\r\n\r\n=> This is surely not perfect yet, but an approach to a better solution that the current \"nudge method\". \r\n\r\nHappy to get feedback on this and get it to something real-life ready.\r\n\r\n### Are there any points in the code the reviewer needs to double check?\r\n\r\nYes, but I'd like it to be plainly reviewed first, and then we get into the tricky considerations of this solution.\r\n\r\n### Resolves issues:\r\n\r\nYes.\r\n\r\n### Checklist\r\n\r\n- [ ] changes have been done against master branch, and PR does not conflict\r\n- [ ] new unit / functional tests have been added (whenever applicable)\r\n- [ ] API or design changes are documented in API.md\r\n"},"comment":{"url":"https://api.github.com/repos/video-dev/hls.js/issues/comments/420455951","html_url":"https://github.com/video-dev/hls.js/pull/1894#issuecomment-420455951","issue_url":"https://api.github.com/repos/video-dev/hls.js/issues/1894","id":420455951,"node_id":"MDEyOklzc3VlQ29tbWVudDQyMDQ1NTk1MQ==","user":{"login":"tchakabam","id":1480052,"node_id":"MDQ6VXNlcjE0ODAwNTI=","avatar_url":"https://avatars2.githubusercontent.com/u/1480052?v=4","gravatar_id":"","url":"https://api.github.com/users/tchakabam","html_url":"https://github.com/tchakabam","followers_url":"https://api.github.com/users/tchakabam/followers","following_url":"https://api.github.com/users/tchakabam/following{/other_user}","gists_url":"https://api.github.com/users/tchakabam/gists{/gist_id}","starred_url":"https://api.github.com/users/tchakabam/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tchakabam/subscriptions","organizations_url":"https://api.github.com/users/tchakabam/orgs","repos_url":"https://api.github.com/users/tchakabam/repos","events_url":"https://api.github.com/users/tchakabam/events{/privacy}","received_events_url":"https://api.github.com/users/tchakabam/received_events","type":"User","site_admin":false},"created_at":"2018-09-11T23:07:08Z","updated_at":"2018-09-11T23:07:08Z","author_association":"COLLABORATOR","body":"> I disagree. \r\n\r\nI this case I think there is real a misunderstanding on the matter here on your side. Hopefully we can clarify it.\r\n\r\nCould you develop / explain and express some arguments however? It shouldn't be possible to reject the presented explanations here without being more specific.\r\n\r\nConcerning your other reply, it is imo a consequence of the misunderstanding. Before we can continue the discussion there needs to be a common understanding of the problem obviously."}}
{"actor":{"display_login":"tchakabam"}}