Open Bug 1575184 Opened 1 year ago Updated 1 month ago

livestream - Video constantly restart

Categories

(Web Compatibility :: Mobile, defect, P1)

Firefox 66
All
Android
defect

Tracking

(firefox-esr68 affected, firefox68 wontfix, firefox70 wontfix)

Tracking Status
firefox-esr68 --- affected
firefox68 --- wontfix
firefox70 --- wontfix

People

(Reporter: karlcow, Unassigned)

References

()

Details

(Keywords: webcompat:site-wait, Whiteboard: [fenix:p1] [sitewait])

Attachments

(4 files)

This was reported initially on https://webcompat.com/issues/38113

With Firefox on Android,

  1. Go to http://www.higherground.org/watch-our-service-live/
  2. tap on the icon for play
  3. Then a second time.

Let it play.

After a couple of seconds the video restarts

John, could you help me take a look at this?

Flags: needinfo?(jolin)
Duplicate of this bug: 1571887

It seems to be a site script issue. The HLS video in the page plays when 'request desktop site' is on and when directly loading the M3U resource [1] w/o running livestream.com player script.

Karl, could you please help reach out and see if the vendor is available to check what's wrong? Thanks a lot!

[1] https://player-api.new.livestream.com/accounts/1168470/events/8784770/videos/195191560.secure.m3u8?token=5d5dc164_1721479b24f96cb2296d92653cec3bd529e1f72e

Flags: needinfo?(jolin) → needinfo?(kdubost)
Attached image network traffic

Thanks. We need to understand a bit better before contacting.

<iframe id="ls_embed_1566697245" 
  src="https://livestream.com/accounts/1168470/events/8793552/player?width=960&amp;height=540&amp;enableInfoAndActivity=true&amp;defaultDrawer=feed&amp;autoPlay=true&amp;mute=false" 
  scrolling="no" 
  allowfullscreen="" 
  width="960"
  height="540" 
  frameborder="0">
</iframe>

window.location = 'https://livestream.com/accounts/1168470/events/8793552/player?width=960&amp;height=540&amp;enableInfoAndActivity=true&amp;defaultDrawer=feed&amp;autoPlay=true&amp;mute=false'
on Firefox fennec, exhibits the same issue.

It's trying 11 times then it's giving up.
https://vpe-cdn.livestream.com/playerjs/0.75.0/player.js

I was able to generate this error message but not sure it's related. It could be due to my breakpoints.

08:46:10.837 Error: [$rootScope:inprog] $apply already in progress
https://errors.angularjs.org/1.7.7/$rootScope/inprog?p0=%24apply event_embed.js:135:4548
    i event_embed.js:135
    h event_embed.js:137
    $digest event_embed.js:137
    $apply event_embed.js:137
    o event_embed.js:151
    it event_embed.js:135
    n event_embed.js:135
    onEvent eval:760
    proxy eval:728
    enter event-loop.js:116
    enter self-hosted:1001
    _pushThreadPause thread.js:222
    _pauseAndRespond thread.js:593
    hit breakpoint.js:259
    m player.js:20524
    value player.js:24946
    canPlay player.js:19278
    detectSupportedPlayback event_embed.js:156
    togglePlayerState event_embed.js:147
    stateChangeActions event_embed.js:147
    t event_embed.js:147
    n event_embed.js:156
    closeForm event_embed.js:156
    closeOpenModal event_embed.js:147
    closePostVideoDetailBox event_embed.js:149
    fn event_embed.js line 139 > Function:4
    r event_embed.js:138
    $eval event_embed.js:137
    $apply event_embed.js:137
    compile event_embed.js:138
    it event_embed.js:135
    n event_embed.js:135
Flags: needinfo?(kdubost)
Component: Audio/Video → Mobile
Product: Core → Web Compatibility
Hardware: Unspecified → All
Version: 68 Branch → Firefox 66

The original bug on higherground has been closed on the webcompat side, they moved live streaming to Facebook.
But the m.cricbuzz.com bug still reproduces for me in Fenix nightly. But when requesting desktop site it plays fine.

I see in the network panel it is also using livestream.com, which is owned by Vimeo. We have contacts there.
https://player-api.new.livestream.com/accounts/26005112/events/8697501/videos/193757381.secure.m3u8?token=5e582331_cd91ff10cfbeacf2110e0cebc6f6fdf33b9cbff3

Karl or John, do you think this is also related to the page itself or should we go directly to livestream with this bug?

The site is ranked 24 in India and 300 globally by Alexa.

Flags: needinfo?(kdubost)
Flags: needinfo?(jolin)
Priority: -- → P1

(In reply to Adam Stevenson [:adamopenweb] from comment #9)

But the m.cricbuzz.com bug still reproduces for me in Fenix nightly. But when requesting desktop site it plays fine.

On rdm desktop (macos) with firefox android ua, this is working. The video plays without issues.
but indeed on the device itself it repeats.

if you let it play (on repeat) long enough, it eventually bails out.
with: Invalid URI. Load of media resource failed.

See the screenshot which shows the traffic from the moment we tap the play button to the moment it fails.

Flags: needinfo?(kdubost)

first request

HTTP/2 206 Partial Content
server: openresty
content-type: application/vnd.apple.mpegurl; charset=utf-8
x-powered-by: Express
x-ls-infinite-cache: 1
x-ls-api-account: 26005112
x-ls-api-event: 8697501
cache-control: max-age=0
content-range: bytes 0-993/994
date: Fri, 28 Feb 2020 00:54:26 GMT
x-served-by: cache-tyo19947-TYO
x-cache: MISS, MISS
x-cache-hits: 0
x-timer: S1582851266.717006,VS0,VE640
age: 0
via: 1.1 varnish
accept-ranges: bytes
content-length: 994
X-Firefox-Spdy: h2

last request

HTTP/2 206 Partial Content
server: openresty
content-type: application/vnd.apple.mpegurl; charset=utf-8
x-powered-by: Express
x-ls-infinite-cache: 1
x-ls-api-account: 26005112
x-ls-api-event: 8697501
cache-control: max-age=0
content-range: bytes 0-993/994
date: Fri, 28 Feb 2020 00:55:49 GMT
x-served-by: cache-tyo19947-TYO
x-cache: HIT, MISS
x-cache-hits: 0
x-timer: S1582851349.249011,VS0,VE158
age: 0
via: 1.1 varnish
accept-ranges: bytes
content-length: 994
X-Firefox-Spdy: h2
<div ls-vod-player="" data-flash-container="postVideoContent" data-is-embed="true" data-player-name="'video_post'" data-video-id="selectedFeedData.data.id" data-is-video-embed="isVideoEmbed" class="ng-isolate-scope">
	<div class="player_wrapper js-vod_player_wrapper" id="postVideoPlayerContainer">
		<div class="player_inner" id="js-vod_player_inner" ng-show="readyForEmbed" style="width: 100%; height: 100%;">
			<!-- ngIf: playbackType === 'flash' -->
			<!-- ngIf: playbackType === 'pjs' -->
			<!-- ngIf: playbackType === 'mjs' -->
			<div class="playerm_player_wrapper js-playerm_playback ng-scope" ng-if="playbackType === 'mjs'" ng-init="initializePlayerM()" style="">
				<div class="mjs-root-view">
					<div class="mjs-video-view">
						<video class="mjs-video-element" poster="http://img.new.livestream.com/events/000000000084b69d/9289f660-3e42-4fc2-be8e-3cf5c31dde67_630.jpg" src="https://player-api.new.livestream.com/accounts/26005112/events/8697501/videos/193757381.secure.m3u8?token=5e586d49_35e893588e5c49805c9fc70e8db7207515d84842"
						controls=""></video>
					</div>
					<div class="mjs-spinner-view" style="display: block;">
						<div class="mjs-spinner-view__donut"></div>
					</div>
					<div class="mjs-ad-view" style="display: none;"></div>
					<div class="mjs-hit-view" style="display: none;">
						<div class="mjs-hit-view__play-icon">
							<div class="mjs-hit-view__arrow"></div>
						</div>
					</div>
				</div>
			</div>
			<!-- end ngIf: playbackType === 'mjs' -->
			<!-- ngIf: playbackType === null -->
		</div>
	</div>
</div>

The spinner is here each time it tries to replay the video.

the video is inserted in the page through

<iframe id="video_player_193757381"
        src="https://livestream.com/accounts/26005112/events/8697501/videos/193757381/player?width=400&amp;height=300&amp;enableInfoAndActivity=true&amp;defaultDrawer=&amp;autoPlay=true&amp;mute=false"
        scrolling="no"
        allowfullscreen=""
        width="100%"
        height="100%"
        frameborder="0"></iframe>

Let's try to load directly
https://livestream.com/accounts/26005112/events/8697501/videos/193757381/player?width=400&amp;height=300&amp;enableInfoAndActivity=true&amp;defaultDrawer=&amp;autoPlay=true&amp;mute=false

The same thing is happening. so we know this is not cricbuzz issue.

There is a very very very brief moment when we start the video which is i believe is the icon of the unsupported format.
so maybe they are sending the wrong type.

<video class="mjs-video-element"
       poster="http://img.new.livestream.com/events/000000000084b69d/9289f660-3e42-4fc2-be8e-3cf5c31dde67_630.jpg"
       src="https://player-api.new.livestream.com/accounts/26005112/events/8697501/videos/193757381.secure.m3u8?token=5e586d49_35e893588e5c49805c9fc70e8db7207515d84842"
       controls=""></video>

so yes adam we can contact directly livestream.

Flags: needinfo?(astevenson)

Contacting Vimeo by mailing list about this.

Flags: needinfo?(jolin)
Flags: needinfo?(astevenson)
Whiteboard: [fenix:p1] → [fenix:p1] [sitewait]

Livestream says we aren't supported. We should investigate what's required to fix this in the webcompat addon.

This seems like a buggy server issue, perhaps. On Desktop when I request the HLS manifest, I get 200 OK. From Karl's screenshots, we're getting 206 Partial Content.

Note that the content-length is 994 for the 200, and Fenix is getting a 206 with content-range: bytes 0-993/994. So it's going back for the last byte and getting the same content again, in the meantime playing the first few frames, then repeating once it gets a new 206 (which is the same over and over).

edit: I just learned 0-993 means all 994 bytes are transferred.

John, do we have known bugs similar to this?

Flags: needinfo?(jolin)
Attached image chrome mobile

Actually, Chrome Mobile gets a similar 206 as well, and they don't end up in a reload loop.🤔

(In reply to Mike Taylor [:miketaylr] from comment #15)

Created attachment 9130894 [details]
Screen Shot 2020-03-04 at 3.07.32 PM.png

This seems like a buggy server issue, perhaps. On Desktop when I request the HLS manifest, I get 200 OK. From Karl's screenshots, we're getting 206 Partial Content.

Note that the content-length is 994 for the 200, and Fenix is getting a 206 with content-range: bytes 0-993/994. So it's going back for the last byte and getting the same content again, in the meantime playing the first few frames, then repeating once it gets a new 206 (which is the same over and over).

edit: I just learned 0-993 means all 994 bytes are transferred.

John, do we have known bugs similar to this?

Gecko doesn't support HLS on desktop and my guess is that their script for desktop transmuxes the cotents from HLS to MSE. If that's the case, they must run different code for desktop than mobile, where HLS is supported natively. Could the different status codes be caused by different versions of scripts?

Flags: needinfo?(jolin)

BTW, the native HLS support in GV relies on Exoplayer to handle the M3U8 contents. It could be that Exoplayer doesn't support 206 responses properly.

https://github.com/google/ExoPlayer/issues

John is there a way to know which version of the ExoPlayer is being used? (from the devtools console?)
Thanks

(In reply to Karl Dubost💡 :karlcow from comment #19)

https://github.com/google/ExoPlayer/issues

John is there a way to know which version of the ExoPlayer is being used? (from the devtools console?)
Thanks

I don't think so. But according to the commit[1], it's r2.4.0.

[1] https://hg.mozilla.org/mozreview/gecko/rev/af12643a49c4231aca96c149bc76e2cf9827ffac

https://github.com/google/ExoPlayer/releases/tag/r2.4.0
is from april 27, 2017
latest is r2.11.3 february 19, 2020
around ~3 years ago.

that's a lot of things to digest.
https://github.com/google/ExoPlayer/compare/r2.4.0...r2.11.3

I see a couple of things related to hls in there, but that doesn't mean that would necessary solve this issue.

https://github.com/google/ExoPlayer/issues/2863
https://github.com/google/ExoPlayer/issues/6155
https://github.com/google/ExoPlayer/issues/6322
https://github.com/google/ExoPlayer/issues/6903

Are there any updates on this issue. Fenix has requested that this be resolved as a high priority.

My guess in comment 18 was wrong. I thought it could be some bug in ExoPlayer that causes the master playlist file [1] to be loaded repeatedly, but when trying to reproduce it today I noticed that the master playlist file [1] is shown again and again approximately every 8s in Network panel, as in comment 15. If the bug is indeed in ExoPlayer, Network panel should only show the playlist once because the following fetches will be handled by ExoPlayer internally and invisible to us. It seems to me that ExoPlayer does fetch the index playlist file [2] provided in the master playlist and play it for ~8s, then some code in the player script that triggers HTMLMediaElement.load() and causes the master playlist to be reloaded.

Adam, could you please help contact Vimeo and ask if their script does something like that? Thanks a lot!

[1] https://player-api.new.livestream.com/accounts/26005112/events/8697501/videos/193757381.secure.m3u8?token=5ec46e2c_83259c5db1dfde0b64d9d00a2ad23148154f5771
[2] https://vod.livestream.com/5ec47c69_b7bfe91d734c145fdbefbe31e87291dbba2cf8ff/events/000000000084b69d/9289f660-3e42-4fc2-be8e-3cf5c31dde67_428.m3u8

Flags: needinfo?(astevenson)

Tom, given Comment #23, do you think we could work around this while we wait on outreach? I guess we still only have a theory that we're calling load() again, perhaps something you can verify?

Flags: needinfo?(twisniewski)

I've just checked in with John and believe we are at the same place as comment 23 -- a site script appears to be causing us to reload the video. Any updates on outreach or if we can mitigate this elsewhere are appreciated.

The site seems to have changed their livestream provider
http://www.higherground.org/hgbc-live
http://www.higherground.org/live-stream-archive
And their videos in the current archive is working.

(In reply to Adam Stevenson [:adamopenweb] from comment #13)

Contacting Vimeo by mailing list about this.

The message on Vimeo mailing-list was on March 5, 2020

I asked around, and apparently Firefox on Android is not a supported platform for Livestream.

This is still happening.

WONTFIX?

Flags: needinfo?(twisniewski)
Flags: needinfo?(astevenson)
Summary: Video constantly restart → livestream - Video constantly restart
You need to log in before you can comment on or make changes to this bug.