[FFmpeg-devel] [PATCH] rtsp: rename certain options after a deprecation period

[Michael Niedermayer]

On Fri, Jan 26, 2018 at 02:45:47AM +0200, Jan Ekström wrote:
> On Fri, Jan 26, 2018 at 1:56 AM, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> > 2018-01-26 0:52 GMT+01:00 wm4 <nfxjfg at googlemail.com>:
> >> (and I already wrote that on IRC too, where he lurks as
> >> michaelni)
> >
> > Could one of the native speakers please try to convince
> > me that this is not a disparaging term?
> >
> 
> Hi,
> 
> I am not an English native, but the verb "to lurk" is colloquially utilized as:
> 
> "read the postings in an Internet forum without actively contributing."
> (quote from whatever dictionary Google utilizes)
> 
> ...and this IMHO is applicable enough as Michael is busy just like
> many of us are busy most of the day.
> 
> Now, please, all parties. Stop. We've had enough rudeness in this
> thread. And now, back to on-topic:
> 
> * This change set offers to rename some options to make them similar
> to how the TCP protocol does things
> (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/tcp.c;h=8773493df1efebac33cff5d203c8c9ff17299d4b;hb=HEAD#l52).
> UDP protocol seems to follow suite regarding the "timeout" parameter,
> even matching the microsecond part?
> * It's imperfect since it doesn't change any of the types of the
> options (listen_timeout is now name-wise matched, but type-wise is
> supposed to contain seconds for rtsp, milliseconds (! yet another time
> scale) in tcp).
> * But if we do not rename the current timeout parameter (which does a
> different thing than timeout for both TCP and UDP - and name-wise
> matches "listen_timeout" as far as it can be seen), we cannot have the
> matching name for the matching type of - which should be under the
> option "timeout".
> 
> So, as far as I can see for now applying this or a slightly modified
> version of this as per James' comments doesn't seem to be a too bad
> initial step. It brings at least one option in line. We can then start
> the larger job of normalizing the timeout parameter across FFmpeg, as
> it seems like mentioning this area made multiple people notice
> possible improvements in this area. But this is just my 2 eurocents.

I think we first should take a step back and decide how we want a
consistent API to look exactly.
Then make changes towards that.

This patch introduces a parameter that very possibly will have to
be deprecated when things are changed to consistent second based timeouts.

I mean this patch makes rtsp consistent with parameters that we may have to
deprecate.

Lets just for a moment assume we agree that we want to have consistent
second based timeouts throughout the codebase.
To achive this with minimal confusion it requires a new parameter name
that has not been used for micro or nano or milli seconds before.
If now a new parameter for timeouts is added in seconds then each
piece of code can independantly add support to it one by one never
conflicting with anything or depending on anything.
And all existing timeouts that are not in seconds would then become
deprecated.

I think thats a meaningfull way forward and i would suggest that we
go that direction. Its very easy to do too once there is agreement on
the name of the new parameter(s)

We can also apply this patch but its not really moving us closer to
consistent second based timeouts.

thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180126/e99c26b0/attachment.sig>