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

Jan Ekström jeebjp at gmail.com
Fri Jan 26 02:45:47 EET 2018


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.


Best regards,
Jan


More information about the ffmpeg-devel mailing list