search

feross / simple-peer

📡 Simple WebRTC video, voice, and data channels
MIT License
7.44k stars 974 forks source link

stream event not fired when using simplepeer.min.js v9.1.1 and Chromium Portable #308

Closed jarretttaylor closed 6 years ago

jarretttaylor commented 6 years ago

When using simplepeer.min.js v9.1.1, the stream event is not fired in the browser when a connection is established. When I replace it with v9.1.0, the event is fired as expected.

I have tested using the following browsers:

Google Chrome Version 66.0.3359.139 (Official Build) (64-bit) on Windows 10.0.16299.431 Google Chrome Version 66.0.3359.170 (Official Build) (64-bit) on Windows 10.0.16299.431 Chromium Portable Version 61.0.3153.0 (Official Build) (64-bit) on Windows 10.0.16299.431

There appears to have been no change in the simple-peer code from version 9.1.0 to 9.1.1 and the only dependency update was for simple-get (v2.0.0 to v3.0.1). That leads me to believe it was something in simple-get or something in the packaging process that is causing the issue.

nazar-pc commented 6 years ago

@jarretttaylor, thanks for reporting, could you make a reduced demo on jsfiddle or similar service?

jarretttaylor commented 6 years ago

@nazar-pc Please forgive my ignorance. I don't know where (online) I can reference the versions of simplepeer.min.js to build the example. I have attached my test file which is based on the examples provided in the project's README.md.

Things to note about my test: I ran two separate browsers (Chrome and Chromium Portable). I had my integrated camera assigned on one browser and a USB webcam assigned to the other so that there would be no resource contention. I accessed the test URL (running under Apache Tomcat) from one browser and then the same URL plus #1 from the other browser. I copy/pasted the offer generated by the initiator browser (i.e. the one with the #1 in the URL) into the box in the other browser and clicked submit. I then took the answer generated by that browser and copy/pasted it back into the box on the initiator browser and clicked submit. When using simplepeer.min.js v9.1.0, the video session is established. Additionally, you can see the stream event fire in the console. Swapping out simplepeer.min.js to v9.1.1 and repeating these steps results in no stream event firing (and, consequently, no video session). I should note that the peers do connect successfully and the data channel works, there are just no stream events.

test.html.txt

feross commented 6 years ago

@jarretttaylor When you specify a version of simple-peer, are you using the git tags or the npm package to determine the version?

The way that I do releases at the moment, the build happens after the git tag is made, so if you're using the v9.1.0 git tag you're actually getting v9.0.0 of simplepeer.min.js.

(Just wanted to clear that up to aid @nazar-pc in debugging)

jarretttaylor commented 6 years ago

@feross In my testing I am using the simplepeer.min.js found in the zip files for the releases. Downloaded from the following URLs:

https://github.com/feross/simple-peer/archive/v9.1.0.zip https://github.com/feross/simple-peer/archive/v9.1.1.zip

Considering the way the tagging and releasing takes place, my original statement about the simple-get version change was incorrect. The only change (comparing the v9.1.1 tag with master/head is a version update for airtap (from 0.0.4 to 0.0.5).

feross commented 6 years ago

So, your issue was introduced in 9.1.0. That was quite a big release. These are the commits that went into that release: https://github.com/feross/simple-peer/compare/v9.0.0...v9.1.0

It would be very helpful if you could isolate which commit introduced the issue you're experiencing. (git bisect would be useful)

jarretttaylor commented 6 years ago

@feross Please clarify so that I am not creating more confusion (for myself or anyone else) when using version the numbers.

  1. What version of simplepeer.min.js is found under the tag v9.1.0?
  2. What version of simplepeer.min.js is found in the zip for release v.9.1.0?
nazar-pc commented 6 years ago

@jarretttaylor, fresh build of simplepeer.min.js is created AFTER corresponding tag. So with tag v9.1.0 you'll get build of previous version, v9.0.0 in this case. Zip archive is created from tag, so the same rules apply.

jarretttaylor commented 6 years ago

@nazar-pc Thank you for the clarification.

t-mullen commented 6 years ago

Chromium Portable hasn't been updated since July 16th 2017, and looks like it's been dying for several years now. I don't doubt that it's WebRTC implementation is off-spec.

Your demo works fine in Chrome 66.0.3359.170.

My bet is that it doesn't support the track API correctly, since we removed the Chromium stream fallback to allow multi-streaming.

Also, could you run !!(new RTCPeerConnection()).addTrack on portable Chrome?

jarretttaylor commented 6 years ago

@RationalCoding Thank you. I will retest between two computers both running the most recent version of Chrome.

jarretttaylor commented 6 years ago

@RationalCoding it returned false

t-mullen commented 6 years ago

Thanks, that's definitely an issue. Do you get any errors in the browser log while running your demo on Portable Chrome?

jarretttaylor commented 6 years ago

@RationalCoding When I ran with the simplepeer.min.js included in the 9.1.0 zip, everything worked in Chromium Portable. When I ran with the simplepeer.min.js included in the 9.1.1 zip, there were no errors; however, the stream event did not fire. Ultimately, I don't need Chromium Portable to work... It was just an easy way for me to test from the same computer. I am attempting to perform my tests now with two computers both running the most recent version of Chrome. I'll post the results of that when done.

jarretttaylor commented 6 years ago

These are the results of tests using the simplepeer.min.js from master: Test 1: Google Chrome Version 66.0.3359.170 (Official Build) (64-bit) - normal window (acting as initiator) Google Chrome Version 66.0.3359.170 (Official Build) (64-bit) - incognito window (non-initiator) Copy/Pasting offers/answers between browser windows. Result: The connection was established successfully and video streamed in both directions.

Test 2: Google Chrome Version 66.0.3359.170 (Official Build) (64-bit) - normal window (acting as initiator) Google Chrome Version 66.0.3359.170 (Official Build) (64-bit) - normal window on secondary PC (non-initiator) Using a signaling server to transfer offers/answers between browsers.. Result: The connection was established successfully and video streamed in both directions.

Everything is working correctly. Please accept my apology for opening this non-issue. Also, I really appreciate all the work the contributors put into this project. I am currently replacing PeerJS in an application (PeerJS seems to have broken with Chrome 65 or 66) and was relieved to find both an active and well-designed project. Thank you.