I am trying to do live video streaming from my laptop webcam out to a AWS EC2 Windows instance. Below link details the steps I followed: http://learn.iis.net/page.aspx/620/getting-started-with-iis-live-smooth-streaming/
A few seconds after pressing the "START" on ExpressionsEncoder4, I get random error pop-outs like "An unknown error has occurred", "A network error has occurred causing the encode to stop" and "The request could not be understood by the server".
Once in a while, these errors doesn't appear and I am able to see the captured video output on the preview screen.
At any one time, I am unable to register any streams on the IIS Publishing Point.
Any ideas? Thanks for any help!
There are a few problems here to solve. Let's go through them one by one.
Unknown Errors
Most often, "an unknown error has occurred" comes from calls to DirectShow APIs that fail for any unexpected reason (weird capture device, CPU can't keep up with encode, and basically any event that can interrupt the DirectShow graph frame stream). Try a different capture source, and see if your results change. Also, do a long encode from your device to a local Windows Media file to make sure everything is okay here.
Network Errors / Request not Understood by Server
Network errors in my experience have been mostly related to bandwidth; however Request Not Understood could mean you have something changing something in your HTTP requests (a proxy in between, etc).
Test On-Demand First
Test an on-demand stream from your EC2 server first. Download Big Buck Bunny or encode something yourself and make sure you can access http://example.com/BigBuckBunny.ism/Manifest in your browser. Test it using Smooth Streaming Health Monitor on the client side and server chunk performance using IIS Smooth Streaming Performance Testing Tool. This will verify that IIS Media Services is working properly.
Startup Order
Make sure you are starting your live publishing point stream in the following order:
On your EC2 server, navigate to the Live Publishing Point and start it. This will put the publishing point in a state that is ready to accept a stream.
In Expression Encoder, press Connect after entering the publishing point URL. You should see a successful connection at this point as long as port 80 is open.
Press Start and encoding should begin. (Best to start with only 1 or 2 bitrates when testing your stream; keep the bandwidth low.)
Alternate Setup
If all else fails, set up a Smooth Stream on your localhost (Expression pushes stream to IIS Media Services on localhost), and configure your localhost publishing point to push the stream to your EC2 instance. This is also a good method to use if you need a more network-hiccup-tolerant solution for long term streams or where your connection isn't as solid as you'd like.
Good luck and hopefully some of this info will narrow it down.
Related
I've just started experimenting with WebRTC with Go and downloaded pions/webrtc library but I'am stuck with it's data-channels example.
As it written in docs I opened jsfiddle client example.
Then I'am running go run main.go command in the /go/src/github.com/pions/webrtc/examples/data-channels folder on my server to launch data-channel.
After that I copy Browser base64 Session Description from jsfiddle example and paste it into my terminal where data-channels go script is running and it generates Golang base64 Session Description code which I paste into jsfiddle example and then press Sart session button.
And it fails to establish connection :(
This is my jsfiddle example for client side:
And this is my server side go script:
What am I doing wrong?
Thanks for using pion-WebRTC (I am one of the developers!)
WebRTC uses a technology called ICE to allow peers to talk to each other. Two peers exchange IP addresses via the SDP (the text you pasted) then they attempt to communicate by sending small UDP packets between each other. Once two IP addresses successfully communicate via ICE the rest of the WebRTC steps can continue. For you this process is failing. I don't know how/why though. Firewalls, VPNs etc... all can cause problems.
You will have to debug and check different scenarios. I would try running the examples on your local PC. If that works then maybe try between a different server. A good tool to help here also is tcpdump that can show if UDP packets are arriving. I usually use tcpdump -i any udp and inbound
We also recently added IPv6 support, so might be worth trying from master and see if that helps at all! Hopefully this helps, but if you are still having issues feel free to ask more questions. We are also all available via our Slack Channel you can sign up here here and would be more then happy to chat!
I met similar problem, and I solved by
echo $BROWSER_SDP | ./main
BROWSER_SDP is the session description in your browser, main is the exe by go build main.go(you can rename exe by mv). This can make sure transfer SDP to the server, which is really important.
The detail
I'm working to create a video calling web app using WebRTC.
The communication is working fine on same network. But when communicating in different network I'm getting ICE failed error.
Error: ICE failed, see about:webrtc for more details
In about:webrtc I' able to get local and remote SDP's, but ICE State is failed. http://imgur.com/a/nPPDr
Here is the code of my main.js file
Here is the my log file from about:webrtc
P.S: Before posting the question I've checked several posts in SO and in other sites but no one did the trick.
Looking at the log file you provided it looks like you provided a TURN server, but the communication with that TURN server simply times out. So either something like a local firewall is blocking the communication with your TURN server or your TURN server is not working.
In case your local firewall blocks UDP traffic it might help to configure and use TURN TCP additionally to get through the firewall.
your about:webrtc does not show any relay candidates gathered from a TURN server. At the risk of sounding like a broken record: you need a TURN server for the majority of connections between different networks.
I want to create an app that can start and stop recording from a Sony AS100VR camera using camera remote API.
I can get the same working from my nexus using a direct Wifi connection, but when I establish a direct wifi connection from my Sony smartwatch, it fails at the SSDP detection stage.
It's definitely connected to the camera, SSID over Wifi, but it can't detect it.
I have tried playing with retries and timeout values, but I have sort of run out of ideas.
it's falling into the catch catch (InterruptedIOException e) with a java.net.SocketTimeoutException
Any suggestions gratefully appreciated!
UDP Mulitcast is not available on smartwatch, so SSDP discovery fails.
There is a fail-safe choice for any UPnP based application, that is:
As in most case, the resource URL structure keeps unchanged except IP Address, so when SSDP discovery failed, let user directly input the IP Address (maybe in form of UI Picker) and get "DeviceDescription.xml" or something else then setup services.
Have you taken a look at the CameraRemoteSampleApp that comes with the Camera Remote API SDK? I assume when you say Smartwatch you mean you are using a Sony SmartWatch 3 that supports a direct WiFi connection? If so, you should be able to modify the sample app with minimal changes and run it on the SW3.
I have local access from one computer to RTSP server by my ISP which is delivering IPTV content archive (timeshift). RTSP is avilable only from this computer because it has correctly configured internet access to the server. Because I would like to watch the content of this RTSP server on every device at home, I'd like to create local server which would accept connections and just transfer data from the end server (by ISP) to client.
I already tried to configure Live555 RTSP Proxy, but it's not really the right software which would enable me what I need. Another thing I tried out is Darwin Streaming Server, but I think it wouldn't support the format of IPTV content archive. What do I actually need?
Link to ISP's content archive looks like: rtsp://archive.my-isp.tld:554/programme_id_channel.ts.
I would like to access to the same stream via rtsp://IP-of-my-computer:port/programme_id_channel.ts.
Is there any software which is acting like proxy and it would be possible to set it to my needs? I would really appreciate any answer and help.
P.S.: Type of ISP's stream is MPEG TS.
EDIT: I already tried out node-ffmpeg-mpegts-proxy and it works good for approximately 10 seconds, then I got some error from avconv about RTSP packet loss and stream stops. I would also need an option to seek video to wanted destination and with current setup (default options of avconv) of node-ffmpeg-mpegts-proxy. For the start I need something that will successfully stream video from source to destination.
I am working on a Windows (Microsoft Visual C++ 2005) application that uses several processes
running on different hosts in an intranet.
Processes communicate with each other using TCP/IP. Different processes can be on the
same host or on different hosts (i.e. the communication can be both within the same
host or between different hosts).
We have currently a bug that appears irregularly. The communication seems to work
for a while, then it stops working. Then it works again for some time.
When the communication does not work, we get an error (apparently while a process
was trying to send data). The call looks like this:
send(socket, (char *) data, (int) data_size, 0);
By inspecting the error code we get from
WSAGetLastError()
we see that it is an error 10054. Here is what I found in the Microsoft documentation
(see here):
WSAECONNRESET
10054
Connection reset by peer.
An existing connection was forcibly closed by the remote host. This normally
results if the peer application on the remote host is suddenly stopped, the
host is rebooted, the host or remote network interface is disabled, or the
remote host uses a hard close (see setsockopt for more information on the
SO_LINGER option on the remote socket). This error may also result if a
connection was broken due to keep-alive activity detecting a failure while
one or more operations are in progress. Operations that were in progress
fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
So, as far as I understand, the connection was interrupted by the receiving process.
In some cases this error is (AFAIK) correct: one process has terminated and
is therefore not reachable. In other cases both the sender and receiver are running
and logging activity, but they cannot communicate due to the above error (the error
is reported in the logs).
My questions.
What does the SO_LINGER option mean?
What is a keep-alive activity and how can it break a connection?
How is it possible to avoid this problem or recover from it?
Regarding the last question. The first solution we tried (actually, it is rather a
workaround) was resending the message when the error occurs. Unfortunately, the
same error occurs over and over again for a while (a few minutes). So this is not
a solution.
At the moment we do not understand if we have a software problem or a configuration
issue: maybe we should check something in the windows registry?
One hypothesis was that the OS runs out of ephemeral ports (in case connections are
closed but ports are not released because of TcpTimedWaitDelay), but by analyzing
this issue we think that there should be plenty of them: the problem occurs even
if messages are not sent too frequently between processes. However, we still are not
100% sure that we can exclude this: can ephemeral ports get lost in some way (???)
Another detail that might help is that sending and receiving occurs in each process
concurrently in separate threads: are there any shared data structures in the
TCP/IP libraries that might get corrupted?
What is also very strange is that the problem occurs irregularly: communication works
OK for a few minutes, then it does not work for a few minutes, then it works again.
Thank you for any ideas and suggestions.
EDIT
Thanks for the hints confirming that the only possible explanation was a connection closed error. By further analysis of the problem, we found out that the server-side process of the connection had crashed / had been terminated and had been restarted. So there was a new server process running and listening on the correct port, but the client had not detected this and was still trying to use the old connection. We now have a mechanism to detect such situations and reset the connection on the client side.
That error means that the connection was closed by the
remote site. So you cannot do anything on your programm except to accept that the connection is broken.
I was facing this problem for some days recently and found out that Adobe Acrobat Reader update was the culprit. As soon as you completely uninstall Adobe from the system everything returns back to normal.
I spent a long time debugging a 10054/10053 error in s3 pre-signed uploads
Turns out that the s3 server will reject pre-signed s3 uploads for the first 15 minutes of it's life.
So - If you're debugging s3 check it's not a new bucket.
If you're debugging something else - this is most likely a problem on the server side not client side.