| Message ID | 20201013081712.1969-1-git@yigituyan.com |
|---|---|
| State | Accepted |
| Commit | c1efb1decb01af84d466a3f740c06c56c446ce56 |
| Headers | show |
| Series | [FFmpeg-devel] Preventing Buffer Overflow for RTSP Links Increasing the buffer size of control uri, used when storing the input argument RTSP link. Following the Web URI standards, lengths of RTSP links can extend beyond 1k characters. | expand |
| Context | Check | Description |
|---|---|---|
| andriy/x86_make | success | Make finished |
| andriy/x86_make_fate | success | Make fate finished |
| andriy/PPC64_make | warning | Make failed |
Hi, I've just checked the state of this patch on Patchwork. There are three builds listed, two successful and one warning. I've checked the logs for the warning, none seems to be about the submitted patch. I've also thoroughly tested the code prior to submitting. This is the first patch I'm submitting to ffmpeg. When would this patch be included in the official builds? Is there anything I need to do? Also is there a nightly, or a dev version of ffmpeg including this patch that I can share with others to try it out? Thanks,
Hi, Quoting git@yigituyan.com (2020-10-21 20:17:18) > Hi, I've just checked the state of this patch on Patchwork. There are > three builds listed, two successful and one warning. I've checked the > logs for the warning, none seems to be about the submitted patch. I've > also thoroughly tested the code prior to submitting. > > This is the first patch I'm submitting to ffmpeg. When would this patch > be included in the official builds? Is there anything I need to do? > > Also is there a nightly, or a dev version of ffmpeg including this patch > that I can share with others to try it out? I am not an expert on RTSP, but it could help if you: - reformatted the commit message according to project standards - added a more specific reference to the standards you mention - described how did you test the fix
Hi Anton, Thanks for responding! - For more information on URI length standards for the web domain, this link provides a good explanation: https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers Simply speaking there are no set standards for the maximum limit on a HTTPs or RTSPs URI, but a de-facto one from browsers such as Chrome and Firefox start clipping URIs at 2k characters. In line with this, many infrastructure preparing, serving and consuming these URIs also generally try to stay under the limit of 2k characters. In our case (Google), the infrastructure preparing these URIs is also targeting 2k characters. In the RTSPs (secured RTSP) case, with authentication tokens 512 or 1024 character long attached to the URI, it is very easy to come close to this limit. As we open up several million cameras around the world to individual developers and companies, as part of our Device Access program (https://developers.google.com/nest/device-access), we started to get questions from people that wanted to use FFmpeg to stream their video. Your application handles RTSPs URIs up to an arbitrary 1k limit fine, but falls short on URIs that goes up to 2k characters. This patch addresses that issue. - How to run: ffmpeg <rtsts url> To test, if you run this command with an RTSPs URI longer than 1024 characters, you'll see the playback fails. With this patch applied, those URIs will start to work too. Please let me know if there are any non-acceptable blockers on your side to ingest this patch. Otherwise, please help me to get this patch into the next ffmpeg release in a timely manner, so people can start using it. Best, - Yiğit
diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h index 54a9a30c16..2b37f5b49f 100644 --- a/libavformat/rtsp.h +++ b/libavformat/rtsp.h @@ -315,7 +315,7 @@ typedef struct RTSPState { /** some MS RTSP streams contain a URL in the SDP that we need to use * for all subsequent RTSP requests, rather than the input URI; in * other cases, this is a copy of AVFormatContext->filename. */ - char control_uri[1024]; + char control_uri[2048]; /** The following are used for parsing raw mpegts in udp */ //@{