webrtc / testrtc Goto Github PK
View Code? Open in Web Editor NEWWebRTC Troubeshooter PROJECT IS ON HOLD
Home Page: https://test.webrtc.org/
License: BSD 3-Clause "New" or "Revised" License
WebRTC Troubeshooter PROJECT IS ON HOLD
Home Page: https://test.webrtc.org/
License: BSD 3-Clause "New" or "Revised" License
{"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."}},
Original tracked in this crbug
MediaStreamTrack.getSources() will soon be deprecated.
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..
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.
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)
Objective: Test that it's possible to send a message using SCTP Data Channel between two Hosts
Steps followed:
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.
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:
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 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
Specially important for low bandwidth connections.
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)
We have started to gather a few reports from the latency test... however we lack the tooling to analyze them.
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.
Moved from original repo, original issue
We should optimize the page using pagespeed recommendations. We could also add the grunt plugin to make sure we do not regress.
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).
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.
See pull request #58
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.
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).
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.
We need to create a build script for everything needed to deploying on GAE, currently some stuff is needed to be done manually.
After this is done we can setup jenkins #65.
It appears quite a few test scripts want to use a loopback to test... maybe we should have such a test?
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.
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.
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...
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:
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
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.
Address issues like this.
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.
ScriptProcessor is deprecated in favor of Worker and should be replaced eventually.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.