Discussion:
[PATCH 0/20] removal of deprecated features
(too old to reply)
Vittorio Giovara
2015-07-28 13:36:16 UTC
Permalink
This set contains the removal of all deprecated features marked as
such until 2012/early 2013. This was announced several times in the
past months and agreed at several meetings (since fosdem and recently
at the sprint).

With more than two year span, downstream users should have had enough
time to update their API usage (or comment otherwise).

This is in preparation of release 13 for August/September.
Cheers
--
Vittorio
Kostya Shishkov
2015-07-28 13:54:32 UTC
Permalink
Post by Vittorio Giovara
This set contains the removal of all deprecated features marked as
such until 2012/early 2013. This was announced several times in the
past months and agreed at several meetings (since fosdem and recently
at the sprint).
With more than two year span, downstream users should have had enough
time to update their API usage (or comment otherwise).
I'd say swscale in general is a deprecated feature or should be one. And it's
your fault it's still not been replaced.
Anton Khirnov
2015-07-29 06:44:48 UTC
Permalink
Quoting Kostya Shishkov (2015-07-28 15:54:32)
Post by Kostya Shishkov
Post by Vittorio Giovara
This set contains the removal of all deprecated features marked as
such until 2012/early 2013. This was announced several times in the
past months and agreed at several meetings (since fosdem and recently
at the sprint).
With more than two year span, downstream users should have had enough
time to update their API usage (or comment otherwise).
I'd say swscale in general is a deprecated feature or should be one. And it's
your fault it's still not been replaced.
I strongly suspect you could have written mountains of SIMD for avscale
in the time it takes you to write these mails =p
--
Anton Khirnov
Kostya Shishkov
2015-07-29 06:59:42 UTC
Permalink
Post by Anton Khirnov
Quoting Kostya Shishkov (2015-07-28 15:54:32)
Post by Kostya Shishkov
Post by Vittorio Giovara
This set contains the removal of all deprecated features marked as
such until 2012/early 2013. This was announced several times in the
past months and agreed at several meetings (since fosdem and recently
at the sprint).
With more than two year span, downstream users should have had enough
time to update their API usage (or comment otherwise).
I'd say swscale in general is a deprecated feature or should be one. And it's
your fault it's still not been replaced.
I strongly suspect you could have written mountains of SIMD for avscale
in the time it takes you to write these mails =p
Maybe, there's just no point doing all that alone with no clear goal.
Anton Khirnov
2015-07-29 07:07:53 UTC
Permalink
Quoting Kostya Shishkov (2015-07-29 08:59:42)
Post by Kostya Shishkov
Post by Anton Khirnov
Quoting Kostya Shishkov (2015-07-28 15:54:32)
Post by Kostya Shishkov
Post by Vittorio Giovara
This set contains the removal of all deprecated features marked as
such until 2012/early 2013. This was announced several times in the
past months and agreed at several meetings (since fosdem and recently
at the sprint).
With more than two year span, downstream users should have had enough
time to update their API usage (or comment otherwise).
I'd say swscale in general is a deprecated feature or should be one. And it's
your fault it's still not been replaced.
I strongly suspect you could have written mountains of SIMD for avscale
in the time it takes you to write these mails =p
Maybe, there's just no point doing all that alone with no clear goal.
Here's a clear goal:
1) make avscale feature complete
2) deprecate swscale
3) ???
4) profit
--
Anton Khirnov
Kostya Shishkov
2015-07-29 07:23:32 UTC
Permalink
Post by Anton Khirnov
Quoting Kostya Shishkov (2015-07-29 08:59:42)
Post by Kostya Shishkov
Post by Anton Khirnov
Quoting Kostya Shishkov (2015-07-28 15:54:32)
Post by Kostya Shishkov
Post by Vittorio Giovara
This set contains the removal of all deprecated features marked as
such until 2012/early 2013. This was announced several times in the
past months and agreed at several meetings (since fosdem and recently
at the sprint).
With more than two year span, downstream users should have had enough
time to update their API usage (or comment otherwise).
I'd say swscale in general is a deprecated feature or should be one. And it's
your fault it's still not been replaced.
I strongly suspect you could have written mountains of SIMD for avscale
in the time it takes you to write these mails =p
Maybe, there's just no point doing all that alone with no clear goal.
1) make avscale feature complete
2) deprecate swscale
3) ???
4) profit
So far I like only step #3, avscale might happen but not in Libav.
Andreas Cadhalpun
2015-07-30 15:05:12 UTC
Permalink
Hi,
Post by Vittorio Giovara
This set contains the removal of all deprecated features marked as
such until 2012/early 2013. This was announced several times in the
past months and agreed at several meetings (since fosdem and recently
at the sprint).
With more than two year span, downstream users should have had enough
time to update their API usage (or comment otherwise).
Unfortunately this is just wishful thinking.
As it is, your proposed removal of deprecated features is going to break
about three quarters of all packages using the libav* libraries in Debian:

FF_API_PIX_FMT: 57
amide avbin avifile bino chromium-browser dff dolphin-emu dvswitch
ffmpeg2theora ffmpegthumbnailer ffmpegthumbs fuse-emulator-utils
gmerlin-avdecoder gmerlin-encoders gnash gpac gst-libav1.0 guvcview harvid
hedgewars info-beamer karlyriceditor kodi lebiniou libam7xxx libavg libde265
libextractor libquicktime linphone lives lynkeos.app mlt mplayer mplayer2 opal
openscenegraph ovito paraview performous pjproject qutecom rbdoom3bfg sflphone
strigi survex transcode vtk vtk6 vxl wxsvg x264 xjadeo xpra yorick-av
zoneminder

FF_API_AVFRAME_LAVC: 19
acoustid-fingerprinter amarok aubio blender chromaprint dvbcut gazebo
goldendict jugglemaster kino lightspark mrpt opencv shotdetect spek
squeezelite vcmi vlc xine-lib-1.2

FF_API_AUDIOCONVERT: 5
alsa-plugins cantata ffdiaporama moc mpv

FF_API_DESTRUCT_PACKET: 1
openmw

FF_API_AVFILTERBUFFER: 1
pianobar

Note that this is only counting one API per packet.

Ideally you should make sure that patches for all of them are available,
before these APIs get removed.

Considering how widespread the use of FF_API_PIX_FMT and FF_API_AVFRAME_LAVC
still is, it might make sense to delay their removal.

Best regards,
Andreas
Anton Khirnov
2015-07-30 15:38:07 UTC
Permalink
Quoting Andreas Cadhalpun (2015-07-30 17:05:12)
Post by Andreas Cadhalpun
Hi,
Post by Vittorio Giovara
This set contains the removal of all deprecated features marked as
such until 2012/early 2013. This was announced several times in the
past months and agreed at several meetings (since fosdem and recently
at the sprint).
With more than two year span, downstream users should have had enough
time to update their API usage (or comment otherwise).
Unfortunately this is just wishful thinking.
As it is, your proposed removal of deprecated features is going to break
FF_API_PIX_FMT: 57
amide avbin avifile bino chromium-browser dff dolphin-emu dvswitch
ffmpeg2theora ffmpegthumbnailer ffmpegthumbs fuse-emulator-utils
gmerlin-avdecoder gmerlin-encoders gnash gpac gst-libav1.0 guvcview harvid
hedgewars info-beamer karlyriceditor kodi lebiniou libam7xxx libavg libde265
libextractor libquicktime linphone lives lynkeos.app mlt mplayer mplayer2 opal
openscenegraph ovito paraview performous pjproject qutecom rbdoom3bfg sflphone
strigi survex transcode vtk vtk6 vxl wxsvg x264 xjadeo xpra yorick-av
zoneminder
FF_API_AVFRAME_LAVC: 19
acoustid-fingerprinter amarok aubio blender chromaprint dvbcut gazebo
goldendict jugglemaster kino lightspark mrpt opencv shotdetect spek
squeezelite vcmi vlc xine-lib-1.2
FF_API_AUDIOCONVERT: 5
alsa-plugins cantata ffdiaporama moc mpv
FF_API_DESTRUCT_PACKET: 1
openmw
FF_API_AVFILTERBUFFER: 1
pianobar
Note that this is only counting one API per packet.
Ideally you should make sure that patches for all of them are available,
before these APIs get removed.
Considering how widespread the use of FF_API_PIX_FMT and FF_API_AVFRAME_LAVC
still is, it might make sense to delay their removal.
Past experience indicates that if we wanted to wait for all (or even
most) of the downstreams to adapt before breaking compatiblity, we'd
have to wait forever. Most of then, unfortunately, have to be forced
into adopting the new APIs.
--
Anton Khirnov
Andreas Cadhalpun
2015-07-30 15:49:51 UTC
Permalink
Post by Anton Khirnov
Quoting Andreas Cadhalpun (2015-07-30 17:05:12)
Post by Andreas Cadhalpun
Ideally you should make sure that patches for all of them are available,
before these APIs get removed.
Considering how widespread the use of FF_API_PIX_FMT and FF_API_AVFRAME_LAVC
still is, it might make sense to delay their removal.
Past experience indicates that if we wanted to wait for all (or even
most) of the downstreams to adapt before breaking compatiblity, we'd
have to wait forever.
I think that keeping some of these APIs "forever" is much less of a problem
then breaking the majority of reverse dependencies.
Post by Anton Khirnov
Most of then, unfortunately, have to be forced into adopting the new APIs.
Have you tried sending them patches before breaking compatibility?

Best regards,
Andreas
Hendrik Leppkes
2015-07-30 16:00:58 UTC
Permalink
Am 30.07.2015 17:50 schrieb "Andreas Cadhalpun" <
Post by Andreas Cadhalpun
Post by Anton Khirnov
Quoting Andreas Cadhalpun (2015-07-30 17:05:12)
Post by Andreas Cadhalpun
Ideally you should make sure that patches for all of them are available,
before these APIs get removed.
Considering how widespread the use of FF_API_PIX_FMT and
FF_API_AVFRAME_LAVC
Post by Andreas Cadhalpun
Post by Anton Khirnov
Post by Andreas Cadhalpun
still is, it might make sense to delay their removal.
Past experience indicates that if we wanted to wait for all (or even
most) of the downstreams to adapt before breaking compatiblity, we'd
have to wait forever.
I think that keeping some of these APIs "forever" is much less of a problem
then breaking the majority of reverse dependencies.
Post by Anton Khirnov
Most of then, unfortunately, have to be forced into adopting the new APIs.
Have you tried sending them patches before breaking compatibility?
Patching dozens of downstream projects is clearly not in the scope of what
should be expected from any Libav or FFmpeg developer.

Adapting to most of the changes being deprecated here is trivial however,
so if those projects have any maintainers at all, maybe you should notify
them instead to fix their project, instead of expecting us to do it for
them.
Andreas Cadhalpun
2015-07-30 17:06:56 UTC
Permalink
Post by Hendrik Leppkes
Patching dozens of downstream projects is clearly not in the scope of what
should be expected from any Libav or FFmpeg developer.
But keeping the API usable is. Regularly breaking the majority of reverse
dependencies makes an API much less usable.

So the choice should be between either keeping the still widely used,
deprecated API or fixing downstream projects.
Post by Hendrik Leppkes
Adapting to most of the changes being deprecated here is trivial however,
so if those projects have any maintainers at all, maybe you should notify
them instead to fix their project, instead of expecting us to do it for
them.
It might be trivial for you, but probably not for all the developers of the
downstream projects. Thus if such a notification came with a patch it would
likely be much more helpful.

Best regards,
Andreas
Luca Barbato
2015-07-30 16:10:19 UTC
Permalink
Post by Andreas Cadhalpun
Have you tried sending them patches before breaking compatibility?
We did in the past.

Needless to say distributors then did not pick up the updated releases
of those softwares making it sort of a meaningless endeavor.

lu
Andreas Cadhalpun
2015-07-30 17:08:12 UTC
Permalink
Post by Luca Barbato
Post by Andreas Cadhalpun
Have you tried sending them patches before breaking compatibility?
We did in the past.
Great, so please do it again.
Post by Luca Barbato
Needless to say distributors then did not pick up the updated releases
of those softwares making it sort of a meaningless endeavor.
Probably they just needed more time to pick them up.
It's the fault of the distributors, if they ship newer versions of
the libav* libraries, but not of the packages using them.

Best regards,
Andreas
Anton Khirnov
2015-07-30 16:26:47 UTC
Permalink
Quoting Andreas Cadhalpun (2015-07-30 17:49:51)
Post by Andreas Cadhalpun
Post by Anton Khirnov
Quoting Andreas Cadhalpun (2015-07-30 17:05:12)
Post by Andreas Cadhalpun
Ideally you should make sure that patches for all of them are available,
before these APIs get removed.
Considering how widespread the use of FF_API_PIX_FMT and FF_API_AVFRAME_LAVC
still is, it might make sense to delay their removal.
Past experience indicates that if we wanted to wait for all (or even
most) of the downstreams to adapt before breaking compatiblity, we'd
have to wait forever.
I think that keeping some of these APIs "forever" is much less of a problem
then breaking the majority of reverse dependencies.
The API breaks are not done for the fun of it. There's a bunch of
reasons why I think keeping them is a bad idea:
- some of the changes involve adding prefixes for proper namespacing, so
libav does not randomly conflict with other libraries. Here, keeping
the old names pretty much negates the whole point.
- the less trivial changes are mostly done because the old API was
inadequate. Many of the old APIs were not designed at all, but just
randomly added because mplayer or ffmpeg.c happened to need some
feature at the time. The result was usually un(der)documented, hard to
use correctly and often not well defined in some cases. Most users of
the old API that I've seen actually used it wrong and would at best
occasionally fail to work, at worst crash randomly. So keeping those
APIs is not really in anyone's interest IMO.
- finally there's of course the maintenance burden of keeping
compatibility layers, sometimes of rather large complexity. They are
also often poorly tested and not very much maintained so, again, they
might fail to work in some less common cases.
Post by Andreas Cadhalpun
Post by Anton Khirnov
Most of then, unfortunately, have to be forced into adopting the new APIs.
Have you tried sending them patches before breaking compatibility?
I actually did fix a huge number of packages during the last two API
breaks. But it's not really reasonable to expect me to do it all the
time.
--
Anton Khirnov
Andreas Cadhalpun
2015-07-30 17:10:12 UTC
Permalink
Post by Anton Khirnov
Quoting Andreas Cadhalpun (2015-07-30 17:49:51)
Post by Andreas Cadhalpun
I think that keeping some of these APIs "forever" is much less of a problem
then breaking the majority of reverse dependencies.
The API breaks are not done for the fun of it.
I hope so. ;)
Post by Anton Khirnov
- some of the changes involve adding prefixes for proper namespacing, so
libav does not randomly conflict with other libraries. Here, keeping
the old names pretty much negates the whole point.
However, it works without namespace clashes so far.
Post by Anton Khirnov
- the less trivial changes are mostly done because the old API was
inadequate. Many of the old APIs were not designed at all, but just
randomly added because mplayer or ffmpeg.c happened to need some
feature at the time. The result was usually un(der)documented, hard to
use correctly and often not well defined in some cases. Most users of
the old API that I've seen actually used it wrong and would at best
occasionally fail to work, at worst crash randomly. So keeping those
APIs is not really in anyone's interest IMO.
- finally there's of course the maintenance burden of keeping
compatibility layers, sometimes of rather large complexity. They are
also often poorly tested and not very much maintained so, again, they
might fail to work in some less common cases.
Removing these APIs causes compile failures, which are more severe than
occasional runtime failures. It means people have to use old versions of
the libav* libraries.
Post by Anton Khirnov
Post by Andreas Cadhalpun
Post by Anton Khirnov
Most of then, unfortunately, have to be forced into adopting the new APIs.
Have you tried sending them patches before breaking compatibility?
I actually did fix a huge number of packages during the last two API
breaks. But it's not really reasonable to expect me to do it all the
time.
Certainly. But someone has to do the work, if you want to remove widely
used APIs.

Best regards,
Andreas
Anton Khirnov
2015-07-30 17:49:06 UTC
Permalink
Quoting Andreas Cadhalpun (2015-07-30 19:10:12)
Post by Andreas Cadhalpun
Post by Anton Khirnov
- some of the changes involve adding prefixes for proper namespacing, so
libav does not randomly conflict with other libraries. Here, keeping
the old names pretty much negates the whole point.
However, it works without namespace clashes so far.
Because, when such clashes occur, the caller has to some rather painful
black magic to fix them. The point here is to avoid this for all future
code.
Post by Andreas Cadhalpun
Post by Anton Khirnov
- the less trivial changes are mostly done because the old API was
inadequate. Many of the old APIs were not designed at all, but just
randomly added because mplayer or ffmpeg.c happened to need some
feature at the time. The result was usually un(der)documented, hard to
use correctly and often not well defined in some cases. Most users of
the old API that I've seen actually used it wrong and would at best
occasionally fail to work, at worst crash randomly. So keeping those
APIs is not really in anyone's interest IMO.
- finally there's of course the maintenance burden of keeping
compatibility layers, sometimes of rather large complexity. They are
also often poorly tested and not very much maintained so, again, they
might fail to work in some less common cases.
Removing these APIs causes compile failures, which are more severe than
occasional runtime failures. It means people have to use old versions of
the libav* libraries.
I would disagree here. A build failure affects everyone, so it usually
motivates someone into adapting to the new API, which is usually rather
easy to do.

OTOH random misbehaviour affects only some users, so it often goes
unreported, and even if reported can be hard to debug. So I'd say it is
worse for the users.
Post by Andreas Cadhalpun
Post by Anton Khirnov
Post by Andreas Cadhalpun
Post by Anton Khirnov
Most of then, unfortunately, have to be forced into adopting the new APIs.
Have you tried sending them patches before breaking compatibility?
I actually did fix a huge number of packages during the last two API
breaks. But it's not really reasonable to expect me to do it all the
time.
Certainly. But someone has to do the work, if you want to remove widely
used APIs.
That would typically be the maintainer of the code. I'll gladly to
answer any question regarding migration on IRC, but I really don't have
the kind of free time to fix everything myself.
--
Anton Khirnov
Vittorio Giovara
2015-07-31 14:17:24 UTC
Permalink
On Thu, Jul 30, 2015 at 6:10 PM, Andreas Cadhalpun
Post by Andreas Cadhalpun
Removing these APIs causes compile failures, which are more severe than
occasional runtime failures. It means people have to use old versions of
the libav* libraries.
I disagree as well, it's true that noone likes code failing to
compile, but a runtime misbehaviour is several orders of magnitude
worse. Also, in my opinion, if maintainers or the community don't
upgrade their code (or code they care about) when APIs change, it's
not a good sign of a healthy, engaged environment, where code can be
left bitrotting.
Post by Andreas Cadhalpun
Post by Anton Khirnov
I actually did fix a huge number of packages during the last two API
breaks. But it's not really reasonable to expect me to do it all the
time.
Certainly. But someone has to do the work, if you want to remove widely
used APIs.
"widely used APIs" that were marked deprecated two years ago. That
someone is the downstream project maintainer.

Exactly like there is a "promise" that API won't be broken (unless
necessary) between minor releases, by using libav APIs you "agree"
that there can be breakage between major, and for good reasons too.
The "announcement" is in the form of warnings when you try to use the
API. Not removing deprecated APIs when the time is due would mean that
no deprecation would be taken seriously, thus neutering the whole
concept of deprecating code.

Also please kindly stop saying "you should do this" or "you should do
that", noone is asking you to do anything, so don't try to impose
additional expectations on libav maintainers. Finally there is still
time before distributions pick up candidates for new releases, both of
the library and of the downstream project, so I don't really see any
use of complaining now (two years *after* the deprecation was
announced).

Cheers
--
Vittorio
Janne Grunau
2015-08-02 10:54:37 UTC
Permalink
Post by Anton Khirnov
Quoting Andreas Cadhalpun (2015-07-30 17:05:12)
Post by Andreas Cadhalpun
Hi,
Post by Vittorio Giovara
This set contains the removal of all deprecated features marked as
such until 2012/early 2013. This was announced several times in the
past months and agreed at several meetings (since fosdem and recently
at the sprint).
With more than two year span, downstream users should have had enough
time to update their API usage (or comment otherwise).
Unfortunately this is just wishful thinking.
As it is, your proposed removal of deprecated features is going to break
FF_API_PIX_FMT: 57
amide avbin avifile bino chromium-browser dff dolphin-emu dvswitch
ffmpeg2theora ffmpegthumbnailer ffmpegthumbs fuse-emulator-utils
gmerlin-avdecoder gmerlin-encoders gnash gpac gst-libav1.0 guvcview harvid
hedgewars info-beamer karlyriceditor kodi lebiniou libam7xxx libavg libde265
libextractor libquicktime linphone lives lynkeos.app mlt mplayer mplayer2 opal
openscenegraph ovito paraview performous pjproject qutecom rbdoom3bfg sflphone
strigi survex transcode vtk vtk6 vxl wxsvg x264 xjadeo xpra yorick-av
zoneminder
FF_API_AVFRAME_LAVC: 19
acoustid-fingerprinter amarok aubio blender chromaprint dvbcut gazebo
goldendict jugglemaster kino lightspark mrpt opencv shotdetect spek
squeezelite vcmi vlc xine-lib-1.2
FF_API_AUDIOCONVERT: 5
alsa-plugins cantata ffdiaporama moc mpv
FF_API_DESTRUCT_PACKET: 1
openmw
FF_API_AVFILTERBUFFER: 1
pianobar
Note that this is only counting one API per packet.
Ideally you should make sure that patches for all of them are available,
before these APIs get removed.
Considering how widespread the use of FF_API_PIX_FMT and FF_API_AVFRAME_LAVC
still is, it might make sense to delay their removal.
Past experience indicates that if we wanted to wait for all (or even
most) of the downstreams to adapt before breaking compatiblity, we'd
have to wait forever. Most of then, unfortunately, have to be forced
into adopting the new APIs.
random silly idea:

instead of deleting deprecated features keep them for another release
but hidden under a define like
AV_USE_REMOVED_FEATURES_WILL_BREAK_WITH_$VERSION_NEXT. That would result
in compile errors by default and gives hopefully enough motivation to
fix things while it allows distributions to compile not updated software
against new libav.

I'm not certain if it will have the desired effect but at least we could
ignore every project which hardcaodes that define.

Janne
Luca Barbato
2015-08-04 13:34:02 UTC
Permalink
Post by Janne Grunau
instead of deleting deprecated features keep them for another release
but hidden under a define like
AV_USE_REMOVED_FEATURES_WILL_BREAK_WITH_$VERSION_NEXT. That would result
in compile errors by default and gives hopefully enough motivation to
fix things while it allows distributions to compile not updated software
against new libav.
I'm not certain if it will have the desired effect but at least we could
ignore every project which hardcodes that define.
I'd surely consider that for the round of release 13-14 if everybody
likes the idea.

lu
wm4
2015-07-31 15:08:56 UTC
Permalink
On Thu, 30 Jul 2015 17:05:12 +0200
Post by Andreas Cadhalpun
Hi,
Post by Vittorio Giovara
This set contains the removal of all deprecated features marked as
such until 2012/early 2013. This was announced several times in the
past months and agreed at several meetings (since fosdem and recently
at the sprint).
With more than two year span, downstream users should have had enough
time to update their API usage (or comment otherwise).
Unfortunately this is just wishful thinking.
As it is, your proposed removal of deprecated features is going to break
FF_API_PIX_FMT: 57
amide avbin avifile bino chromium-browser dff dolphin-emu dvswitch
ffmpeg2theora ffmpegthumbnailer ffmpegthumbs fuse-emulator-utils
gmerlin-avdecoder gmerlin-encoders gnash gpac gst-libav1.0 guvcview harvid
hedgewars info-beamer karlyriceditor kodi lebiniou libam7xxx libavg libde265
libextractor libquicktime linphone lives lynkeos.app mlt mplayer mplayer2 opal
openscenegraph ovito paraview performous pjproject qutecom rbdoom3bfg sflphone
strigi survex transcode vtk vtk6 vxl wxsvg x264 xjadeo xpra yorick-av
zoneminder
FF_API_AVFRAME_LAVC: 19
acoustid-fingerprinter amarok aubio blender chromaprint dvbcut gazebo
goldendict jugglemaster kino lightspark mrpt opencv shotdetect spek
squeezelite vcmi vlc xine-lib-1.2
FF_API_AUDIOCONVERT: 5
alsa-plugins cantata ffdiaporama moc mpv
FF_API_DESTRUCT_PACKET: 1
openmw
FF_API_AVFILTERBUFFER: 1
pianobar
Note that this is only counting one API per packet.
Ideally you should make sure that patches for all of them are available,
before these APIs get removed.
Considering how widespread the use of FF_API_PIX_FMT and FF_API_AVFRAME_LAVC
still is, it might make sense to delay their removal.
Why? It's not our job. Most of these things have been deprecated for
years, and these projects had time to catch up. If we keep everything
forever, we will never make progress.

Plus, you're probably overly conservative because you have to do
something about these packages. I suggest simply packaging an older
release of ffmpeg to keep these packages going.
Andreas Cadhalpun
2015-08-05 19:31:38 UTC
Permalink
I do have on more proposal, but the problem is it needs someone to do the work.
For each removed feature, prepare documentation "a monkey could follow" on how
to replace it (you could call it a transition guide).
Even better, a script that automates it where reasonable.
I think this is a very good idea.
In some cases it is just a matter of copy-pasting some existing wrapper code,
particularly if we remove that wrapper code it is useful if people still have
it available in the new release.
If it's just a few hours of someone's time who even doesn't need to understand
the code, I think we can very confidently say "not really our problem" if some
applications still use it.
Agreed.
If we that way find out that there are non-trivial cases or cases where the code
gets a lot more complicated it might be a hint the new API is still crap and we
maybe should come up with something better first.
A more complete usage list for the deprecated APIs is:

FF_API_PIX_FMT: 71
amide avbin avifile bino blender chromium-browser dff dolphin-emu dvbcut
dvswitch ffdiaporama ffmpeg2theora ffmpegthumbnailer ffmpegthumbs ffms2
fuse-emulator-utils gazebo gmerlin-avdecoder gmerlin-encoders gnash gpac
gst-libav1.0 guvcview harvid hedgewars info-beamer jugglemaster karlyriceditor
kino kodi lightspark lebiniou libam7xxx libavg libde265 libextractor
libquicktime linphone lives lynkeos.app mlt mplayer mplayer2 mrpt opal
opencv openmw openscenegraph ovito paraview performous pjproject qutecom
rbdoom3bfg renpy shotdetect sflphone strigi survex transcode vcmi vlc vtk vtk6
vxl wxsvg x264 xjadeo xpra yorick-av zoneminder

FF_API_AVFRAME_LAVC: 53
alsa-plugins amarok aubio avbin blender chromaprint dff dolphin-emu dvbcut
ffdiaporama ffmpegthumbnailer ffmpegthumbs fuse-emulator-utils gazebo
gmerlin-avdecoder gmerlin-encoders goldendict gpac gst-libav1.0 hedgewars
info-beamer jugglemaster kino libavg libextractor libquicktime lightspark
linphone mplayer mplayer2 mrpt opal opencv openscenegraph ovito paraview
performous pianopar qutecom renpy shotdetect spek squeezelite transcode
vcmi vlc vtk vtk6 vxl xine-lib-1.2 xpra yorick-av zoneminder

FF_API_GET_BUFFER: 9
avifile dvswitch gmerlin-avdecoder gst-libav1.0 libavg mplayer mplayer2 openmw
openscenegraph

FF_API_AUDIOCONVERT: 7
alsa-plugins cantata ffdiaporama moc mplayer2 mpv vlc

FF_API_SWS_CPU_CAPS: 6
fuse-emulator-utils kodi mlt mplayer2 vlc zoneminder

FF_API_DEINTERLACE: 5
blender dff ffmpegthumbnailer ffmpegthumbs vxl

FF_API_AVFRAME_LAVC(qscale): 3
ffmpeg2theora kodi xine-lib-1.2

FF_API_CODEC_ID: 3
chromium-browser dvswitch ffms2

FF_API_CONTEXT_SIZE: 3
mplayer mplayer2 xine-lib-1.2

FF_API_REQUEST_CHANNELS: 3
mplayer mplayer2 renpy

FF_API_AV_REVERSE: 2
mplayer mplayer2

FF_API_AVCODEC_RESAMPLE: 2
mlt mplayer

FF_API_DESTRUCT_PACKET: 2
lives openmw

FF_API_AVFILTERBUFFER: 2
ffdiaporama pianobar

FF_API_AVFILTERPAD_PUBLIC: 1
mplayer

FF_API_VIMA_DECODER: 1
mplayer



FF_API_PIX_FMT and FF_API_AVFRAME_LAVC are still widely used, but the
"patch-monkey" could deal with the changes and also with FF_API_AUDIOCONVERT,
FF_API_SWS_CPU_CAPS, FF_API_CODEC_ID, FF_API_CONTEXT_SIZE,
FF_API_REQUEST_CHANNELS and FF_API_VIMA_DECODER.

Regarding FF_API_GET_BUFFER, get_buffer should be replaced with get_buffer2,
but it's not clear how release_buffer/reget_buffer should be replaced.
Can someone explain/document this?

To get rid of FF_API_DEINTERLACE, one should 'use yadif (in libavfilter) instead'.
Well, ... how?

Then, as part of FF_API_AVFRAME_LAVC(qscale), the fields qscale_table, qstride and
qscale_type of AVFrame are to be removed, but (at least in FFmpeg) these are used by
the not deprecated functions av_frame_set_qp_table and av_frame_get_qp_table, so they
shouldn't be removed. Anyway it's not clear how to replace their usage.

Why is FF_API_AV_REVERSE deprecated?
It is used in FFmpeg's libavutil/eval.c.

One should 'use libswresample instead' of FF_API_AVCODEC_RESAMPLE.
A more detailed explanation would be good.

Same holds for FF_API_DESTRUCT_PACKET, where one should 'use the AVBuffer API
instead'.

For FF_API_AVFILTERBUFFER no replacement is documented.

FF_API_AVFILTERPAD_PUBLIC should be replaced by avfilter_pad_get_name and
avfilter_pad_get_type, but it seems that mplayer also uses others.

Better documentation would surely be helpful.
Btw. the magic option to enable compatibility is still somewhat useful as it lists
and allows testing the specific changes that are coming up. But I agree it's only
a minor help.
The problem with such a magic option is that it combines the disadvantages of
removing and not removing: Programs using the old API get broken by default
and the deprecated functionality remains in the code base.

Best regards,
Andreas
Reimar Döffinger
2015-08-05 20:07:45 UTC
Permalink
Post by Andreas Cadhalpun
Btw. the magic option to enable compatibility is still somewhat useful as it lists
and allows testing the specific changes that are coming up. But I agree it's only
a minor help.
The problem with such a magic option is that it combines the disadvantages of
removing and not removing: Programs using the old API get broken by default
and the deprecated functionality remains in the code base.
TLDR: the real advantage would be support for test automation.
Maybe the default should be the other way round, but I think you are missing the point.
How otherwise will you tell people what will be removed for the next release?
Documentation? Nobody reads it until they have a problem.
Mailing list? Nobody has time to read that amount of traffic.
(feel free to put "nobody" in quotation marks in your mind)
Just wait until the release and watch the panic as everyone has to hurry to support it?
Even if everyone knew what was going to be removed, how would they test? Manually editing files??
For those who have a proper setup with testing, such an option would just mean having a configuration with it set to test upcoming removals (and never have to edit that configuration, to e.g. manually set what to remove).
Sure, it would be broken much of the time probably, but run e.g. "make -k" and you have an idea how bad it is, you can piece by piece work on fixing it, have a time plan to have it pass by the time the next release is due, complain to us if there is something you don't think is reasonable etc.
And except for the "broken much of the time", we are one of those users that could use it ourselves.
Or has anyone who proposed removals ever tested on anything even approaching our full FATE test (in particular different architectures)?
Andreas Cadhalpun
2015-08-05 20:29:46 UTC
Permalink
Post by Reimar Döffinger
Post by Andreas Cadhalpun
Btw. the magic option to enable compatibility is still somewhat useful as it lists
and allows testing the specific changes that are coming up. But I agree it's only
a minor help.
The problem with such a magic option is that it combines the disadvantages of
removing and not removing: Programs using the old API get broken by default
and the deprecated functionality remains in the code base.
TLDR: the real advantage would be support for test automation.
If it's broken by default, it's not really good for testing.
Post by Reimar Döffinger
Maybe the default should be the other way round,
That's an essential difference.
Post by Reimar Döffinger
but I think you are missing the point.
How otherwise will you tell people what will be removed for the next release?
Maybe mention it in the release notes?
Post by Reimar Döffinger
Documentation? Nobody reads it until they have a problem.
How should one find out about a magic option if one doesn't read the documentation?
Post by Reimar Döffinger
Mailing list? Nobody has time to read that amount of traffic.
(feel free to put "nobody" in quotation marks in your mind)
Just wait until the release and watch the panic as everyone has to hurry to support it?
Even if everyone knew what was going to be removed, how would they test?
Manually editing files??
For those who have a proper setup with testing, such an option would just mean having a
configuration with it set to test upcoming removals (and never have to edit that
configuration, to e.g. manually set what to remove).
One could already '#define LIB*_MAJOR_VERSION 100' for testing the deprecations.
Post by Reimar Döffinger
Sure, it would be broken much of the time probably, but run e.g. "make -k" and you have
an idea how bad it is, you can piece by piece work on fixing it, have a time plan to have
it pass by the time the next release is due, complain to us if there is something you don't
think is reasonable etc.
And except for the "broken much of the time", we are one of those users that could use
it ourselves.
Or has anyone who proposed removals ever tested on anything even approaching our full
FATE test (in particular different architectures)?
Such an option might be useful, but I wouldn't rely on many using it.

Best regards,
Andreas
Luca Barbato
2015-08-05 21:58:34 UTC
Permalink
Post by Andreas Cadhalpun
I do have on more proposal, but the problem is it needs someone to do the work.
For each removed feature, prepare documentation "a monkey could follow" on how
to replace it (you could call it a transition guide).
Even better, a script that automates it where reasonable.
I think this is a very good idea.
It is being worked on since release 10 in our wiki...

lu
Andreas Cadhalpun
2015-08-06 21:19:46 UTC
Permalink
Post by Luca Barbato
Post by Andreas Cadhalpun
I do have on more proposal, but the problem is it needs someone to do the work.
For each removed feature, prepare documentation "a monkey could follow" on how
to replace it (you could call it a transition guide).
Even better, a script that automates it where reasonable.
I think this is a very good idea.
It is being worked on since release 10 in our wiki...
That's a start, but unfortunately the wiki doesn't cover most deprecated APIs.
And apparently it's not advertised enough, as even APIs mentioned there are
still widely in use.

Best regards,
Andreas
wm4
2015-08-05 22:53:50 UTC
Permalink
On Wed, 5 Aug 2015 21:31:38 +0200
Post by Andreas Cadhalpun
I do have on more proposal, but the problem is it needs someone to do the work.
For each removed feature, prepare documentation "a monkey could follow" on how
to replace it (you could call it a transition guide).
Even better, a script that automates it where reasonable.
I think this is a very good idea.
In some cases it is just a matter of copy-pasting some existing wrapper code,
particularly if we remove that wrapper code it is useful if people still have
it available in the new release.
If it's just a few hours of someone's time who even doesn't need to understand
the code, I think we can very confidently say "not really our problem" if some
applications still use it.
Agreed.
If we that way find out that there are non-trivial cases or cases where the code
gets a lot more complicated it might be a hint the new API is still crap and we
maybe should come up with something better first.
FF_API_PIX_FMT: 71
amide avbin avifile bino blender chromium-browser dff dolphin-emu dvbcut
dvswitch ffdiaporama ffmpeg2theora ffmpegthumbnailer ffmpegthumbs ffms2
fuse-emulator-utils gazebo gmerlin-avdecoder gmerlin-encoders gnash gpac
gst-libav1.0 guvcview harvid hedgewars info-beamer jugglemaster karlyriceditor
kino kodi lightspark lebiniou libam7xxx libavg libde265 libextractor
libquicktime linphone lives lynkeos.app mlt mplayer mplayer2 mrpt opal
opencv openmw openscenegraph ovito paraview performous pjproject qutecom
rbdoom3bfg renpy shotdetect sflphone strigi survex transcode vcmi vlc vtk vtk6
vxl wxsvg x264 xjadeo xpra yorick-av zoneminder
FF_API_AVFRAME_LAVC: 53
alsa-plugins amarok aubio avbin blender chromaprint dff dolphin-emu dvbcut
ffdiaporama ffmpegthumbnailer ffmpegthumbs fuse-emulator-utils gazebo
gmerlin-avdecoder gmerlin-encoders goldendict gpac gst-libav1.0 hedgewars
info-beamer jugglemaster kino libavg libextractor libquicktime lightspark
linphone mplayer mplayer2 mrpt opal opencv openscenegraph ovito paraview
performous pianopar qutecom renpy shotdetect spek squeezelite transcode
vcmi vlc vtk vtk6 vxl xine-lib-1.2 xpra yorick-av zoneminder
FF_API_GET_BUFFER: 9
avifile dvswitch gmerlin-avdecoder gst-libav1.0 libavg mplayer mplayer2 openmw
openscenegraph
FF_API_AUDIOCONVERT: 7
alsa-plugins cantata ffdiaporama moc mplayer2 mpv vlc
FF_API_SWS_CPU_CAPS: 6
fuse-emulator-utils kodi mlt mplayer2 vlc zoneminder
FF_API_DEINTERLACE: 5
blender dff ffmpegthumbnailer ffmpegthumbs vxl
FF_API_AVFRAME_LAVC(qscale): 3
ffmpeg2theora kodi xine-lib-1.2
FF_API_CODEC_ID: 3
chromium-browser dvswitch ffms2
FF_API_CONTEXT_SIZE: 3
mplayer mplayer2 xine-lib-1.2
FF_API_REQUEST_CHANNELS: 3
mplayer mplayer2 renpy
FF_API_AV_REVERSE: 2
mplayer mplayer2
FF_API_AVCODEC_RESAMPLE: 2
mlt mplayer
FF_API_DESTRUCT_PACKET: 2
lives openmw
FF_API_AVFILTERBUFFER: 2
ffdiaporama pianobar
FF_API_AVFILTERPAD_PUBLIC: 1
mplayer
FF_API_VIMA_DECODER: 1
mplayer
Well, you sure like to list a lot of projects. But what you don't say
is that many of these are either definitely dead (mplayer2 comes to
mind), or are ancient releases of software which fixed their API usage
later (like my own project, and probably most other reasonable active
projects).

Why do we have to suffer because Debian tries to compile ancient
releases against newer ffmpeg/libav releases? (How does that even make
sense?)

And then there's the category of projects that are "alive", but barely
care about anything unless being severely prodded. I'm not sure why we
should suffer forever just to accommodate these projects. They had more
than enough time.

I feel like I'm repeating myself and others, but I don't remember
whether you acknowledged these arguments.
Post by Andreas Cadhalpun
Better documentation would surely be helpful.
Many of these are non-trivial. Project authors either update their
code, or the project dies. It's simple. If you don't want this, keep an
old ffmpeg/libav package around for them. But you distro peoples want a
single libavcodec package, no matter how much this fucking tortures
everyone.
Andreas Cadhalpun
2015-08-06 21:26:05 UTC
Permalink
Post by wm4
Well, you sure like to list a lot of projects.
No, I don't. I'd like it much more if the list was empty.
Post by wm4
But what you don't say
is that many of these are either definitely dead (mplayer2 comes to
mind),
One is not many. But OK, let's get rid of mplayer2 [1].
Post by wm4
or are ancient releases of software which fixed their API usage
later (like my own project, and probably most other reasonable active
projects).
Now I'm curious what your own project is.
I thought you were involved with mpv, but that still uses the deprecated
FF_API_AUDIOCONVERT [2].

Projects like blender, gst-libav or mplayer are reasonably recent in Debian
and active upstream. But still they use deprecated APIs.
Post by wm4
Why do we have to suffer because Debian tries to compile ancient
releases against newer ffmpeg/libav releases? (How does that even make
sense?)
This is just your prejudice that doesn't have much to do with reality.
Post by wm4
And then there's the category of projects that are "alive", but barely
care about anything unless being severely prodded. I'm not sure why we
should suffer forever just to accommodate these projects. They had more
than enough time.
It's actually the other projects that have to suffer, because FFmpeg/Libav
breaks it's API. Time alone is not enough, there also needs to be good
documentation about API replacements and that is currently insufficient.
Post by wm4
I feel like I'm repeating myself and others, but I don't remember
whether you acknowledged these arguments.
I'm seeing more dramatic words than good arguments in your mail.
Post by wm4
Post by Andreas Cadhalpun
Better documentation would surely be helpful.
Many of these are non-trivial. Project authors either update their
code, or the project dies. It's simple. If you don't want this, keep an
old ffmpeg/libav package around for them. But you distro peoples want a
single libavcodec package, no matter how much this fucking tortures
everyone.
So instead of keeping a little bit of deprecated code, everyone should
keep multiple copies of libavcodec?
This is several orders of magnitude worse.

Best regards,
Andreas


1: https://bugs.debian.org/794817
2: https://github.com/mpv-player/mpv/blob/master/audio/filter/af_lavcac3enc.c#L29
Luca Barbato
2015-08-06 22:42:57 UTC
Permalink
Post by Andreas Cadhalpun
I'm seeing more dramatic words than good arguments in your mail.
Could we please tune it down a little?

The summary so far is that the people in Libav do not want to do again
three time the extra miles.

This time will be up to the downstreams to take care of it and will be
up to the distributor do the distributor job and update the packets or
prod downstreams.

The deprecated APIs will keep getting used till they do not disappear, I
know quite well since my downstream projects will get some updates that
I postponed till now because "hey they are easy I can do once I have a
moment" for... well more than 2 years...

For this release the deprecated APIs will be dropped w/out a third
warning, if nobody does not provide an alternate patchset and there
isn't consensus in doing otherwise. The even-odd pace had been agreed
during the last two meetings.

For the next release probably we can make so the odd release does win a
trigger --enable-future that makes all the apis slated to drop in the
even release disappear for that build. I will make so that the
libav-9999 build in Gentoo will have a +future use flag (as in always on
until disabled).

I know that probably is not great for you, but... Well, I can't blame
anybody for not wasting their time on a thankless and partially
fruitless effort, there is tons of new and interesting code to be
written instead =)

lu
Andreas Cadhalpun
2015-08-08 11:30:08 UTC
Permalink
Post by Luca Barbato
Post by Andreas Cadhalpun
I'm seeing more dramatic words than good arguments in your mail.
Could we please tune it down a little?
Tell that wm4.
Post by Luca Barbato
For this release the deprecated APIs will be dropped w/out a third
warning, if nobody does not provide an alternate patchset and there
isn't consensus in doing otherwise.
I'll be sending an alternative patch set in a moment.
Post by Luca Barbato
For the next release probably we can make so the odd release does win a
trigger --enable-future that makes all the apis slated to drop in the
even release disappear for that build.
I'm curious how this --enable-future trigger should work.
Do you have ideas already?

Best regards,
Andreas
Luca Barbato
2015-08-08 13:44:53 UTC
Permalink
Post by Andreas Cadhalpun
I'm curious how this --enable-future trigger should work.
Do you have ideas already?
Basically in avconfig.h you get a #define LIBAV_FUTURE 1 / 0

The value is added in the version computations everywhere.

So you have your normal version + future to compute what to hide.

Ideally one can do --enable-feature=2 to get two steps further and so on.

The only part I'd like further attention and eyes is decided to make the
soversion odd for interim/future builds and have the stable api always
use the even soversion to make sure builds using future do not get
mismatched as the current release.

lu

wm4
2015-08-07 13:36:26 UTC
Permalink
On Thu, 6 Aug 2015 23:26:05 +0200
Post by Andreas Cadhalpun
Post by wm4
Well, you sure like to list a lot of projects.
No, I don't. I'd like it much more if the list was empty.
Post by wm4
But what you don't say
is that many of these are either definitely dead (mplayer2 comes to
mind),
One is not many. But OK, let's get rid of mplayer2 [1].
So why does mplayer2 have to die, but other projects are extremely
important to keep and thus no deprecated API should be dropped?

I didn't attempt to check how many projects really rely on deprecated
features, but...
Post by Andreas Cadhalpun
Post by wm4
or are ancient releases of software which fixed their API usage
later (like my own project, and probably most other reasonable active
projects).
Now I'm curious what your own project is.
I thought you were involved with mpv, but that still uses the deprecated
FF_API_AUDIOCONVERT [2].
It is mpv. Yes, there are 3 audioconvert.h include statements, but
usage of any of the symbols was removed almost 2.5 years ago. You only
need a trivial patch to fix it. (Or make the upstream project aware. I
didn't know about this, but removed the includes yesterday when I read
your post. Why didn't I ever get a bug report from you about this?)

How many more projects are there that can be trivially updated, but
you weren't aware of? I also doubt that software like vlc, kodi, or
chromium actually use deprecated API in their git development branches.
Why do you want to compile old releases against bleeding edge
libav/ffmpeg?
Post by Andreas Cadhalpun
Projects like blender, gst-libav or mplayer are reasonably recent in Debian
and active upstream. But still they use deprecated APIs.
Post by wm4
Why do we have to suffer because Debian tries to compile ancient
releases against newer ffmpeg/libav releases? (How does that even make
sense?)
This is just your prejudice that doesn't have much to do with reality.
I've had very much experience with distro reality. They tend to make
everyone's life harder (including their own) by demanding that EVERY
project uses the same libav* build.

Well, if you want to do this, you're free to do so. But it's not our
problem. Feel free to put as much effort into it as you like.
Post by Andreas Cadhalpun
Post by wm4
And then there's the category of projects that are "alive", but barely
care about anything unless being severely prodded. I'm not sure why we
should suffer forever just to accommodate these projects. They had more
than enough time.
It's actually the other projects that have to suffer, because FFmpeg/Libav
breaks it's API. Time alone is not enough, there also needs to be good
documentation about API replacements and that is currently insufficient.
This is all very tiring. We're trying to improve the APIs everyone
likes to complain so much about. But staying compatible forever is just
not feasible. It leads to accumulation of strange things, even if it's
minor changes like the PIXFMT renames.

Do you think anyone has it easier to develop a program using the libs
when confronted with tons of legacy symbols?
Post by Andreas Cadhalpun
Post by wm4
I feel like I'm repeating myself and others, but I don't remember
whether you acknowledged these arguments.
I'm seeing more dramatic words than good arguments in your mail.
OK, let's be polemic: I'm seeing outright lies from you. Not nearly
enough important software as you make it seem depends on deprecated
features, and even if, many of them are trivially fixable.

Of course older releases of them use deprecated features, because at the
time they were not deprecated yet, or were still within the grace
period. And I don't see why you see this as "proof".

(Note that sometimes it's preferable to use deprecated features,
because distros are on ancient libav* versions to keep unmaintained
software depending on it going. This also very much sucks for the
project authors, btw.)
Post by Andreas Cadhalpun
Post by wm4
Post by Andreas Cadhalpun
Better documentation would surely be helpful.
Many of these are non-trivial. Project authors either update their
code, or the project dies. It's simple. If you don't want this, keep an
old ffmpeg/libav package around for them. But you distro peoples want a
single libavcodec package, no matter how much this fucking tortures
everyone.
So instead of keeping a little bit of deprecated code, everyone should
keep multiple copies of libavcodec?
This is several orders of magnitude worse.
Why is it worse? Disk space is very cheap, and the libs aren't that big
after all. But I know, you distro folks would rather waste a lot of
time trying to make all projects use the same libs, instead of going
the easy way.

By the way, why the hell do I have to have two versions of Qt and 2
versions of Python on my Debian system? These are much heavier than
libav*.
Post by Andreas Cadhalpun
Best regards,
Andreas
1: https://bugs.debian.org/794817
2: https://github.com/mpv-player/mpv/blob/master/audio/filter/af_lavcac3enc.c#L29
Andreas Cadhalpun
2015-08-06 21:56:19 UTC
Permalink
On Thu, Aug 6, 2015 at 3:32 AM, Michael Niedermayer
[...]
IMO {
trivial API, like identifers with different names or wrapers
that are identical except having 1 argument less.
That is API which does not require any testing to ensure its future
function and correctness, should be kept as long as they are needed
by a distribution.
I don't really mind if extra codec defines etc stick around for a
while, as long as they don't break things.
There is one part about the pixfmt compat code which does frequently
break in weird ways though, #define PixelFormat AVPixelFormat
PixelFormat is a very generic name, and that define has renamed
variables etc in not only a few projects before. ;)
You have a point there. However PIX_FMT_* is much less generic.
So maybe we could remove PixelFormat, but keep PIX_FMT_* until the
next bump?
non trivial API, which has a volunteer maintaining and testing it
and has one or more fate tests ensuring its fully functional and
correct could be similarly kept as long as that person is testing
and maintaining it
I would argue that for the sake of an easy to understand API, even
then they should be considered for removal at some point.
Usually there also is a reason we needed a new API, so the old API has
short-comings that an emulation may not be able to fix.
But sometimes the new API is much more difficult to use, e.g.
FF_API_DEINTERLACE doesn't have a simple replacement.
the rest should be removed once it has been deprecated for a
sufficient period of time.
Its a bit unprofessional to break/remove API every 1-2 years
I think we can agree on that, but the functions under discussion here
are 3-4 years deprecated, so yay? :)
This is not entirely true:
AV_PIX_FMT_FLAG_* were introduced in May 2013 and
avcodec_get_frame_defaults was deprecated in December 2013.

That might also explain why these are still widely used.

Best regards,
Andreas
Continue reading on narkive:
Loading...