Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When I seek to just before the end, PLAYBACK_COMPLETE event does not fire #473

Open
zawao opened this issue Jan 14, 2016 · 16 comments
Open

Comments

@zawao
Copy link

zawao commented Jan 14, 2016

I seek to just before the end of the video. And the video is completed.
However, PLAYBACK_COMPLETE event does not fire.
Playback state stops at PLAYING_BUFFERING.

This problem occurs in the sample player.
http://www.flashls.org/latest/examples/chromeless/

image

@dtniland
Copy link

Mangui, we're seeing this as well when we upgraded to 0.4.4.16. Our automated tests started failing on several of our test medias.

There appears to be a strange hitch at the end of the media that we've never noticed before. We get a series of MediaPlayerStateChange events: buffering, playing, ready, then the PLAYBACK_COMPLETE event is fired directly.

The issue is that sometimes (it seems to be when the last fragment isn't cached?) the state gets stuck on buffering and never recovers. I put in a timer to close things down when it stalls, but I'm hoping that's temporary.

Here's some of the media we're seeing the "hitch" on:

http://delivery.support.theplatform.com/pdk_qa/PDK_(VMS)/928/739/Batman_v_Superman-_Dawn_of_Justice_-_Comic-Con_Trailer_[HD]_(720p).m3u8
http://delivery.support.theplatform.com/pdk_qa/PDK_AUTOMATION/ad_FIles/xml_dam_vast_pods_M3U_AUTO_WRAPPER.xml
(you might want to turn the volume down for the last one. :))

Merci beaucoup,

Daniel Niland
thePlatform

@dtniland
Copy link

We found the same issue, where playback gets stuck on buffering, could happen during seeks in the middle of the media. We had to roll back to our prior forked version.

@mangui
Copy link
Owner

mangui commented Jan 23, 2016

Hi Daniel. Will check on monday

@mangui
Copy link
Owner

mangui commented Jan 25, 2016

Hi @zawao
I cannot reproduce on big buck bunny http://flashls.org/flashls-0.4.4.17/examples/chromeless

mangui added a commit that referenced this issue Jan 25, 2016
…ted PTS is above max PTS

when level switch-down occurs after the loading of last fragment,
playback complete was not fired appropriately, leading to flashls staying stuck on buffering state at the end of the playback.

related to #473
mangui added a commit that referenced this issue Jan 25, 2016
related to #473
@mangui mangui added the bug label Jan 25, 2016
@nozawa-gy
Copy link

Hi @mangui
Steps to Reproduce
1.playback start
2.seek to 5 seconds before the playback end
3.change current level to 0 (240)
4.change current level to auto
5.playback end

When the playback is finished, it may to occur values of "current level" and "load level" are different?
image

@mangui
Copy link
Owner

mangui commented Jan 25, 2016

ok I was able to reproduce similar issue with @dtniland stream.
it should also be similar to the issue faced by @zawao and @nozawa-gy
it happens when bandwidth significantly changes on last fragment loading. this could happen if prior loaded segments are cached but not latest one for example.
current logic in Fragment Loader is that playback complete is triggered when trying to load a new fragment, but it was triggered only if flashls was not in PTS analysis state.
in that case, playback complete was never triggered .. leading to flashls staying stuck on buffering state.

this logic is there since a while (does not look like a regression)
@dtniland, just curious, which release were you using prior to v0.4.4.16 ?

@mangui
Copy link
Owner

mangui commented Jan 25, 2016

plz recheck with latest flashls/dev, and tell me how it behaves now

@dtniland
Copy link

@mangui we had been using a fork of 0.4.2.3 or so. I'll check it today.

Thanks for the quick fix!

@dtniland
Copy link

Unfortunately, it looks like there is still an issue. You have fixed the issue with the last fragment -- our tests no longer hang there. But, we're also seeing the same issue in the middle of the media. Our system dynamically inserts ads from the server by creating a discontinuity. We're seeing the buffer not returning when we seek to the exact spot of this continuity. Strangely, it is only an issue on Windows Chrome -- it could have something to do with caching?

Our system can only be accessed via a token that expires in seconds so it isn't possible to give you a link to the manifest directly. I'm attaching the manifest files as they've been downloaded by the browser and hopefully you can look at them to figure out what's going on.

In this particular media, we're seeking to 114.0 seconds. In OSMF, we get a MediaPlayerStateChange of buffering, then an onSeekChange with seeking = true, then we call play(). At that point the media never goes to the the playing state.
ssa_1.m3u8.txt
ssa_5.m3u8.txt
ssa_main.m3u8.txt

If this isn't enough to know what's going on, let me know... we'll try to work something out.

Thanks!

dtniland

@mangui
Copy link
Owner

mangui commented Jan 26, 2016

Hi @dtniland
if you could provide debug/debug2 logs, that might help.
or if it is a VoD playlist, you can also mirror it and share it via PM

@zawao
Copy link
Author

zawao commented Jan 26, 2016

Hi @mangui
My problem is resolved in the latest version.
http://flashls.org/flashls-0.4.4.18/examples/chromeless/

Thanks!

@dtniland
Copy link

@mangui We have a repro that you can hit.

In http://www.flashls.org/latest/examples/osmf/StrobeMediaPlayback.html go the js console and type in:

player.setMediaResourceURL("http://demo.theplatform.com/pdk/jeremy/PDK-12854/master.m3u8");

hit the play button then in the js console:

player.seek(114.0):

We have reproed the buffering message spinning forever.

@mangui
Copy link
Owner

mangui commented Jan 29, 2016

ok will check next week

@jlacivita
Copy link
Contributor

thanks, @mangui.

mangui added a commit that referenced this issue Feb 1, 2016
if requested PTS is bigger than any PTS in this continuity counter range and if this is not the last continuity range of this playlist,
then matching Sequence Number is the first one of following continuity range, i.e last frag.seqnum + 1

related to #473
mangui added a commit that referenced this issue Feb 1, 2016
related to #473
@mangui
Copy link
Owner

mangui commented Feb 1, 2016

@dtniland you can recheck with latest flashls/dev, issue should be fixed

@dtniland
Copy link

dtniland commented Feb 5, 2016

@mangui, your fix worked perfectly -- we're not seeing the issue any more.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants