No video tags are created when using tokbox stream




Audio/Video: Playback
2 years ago
2 years ago


(Reporter: jwwang, Assigned: pkerr)



48 Branch

Firefox Tracking Flags

(firefox47 unaffected, firefox48 wontfix, firefox49 wontfix, firefox50 wontfix)




2 years ago
Blocks: 1280337
Can you please clarify the situation here. Is this a regression? Why is it filed under DOM?
Flags: needinfo?(jwwang)

Comment 2

2 years ago
regression? I think so. Because it works fine on FF 47 for Linux but not FF 48~50.
DOM? I guess there are some javascript errors which fail to create the media elements as expected. I am not sure should it be clarified as DOM or JS.
Flags: needinfo?(jwwang)

Comment 3

2 years ago
Is this a e10s vs. non-e10s issue? Do you perhaps get e10s in post FF47?
Keywords: regression, regressionwindow-wanted

Comment 4

2 years ago
FF 50 on Linux doesn't work with or without e10s.
Firefox: 50.0a1, Build ID: 20160703030210
User Agent  Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0

I have tested this issue with the latest Nightly (50.0a1) build on Ubuntu 14.04 x64. 
I have used the provided test case from bug 1280337 comment 3, and tried to make a regression, but I didn't find a good version where the "loadedmetadata" message is displayed.
But using the provided test case from bug 1280337 comment 0, I was able to find a good version where the "loadedmetadata" message is displayed, so I performed a regression.

This are the results: 

Last good revision: c7eedb39844a0131bbd86109a325f402bfa8bf2d
First bad revision: 5213de555ac0470a87a7163e06c1f6c19c0ffb3b

This is the same regression as in bug 1280337 comment 7.
Keywords: regressionwindow-wanted
Thanks for the regression range!

Looks like Andreas may know more here but his bugzilla name says he's away until August 1. Paul reviewed the change in bug 1248154 so maybe he has thoughts here?
Component: DOM → Audio/Video: Playback
(Oops, see comment 6)
Flags: needinfo?(pkerr)

Comment 8

2 years ago
I will take a look at this. The fix in the patch took advantage of the fact that the received frame will actually set the width and height regardless of the initial setting. Perhaps there is a side effect where a 0 x 0 size will fail to generate a video tag in the DOM.
Flags: needinfo?(pkerr)
Assignee: nobody → pkerr
status-firefox47: --- → unaffected
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox48: affected → wontfix
I'm going to mark this as P1 because it is a regression.
Priority: -- → P1
Please see bug 1280337 comment 18, 22 and 25 (where it got resolved as INVALID).

We were correcting a non-spec behavior for loadedmetadata, and SFU/MCU implementations that negotiate video (but don't use it or send a frame) cause video elements to a) play the audio (and update the time), but b) don't fire loadedmetadata because we don't know hte video dimensions (which had previously been reported on a number of occasions when we did fire it immediately).

Chrome has a similar-but-not-identical issue where in this case they don't play audio *or* video until they can fire loadedmetadata.

This is overall an unfortunate hole in the spec when used with non-transport streams, as it was designed with streaming media in mind.
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1280337
Bug 1280337 is marked as invalid due to work as expected. So, mark 49/50 as won't fix.
status-firefox49: affected → wontfix
status-firefox50: affected → wontfix
You need to log in before you can comment on or make changes to this bug.