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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
