Opened 7 years ago
Closed 5 years ago
#6984 closed defect (invalid)
RTSP protocol options are inconsistent with HTTP protocol options
Reported by: | gjdfgh | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | unspecified | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug:
The RTSP protocol has a "timeout" option, like the HTTP protocol. But it has very different semantics, which makes it a problem for API users, which try to provide a generic timeout option.
The differences are:
- the "timeout" option is in seconds instead of microseconds
- the "timeout" option enables listen mode and breaks any client usage
There is a "stimeout" option that does what you'd expect for "timeout", but since it has a different name and requires being aware of the protocol being used anyway, this does not help.
A proper solution would rename "timeout" to something else, and "stimeout" to "timeout".
How to reproduce:
% ffmpeg -timeout 6000000 -i rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov -f null -
This should not fail. Happens with any ffmpeg version from current git master to releases from a few years ago. Full uncut console output available on your shell terminal.
In addition, the "user-agent" option should be named "user_agent".
Maybe fixed but since all necessary information is missing and multiple issues are reported, it makes more sense to close as invalid.