Comments (13)
goruck
commented on June 2, 2024
It looks like something is wrong with your certs since I don't see any TLS negotiation in your logs. How did you generate your certs?
Here's how I did it using cert bot and letsencrypt:
$ sudo certbot -d example.com --rsa-key-size 4096 --manual --preferred-challenges dns certonly- Log into the hosting service that runs the domain and create a DNS TXT record per the message the command above generates.
- Wait a minute or two for the TXT entry to take effect. You can poll the domain to make sure its actually taken hold before going on to the next step.
- Continue with certbot. (Press Enter to Continue)
- Copy the SSLCertificateFile (fullchain.pem) and SSLCertificateKeyFile (privkey.pem) to where stunnel can find them. (Looks like you are using /etc/stunnel/fullchain.pem and /etc/stunnel/privkey.pem)
- Restart stunnel.
- Delete the TXT entry from the DNS record.
For reference here's an stunnel log from a run where I successfully connected with my Fire HD 10 tablet:
2018.11.25 06:45:31 LOG7[ui]: Clients allowed=500
2018.11.25 06:45:31 LOG5[ui]: stunnel 5.44 on x86_64-pc-linux-gnu platform
2018.11.25 06:45:31 LOG5[ui]: Compiled/running with OpenSSL 1.1.0g 2 Nov 2017
2018.11.25 06:45:31 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI Auth:LIBWRAP
2018.11.25 06:45:31 LOG7[ui]: errno: (*__errno_location ())
2018.11.25 06:45:31 LOG5[ui]: Reading configuration from file /etc/stunnel/stunnel.conf
2018.11.25 06:45:31 LOG5[ui]: UTF-8 byte order mark not detected
2018.11.25 06:45:31 LOG5[ui]: FIPS mode disabled
2018.11.25 06:45:31 LOG7[ui]: Compression disabled
2018.11.25 06:45:31 LOG7[ui]: Snagged 64 random bytes from /home/lindo/.rnd
2018.11.25 06:45:31 LOG7[ui]: Wrote 1024 new random bytes to /home/lindo/.rnd
2018.11.25 06:45:31 LOG7[ui]: PRNG seeded successfully
2018.11.25 06:45:31 LOG6[ui]: Initializing service [rtsp]
2018.11.25 06:45:31 LOG7[ui]: Ciphers: HIGH:!DH:!aNULL:!SSLv2
2018.11.25 06:45:31 LOG7[ui]: TLS options: 0x02024004 (+0x02004000, -0x00000000)
2018.11.25 06:45:31 LOG6[ui]: Loading certificate from file: /etc/letsencrypt/live/cam.lsacam.com/fullchain.pem
2018.11.25 06:45:31 LOG6[ui]: Certificate loaded from file: /etc/letsencrypt/live/cam.lsacam.com/fullchain.pem
2018.11.25 06:45:31 LOG6[ui]: Loading private key from file: /etc/letsencrypt/live/cam.lsacam.com/privkey.pem
2018.11.25 06:45:31 LOG4[ui]: Insecure file permissions on /etc/letsencrypt/live/cam.lsacam.com/privkey.pem
2018.11.25 06:45:31 LOG6[ui]: Private key loaded from file: /etc/letsencrypt/live/cam.lsacam.com/privkey.pem
2018.11.25 06:45:31 LOG7[ui]: Private key check succeeded
2018.11.25 06:45:31 LOG7[ui]: DH initialization
2018.11.25 06:45:31 LOG7[ui]: Could not load DH parameters from /etc/letsencrypt/live/cam.lsacam.com/fullchain.pem
2018.11.25 06:45:31 LOG6[ui]: Using dynamic DH parameters
2018.11.25 06:45:31 LOG7[ui]: ECDH initialization
2018.11.25 06:45:31 LOG7[ui]: ECDH initialized with curve prime256v1
2018.11.25 06:45:31 LOG5[ui]: Configuration successful
2018.11.25 06:45:31 LOG7[ui]: Binding service [rtsp]
2018.11.25 06:45:31 LOG7[ui]: Listening file descriptor created (FD=7)
2018.11.25 06:45:31 LOG7[ui]: Option SO_REUSEADDR set on accept socket
2018.11.25 06:45:31 LOG7[ui]: Service [rtsp] (FD=7) bound to 0.0.0.0:443
2018.11.25 06:45:31 LOG7[ui]: Created pid file /var/run/stunnel4.pid
2018.11.25 06:45:31 LOG7[cron]: Cron thread initialized
2018.11.25 06:46:31 LOG6[cron]: Executing cron jobs
2018.11.25 06:46:31 LOG5[cron]: Updating DH parameters
2018.11.25 06:46:43 LOG5[cron]: DH parameters updated
2018.11.25 06:46:43 LOG6[cron]: Cron jobs completed in 12 seconds
2018.11.25 06:46:43 LOG7[cron]: Waiting 86388 seconds
2018.11.25 06:51:28 LOG7[ui]: Found 1 ready file descriptor(s)
2018.11.25 06:51:28 LOG7[ui]: FD=4 events=0x2001 revents=0x0
2018.11.25 06:51:28 LOG7[ui]: FD=7 events=0x2001 revents=0x1
2018.11.25 06:51:28 LOG7[ui]: Service [rtsp] accepted (FD=3) from 192.168.1.128:33519
2018.11.25 06:51:28 LOG7[0]: Service [rtsp] started
2018.11.25 06:51:28 LOG7[0]: Option TCP_NODELAY set on local socket
2018.11.25 06:51:28 LOG5[0]: Service [rtsp] accepted connection from 192.168.1.128:33519
2018.11.25 06:51:28 LOG6[0]: Peer certificate not required
2018.11.25 06:51:28 LOG7[0]: TLS state (accept): before SSL initialization
2018.11.25 06:51:28 LOG7[0]: TLS state (accept): before SSL initialization
2018.11.25 06:51:28 LOG7[0]: SNI: no virtual services defined
2018.11.25 06:51:28 LOG7[0]: TLS state (accept): SSLv3/TLS read client hello
2018.11.25 06:51:28 LOG7[0]: TLS state (accept): SSLv3/TLS write server hello
2018.11.25 06:51:28 LOG7[0]: TLS state (accept): SSLv3/TLS write certificate
2018.11.25 06:51:28 LOG7[0]: TLS state (accept): SSLv3/TLS write key exchange
2018.11.25 06:51:28 LOG7[0]: TLS state (accept): SSLv3/TLS write server done
2018.11.25 06:51:28 LOG7[0]: TLS state (accept): SSLv3/TLS write server done
2018.11.25 06:51:28 LOG7[0]: TLS state (accept): SSLv3/TLS read client key exchange
2018.11.25 06:51:28 LOG7[0]: TLS state (accept): SSLv3/TLS read change cipher spec
2018.11.25 06:51:28 LOG7[0]: TLS state (accept): SSLv3/TLS read finished
2018.11.25 06:51:28 LOG7[0]: TLS state (accept): SSLv3/TLS write change cipher spec
2018.11.25 06:51:28 LOG7[0]: TLS state (accept): SSLv3/TLS write finished
2018.11.25 06:51:28 LOG7[0]: New session callback
2018.11.25 06:51:28 LOG7[0]: 1 server accept(s) requested
2018.11.25 06:51:28 LOG7[0]: 1 server accept(s) succeeded
2018.11.25 06:51:28 LOG7[0]: 0 server renegotiation(s) requested
2018.11.25 06:51:28 LOG7[0]: 0 session reuse(s)
2018.11.25 06:51:28 LOG7[0]: 1 internal session cache item(s)
2018.11.25 06:51:28 LOG7[0]: 0 internal session cache fill-up(s)
2018.11.25 06:51:28 LOG7[0]: 0 internal session cache miss(es)
2018.11.25 06:51:28 LOG7[0]: 0 external session cache hit(s)
2018.11.25 06:51:28 LOG7[0]: 0 expired session(s) retrieved
2018.11.25 06:51:28 LOG6[0]: TLS accepted: new session negotiated
2018.11.25 06:51:28 LOG6[0]: No peer certificate received
2018.11.25 06:51:28 LOG6[0]: Negotiated TLSv1.2 ciphersuite ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption)
2018.11.25 06:51:28 LOG7[0]: Compression: null, expansion: null
2018.11.25 06:51:28 LOG6[0]: failover: round-robin, starting at entry #1
2018.11.25 06:51:28 LOG6[0]: s_connect: connecting 127.0.0.1:554
2018.11.25 06:51:28 LOG7[0]: s_connect: s_poll_wait 127.0.0.1:554: waiting 10 seconds
2018.11.25 06:51:28 LOG5[0]: s_connect: connected 127.0.0.1:554
2018.11.25 06:51:28 LOG6[0]: persistence: 127.0.0.1:554 cached
2018.11.25 06:51:28 LOG5[0]: Service [rtsp] connected remote server from 127.0.0.1:41008
2018.11.25 06:51:28 LOG7[0]: Option TCP_NODELAY set on remote socket
2018.11.25 06:51:28 LOG7[0]: Remote descriptor (FD=9) initialized
2018.11.25 06:51:30 LOG7[0]: SSL_write returned WANT_WRITE: retrying
2018.11.25 06:51:55 LOG6[0]: TLS socket closed (SSL_read)
2018.11.25 06:51:55 LOG7[0]: Sent socket write shutdown
2018.11.25 06:51:55 LOG5[0]: Connection closed: 5121151 byte(s) sent to TLS, 634 byte(s) sent to socket
2018.11.25 06:51:55 LOG7[0]: Remote descriptor (FD=9) closed
2018.11.25 06:51:55 LOG7[0]: Local descriptor (FD=3) closed
2018.11.25 06:51:55 LOG7[0]: Service [rtsp] finished (0 left)
from alexa-ip-cam.
justinmiller61
commented on June 2, 2024
Yeah that’s how I generated mine, though I did two -d’s. One for the camera host name and one for the main one. Looks like maybe mine is using an older version of SSL (v1 or v2) maybe since I see refs to TLS in your logs and only SSL in mine. Can I force stunned to use TLS? Wouldn’t surprise me if amazon requires TLS/SSLv3.
I thought that everything was successful because of:
2018.11.20 21:29:00 LOG6[0]: SSL accepted: new session negotiated
2018.11.20 21:29:00 LOG6[0]: No peer certificate received
2018.11.20 21:29:00 LOG6[0]: Negotiated TLSv1.2 ciphersuite ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption)
from alexa-ip-cam.
goruck
commented on June 2, 2024
The Alexa Smart Home Camera API requires TLS 1.2.
My stunnel is configured not to use SSLv2 or SSLv3 which I believe is the default.
Can you run $ stunnel -version and report back the result? I'm thinking either stunnel is configured incorrectly or the version of OpenSSL you are using is either old or mis-confgured as well.
Here's mine:
lindo@minuteman:/etc/stunnel$ stunnel -version
stunnel 5.44 on x86_64-pc-linux-gnu platform
Compiled/running with OpenSSL 1.1.0g 2 Nov 2017
Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI Auth:LIBWRAP
Global options:
pid = /var/run/stunnel4.pid
RNDbytes = 64
RNDfile = /dev/urandom
RNDoverwrite = yes
Service-level options:
ciphers = FIPS (with "fips = yes")
ciphers = HIGH:!DH:!aNULL:!SSLv2 (with "fips = no")
curve = prime256v1
debug = daemon.notice
logId = sequential
options = NO_SSLv2
options = NO_SSLv3
sessionCacheSize = 1000
sessionCacheTimeout = 300 seconds
stack = 65536 bytes
TIMEOUTbusy = 300 seconds
TIMEOUTclose = 60 seconds
TIMEOUTconnect = 10 seconds
TIMEOUTidle = 43200 seconds
verify = none
from alexa-ip-cam.
justinmiller61
commented on June 2, 2024
Yeah that was my next plan, to compile a new OpenSSL and stunnel. Mine is a bit older:
tunnel 5.30 on x86_64-pc-linux-gnu platform
Compiled/running with OpenSSL 1.0.2g 1 Mar 2016
Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD TLS:ENGINE,FIPS,OCSP,PSK,SNI Auth:LIBWRAP
Global options:
debug = daemon.notice
pid = /var/run/stunnel4.pid
RNDbytes = 64
RNDfile = /dev/urandom
RNDoverwrite = yes
Service-level options:
ciphers = FIPS (with "fips = yes")
ciphers = HIGH:+3DES:+DH:!aNULL:!SSLv2 (with "fips = no")
curve = prime256v1
debug = notice
logId = sequential
options = NO_SSLv2
options = NO_SSLv3
sessionCacheSize = 1000
sessionCacheTimeout = 300 seconds
stack = 65536 bytes
TIMEOUTbusy = 300 seconds
TIMEOUTclose = 60 seconds
TIMEOUTconnect = 10 seconds
TIMEOUTidle = 43200 seconds
verify = none
from alexa-ip-cam.
justinmiller61
commented on June 2, 2024
Okey doke, compiled openssl and stunnel from source and my output is pretty similar to yours now, yet still it's not connecting.
Anything stand out to you?
2018.11.25 21:18:31 LOG7[0]: Service [rtsp] started
2018.11.25 21:18:31 LOG7[0]: Setting local socket options (FD=3)
2018.11.25 21:18:31 LOG7[0]: Option TCP_NODELAY set on local socket
2018.11.25 21:18:31 LOG5[0]: Service [rtsp] accepted connection from 192.168.1.66:39949
2018.11.25 21:18:31 LOG6[0]: Peer certificate not required
2018.11.25 21:18:31 LOG7[0]: TLS state (accept): before SSL initialization
2018.11.25 21:18:31 LOG7[0]: TLS state (accept): before SSL initialization
2018.11.25 21:18:31 LOG7[0]: SNI: no virtual services defined
2018.11.25 21:18:31 LOG7[0]: TLS state (accept): SSLv3/TLS read client hello
2018.11.25 21:18:31 LOG7[0]: TLS state (accept): SSLv3/TLS write server hello
2018.11.25 21:18:31 LOG7[0]: TLS state (accept): SSLv3/TLS write certificate
2018.11.25 21:18:32 LOG7[0]: TLS state (accept): SSLv3/TLS write key exchange
2018.11.25 21:18:32 LOG7[0]: TLS state (accept): SSLv3/TLS write server done
2018.11.25 21:18:32 LOG7[0]: TLS state (accept): SSLv3/TLS write server done
2018.11.25 21:18:32 LOG7[0]: TLS state (accept): SSLv3/TLS read client key exchange
2018.11.25 21:18:32 LOG7[0]: TLS state (accept): SSLv3/TLS read change cipher spec
2018.11.25 21:18:32 LOG7[0]: TLS state (accept): SSLv3/TLS read finished
2018.11.25 21:18:32 LOG7[0]: TLS state (accept): SSLv3/TLS write change cipher spec
2018.11.25 21:18:32 LOG7[0]: TLS state (accept): SSLv3/TLS write finished
2018.11.25 21:18:32 LOG7[0]: New session callback
2018.11.25 21:18:32 LOG6[0]: No peer certificate received
2018.11.25 21:18:32 LOG6[0]: Session id: 28359D8DC6FAC0B47D7C7CD69401EDC075E946CB71649291401C8D248DC100DB
2018.11.25 21:18:32 LOG7[0]: 1 server accept(s) requested
2018.11.25 21:18:32 LOG7[0]: 1 server accept(s) succeeded
2018.11.25 21:18:32 LOG7[0]: 0 server renegotiation(s) requested
2018.11.25 21:18:32 LOG7[0]: 0 session reuse(s)
2018.11.25 21:18:32 LOG7[0]: 1 internal session cache item(s)
2018.11.25 21:18:32 LOG7[0]: 0 internal session cache fill-up(s)
2018.11.25 21:18:32 LOG7[0]: 0 internal session cache miss(es)
2018.11.25 21:18:32 LOG7[0]: 0 external session cache hit(s)
2018.11.25 21:18:32 LOG7[0]: 0 expired session(s) retrieved
2018.11.25 21:18:32 LOG6[0]: TLS accepted: new session negotiated
2018.11.25 21:18:32 LOG6[0]: TLSv1.2 ciphersuite: ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption)
2018.11.25 21:18:32 LOG7[0]: Compression: null, expansion: null
2018.11.25 21:18:32 LOG6[0]: s_connect: connecting 192.168.1.13:554
2018.11.25 21:18:32 LOG7[0]: s_connect: s_poll_wait 192.168.1.13:554: waiting 10 seconds
2018.11.25 21:18:32 LOG5[0]: s_connect: connected 192.168.1.13:554
2018.11.25 21:18:32 LOG6[0]: persistence: 192.168.1.13:554 cached
2018.11.25 21:18:32 LOG5[0]: Service [rtsp] connected remote server from 192.168.1.8:46946
2018.11.25 21:18:32 LOG7[0]: Setting remote socket options (FD=11)
2018.11.25 21:18:32 LOG7[0]: Option TCP_NODELAY set on remote socket
2018.11.25 21:18:32 LOG7[0]: Remote descriptor (FD=11) initialized
2018.11.25 21:18:32 LOG6[0]: TLS socket closed (SSL_read)
2018.11.25 21:18:32 LOG7[0]: Sent socket write shutdown
2018.11.25 21:18:32 LOG5[0]: Connection closed: 139 byte(s) sent to TLS, 163 byte(s) sent to socket
2018.11.25 21:18:32 LOG7[0]: Remote descriptor (FD=11) closed
2018.11.25 21:18:32 LOG7[0]: Local descriptor (FD=3) closed
2018.11.25 21:18:32 LOG7[0]: Service [rtsp] finished (0 left)
from alexa-ip-cam.
goruck
commented on June 2, 2024
Not sure... Looks like your Fire tablet's IP address is 192.168.1.66 and the server running stunnel is at 192.168.1.13. But then I see the rtsp service connect from 192.168.1.8. What IP address do you have in your DNS A record? It should be the local server running stunnel.
from alexa-ip-cam.
justinmiller61
commented on June 2, 2024
Not quite. So .66 is indeed the tablet. .13 is the camera (set in the skill) and .8 is the local server. My read is that the tablet is making a connection to .8 where stunnel is running, which then connects to .13.
The .8 address is in my dns record.
It’s possible the camera is screwy, even though VLC works fine (albeit without stunnel).
from alexa-ip-cam.
goruck
commented on June 2, 2024
Got it.
So do you actually have 192.168.1.13 as part of the uri you are providing
to the smart home camera API in the skill? I.e.,
rtsp://192.168.1.13:443/...
Or something like
rtsp://example.com:443/...
Only the second case will work with the camera API. Since you are not using
the live555 proxy you'll have to point stunnel directly to your camera
stream.
Thanks.
…On Mon, Nov 26, 2018, 11:55 AM Justin Miller ***@***.*** wrote:
Not quite. So .66 is indeed the tablet. .13 is the camera (set in the
skill) and .8 is the local server. My read is that the tablet is making a
connection to .8 where stunnel is running, which then connects to .13.
The .8 address is in my dns record.
It’s possible the camera is screwy, even though VLC works fine (albeit
without stunnel).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#9 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALkFIP8t_vSnprUgDLNxM-g8ziXTTO7Aks5uzEdFgaJpZM4YsS3y>
.
from alexa-ip-cam.
justinmiller61
commented on June 2, 2024
Yep. The skill is using the latter example. And stunnel is pointing
directly at the camera, not the live555 proxy since, when I couldn't
initially get everything to work, I figured let's remove some of the
complication (the proxy). I'm wondering if I should introduce that back
into the mix in case it's mitigating any potential RTSP weirdness
(unverified, but it wouldn't surprise me) from my particular camera.
On Mon, Nov 26, 2018 at 4:43 PM Lindo St. Angel <[email protected]>
wrote:
… Got it.
So do you actually have 192.168.1.13 as part of the uri you are providing
to the smart home camera API in the skill? I.e.,
rtsp://192.168.1.13:443/...
Or something like
rtsp://example.com:443/...
Only the second case will work with the camera API. Since you are not using
the live555 proxy you'll have to point stunnel directly to your camera
stream.
Thanks.
On Mon, Nov 26, 2018, 11:55 AM Justin Miller ***@***.***
wrote:
> Not quite. So .66 is indeed the tablet. .13 is the camera (set in the
> skill) and .8 is the local server. My read is that the tablet is making a
> connection to .8 where stunnel is running, which then connects to .13.
>
> The .8 address is in my dns record.
>
> It’s possible the camera is screwy, even though VLC works fine (albeit
> without stunnel).
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#9 (comment)
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/ALkFIP8t_vSnprUgDLNxM-g8ziXTTO7Aks5uzEdFgaJpZM4YsS3y
>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#9 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGaLzl-P0HL__WNCN5zXxcmiYIVrIzHVks5uzGBmgaJpZM4YsS3y>
.
from alexa-ip-cam.
goruck
commented on June 2, 2024
What does your stunnel configuration look like?
I imagine something like this:
[rtsp]
accept = 443
connect = 192.168.1.13:554
Also, just to be clear your DNS A record needs to point to your local server (.8) running stunnel and not your camera's IP.
from alexa-ip-cam.
justinmiller61
commented on June 2, 2024
Sorry for the delayed response (and thanks for your quick responses).
Yep, my DNS A record is pointing to .8. Here's my stunnel config (credentials and hostname omitted):
cert = /etc/letsencrypt/live/myhost.com/fullchain.pem
key = /etc/letsencrypt/live/myhost.com/privkey.pem
; Some performance tunings
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
output = /var/log/stunnel.log
; Some debugging stuff useful for troubleshooting
debug = 7
foreground=yes
; Service-level configuration
[rtsp]
;accept = 58928
accept = 443
connect = 192.168.1.13:554
protocolUsername = <blank>
protocolPassword = <blank>
TIMEOUTclose = 0
from alexa-ip-cam.
justinmiller61
commented on June 2, 2024
Got it! Ok, so I figured I would try and use live555Proxy again. This time I could see it started to send data. But it kept closing the rtsp link. So I wondered if for some reason it had to do with the resolution/FPS/bitrate of the video stream. So I started messing around with that, basically lowering it until I got video, and viola! It worked.
So it seems like either the Fire HD, the Alexa skill, the live555Proxy or some combination thereof, seems to prefer a lower resolution, FPS of ~10, CBR and a bitrate of ~1024. Even though these are 4MP and 2MP cameras, I was able to use the sub stream for the lower resolution, so the main stream that records to my NVR won't be affected.
Thanks for all the help and troubleshooting. This might be some useful info to put in the README in case others run into a similar problem.
from alexa-ip-cam.
goruck
commented on June 2, 2024
Great that you got it to work. The smart home camera API is finicky so in hindsight I'm not surprised that a particular configuration is required. In my case I used the the H.264 Main profile and a bit rate of 1000 kbs. The README already has a picture that shows these settings but I will make sure to highlight that only this specific configuration is known to work.
from alexa-ip-cam.
Related Issues (14)
- Problem with stunnel HOT 12
- video plays for about a second or two, then buffers indefinitely HOT 17
- Live555 blog link dead HOT 1
- ALL CAMERAS ARE NOT RESPONDING! HOT 5
- Issue with LetsEncrypt expiration HOT 1
- Can this work using ip reservation and port forwarding intead of static ip? HOT 1
- MongoDB
- Why did you need a rtsp proxy? HOT 3
- Alexa skill not discovering new devices HOT 6
- Alexsa Account Linking HOT 15
- have you converted Zoneminder mjpeg to RTSP for this project? HOT 6
- Noob Account linking problems HOT 2
- domain and TLS certs problem HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from alexa-ip-cam.