webrtc / testrtc Goto Github PK

Copied from https://code.google.com/p/chromium/issues/detail?id=418074:

I think it would be usable to have a volume (audio energy) indicator of some kind at the https://cdn.rawgit.com/GoogleChrome/webrtc/master/samples/web/content/manual-test/peer2peer/index.html test page.

Then it would be easier to visually see when you have audio both locally and remotely. This would also mean you can test simple scenarios without having to put on and off headsets all the time.

I'm imagining some kind of small bar that moves up and down, similar to the Hangouts volume indicator (but it could just be a number that updates frequently to start with).

Moved from original repo, original issue

It seems collecting audio from a microphone is reasonable flaky to the point one needs to wait 2 seconds to start getting some input from the stream.

Instead of an hard-code timeout of 2 seconds the test should maybe run for as much as 5 seconds terminating as soon as some audio is noticed.. also reporting how long it took to start gathering audio.

Do sudo npm update
Then grunt

Running "jscs:src" (jscs) task
Expected indentation of 6 characters at src/js/report.js :
49 | // test is doing in the wild.
50 | ga('send', {
51 | 'hitType': 'event',
--------------^
52 | 'eventCategory': 'Test',
53 | 'eventAction': status,
Expected indentation of 6 characters at src/js/report.js :
50 | ga('send', {
51 | 'hitType': 'event',
52 | 'eventCategory': 'Test',
--------------^
53 | 'eventAction': status,
54 | 'eventLabel': testName,
Expected indentation of 6 characters at src/js/report.js :
51 | 'hitType': 'event',
52 | 'eventCategory': 'Test',
53 | 'eventAction': status,
--------------^
54 | 'eventLabel': testName,
55 | 'nonInteraction': 1
Expected indentation of 6 characters at src/js/report.js :
52 | 'eventCategory': 'Test',
53 | 'eventAction': status,
54 | 'eventLabel': testName,
--------------^
55 | 'nonInteraction': 1
56 | });
Expected indentation of 6 characters at src/js/report.js :
53 | 'eventAction': status,
54 | 'eventLabel': testName,
55 | 'nonInteraction': 1
--------------^
56 | });
57 | },
Expected indentation of 0 characters at src/js/util.js :
9 |/* exported arrayAverage, arrayMax, arrayMin */
10 |
11 | // array returns the average (down to nearest int), max and min of
--------^
12 | // an int array.
13 |function arrayAverage(array) {
Expected indentation of 0 characters at src/js/util.js :
10 |
11 | // array returns the average (down to nearest int), max and min of
12 | // an int array.
--------^
13 |function arrayAverage(array) {
14 | var cnt = array.length;

7 code style errors found!
Warning: Task "jscs:src" failed. Use --force to continue.

Need to fix errors or adjust the rules..

Currently if a user is missing a microphone or camera TestRTC will show an error and stop. I think it should be possible to run tests with just one device type connected, just disable the tests dependent on the missing device type (mic or camera).

NOTE: This should be done after gumhandler.js has been converted to a Polymer element with device states.

OS: Ubuntu 14.04.1 LTS
Setup: use iptables to block nearly all outbound tcp (except 80 and 443) and udp (except dns and dhcp).

Repro steps:

1. Open https://test-rtc.appspot.com/
2. Press Start

Issue:
Test seems to hang at the "Data channel throughput" test. Perhaps it's missing a timeout?

Full test output below:
[ RUN ] MicrophoneTest
[ OK ] getUserMedia succeeded.
[ OK ] Audio track exists with label=Default
[ OK ] Audio num channels=1
[ OK ] Audio sample rate=44100
[ OK ] Audio power=-36.1199102794985
[ ------ ]
[ RUN ] UdpConnectivityTest
[ FAILED ] Failed to gather specified candidates
[ ------ ]
[ RUN ] TcpConnectivityTest
[ FAILED ] Failed to gather specified candidates
[ ------ ]
[ RUN ] HasIpv6Test
[ OK ] Gathered candidate with type: host address: 2620:0:1000:1600:a2e:5fff:fe0d:28c0
[ ------ ]
[ RUN ] CamResolutionsTest
[ INFO ] Supported resolution: (160x120)
[ INFO ] Supported resolution: (320x180)
[ INFO ] Supported resolution: (320x240)
[ INFO ] Supported resolution: (640x360)
[ INFO ] Supported resolution: (640x480)
[ INFO ] Resolution NOT supported: (768x576)
[ INFO ] Resolution NOT supported: (1024x576)
[ FAILED ] Camera does not support a mandatory resolution, (1280x720)
[ INFO ] Resolution NOT supported: (1280x768)
[ INFO ] Resolution NOT supported: (1280x800)
[ INFO ] Resolution NOT supported: (1920x1080)
[ INFO ] Resolution NOT supported: (1920x1200)
[ INFO ] Resolution NOT supported: (3840x2160)
[ INFO ] Resolution NOT supported: (4096x2160)
[ ------ ]
[ RUN ] CamCaptureTest
[ OK ] getUserMedia succeeded.
[ OK ] Video track exists with label = Microsoft® LifeCam VX-2000 (045e:0761)
[ INFO ] Checking if your camera is delivering frames for five seconds...
[ OK ] Expected: 640 === 640: Width OK
[ OK ] Expected: 480 === 480: Height OK
[ OK ] Expected: false === false: Camera is delivering frames
[ OK ] Expected: 0 === 0: Camera is sending non-black frames.
[ ------ ]
[ RUN ] Data channel throughput

Find a way to run the "Wifi Periodic Scan" test from testrtc. Due to its nature (multiple minutes) it cannot be run by default and one may need to have a UI to allow to trigger it.

For now the test is/will be implemented under the "?test_filter=Wifi Periodic Scan" flag.

I really appreciate the small amount of code for handling reports... if we can reduce the size of the link it would be great if that does not adds complexity on the code considerably.

We should optimize the page using pagespeed recommendations. We could also add the grunt plugin to make sure we do not regress.

{"ts":1423122848212,"name":"test-run","id":9,"args":{"name":"Check 1280x720 resolution","status":"Running"}},
{"ts":1423122848212,"name":"getusermedia","id":10,"args":{"status":"pending","constraints":{"audio":false,"video":{"mandatory":{"minWidth":1280,"minHeight":720,"maxWidth":1280,"maxHeight":720},"optional":[{"sourceId":"c3792e9b75491b1c3176d3b36b7e217419566278d946f734cb5dc62e1fd645ae"}]}}}},
{"ts":1423122848363,"name":"getusermedia","id":10,"args":{"status":"success","camera":"camera 1, facing front","microphone":null}},
{"ts":1423122848363,"name":"call","id":11,"args":{}},
{"ts":1423122848365,"name":"call","id":11,"args":{"state":"start"}},
{"ts":1423122848366,"name":"test-run","id":9,"args":{"info":"Camera label: camera 1, facing front"}},
{"ts":1423122856695,"name":"call","id":11,"args":{"state":"end"}},
{"ts":1423122857526,"name":"test-run","id":9,"args":{"info":"actualVideoWidth: 720"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"actualVideoHeight: 720"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"encodeSetupTimeMs: 3264"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"avgEncodeTimeMs: 33"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"minEncodeTimeMs: 16"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"maxEncodeTimeMs: 65"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"avgInputFps: 13"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"minInputFps: 12"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"maxInputFps: 14"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"avgSentFps: 12"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"minSentFps: 12"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"maxSentFps: 13"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"isMuted: false"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"readyState: ended"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"testedFrames: 22"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"blackFrames: 0"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"info":"frozenFrames: 0"}},
{"ts":1423122857527,"name":"test-run","id":9,"args":{"success":"Average FPS above threshold"}},
{"ts":1423122857528,"name":"test-run","id":9,"args":{"success":"Captured video using expected resolution."}},

Address issues like this.

When IPv6 test fails users get overly worried. We should make it a soft failure and possibly explain better what it means. (e.g. see crbug.com/465700)

Use "directory" in bowerrc.
Example from polymer repo.

See pull request #58

Original tracked in this crbug

MediaStreamTrack.getSources() will soon be deprecated.

Using MediaStream.getTracks is nice but not part of the standard hence it does not work in Firefox etc.

We should go back to use getVideoTracks and getAudioTracks even if it means more code...

Old laptop of mine: Latitidue e6400
during test I was connected to vpn network (openvpn)

TypeError: Argument 1 of mozRTCPeerConnection.getStats does not implement interface MediaStreamTrack.

had no problems with Canary
hope it's useful

The logs from the console are as follows:

setLocalDescription success
main.js:1108 Sending message {"candidate":"candidate:855189020 1 udp 2122260223 192.168.1.229 37197 typ host generation 0","sdpMid":"audio","sdpMLineIndex":0} to peer null.
main.js:1108 Sending message {"candidate":"candidate:855189020 2 udp 2122260222 192.168.1.229 43887 typ host generation 0","sdpMid":"audio","sdpMLineIndex":0} to peer null.
main.js:1108 Sending message {"candidate":"candidate:855189020 1 udp 2122260223 192.168.1.229 56239 typ host generation 0","sdpMid":"video","sdpMLineIndex":1} to peer null.
main.js:1108 Sending message {"candidate":"candidate:855189020 2 udp 2122260222 192.168.1.229 54695 typ host generation 0","sdpMid":"video","sdpMLineIndex":1} to peer null.
main.js:756 POST http://192.168.1.110:8888/message?peer_id=20&to=null 500 (Error)sendToPeer @ main.js:756setLocalAndSendMessage_ @ main.js:915
main.js:756 POST http://192.168.1.110:8888/message?peer_id=20&to=null 500 (Error)sendToPeer @ main.js:756iceCallback_ @ main.js:904
main.js:756 POST http://192.168.1.110:8888/message?peer_id=20&to=null 500 (Error)sendToPeer @ main.js:756iceCallback_ @ main.js:904
main.js:756 POST http://192.168.1.110:8888/message?peer_id=20&to=null 500 (Error)sendToPeer @ main.js:756iceCallback_ @ main.js:904
main.js:756 POST http://192.168.1.110:8888/message?peer_id=20&to=null 500 (Error)sendToPeer @ main.js:756iceCallback_ @ main.js:904
main.js:1108 Sending message {"candidate":"candidate:3014729896 1 udp 1686052607 104.135.6.108 60806 typ srflx raddr 192.168.1.229 rport 37197 generation 0","sdpMid":"audio","sdpMLineIndex":0} to peer null.
main.js:1108 Sending message {"candidate":"candidate:3014729896 2 udp 1686052606 104.135.6.108 62307 typ srflx raddr 192.168.1.229 rport 54695 generation 0","sdpMid":"video","sdpMLineIndex":1} to peer null.
main.js:1108 Sending message {"candidate":"candidate:3014729896 1 udp 1686052607 104.135.6.108 54127 typ srflx raddr 192.168.1.229 rport 56239 generation 0","sdpMid":"video","sdpMLineIndex":1} to peer null.
main.js:1108 Sending message {"candidate":"candidate:3014729896 2 udp 1686052606 104.135.6.108 50893 typ srflx raddr 192.168.1.229 rport 43887 generation 0","sdpMid":"audio","sdpMLineIndex":0} to peer null.
main.js:1108 Sending message {"candidate":"candidate:2088426220 1 tcp 1518280447 192.168.1.229 0 typ host tcptype active generation 0","sdpMid":"audio","sdpMLineIndex":0} to peer null.
main.js:1108 Sending message {"candidate":"candidate:2088426220 2 tcp 1518280446 192.168.1.229 0 typ host tcptype active generation 0","sdpMid":"audio","sdpMLineIndex":0} to peer null.
main.js:1108 Sending message {"candidate":"candidate:2088426220 1 tcp 1518280447 192.168.1.229 0 typ host tcptype active generation 0","sdpMid":"video","sdpMLineIndex":1} to peer null.
main.js:1108 Sending message {"candidate":"candidate:2088426220 2 tcp 1518280446 192.168.1.229 0 typ host tcptype active generation 0","sdpMid":"video","sdpMLineIndex":1} to peer null.
main.js:756 POST http://192.168.1.110:8888/message?peer_id=20&to=null 500 (Error)sendToPeer @ main.js:756iceCallback_ @ main.js:904
main.js:756 POST http://192.168.1.110:8888/message?peer_id=20&to=null 500 (Error)sendToPeer @ main.js:756iceCallback_ @ main.js:904
main.js:756 POST http://192.168.1.110:8888/message?peer_id=20&to=null 500 (Error)sendToPeer @ main.js:756iceCallback_ @ main.js:904
main.js:756 POST http://192.168.1.110:8888/message?peer_id=20&to=null 500 (Error)sendToPeer @ main.js:756iceCallback_ @ main.js:904
main.js:756 POST http://192.168.1.110:8888/message?peer_id=20&to=null 500 (Error)sendToPeer @ main.js:756iceCallback_ @ main.js:904
main.js:756 POST http://192.168.1.110:8888/message?peer_id=20&to=null 500 (Error)sendToPeer @ main.js:756iceCallback_ @ main.js:904
main.js:756 POST http://192.168.1.110:8888/message?peer_id=20&to=null 500 (Error)sendToPeer @ main.js:756iceCallback_ @ main.js:904
main.js:756 POST http://192.168.1.110:8888/message?peer_id=20&to=null 500 (Error)sendToPeer @ main.js:756iceCallback_ @ main.js:904

The plan on uploading the report is simply to make it a link one can paste on a bug.
However it is not very clear at the moment the simply uploading won't make anyone look at it.

ScriptProcessor is deprecated in favor of Worker and should be replaced eventually.

http://webaudio.github.io/web-audio-api/#the-audioworker

We need to create a build script for everything needed to deploying on GAE, currently some stuff is needed to be done manually.

• Vulcanize index.html
• Make sure components/webrtc-adapter exists due to test pages in manual/ depend on it (testrtc no longer requires access to components/ after vulcanize (it pulls all (almost) files together into one file)).

After this is done we can setup jenkins #65.

Objective: Test that it's possible to send a message using SCTP Data Channel between two Hosts

Steps followed:

1. On host A and B: Browse to peer2peer and negotiate a call
2. On host A click on create Data Channel and negotiate again
3. On host A: type a message in Data Channel field and click on send button

Expected Result: Verify that Host B received the message in the ""Received on Data Channel"" field

Actual Result: There is no data exchanged between the two users and there is no error messages seen in the console.

More Info: Tried with both the M43-43.0.2357.65 (64-bit) on Desktop as well as on M44-44.0.2403.14(7077.11.0)dev on Parrot-freon. Both of them shows the same behaviour. It is reproducible.

1. On host A: Browse to http://test.webrtc.org/manual/peer2peer page
2. On host A: Request Audio/Video/AV by clicking on 'Request GetUserMedia

Actual Result: The Error message is seen as follows:
Failed to load resource: the server responded with a status of 404 (OK)
/manual/peer2peer/js/main.js:1108 getUserMedia says: ReferenceError: getUserMedia is not defined

Expected Result: The request should be success and based on the request, the audio or video or both should be functional.

https://gitreports.com/about

https://code.google.com/p/chromium/issues/detail?id=417029

IPv6 test should work by trying to gather a relay candidate from a IPv6 turn server (instead of simply verifying it can gather local IPv6).

1. On host A: Browse to peer2peer, fill in the Force iSAC checkbox, and call (audio only).
2. On host B: Browse to peer2peer, fill in the Force iSAC checkbox, and call (audio only).
3. Verify audio is flowing between the hosts.

Expected Result: The audio should flow between the two users

Actual Result: The audio isn't flowing between the two users instead i see the error message as below:
Uncaught Error: setRemoteDescription

We have started to gather a few reports from the latency test... however we lack the tooling to analyze them.

From webrtc/samples#308

juberti commented on Dec 17, 2014
This would involve uploading the report to GAE, and then having GAE use some API to file the bug. This might need to wait for Chrome's upcoming bug tracker migration.

End condition and logging of data throughput test needs to be fixed for machines running in low connectivity..

E.g. on gin-2g-poor it takes forever to receive the whole buffered 100KB even after the test stops sending.

Currently the following dependency issue:
Unable to find a suitable version for webcomponentsjs, please choose one:
1) webcomponentsjs#^0.5.0 which resolved to 0.5.5 and is required by TestRTC
2) webcomponentsjs#* which resolved to 0.5.5 and is required by core-component-page#0.5.6
3) webcomponentsjs#^0.6.0 which resolved to 0.6.2 and is required by polymer#0.5.6

forces us to bump webcomponentsjs to 0.6.0 which results in vulcanize complaining and we need to pin that to 0.7.10. Also webcomponentsjs 0.6.+ breaks all polymer code, most likely due to new syntax hence the page does not render properly.

This prevents me from pushing the latest master to GAE.

Possibly solutions:

• Pin core-component-page to a lower version that does not require webcomponents.js 0.6.+ and pin [email protected] < Most viable short term option IMHO.
• Bump webcomponentsjs to 0.6+ and update the polymer element syntax. < Most viable long term option, we will eventually have to do this anyway to make sure we keep up with the latest polymer (at least up to 1.0 stable, currently on 0.5 beta).

Currently if you specify a test that does not exist or just ?test_filter the Webrtc troubleshooter title header is only present.

We should have some sort of error.

I think we should change the fail criteria for clipping in the mic test due to lots of Mic's on Chromebooks, 3.5mm headsets and some Windows laptops have high input volume due to I guess to make sure it can get sufficiently high enough input when the user is far away from the mic. Or the quality/config is just bad in general on these devices.

I propose changing from error to info.

fsolenberg@ WDYT?

The 1280x720 test failed with "Camera does not support a mandatory resolution: 1280x720
," but the output for "Check supported resolutions" includes the line "Supported 1280x720"
https://test.webrtc.org/report/AMIfv9730AKm3Pen5Cxe2x-WYdshuk5vG7BFi1PaGMGvoPH1oWuWkwdp5NFgoP1s9zfUaiUsO3U3IrzQgXmq4FQkOYbLFSPYdtUp3M9GEW4GpTdIXz1dxx0cNR2RWSvjGqclcabQwVy_cg6jfory875miwvAqU_7KQ

(Also, I'm not sure why the test stopped at that point, but that's probably a separate issue)

Specially important for low bandwidth connections.

To make it easier to reuse testrtc we should make sure all comments are up to date and contain useful information. Also add comments where it's lacking.

It appears quite a few test scripts want to use a loopback to test... maybe we should have such a test?