Closed gkindel closed 9 years ago
mangui
commented
9 years ago really strange .... do you have debug logs for the complete session ? I have detected a potential flaw in the playlist reloading logic in case of adaptive live streaming. in case a level switching occurs while a level playlist is being loaded, then this level load is not discarded properly. when this loading completes, another timer is re-armed... will push a fix soon
mangui
commented
9 years ago @gkindel you might recheck with latest flashls/dev if still repro i would need full debug session and event metrics as well. If anybody could volunteer to modify the chromeless and metrics page so that we could also copy the base64 metrics blob from chromeless page and paste it in the metrics page in case the URL is too long ? this would help analyzing long streaming sessions.
here : https://github.com/mangui/flashls/blob/dev/examples/chromeless/index.html#L525 and here : https://github.com/mangui/flashls/blob/dev/examples/chromeless/metrics.html#L43
this way we could share full streaming sessions metrics using gist. we could also eventually redirect flash debug logs and push them into this event structure as well...
tks, cheers. Mangui
gkindel
commented
9 years ago Thanks for looking at this. I'll see about getting public access to our test stream, the metrics blob, or both, as well as trying out the latest build.
I was able to verify that it happens with .0.3 OSMF which is what we're still using. I tried a pull of the latest 0.4 stable, but we're still having stability issues around it recovering from a buffer underrun, currentTime math being off, etc. If I can capture more details, I'll file them here and try to help solve them as I go.
I'm campaigning to switch over to your chromeless from OSFM, once i get our ads solution patched in.
You may also be happy to know that encryption works great for us. I did tweak the fragment loader not to fail hard if an individual key is bad (something that shouldn't happen unless there are problems elsewhere). Apologies for not creating pull requests --it takes some time to integrate across git and our own vcs.
gkindel
commented
9 years ago Fix looks good!
I think this is pretty hard to reproduce unless the manifest is sufficiently large, which we have taken other efforts to reduce (gzip, larger segments, etc).
Key to reproduction is that the TS file finished downloading in the middle of of a manfest download. I clamped down my bandwidth to second-lowest bitrate and reduced the browser zoom as the TS file was downloading, which often worked to trigger a stage-size level switch.
This screen shot shows your fix correctly aborts the previous manifest request, which is great.
What are your thoughts on pausing the manifest poll while paused?
We have some long-lived live streams which are choking after a while. I'm guessing there are many problems, but one is definitely some latency introduced by extra requests to tail the manifest file.
I've repo'd with the chromeless player, which occurs every time the bitrate switches. I have not seen this problem with a version from the fall (0.3.?) but I haven't spent much time trying.
I'll spend some time digging into where the timers/listeners are being attached and see if i can find the cause, but in the meantime here's some visual evidence from the (very awesome) debugging stats on the chromless player. Our test stream is internal, and i'm running short on external streams that are both live and abr.