Closed Bug 1493738 Opened 6 years ago Closed 2 years ago

AirMozilla sometimes fails to start streaming with Nightly

Categories

(Core :: Audio/Video: Playback, defect, P3)

Product:
Core
Component:
Audio/Video: Playback
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: drno, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(2 files)

Win_10_no-player-controls-Nightly-2018-09-26.png
1.18 MB, image/png
Details
INXPO-in-Nightly-as-of-100418
992.33 KB, image/png
Details
According to user reports under unknown circumstances the new Airmo for users on Firefox Nightly sometimes fails to start rendering a video stream. Apparently this behavior is not tight to a certain version of Firefox, but appears to be caused by the Nightly channel. Which seems to suggest it might be caused by a user pref which has a different value in the Nightly channel then in the Release channel. The external streaming service uses H264 and DASH.
Atoll: if you still have more details about what went wrong for you could please provide it here? Jya: do you have any idea which playback feature we are currently holding in Nightly only?
Flags: needinfo?(jyavenard)
I don't know anything about this specific issue, sorry. It doesn't relate to either of the issues I do know about.
There are none that I'm aware of. (the page could be dependent on MediaCapabilities and use a different code base, but this is in beta as well) Which platform is this on?
Flags: needinfo?(jyavenard)
Priority: -- → P3
I've been badly bitten by that. Not sure how much, but it seemed to be 100% repro STR as long as I refused to share my webcam / mic.
(In reply to Alexandre LISSY :gerard-majax from comment #4) > I've been badly bitten by that. Not sure how much, but it seemed to be 100% > repro STR as long as I refused to share my webcam / mic. FTR, in my case, the issue was on AirMo admin page, and this was preventing me from properly getting streaming working. Wirecast encoder was "properly" added as a source, but the playback would never start on the preview, and looking on YouTube you would only see black being streamed.
(In reply to Jean-Yves Avenard [:jya] from comment #3) > There are none that I'm aware of. (the page could be dependent on > MediaCapabilities and use a different code base, but this is in beta as well) > > Which platform is this on? Ubuntu 18.04 / ThinkPad T480s
I've had similar experiences where it would fail to start. I also experienced cases where nightly will have periodic blips in the stream response. If it would be helpful, I'm willing to share my about:support on nightly.
(In reply to Jonathan Claudius [:claudijd] (use NEEDINFO) from comment #7) > I've had similar experiences where it would fail to start. I also > experienced cases where nightly will have periodic blips in the stream > response. If it would be helpful, I'm willing to share my about:support on > nightly. I've noticed that I can replicate blips more common when operating in another window.
Next time it happens, could you please install the media devtools extension https://addons.mozilla.org/en-US/firefox/addon/devtools-media-panel/, press Ctrl-Shift-I (or Command-Option-I on mac) go to the media, select the URL in the list showing and copy paste the text here. Also, any error messages on the console would be helpful
It seems to be the same as bug 1489291 Here we have a video without video controls, no play button. Should people had disabled autoplay, the video couldn't get started.
Depends on: 1489291
AirMozilla will be participating in the IT Hackathon next week! We hear your concerns about stream delivery and Nightly and are assembling a team that can offer diagnosis behind the firewall. I will be running a day-long stream (webcast) 8:00 AM - 4:00 PM Pacific and hope to collect data during this time to improve the customer experience for everyone. Please let me know if you can help.
Just to confirm something which wasn't clear to me from previous descriptions: does the problem of playback not starting only ever happen not when consuming something, but when trying to live stream something?
(In reply to Alexandre LISSY :gerard-majax from comment #4) > I've been badly bitten by that. Not sure how much, but it seemed to be 100% > repro STR as long as I refused to share my webcam / mic. I probably don't know enough about how AirMo is suppose to work, but how can you expect live streaming to work if you refuse to share your camera? Is this for some kind of desktop screen sharing scenario?
On the other hand this being our block autoplay experiment, which is only active in Firefox Nightly, finally starts to make sense. The easy work around for that though is to simply white list the AirMo page for autoplay. Or the service vendor should change it's code to only ever autoplay without audio and have options for the users to manually turn on the audio later.
(In reply to Nils Ohlmeier [:drno] from comment #14) > (In reply to Alexandre LISSY :gerard-majax from comment #4) > > I've been badly bitten by that. Not sure how much, but it seemed to be 100% > > repro STR as long as I refused to share my webcam / mic. > > I probably don't know enough about how AirMo is suppose to work, but how can > you expect live streaming to work if you refuse to share your camera? Is > this for some kind of desktop screen sharing scenario? This was trying to live stream an event held in the Paris Salle des Fêtes room, so being streamed from Wirecast's encoder1.commons.par1. Nothing to do with my webcam, at all. And indeed, the root cause was not the sharing but autoplay being disabled.
(In reply to Nils Ohlmeier [:drno] from comment #15) > On the other hand this being our block autoplay experiment, which is only > active in Firefox Nightly, finally starts to make sense. > > The easy work around for that though is to simply white list the AirMo page > for autoplay. > Or the service vendor should change it's code to only ever autoplay without > audio and have options for the users to manually turn on the audio later. I believe that it would be faster for us to whitelist the new AirMozilla for autoplay than seek changes on the vendor side. The vendor has thousands of customers and such a request would have to go on the feature enhancement schedule. I cannot say how long or if that might take place (Mozilla is one customer voice among many).
(In reply to Andy Kochendorfer from comment #17) > I believe that it would be faster for us to whitelist the new AirMozilla for > autoplay than seek changes on the vendor side. The vendor has thousands of > customers and such a request would have to go on the feature enhancement > schedule. I cannot say how long or if that might take place (Mozilla is one > customer voice among many). They will be facing that exact same issue with pretty much all browsers today... So it's in their best interest to do it...
(In reply to Andy Kochendorfer from comment #17) > I believe that it would be faster for us to whitelist the new AirMozilla for > autoplay than seek changes on the vendor side. The vendor has thousands of > customers and such a request would have to go on the feature enhancement > schedule. I cannot say how long or if that might take place (Mozilla is one > customer voice among many). Sorry for the unprecise wording: there is no Firefox wide white list. Each Firefox user builds his/her own white and black lists by clicking "allow" or "don't allow" on each website he/she visits which plays video with audio with autoplay. And the vendor should really have a high interest in improving this on their end, as all Firefox users will be facing this issue with all their customers if they don't improve it on in their software.
(In reply to Alexandre LISSY :gerard-majax from comment #16) > (In reply to Nils Ohlmeier [:drno] from comment #14) > > (In reply to Alexandre LISSY :gerard-majax from comment #4) > > > I've been badly bitten by that. Not sure how much, but it seemed to be 100% > > > repro STR as long as I refused to share my webcam / mic. > > > > I probably don't know enough about how AirMo is suppose to work, but how can > > you expect live streaming to work if you refuse to share your camera? Is > > this for some kind of desktop screen sharing scenario? > > This was trying to live stream an event held in the Paris Salle des Fêtes > room, so being streamed from Wirecast's encoder1.commons.par1. Nothing to do > with my webcam, at all. And indeed, the root cause was not the sharing but > autoplay being disabled. Alexandre - You were using the admin links and not the audience link. The webcast application has a WebRTC environment that allows you and others to present live using your webcam, so that is why admin links request access to the webcam. This is not the case for the general webcast audience.
During testing I did a fresh install of Nightly on Mac High Sierra. I clicked on the webcast link in Nightly and got an autoplay notice from Nightly and from INXPO (which seems new). Once I allowed these, the webcast streamed normally for me in Nightly without a player or interface issue (2.5hrs. plus success now).
During the IT Hackathon 4 users on Windows 10 with a fresh Nightly install reported no issues once they allowed autoplay upon the live stream (Nightly autoplay notice and INXPO autoplay notice). On demand stream player controls in Nightly may still be an issue, but live streaming is functioning normally.
(In reply to Andy Kochendorfer from comment #22) > Created attachment 9014420 [details] > INXPO-in-Nightly-as-of-100418 > > During testing I did a fresh install of Nightly on Mac High Sierra. I > clicked on the webcast link in Nightly and got an autoplay notice from > Nightly and from INXPO (which seems new). Once I allowed these, the webcast > streamed normally for me in Nightly without a player or interface issue > (2.5hrs. plus success now). I never ever had that kind of error message. I think it would have allowed me to properly stream from day one :(
Advice re. Nightly autoplay has been added to the AirMozilla FAQ: https://mana.mozilla.org/wiki/display/AVSE/INXPO+SaaS+Webcasting+Application+FAQ
(In reply to Andy Kochendorfer from comment #25) > Advice re. Nightly autoplay has been added to the AirMozilla FAQ: > https://mana.mozilla.org/wiki/display/AVSE/ > INXPO+SaaS+Webcasting+Application+FAQ Nice, thanks! How come I've never had this error, did they changed something on their side?
This is the first time that I have seen the INXPO autoplay notice. My nagging is paying off :-)
Can someone with a Windows 10 machine please check if the player controls are now visible in Nightly? It works for me in Win 7/64, but I do not have a Win10 machine to check. Thanks!
(In reply to Andy Kochendorfer from comment #28) > Can someone with a Windows 10 machine please check if the player controls > are now visible in Nightly? It works for me in Win 7/64, but I do not have a > Win10 machine to check. Thanks! Andy: did you intent this comment for bug 1494397?
Flags: needinfo?(akochendorfer)
Since the addition of the autoplay "allow" notices, the application seems to function as intended in Nightly. Can we close this bug?
Flags: needinfo?(akochendorfer)
Severity: normal → S3

Still an issue? Aiui we have a new air.m.o.

This bug may be closed. We have long since changed platforms to Panopto, which presents no issues with Nightly. :-)

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: