On Thu, 25 Jan 2018 21:17:54 +0100 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Thu, Jan 25, 2018 at 08:54:51PM +0100, wm4 wrote: > > On Thu, 25 Jan 2018 20:46:13 +0100 > > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > > > On Thu, Jan 25, 2018 at 07:00:43PM +0100, wm4 wrote: > > > > The names inherently clash with the meanings of the HTTP libavformat > > > > protocol options. Rename them after a deprecation period to make them > > > > compatible with the HTTP ones. > > > > --- > > > > I see no better way that wouldn't require more effort than justified. > > > > The incompatible semantics of the "timeout" option while still clashing > > > > with the HTTP one caused major problems to me as API user, and I'm > > > > hoping that this will solve itself in 2 years. > > > > --- > > > > doc/APIchanges | 5 +++++ > > > > libavformat/rtsp.c | 9 +++++++++ > > > > libavformat/version.h | 5 ++++- > > > > 3 files changed, 18 insertions(+), 1 deletion(-) > > > > > > Make sure all newly added options are in standard SI units > > > that is seconds (not micro seconds for example) > > > > 1. you can not use seconds if the option type is int because that would > > not be fine grained enough > > 2. HTTP already uses microseconds and the whole point is making this > > compatible with the HTTP impl. (as it establishes sort of a standard > > being the most used protocol other than file) > > 3. Microsecond actually counts as SI unit > > 4. I'm not going to change the HTTP impl. as that would be a much > > larger and intrusive change and would not solve the RTSP problem > > either > > if the user specifies "-whatever_timeout 500m" That should consistently be > interpreted as 500 milli seconds. > All new code should follow this consistently > > The user always provides a string never an integer. That is parsed, it can > be parsed into a double representing seconds, or an integer representing > micro/nano/milli/whatever. > > If you want to use an integer there are many ways to achive this, adding > a > AV_OPT_TYPE_TIMEOUT with int64 in nano seconds would be one. Using a > double in seconds would be much easier though > > If you do not want to change http, you can leave that to someone else > iam not asking you to do any extra work, just that we move toward > having timeouts handled consistently > Clearly you're trying to bikeshed me here. I'll just ignore this instead of wasting my time on you. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
