I'm using ffmpeg library to write to the rtsp stream.
It is working well when the rtsp url is correct.
But when this rtsp url is incorrect then it is stuck in avformat_write_header.
Is there any solution for this problem?
Thanks.
Please refer to following link:
[FFmpeg-user] How do I set a timeout for an RTSP source?
There are two timeout type of options for RTSP:
‘-timeout’
Set maximum timeout (in seconds) to wait for incoming connections.
A value of -1 mean infinite (default). This option implies the
‘rtsp_flags’ set to ‘listen’. ‘reorder_queue_size’
Set number of packets to buffer for handling of reordered packets.
‘-stimeout’
Set socket TCP I/O timeout in micro seconds.
Both ‘-timeout’ & ‘-stimeout’ do not work for me.
My solution [python code] is:
while True:
try:
check_call('ffmpeg -i <rtsp://your-input-stream-url> -frames:v 1 screenshot.jpg', shell=True, timeout=N) # try to get a screenshot if RTSP stream is OK
except TimeoutExpired as e:
logger.error('RTSP stream error') # send error message if timeout
break
Good luck.
Just my two cents here. Sometimes you are establising the connection and need to close it if there's no stream in N seconds. A simple -timeout option will switch your connection mode (may be unwanted) and they had some bug in older versions of ffmpeg that made -stimeout fail your purpose sometimes.
Here's one more timeout, the rw_timeout:
rw_timeout
Maximum time to wait for (network) read/write operations to complete, in microseconds.
As said, it is a network-related option, could be of use both with ffmpeg utils and from source code.
Related
Problem: How can I detect when the audio UAC1 gadget is used from a host device?
Background: I created a USB audio gadget using USB Audio Class 1 (UAC1) to send/receive audio over USB from a Linux device to/from a Windows host. The gadget is already working and Windows detects the device as an audio in and output. I am also able to send and receive audio over the gadget using alsa and jack.
Detailed Problem: I'm trying to connect two different audio devices with Jack to route an incoming signal from audio-device-1 to the output of audio-device-2. To do this, I'm working with the virtual wiring of Jack. This works already fine, but I run into the problem that if the gadget device is not actively selected as audio in and output in a DAW or other program on the host computer (e.g. Windows), Jack gets a "poll time out" error and the virtual wiring has to be restarted.
$ jackd -r --name default -d alsa --device hw:2 -r 48000 -p 64 -n 2
jackdmp 1.9.17
....
creating alsa driver ... hw:2|hw:2|64|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 64 frames (1.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 24bit little-endian in 3bytes format
ALSA: use 4 periods for capture
ALSA: final selected sample format for playback: 24bit little-endian in 3bytes format
ALSA: use 4 periods for playback
ALSA: poll time out, polled for 2000981 usecs, Retrying with a recovery, retry cnt = 1
ALSA: poll time out, polled for 2000979 usecs, Retrying with a recovery, retry cnt = 2
ALSA: poll time out, polled for 2000982 usecs, Retrying with a recovery, retry cnt = 3
ALSA: poll time out, polled for 2000979 usecs, Retrying with a recovery, retry cnt = 4
ALSA: poll time out, polled for 2000988 usecs, Retrying with a recovery, retry cnt = 5
ALSA: poll time out, polled for 2000989 usecs, Reached max retry cnt = 5, Exiting
JackAudioDriver::ProcessAsync: read error, stopping...
I would like to solve this automatically e.g. via a shell script that detects when the gadget driver is requested by the host and I then start the virtual cabling with Jack.
For this it is necessary to be able to read whether the gadget driver is in use or not.
Is there any directory / file where I can detect, if the audio gadget device is in use?
What would make a write call to a TCPSocket hang indefinitely?
lotsOfBytes = # a really large number of bytes, like 1 or 2 MB of data
socket = TCPSocket.new # some config
socket.write(lotsOfBytes) # this line hangs
I am trying to debug an issue where a get_multi operation sent to memcached with a large number of keys hangs indefinitely, and it does so on a line that resembles that code snippet. I'm trying to better understand how the low-level sockets on which this library is built are expected to work.
What are the values of following attributes on your TCPSocket:
Keep-alive activated and what value is set?
Timeout set and what value is set?
If you will do a Wireshark dump, it's much better so see what happens before hanging connection.
tcpdump? are there any attempts to send anything?
netstat - for see output queue.
does it work on a small number of bytes in your environment?
I'm attempting to play a live stream on ChromeCast. The stream is thrown fine and starts playback appropriately.
However when I play the stream longer: somewhere between 2-15 minutes, the player stops playing and I get MediaStatus.IDLE_REASON_ERROR in my RemoteMediaClient.Callback.
When looking at the console logs from ChromeCast I see that 3-4 calls are failed. Here are the logs:
14:50:26.931 GET https://... 0 ()
14:50:27.624 GET https://... 0 ()
14:50:28.201 GET https://... 0 ()
14:50:29.351 GET https://... 0 ()
14:50:29.947 media_player.js:64 [1381.837s] [cast.player.api.Host] error: cast.player.api.ErrorCode.NETWORK/3126000
Looking at Cast MediaPlayer.ErrorCode Error 312.* is
Failed to retrieve the media (bitrated) playlist m3u8 file with three retries.
Developers need to validate that their playlists are indeed available. It could be the case that a user that cannot reach the playlist as well.
I checked, the playlist was available. So I thought perhaps the server wasn't responding. So I looked at the network calls response logs.
Successful Request
Stalled Request
Note that the stall time far exceeds the usual stall time.
ChromeCast isn't making these calls at all, the requests are simply stalled for a long time until they are cancelled. All the successful requests are stalled for less than 14ms (mostly under 2ms).
The Network Analysis Timing Breakdown provides three reasons for stalling
There are higher priority requests.
There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.
The browser is briefly allocating space in the disk cache
While I do believe the first one should not be the case, the later two can be. However in both cases I believe the fault lies with cast.player.
Am I doing something wrong?
Has anyone else faced the same issue? Is there any way to either fix it or come up with a work-around.
Standard squid config only logs one CONNECT line for any https transaction. What is being counted/timed by the reported bytes and duration fields in that line?
Got an answer via the squid-users mailing list [1]:
Unless you are using SSL-Bump or such to process the contents specially.
The duration is from the CONNECT message arriving to the time TCP close
is used to end the tunnel. The size should be the bytes sent to the
client (excluding the 200 reply message itself) during that time.
[1] http://lists.squid-cache.org/pipermail/squid-users/2016-July/011714.html
I have built an audio stream for mp3 files, and each time client hits the audio it receives something like this:
But what it does is just plays 1 minute sample instead of 120 minute
What am I doing wrong here?
Not 100% sure because you didn't provide code or an example stream to test, but your handling of HTTP range requests is broken.
In your example request, the client sends Range: bytes=0-, and your server responds with a 1MiB response:
Content-Length: 1048576 (aka. 1 MiB)
Content-Range: 0-1048575/...
This is wrong, the client did not request this! It did request bytes=0-, meaning all data from position 0 to the end of the entire stream (See the http 1.1 RFC), i.e. a response equal to one without any Range. (IIRC, Firefox still sends the Range: bytes=0- to detect if the Server handles ranges in the first place).
This, combined with the Content-Length, leads the client (Firefox) to think the whole resource is just 1MiB in size, instead of the real size. I'd imagine the first 1 MiB of your test stream comes out as 1:06 of audio.
PS: The Content-Duration header (aka. RFC 3803) is something browsers don't usually implement at all and just ignore.
Just an idea. Did you tried some of the http 3xx header like:
'308 Resume Incomplete' or '503 Service Temporarily Unavailable' plus 'retry-after:2' or '413 Request Entity Too Large' plus 'retry-after:2'