Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On 07.08.2015 00:42, Luca Barbato wrote: > On 06/08/15 23:26, Andreas Cadhalpun wrote: >> 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Fri, 7 Aug 2015 19:28:26 +0200 Dominik 'Rathann' Mierzejewski wrote: > Hello, > > On Friday, 07 August 2015 at 15:36, wm4 wrote: > > On Thu, 6 Aug 2015 23:26:05 +0200 > > Andreas Cadhalpun wrote: > > > On 06.08.2015 00:53, wm4 wrote: > [...] > > > > 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.) > > 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. > 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 > [...] > > > >> 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. > 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. > > > 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? > Regards, > Dominik (FFmpeg (co-)maintainer in RPMFusion/
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
Hello, On Friday, 07 August 2015 at 15:36, wm4 wrote: > On Thu, 6 Aug 2015 23:26:05 +0200 > Andreas Cadhalpun wrote: > > On 06.08.2015 00:53, wm4 wrote: [...] > > > 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. > 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. [...] > > >> 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. > 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Thu, 6 Aug 2015 23:26:05 +0200 Andreas Cadhalpun wrote: > On 06.08.2015 00:53, wm4 wrote: > > 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. > > > 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... > > 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? > Projects like blender, gst-libav or mplayer are reasonably recent in Debian > and active upstream. But still they use deprecated APIs. > > > 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. > > 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? > > 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.) > >> 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*. > Best regards, > Andreas > > > 1: https://bugs.debian.org/794817 > 2: > https://github.com/mpv-player/mpv/blob/master/audio/filter/af_lavcac3enc.c#L29 ___ ffmpeg-devel mailing list ffmpeg-d
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On 06.08.2015 09:41, Hendrik Leppkes wrote:
> On Thu, Aug 6, 2015 at 3:32 AM, Michael Niedermayer
> wrote:
>> 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.
>
> 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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On 05.08.2015 23:58, Luca Barbato wrote: > On 05/08/15 21:31, Andreas Cadhalpun wrote: >> On 04.08.2015 07:57, Reimar Döffinger wrote: 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On 06.08.2015 00:53, wm4 wrote: > 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. > 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]. > 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. > 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. > 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. > 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. >> 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Thu, Aug 06, 2015 at 09:41:54AM +0200, Hendrik Leppkes wrote:
> On Thu, Aug 6, 2015 at 3:32 AM, Michael Niedermayer
> wrote:
> > 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.
>
> 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
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Thu, Aug 6, 2015 at 3:32 AM, Michael Niedermayer
wrote:
> 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.
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. ;)
>
> 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.
>
> 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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Thu, 6 Aug 2015 03:32:39 +0200 Michael Niedermayer wrote: > Its a bit unprofessional to break/remove API every 1-2 years Great, then we can just drop the currently deprecated functions right now. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
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
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Wed, 5 Aug 2015 21:31:38 +0200 Andreas Cadhalpun wrote: > On 04.08.2015 07:57, Reimar Döffinger wrote: > > 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 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. > 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On 05.08.2015 22:07, Reimar Döffinger wrote: > On 05.08.2015, at 21:31, Andreas Cadhalpun > wrote: >>> 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. > Maybe the default should be the other way round, That's an essential difference. > 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? > 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? > 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. > 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On 05.08.2015, at 21:31, Andreas Cadhalpun wrote: >> 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)? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On 04.08.2015 07:57, Reimar Döffinger wrote: > 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Tue, 4 Aug 2015 07:57:34 +0200 Reimar Döffinger wrote: > On 31.07.2015, at 17:47, Nicolas George wrote: > > I can propose the following middle term: > > 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 > Even better, a script that automates it where reasonable. Would probably work for simple renames, like the AV_ prefix additions. > 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. > 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On 31.07.2015, at 17:47, Nicolas George wrote: > I can propose the following middle term: 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Thu, Jul 30, 2015 at 6:10 PM, Andreas Cadhalpun wrote: > 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. >> 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On 30.07.2015, at 17:05, Andreas Cadhalpun wrote: > Hi, > > On 28.07.2015 15:36, Vittorio Giovara wrote: >> 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. 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? > 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... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On 31.07.2015, at 17:22, Hendrik Leppkes wrote: > On Fri, Jul 31, 2015 at 5:12 PM, compn wrote: >> On Thu, 30 Jul 2015 17:05:12 +0200 >> Andreas Cadhalpun wrote: >> >>> Hi, >>> >>> On 28.07.2015 15:36, Vittorio Giovara wrote: 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: >> >> 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... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Fri, Jul 31, 2015 at 5:47 PM, Nicolas George wrote: > Le tridi 13 thermidor, an CCXXIII, Hendrik Leppkes a écrit : >> 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. > >> 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 , 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
Le tridi 13 thermidor, an CCXXIII, Hendrik Leppkes a écrit : > 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. > 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 , 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 signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Fri, Jul 31, 2015 at 5:12 PM, compn wrote: > On Thu, 30 Jul 2015 17:05:12 +0200 > Andreas Cadhalpun wrote: > >> Hi, >> >> On 28.07.2015 15:36, Vittorio Giovara wrote: >> > 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: > > 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On Thu, 30 Jul 2015 17:05:12 +0200 Andreas Cadhalpun wrote: > Hi, > > On 28.07.2015 15:36, Vittorio Giovara wrote: > > 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: 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On 30.07.2015 18:26, Anton Khirnov wrote: > Quoting Andreas Cadhalpun (2015-07-30 17:49:51) >> 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. ;) > 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. 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. >>> 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On 30.07.2015 18:10, Luca Barbato wrote: > On 30/07/15 17:49, Andreas Cadhalpun wrote: >> 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On 30.07.2015 18:00, Hendrik Leppkes wrote: > 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. > 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
Am 30.07.2015 17:50 schrieb "Andreas Cadhalpun" < andreas.cadhal...@googlemail.com>: > > On 30.07.2015 17:38, Anton Khirnov wrote: > > Quoting Andreas Cadhalpun (2015-07-30 17:05:12) > >> 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? > 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
On 30.07.2015 17:38, Anton Khirnov wrote: > Quoting Andreas Cadhalpun (2015-07-30 17:05:12) >> 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features
Hi, On 28.07.2015 15:36, Vittorio Giovara wrote: > 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
