Discussion:
[libav-devel] [PATCH 0/20] removal of deprecated features
(too old to reply)
Andreas Cadhalpun
2015-07-30 15:05:12 UTC
Permalink
Hi,
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
Andreas Cadhalpun
2015-07-30 15:49:51 UTC
Permalink
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.
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
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 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.
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
Andreas Cadhalpun
2015-07-30 17:08:12 UTC
Permalink
Post by Andreas Cadhalpun
Have you tried sending them patches before breaking compatibility?
We did in the past.
Great, so please do it again.
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
Andreas Cadhalpun
2015-07-30 17:10:12 UTC
Permalink
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. ;)
- 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.
- 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 Andreas Cadhalpun
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
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
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
compn
2015-07-31 15:12:12 UTC
Permalink
On Thu, 30 Jul 2015 17:05:12 +0200
Post by Andreas Cadhalpun
Hi,
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
i am against removing this api in ffmpeg, if my vote counts for
anything.

anyway to keep the old api and have the new api at the same time?
yes, this means letting the old api rot, i have no problem with this.
just to give time for projects to update. or maybe even create a
wrapper ? bah.

-compn
Hendrik Leppkes
2015-07-31 15:22:08 UTC
Permalink
Post by compn
On Thu, 30 Jul 2015 17:05:12 +0200
Post by Andreas Cadhalpun
Hi,
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
i am against removing this api in ffmpeg, if my vote counts for
anything.
anyway to keep the old api and have the new api at the same time?
yes, this means letting the old api rot, i have no problem with this.
just to give time for projects to update. or maybe even create a
wrapper ? bah.
They have had 2-3 years to update, what makes you think they will ever
if we don't force them at some point?
Some of the API is known to exhibit failure under some conditions and
having it actually confuses new developers as we have duplicate API
that behaves differently (and wrongly, even).

Removing it not only serves some purpose of "cleanlyness" as some
people like to pretend, but it actually removes a whole bunch of
problems which new users of the API commonly run into because they
accidentally use the old API (usually because some ancient example
they found used it as well).
Not having this old and wrong API at all anymore will prevent a lot of
these cases and instead help guide the users towards the new and
properly-working and tested API.

- Hendrik
Nicolas George
2015-07-31 15:47:21 UTC
Permalink
Post by Hendrik Leppkes
They have had 2-3 years to update, what makes you think they will ever
if we don't force them at some point?
What makes you think they will ever do it even if we try to force them? They
will just stick to an older version of FFmpeg, and that would be worse for
everyone else. Well, not all would do that, but some of them, too many,
would.
Post by Hendrik Leppkes
Removing it not only serves some purpose of "cleanlyness" as some
people like to pretend, but it actually removes a whole bunch of
problems which new users of the API commonly run into because they
accidentally use the old API (usually because some ancient example
they found used it as well).
Not having this old and wrong API at all anymore will prevent a lot of
these cases and instead help guide the users towards the new and
properly-working and tested API.
I can propose the following middle term:

- Making the old features disabled by default but very easy to enable if you
know how. A single #include <libavutil/depcrecated_api.h>, for example, or
a header that needs to be replaced by another manually at install time
(packagers can use a diversion mechanism to create a
"ffmpeg-deprecated-dev" package).

- The features stay there but are utterly unsupported. If there is a bug, do
not fix it. If there is a security issue, a build failure or anything of
the kind, or if it makes it harder to add new features, remove anything in
the way. If it breaks third party projects, not our problem.

The second point is nice, because it is the least effort policy: we do not
make effort to support the deprecated APIs, but we do not make effort to
remove them either.

Regards,
--
Nicolas George
Hendrik Leppkes
2015-07-31 22:07:54 UTC
Permalink
Post by Nicolas George
Post by Hendrik Leppkes
They have had 2-3 years to update, what makes you think they will ever
if we don't force them at some point?
What makes you think they will ever do it even if we try to force them? They
will just stick to an older version of FFmpeg, and that would be worse for
everyone else. Well, not all would do that, but some of them, too many,
would.
Post by Hendrik Leppkes
Removing it not only serves some purpose of "cleanlyness" as some
people like to pretend, but it actually removes a whole bunch of
problems which new users of the API commonly run into because they
accidentally use the old API (usually because some ancient example
they found used it as well).
Not having this old and wrong API at all anymore will prevent a lot of
these cases and instead help guide the users towards the new and
properly-working and tested API.
- Making the old features disabled by default but very easy to enable if you
know how. A single #include <libavutil/depcrecated_api.h>, for example, or
a header that needs to be replaced by another manually at install time
(packagers can use a diversion mechanism to create a
"ffmpeg-deprecated-dev" package).
- The features stay there but are utterly unsupported. If there is a bug, do
not fix it. If there is a security issue, a build failure or anything of
the kind, or if it makes it harder to add new features, remove anything in
the way. If it breaks third party projects, not our problem.
The second point is nice, because it is the least effort policy: we do not
make effort to support the deprecated APIs, but we do not make effort to
remove them either.
Your second point is the one thing I really would hate to see, which
was also one of my arguments for removing deprecated API in the first
place.
What will happen is that distributions will enable it (because
obscure-app-37 needs it), people will develop new apps on those
distributions, and accidentally use this old broken API in their new
code, because they are just following some ancient example code they
found on the interwebs somewhere.

On top of that, having code with known problems, even worse, security
problems, is just a Bad Idea.

If we offer an API, it should at least be somewhat supported, even if
not tested every day due to being deprecated. If we don't want to
support it anymore, and would even be willing to let it break and have
security issues, we should just kill it entirely.
No-one is going to be helped by a broken insecure obsolete API.

- Hendrik
Reimar Döffinger
2015-08-04 05:57:34 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.
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.
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.
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.

Regards,
Reimar
wm4
2015-08-04 10:21:17 UTC
Permalink
On Tue, 4 Aug 2015 07:57:34 +0200
Post by Reimar Döffinger
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).
Yes, that's a good idea. We should probably require something like this
from every patch that deprecates API for other APIs.

There should probably be a migration guide in doc or so. Libav also
tried something like it: https://wiki.libav.org/Migration/11
Post by Reimar Döffinger
Even better, a script that automates it where reasonable.
Would probably work for simple renames, like the AV_ prefix additions.
Post by Reimar Döffinger
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.
Well, often the problem is that such deprecated features are terribly
entangled with the rest of the code. Consider AVPacket.destruct.
Post by Reimar Döffinger
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.
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.
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.
Andreas Cadhalpun
2015-08-05 19:31:38 UTC
Permalink
Post by Reimar Döffinger
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.
Post by Reimar Döffinger
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.
Post by Reimar Döffinger
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.
Post by Reimar Döffinger
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
Post by Reimar Döffinger
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
Post by Reimar Döffinger
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
wm4
2015-08-05 22:53:50 UTC
Permalink
On Wed, 5 Aug 2015 21:31:38 +0200
Post by Andreas Cadhalpun
Post by Reimar Döffinger
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.
Post by Reimar Döffinger
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.
Post by Reimar Döffinger
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
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
Dominik 'Rathann' Mierzejewski
2015-08-07 17:28:26 UTC
Permalink
Hello,
Post by wm4
On Thu, 6 Aug 2015 23:26:05 +0200
[...]
Post by wm4
Post by Andreas Cadhalpun
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.
Actually, speaking with my distro hat on, that's more or less the idea,
though I wouldn't say we (Fedora/RPMFusion) are demanding anything.
We do want to ship a single ffmpeg build per distro release and have
each depending project link against it. If that means
back/forward-porting code to adapt the other projects to API changes
then that's the package maintainer's job.
Post by wm4
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.
Indeed. Though we may ask politely that FFmpeg project supports a given
ffmpeg release for the ~13 months of a given Fedora release lifecycle.

We would very much appreciate porting-to-new-API guides as that would
make providing patches to depending project upstreams a lot easier.

[...]
Post by wm4
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.
Yes, we do. Once the initial porting work is done, we can fix security
issues and other bugs in one place, by updating one package. That's
a big maintenance win.

However, at least in Fedora, if a project can't be ported to current library
APIs (for example because it's dead) then we either drop it or introduce
a compat package with an older version of the library. There is strong
preference for the first option though.
Post by wm4
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*.
You're right, but there are also much more users of Qt and Python
and there are (I think) much more extensive API changes between Qt 4 and
5, and between python-2.x and 3.x. They were also designed as parallel
installable from the beginning.

Regards,
Dominik (FFmpeg (co-)maintainer in RPMFusion/Fedora)
--
MPlayer http://mplayerhq.hu | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
wm4
2015-08-07 23:12:50 UTC
Permalink
On Fri, 7 Aug 2015 19:28:26 +0200
Post by Dominik 'Rathann' Mierzejewski
Hello,
Post by wm4
On Thu, 6 Aug 2015 23:26:05 +0200
[...]
Post by wm4
Post by Andreas Cadhalpun
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.
Actually, speaking with my distro hat on, that's more or less the idea,
though I wouldn't say we (Fedora/RPMFusion) are demanding anything.
We do want to ship a single ffmpeg build per distro release and have
each depending project link against it. If that means
back/forward-porting code to adapt the other projects to API changes
then that's the package maintainer's job.
That's a commendable goal, but also somewhat counterproductive. If the
devs of a project say that the software can't run with a newer or older
ffmpeg version, it probably has its reasons. I think it's not
unreasonable to ship a software with the dependencies recommended by
its developers.

But the main effect is that the distro's entire multimedia
infrastructure is held back because some relatively unimportant
programs still weren't ported to newer ffmpeg.

And somehow maintainers seem to blame the API improvement progress in
ffmpeg/Libav (especially Libav), instead of the maintainers of these
programs.

(But duplicating Python or Qt is apparently OK.)
Post by Dominik 'Rathann' Mierzejewski
Post by wm4
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.
Indeed. Though we may ask politely that FFmpeg project supports a given
ffmpeg release for the ~13 months of a given Fedora release lifecycle.
If someone takes it on... until recently we actually had a maintainer
who managed a dozen release branches or so, but I doubt other current
FFmpeg devs are so enthusiastic about it.
Post by Dominik 'Rathann' Mierzejewski
We would very much appreciate porting-to-new-API guides as that would
make providing patches to depending project upstreams a lot easier.
Actually Libav, which did pretty much all API changes (as opposed to
additions), has migration guides:

https://wiki.libav.org/Migration/10
https://wiki.libav.org/Migration/11

Of course FFmpeg merged only the git commits, but (apparently) didn't
provide any migration guides.

I think there were also ideas to provide more examples, such as for
libavresample in order to make the lavc resampler deprecation easier.
Not sure what happened to this.

At least FFmpeg has a resampler example:

http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/resampling_audio.c
Post by Dominik 'Rathann' Mierzejewski
[...]
Post by wm4
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.
Yes, we do. Once the initial porting work is done, we can fix security
issues and other bugs in one place, by updating one package. That's
a big maintenance win.
Applying a single patch to 2 very similar codebases is very simple.
Uploading multiple packages automatically surely is trivial.

Keep in mind that a FFmpeg maintainer would have to do the same thing.
Post by Dominik 'Rathann' Mierzejewski
However, at least in Fedora, if a project can't be ported to current library
APIs (for example because it's dead) then we either drop it or introduce
a compat package with an older version of the library. There is strong
preference for the first option though.
Post by wm4
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*.
You're right, but there are also much more users of Qt and Python
and there are (I think) much more extensive API changes between Qt 4 and
5, and between python-2.x and 3.x. They were also designed as parallel
installable from the beginning.
So is it ok if FFmpeg changes more radically between releases, and
use different pkg-config names on each major (incompatible) bump?
Post by Dominik 'Rathann' Mierzejewski
Regards,
Dominik (FFmpeg (co-)maintainer in RPMFusion/Fedora)
Andreas Cadhalpun
2015-08-08 11:30:08 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?
Tell that wm4.
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.
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

Andreas Cadhalpun
2015-08-06 21:19:46 UTC
Permalink
Post by Andreas Cadhalpun
Post by Reimar Döffinger
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
Reimar Döffinger
2015-08-01 06:57:24 UTC
Permalink
Post by Hendrik Leppkes
Post by compn
On Thu, 30 Jul 2015 17:05:12 +0200
Post by Andreas Cadhalpun
Hi,
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
i am against removing this api in ffmpeg, if my vote counts for
anything.
anyway to keep the old api and have the new api at the same time?
yes, this means letting the old api rot, i have no problem with this.
just to give time for projects to update. or maybe even create a
wrapper ? bah.
They have had 2-3 years to update, what makes you think they will ever
if we don't force them at some point?
While there is some truth to it, 2-3 years means you still have to used ifdefs
if you want to support older (but not quite ancient) distros.
For the features the only one or 2 programs use, contacting them might be an option.
We could even think of whether we can reliably write a sed or awk script that replaces things, then distros could either apply that as an extra step or projects use it to create patches...
Just throwing out ideas...
Reimar Döffinger
2015-08-01 07:41:56 UTC
Permalink
Post by Andreas Cadhalpun
Hi,
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.
Hm, so all those PIX_FMT cases might hide a lot of other issues?
I think that one isn't a real issue as it hardly has any maintenance cost (I think I fixed MPlayer now though).
Can we potentially get lists for each, to see if we can put pressure on certain projects so we can get rid of the worst?
Post by Andreas Cadhalpun
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.
If the list was complete, I wouldn't say AVFRAME is that widespread, a bit of pushing might work still...
Michael Niedermayer
2015-08-06 01:32:39 UTC
Permalink
On Thu, Jul 30, 2015 at 05:05:12PM +0200, Andreas Cadhalpun wrote:
[...]

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.

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

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

}

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
wm4
2015-08-06 07:33:15 UTC
Permalink
On Thu, 6 Aug 2015 03:32:39 +0200
Post by Michael Niedermayer
Its a bit unprofessional to break/remove API every 1-2 years
Great, then we can just drop the currently deprecated functions right
now.
Hendrik Leppkes
2015-08-06 07:41:54 UTC
Permalink
On Thu, Aug 6, 2015 at 3:32 AM, Michael Niedermayer
Post by 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. ;)
Post by Michael Niedermayer
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.
Post by Michael Niedermayer
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? :)
I don't remember when the last real API break happened though. The
last major bump was for ABI reasons, not strictly API, if I remember
correctly.
Michael Niedermayer
2015-08-06 08:54:07 UTC
Permalink
Post by Hendrik Leppkes
On Thu, Aug 6, 2015 at 3:32 AM, Michael Niedermayer
Post by 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. ;)
my intend was to reduce problems for user apps.
if keeping s specific API/identifer causes more problems than not
keeping then keeping isnt such a good idea

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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle
Andreas Cadhalpun
2015-08-06 21:56:19 UTC
Permalink
Post by Hendrik Leppkes
On Thu, Aug 6, 2015 at 3:32 AM, Michael Niedermayer
Post by 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?
Post by Hendrik Leppkes
Post by Michael Niedermayer
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.
Post by Hendrik Leppkes
Post by Michael Niedermayer
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...