On Fri, Aug 29, 2014 at 1:17 PM, Michael Niedermayer michae...@gmx.at wrote:
also please dont remove ffmpeg-devel from the CC
I had missed that you removed it so my reply went just to debian-devel
full quote left below for ffmpeg-devel, no further inline comments
Sorry about that. Last time I
Hi Vittorio
On Thu, Aug 28, 2014 at 12:45:42AM -0400, Vittorio Giovara wrote:
On 12/08/2014 18:30, Michael Niedermayer wrote:
Also ive offered my resignation in the past. I do still offer to
resign from the FFmpeg leader position, if it resolves this split
between FFmpeg and Libav and make
Hi Vittorio
also please dont remove ffmpeg-devel from the CC
I had missed that you removed it so my reply went just to debian-devel
full quote left below for ffmpeg-devel, no further inline comments
below
Thanks
On Fri, Aug 29, 2014 at 07:17:55PM +0200, Michael Niedermayer wrote:
Hi Vittorio
Hey.
On 12/08/2014 18:30, Michael Niedermayer wrote:
Also ive offered my resignation in the past. I do still offer to
resign from the FFmpeg leader position, if it resolves this split
between FFmpeg and Libav and make everyone work together again.
I have absolutely no opinion on the
On Thu, 28 Aug 2014, Vittorio Giovara wrote:
On 17/08/2014 18:15, Clément Bœsch wrote:
- you leeching my work by leveraging git merge daily
Welcome to the wonderful world of Open Source Luca.
Sorry but no, definitely no.
While technically what ffmpeg does is allowed by the (L)GPL, it
On 12/08/2014 18:30, Michael Niedermayer wrote:
Also ive offered my resignation in the past. I do still offer to
resign from the FFmpeg leader position, if it resolves this split
between FFmpeg and Libav and make everyone work together again.
Hi Michael,
sorry to come late to the party, but I
On 19/08/2014 04:50, Ondřej Surý wrote:
P.S.: libav doesn't seem to be using Coverity Scan actively:
https://scan.coverity.com/projects/106 (last scan was 4 months ago)
FWIW if you (or anyone else) is interested in preparing and running a
coverity scan on Libav out of curiosity, I can
On 17/08/2014 18:15, Clément Bœsch wrote:
- you leeching my work by leveraging git merge daily
Welcome to the wonderful world of Open Source Luca.
Sorry but no, definitely no.
While technically what ffmpeg does is allowed by the (L)GPL, it
fundamentally goes against the spirit of Open
Hi,
On 17.08.2014 00:49, Andreas Cadhalpun wrote:
I have now sent the pkg-config patches to the BTS [1].
I have found a simpler way to make it possible to link packages not
using pkg-config against FFmpeg in Debian:
The lib*-ffmpeg-dev packages now install symbolic links from the
standard
Hi
On Thu, Aug 21, 2014 at 03:16:50AM +0200, Attila Kinali wrote:
Servus,
On Wed, 20 Aug 2014 18:43:18 +0900
Norbert Preining prein...@logic.at wrote:
By continuing old fights, inspite of the very clearly friendly and
open offers and suggestions byu Michael, you and others from AV
but either way, id like to suggest again, we move forward and
rather discuss how we can improve the situation, do something about
the split and move toward un-doing it!
We look forward to seeing you in Dublin then.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
On 08/19/2014 12:45 PM, Clément Bœsch wrote:
See:
http://fate.ffmpeg.org/
http://coverage.ffmpeg.org/
The 2nd link to coverage (which should show the LCOV output, I guess)
seems to be broken:
I get a 404 Not Found :(
Regards,
Pb
--
To UNSUBSCRIBE, email to
On Wed, Aug 20, 2014 at 11:05:05AM +0200, Peter B. wrote:
On 08/19/2014 12:45 PM, Clément Bœsch wrote:
See:
http://fate.ffmpeg.org/
http://coverage.ffmpeg.org/
The 2nd link to coverage (which should show the LCOV output, I guess)
seems to be broken:
I get a 404 Not Found :(
Sorry
On Sun, 17 Aug 2014, Luca Barbato wrote:
- you tried to commit code that was blatantly below the already lax
quality requirements (e.g. it contained tabs, it was (and still is) hard
to read, it contains dubious, aka security-concerning, practices), I
told you not to commit those as-is and you
Norbert,
On Wed, Aug 20, 2014, at 11:43, Norbert Preining wrote:
[...]
The base line of this discussion for me is:
[...]
* from my point of view, it would be best to throw out Av immediately
and switch to ffmpeg before release.
It would be great if you didn't send your personal judgements
On Thu, 14 Aug 2014 13:58:07 +0200
Stefano Sabatini stefa...@gmail.com wrote:
If you trully want to mend ways, then you and your fellow FFmpeg
developers should stop this constant spreading of lies, this
defamation campaing against libav and its developers that has
been going on for the
Servus,
On Wed, 20 Aug 2014 18:43:18 +0900
Norbert Preining prein...@logic.at wrote:
By continuing old fights, inspite of the very clearly friendly and
open offers and suggestions byu Michael, you and others from AV continue
simply to insult and be nasty.
Sorry, but this is not true. Yes,
On Sat, 16 Aug 2014 17:11:29 +0200
Nicolas George geo...@nsup.org wrote:
The most galling in this issue is that there is no clear decision behind
this orientation. The fork's manifesto stated that everyone was equal
amongst equals, with or without commit rights, but the people who do have
the
On Mon, 18 Aug 2014 13:42:36 +0200
Nicolas George geo...@nsup.org wrote:
The reason for switching from FFmpeg to libav in the first place just after
the fork is much simpler than that.
Yes, the reason was that Reinhard, who was the maintainer of the
ffmpeg package back then, was on the libav
Hi Attila,
I will do a small self-intro, as you most likely don't know me: I am a
high school student who mainly writes documentation for FFmpeg, but
sometimes do small code fixes and patch review (mainly related to
documentation), both for FFmpeg and Libav. I sent my first patch to
FFmpeg last
On Sat, Aug 16, 2014, at 17:29, Thomas Goirand wrote:
On 08/15/2014 11:53 PM, The Wanderer wrote:
It's also something the Linux kernel is still doing, with apparent
success.
Yes, the Linux kernel is a successful project. Does this mean using a
list for reviewing patches is a good thing?
On Sat, Aug 16, 2014, at 20:59, Russ Allbery wrote:
The problem, however, is that taking security seriously, while possibly
necessary, is not sufficient. I'm glad that FFmpeg takes security
seriously, but what FFmpeg needs is to *have fewer security bugs*.
JFTR the Coverity Scan results for
Hi,
On Tue, Aug 19, 2014 at 10:50:31AM +0200, Ondřej Surý wrote:
[...]
From the security viewpoint, I would be also interested if ffmpeg
has tests and what is current code coverage. That could help avoiding
regressions when doing security updates.
1. There are also other tools: llvm/clang
On 8/18/14, Moritz Mühlenhoff j...@inutil.org wrote:
Andreas Cadhalpun andreas.cadhal...@googlemail.com schrieb:
Hi Thomas,
On 18.08.2014 08:36, Thomas Goirand wrote:
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same
On Mon, Aug 18, 2014 at 12:15:10AM +0200, Clément Bœsch wrote:
On Sun, Aug 17, 2014 at 09:14:47PM +0200, Luca Barbato wrote:
[...]
Ive asked [1][2] back then what policy in place was broken
- you tried to commit code that was blatantly below the already lax
quality requirements (e.g.
On 08/16/2014 11:44 PM, wm4 wrote:
This reasoning may work when you have only a small amount of information
to read. When you are overwhelmed with it, having different places to do
different things is a much better approach. Sending patches to a list
simply doesn't scale.
Also, with a list,
On 08/16/2014 11:11 PM, Nicolas George wrote:
L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit :
Using Gerrit and file ownersip are not mutually exclusive. Gerrit
can be configured to automatically invite the right people for review
based on the changed path. We recently migrated to
On 08/16/2014 11:30 PM, Nicolas George wrote:
So what about the code? Shall the FFmpeg developers discard three years of
work and start working on libav? Or shall the libav developers accept to
work with the code from FFmpeg that they do not like?
FFmpeg folks should rework the code to make it
On 08/17/2014 07:41 PM, Andreas Cadhalpun wrote:
Michael Niedermayer already volunteered to help with all security
related problems of FFmpeg in Debian.
So what should he do to relieve the impact on the security and release
teams?
Let's say he would take the role of patching stuff in Stable,
❦ 18 août 2014 14:20 +0800, Thomas Goirand z...@debian.org :
What? Most patches are posted inline (with git-send-email).
Even worse then! It makes it hard to copy to your local fs.
The whole email is a valid patch in this case.
--
Follow each decision as closely as possible with its
Hi Thomas,
On 18.08.2014 08:36, Thomas Goirand wrote:
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same things, with potentially the same security
issues that we'd have to fix twice
Le primidi 1er fructidor, an CCXXII, Thomas Goirand a écrit :
The problem was enforcing patch review policies.
No, it never was.
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same
Andreas Cadhalpun andreas.cadhal...@googlemail.com schrieb:
Hi Thomas,
On 18.08.2014 08:36, Thomas Goirand wrote:
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that are
doing (nearly) the same things, with
Hi Moritz,
On 18.08.2014 14:05, Moritz Mühlenhoff wrote:
Andreas Cadhalpun andreas.cadhal...@googlemail.com schrieb:
On 18.08.2014 08:36, Thomas Goirand wrote:
There's been a very well commented technical reason stated here: the
release team don't want to deal with 2 of the same library that
On Fri, Aug 15, 2014 at 01:19:38AM +0200, Luca Barbato wrote:
Stefano Sabatini wrote:
[...]
The list is quite long and debunking each of the statements could take a
lot of time.
I'm going to address two historical misrepresentations:
# The change of management
Michael Niedermayer
Hi Russ,
On 16.08.2014 18:33, Russ Allbery wrote:
All the renaming and cordial co-existence in the world won't change this.
The things that would change this is for one or both projects to develop a
better security track record and a history of higher-quality code releases
that require less
On 17/08/14 10:28, Michael Niedermayer wrote:
On Fri, Aug 15, 2014 at 01:19:38AM +0200, Luca Barbato wrote:
Stefano Sabatini wrote:
[...]
The list is quite long and debunking each of the statements could take a
lot of time.
I'm going to address two historical misrepresentations:
# The
On Sun, Aug 17, 2014 at 09:14:47PM +0200, Luca Barbato wrote:
[...]
Ive asked [1][2] back then what policy in place was broken
- you tried to commit code that was blatantly below the already lax
quality requirements (e.g. it contained tabs, it was (and still is) hard
to read, it contains
L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit :
Using Gerrit and file ownersip are not mutually exclusive. Gerrit
can be configured to automatically invite the right people for review
based on the changed path. We recently migrated to Gerrit at the
Wireshark project and it helps a
On 08/15/2014 11:53 PM, The Wanderer wrote:
It's also something the Linux kernel is still doing, with apparent
success.
Yes, the Linux kernel is a successful project. Does this mean using a
list for reviewing patches is a good thing? No! The workflow with a list
is simply horrible. Using
Le septidi 27 thermidor, an CCXXII, Thomas Goirand a écrit :
If you guys could find a solution to try to work together
again, and merge back both projects, that'd be best for everyone.
When people suggest that, I always wonder how they see that happening with
regard to the code.
On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George geo...@nsup.org wrote:
The only option is to make sure the users do not suffer from the fork, by
making sure they can easily use the version that is most suited for their
need without being sucked into the developers' disagreements.
Can we get
On Sat, 16 Aug 2014 23:29:56 +0800
Thomas Goirand z...@debian.org wrote:
On 08/15/2014 11:53 PM, The Wanderer wrote:
It's also something the Linux kernel is still doing, with apparent
success.
Yes, the Linux kernel is a successful project. Does this mean using a
list for reviewing
Pau Garcia i Quiles pgqui...@elpauer.org writes:
If libav and ffmpeg maintainers cannot reach an agreement regarding
library names and it's not possible to simply use either ffmpeg or libav
indistinctly due missing features binary compatibility, etc, the obvious
solution is that BOTH libav
Hi Russ,
Russ Allbery r...@debian.org (2014-08-16):
None of this is why libav and FFmpeg can't both be in the archive.
They can't both be in the archive because both the release team and
the security team have said that they're not interested in trying to
support both, due to the amount of
Cyril Brulebois k...@debian.org writes:
Russ Allbery r...@debian.org (2014-08-16):
None of this is why libav and FFmpeg can't both be in the archive.
They can't both be in the archive because both the release team and
the security team have said that they're not interested in trying to
On 8/16/14, Pau Garcia i Quiles pgqui...@elpauer.org wrote:
On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George geo...@nsup.org wrote:
The only option is to make sure the users do not suffer from the fork, by
making sure they can easily use the version that is most suited for their
need without
Hi Nicolas,
2014-08-16 17:11 GMT+02:00 Nicolas George geo...@nsup.org:
L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit :
Using Gerrit and file ownersip are not mutually exclusive. Gerrit
can be configured to automatically invite the right people for review
based on the changed path.
Hi Russ,
2014-08-16 18:59 GMT+02:00 Russ Allbery r...@debian.org:
Cyril Brulebois k...@debian.org writes:
Russ Allbery r...@debian.org (2014-08-16):
None of this is why libav and FFmpeg can't both be in the archive.
They can't both be in the archive because both the release team and
the
Ivan Kalvachev ikalvac...@gmail.com writes:
I'm quite sure the Security team is full of capable people who can
handle one more package.
One, no, this statement is not correct. Not because the security team is
not capable -- they are very capable -- but because they are not *full*.
You imply
On Sat, 16 Aug 2014 11:59:20 -0700
Russ Allbery r...@debian.org wrote:
The problem, however, is that taking security seriously, while possibly
necessary, is not sufficient. I'm glad that FFmpeg takes security
seriously, but what FFmpeg needs is to *have fewer security bugs*.
That is very
Hi,
On 16.08.2014 17:49, Pau Garcia i Quiles wrote:
On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George geo...@nsup.org
mailto:geo...@nsup.org wrote:
The only option is to make sure the users do not suffer from the
fork, by
making sure they can easily use the version that is most
On 8/16/2014 11:27 PM, wm4 wrote:
That is very valuable advice. We'll get to work right away.
I've added it to my TODO:
* Don't write bugs.
- Derek
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
wm4 nfx...@googlemail.com writes:
Russ Allbery r...@debian.org wrote:
Note that all of the above statements also apply to libav. As near as I
can tell, this is not a distinguishing characteristic between the two
projects.
And that's an argument against switching to FFmpeg exactly how?
Derek Buitenhuis derek.buitenh...@gmail.com writes:
On 8/16/2014 11:27 PM, wm4 wrote:
That is very valuable advice. We'll get to work right away.
I've added it to my TODO:
* Don't write bugs.
That's a really bad way of avoiding security bugs.
I'm sure you know that and are just being
On 08/14/2014 11:59 PM, The Wanderer wrote:
On 08/14/2014 11:27 AM, Thomas Goirand wrote:
On 08/13/2014 07:53 AM, Kieran Kunhya wrote:
On 08/13/2014 06:30 AM, Michael Niedermayer wrote:
Also ive offered my resignation in the past. I do still offer to
resign from the FFmpeg leader
On Fri, Aug 15, 2014 at 2:53 PM, Thomas Goirand wrote:
Hum... Well, to me, what's important is that the code gets
peer-reviewed.
... by both humans and by automatically by computers; compiler
warnings, static analysis tools, fuzz testers etc.
--
bye,
pabs
https://wiki.debian.org/PaulWise
On Fri, Aug 15, 2014 at 02:53:09PM +0800, Thomas Goirand wrote:
On 08/14/2014 11:59 PM, The Wanderer wrote:
On 08/14/2014 11:27 AM, Thomas Goirand wrote:
On 08/13/2014 07:53 AM, Kieran Kunhya wrote:
On 08/13/2014 06:30 AM, Michael Niedermayer wrote:
Also ive offered my
On 08/15/2014 08:20 PM, Michael Niedermayer wrote:
Yes, the tricky part in FFmpeg and Libav in relation to this is that
theres quite a bit of code that is only well understood by a single
person even if you would combine both projects together.
Hum... Hang on here then! Does this mean that, in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 08/15/2014 11:23 AM, Thomas Goirand wrote:
On 08/15/2014 08:20 PM, Michael Niedermayer wrote:
Absolutely everyone should *always* be able to leave comments, be
it positive or negative.
yes, i fully agree and this also was always so in
Hi,
2014-08-15 14:20 GMT+02:00 Michael Niedermayer michae...@gmx.at:
On Fri, Aug 15, 2014 at 02:53:09PM +0800, Thomas Goirand wrote:
On 08/14/2014 11:59 PM, The Wanderer wrote:
On 08/14/2014 11:27 AM, Thomas Goirand wrote:
On 08/13/2014 07:53 AM, Kieran Kunhya wrote:
On 08/13/2014
On Wed, Aug 13, 2014 at 12:53:41AM +0100, Kieran Kunhya wrote:
Also ive offered my resignation in the past.
I do still offer to resign from the FFmpeg leader position, if it
resolves this split between FFmpeg and Libav and make everyone work
together again. I never understood why people
On date Wednesday 2014-08-13 16:27:20 +0200, Attila Kinali encoded:
On Wed, 13 Aug 2014 00:30:05 +0200
Michael Niedermayer michae...@gmx.at wrote:
I never understood why people who once where friends
became mutually so hostile
You should know that better than anyone else!
You still
2014-08-14 13:58 GMT+02:00 Stefano Sabatini stefa...@gmail.com:
On date Wednesday 2014-08-13 16:27:20 +0200, Attila Kinali encoded:
On Wed, 13 Aug 2014 00:30:05 +0200
Michael Niedermayer michae...@gmx.at wrote:
I never understood why people who once where friends
became mutually so hostile
On 08/13/2014 07:53 AM, Kieran Kunhya wrote:
Whatever, people can work on their own code happily but the rest of
the world (cf this thread) has to deal with this annoying FFmpeg/libav
madness.
Right! Not only a core of a few upstream authors are affected, but also
downstream distributions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 08/14/2014 11:27 AM, Thomas Goirand wrote:
On 08/13/2014 07:53 AM, Kieran Kunhya wrote:
On 08/13/2014 06:30 AM, Michael Niedermayer wrote:
Also ive offered my resignation in the past. I do still offer to
resign from the FFmpeg leader
Stefano Sabatini wrote:
Please refrain from claiming other people are spreading lies,
especially with no specific references (and this is not the place
where to discuss such things).
Attila already amended one of the false statement that had been spun
around (about the people behind Libav
On Wed, 13 Aug 2014 00:30:05 +0200
Michael Niedermayer michae...@gmx.at wrote:
I never understood why people who once where friends
became mutually so hostile
You should know that better than anyone else!
You still claim to be my friend, yet you said and did things
that i have not seen from
On Mon, 11 Aug 2014 18:34:23 -0400
Theodore Ts'o ty...@mit.edu wrote:
On Mon, Aug 11, 2014 at 10:53:56PM +0200, wm4 wrote:
To be fair, FFmpeg does its own manual symbol versioning by appending
increasing numbers to function names. But the real problem are not
these functions, but public
On Tue, 12 Aug 2014 02:54:39 +0200
Matthias Urlichs matth...@urlichs.de wrote:
Hi,
wm4:
Build something on a newer glibc system, and try to run the binary on
an older system. It most likely won't work - even if it could in
theory. (At least it was this way some years ago. Probably still
Hi,
wm4:
ABI backwards compatibility is not a goal I would want to spend any time
on. Forward compatibility, on the other hand …
Well, I think it's a pretty common complaint from commercial software
vendors. That you can't distribute precompiled binaries reasonably.
They need to compile
Hi,
wm4:
In fact, the API cleanup is an ongoing process, and is what causes the
incompatibilities with each release. For example, a C library should
have a consistent naming schema. FFmpeg/Libav decided to use AV and av_
as prefixes for all symbols in the public header files. This required
Le mardi 12 août 2014 à 14:53 +0200, wm4 a écrit :
gstreamer has more problems than it solves. (Forces glib/gobject on
you, GTK-style OOP, pretty crashy, tons of low-quality plugins,
complicated API and design, ...)
Hummm, I know FUD when I see it…
--
.''`.Josselin Mouette
: :' :
On Tue, 12 Aug 2014 16:51:40 +0200
Matthias Urlichs matth...@urlichs.de wrote:
Hi,
wm4:
In fact, the API cleanup is an ongoing process, and is what causes the
incompatibilities with each release. For example, a C library should
have a consistent naming schema. FFmpeg/Libav decided to
Hi,
On Fri, 8 Aug 2014 08:16:24 -0500
Joe Neal vlvtel...@speakeasy.net wrote:
On both servers and desktops, I've been a Debian user since Sarge. I
use Debian not only because of its strong technical merits, but because
of the strong sense of ethics the project has always had.
A fork
On Tue, 12 Aug 2014 17:13:17 +0200
Attila Kinali att...@kinali.ch wrote:
Well, if you believe in lies, then of course your view of the world
will darken. But i hope that this email clears things up.
If I am spreading falsehoods then I apologize. The ffmpeg/libav split
broke a video sharing
On Tue, 12 Aug 2014 16:51:40 +0200
Matthias Urlichs matth...@urlichs.de wrote:
Hi,
Yes, that would be nice. The FFmpeg/Libav split is mostly a
political/social issue though: it seems some (not all) members from
each side just can't deal with some (not all) members from the other
side.
On Tue, 12 Aug 2014 14:04:32 -0400
compn te...@mi.rr.com wrote:
at least 6+ devels refuse to work with each other , thats only a
quick estimation, i havent polled everyone lately. ffmpeg and libav devs
dont even TALK to each other. theres a couple devs who frequent both
irc/lists, most do
On Tue, 12 Aug 2014 10:44:35 -0500
Joe Neal vlvtel...@speakeasy.net wrote:
When this happened I scoured the net, including mailing lists from both
projects to try and figure out what had happened. The overwhelming
evidence based on mailing list posts, blog posts, forum discussions and
Hi
On Tue, Aug 12, 2014 at 05:13:17PM +0200, Attila Kinali wrote:
Hi,
On Fri, 8 Aug 2014 08:16:24 -0500
Joe Neal vlvtel...@speakeasy.net wrote:
On both servers and desktops, I've been a Debian user since Sarge. I
use Debian not only because of its strong technical merits, but because
On Tue, Aug 12, 2014 at 09:45:37PM +0200, Attila Kinali wrote:
On Tue, 12 Aug 2014 10:44:35 -0500
Joe Neal vlvtel...@speakeasy.net wrote:
When this happened I scoured the net, including mailing lists from both
projects to try and figure out what had happened. The overwhelming
evidence
Also ive offered my resignation in the past.
I do still offer to resign from the FFmpeg leader position, if it
resolves this split between FFmpeg and Libav and make everyone work
together again. I never understood why people who once where friends
became mutually so hostile
The big elephant
On Tue, 12 Aug 2014 21:45:37 +0200
Attila Kinali att...@kinali.ch wrote:
I think you are confusing a few things. Sam was, as far as i know,
never active in FFmpeg. He was (and i think still is) a big figure
in VLC development.
I was only speaking of him as maintainer of the ffmpeg packages in
Hi,
On Montag, 11. August 2014, Ben Hutchings wrote:
dvswitch was also broken by the removal of support for downscaled
decoding of DV video. I don't know whether that change is specific to
libav or was also made in FFmpeg.
dvswitch is still broken and there is no dvswitch in jessie...
We
On 2014-08-09 18:26:19 +0100, Kieran Kunhya wrote:
We also use a fork specifically to work around very wasteful
calculations in libswscale during 10-bit chroma conversion that
involve multiplying a pixel by a 2^n value with 32-bit precision and
then shifting that value down by n back to 16-bit
+++ Wookey [2014-08-08 16:05 +0100]:
My expertise here is extremely limited, but some practical experience
shows that mythtv does at least basically work fine with libav.
It turns out that this is completely wrong (as hinted at in later
mails). I was mislead by info in bugreports.
The
Wookey woo...@wookware.org schrieb:
Unless we were to decide to make an exception re internal libraries
(which seems unlikely in this case given the general discussion on
security load), this package is not going to make it into Debian
anytime soon, which from my POV is very sad - I had
On Mon, Aug 11, 2014 at 06:28:51PM +0200, Moritz Mühlenhoff wrote:
I don't know mythtv, but if it's just a digital video recorder, there's
no significant risk ever needing security updates. A local, forked copy
is problematic for a video player since someone may open a malformed video
file,
Hello,
Apologies for not being able to resist answering even if it is getting
off-topic.
On Sun, Aug 10, 2014 at 05:43:33PM -0400, Theodore Ts'o wrote:
On Sun, Aug 10, 2014 at 12:25:33AM -0700, Andrew Kelley wrote:
High quality libraries must iterate on their API. Especially for a library
On Mon, 11 Aug 2014 20:40:28 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
Hello,
Apologies for not being able to resist answering even if it is getting
off-topic.
On Sun, Aug 10, 2014 at 05:43:33PM -0400, Theodore Ts'o wrote:
On Sun, Aug 10, 2014 at 12:25:33AM -0700, Andrew
Hi
On Sun, Aug 10, 2014 at 09:10:23AM -0400, Reinhard Tartler wrote:
On Sun, Aug 10, 2014 at 3:01 AM, Matthias Urlichs matth...@urlichs.de wrote:
[...]
IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
deprecated interfaces around for another release or two.
This
On Mon, Aug 11, 2014 at 10:53:56PM +0200, wm4 wrote:
To be fair, FFmpeg does its own manual symbol versioning by appending
increasing numbers to function names. But the real problem are not
these functions, but public structs. Imagine a new API user fighting to
guess which fields in
Hi,
wm4:
Build something on a newer glibc system, and try to run the binary on
an older system. It most likely won't work - even if it could in
theory. (At least it was this way some years ago. Probably still is.)
What would be the point of introducing new or updated interfaces
if you then
Hi,
Jean-Yves Avenard:
Including rename of constants (code enums id for example).
Another nail in libav's coffin, then.
IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
deprecated interfaces around for another release or two.
Keeping your own static version is the
On Sun, Aug 10, 2014 at 12:01 AM, Matthias Urlichs matth...@urlichs.de
wrote:
Jean-Yves Avenard:
Including rename of constants (code enums id for example).
Another nail in libav's coffin, then.
IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
deprecated
Hi,
Andrew Kelley:
It is unreasonable to expect no incompatible changes.
When somebody renames constants, a compatibility #ifdef or two is not too
much to ask, IMHO.
Libav is making a more concentrated effort at improving this,
and the evolving API is a side-effect of that.
That begs the
Hi
On 10 August 2014 17:01, Matthias Urlichs matth...@urlichs.de wrote:
Hi,
IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
deprecated interfaces around for another release or two.
Then it becomes unreasonable for a piece of software to be compatible
with
On Sun, Aug 10, 2014 at 1:48 AM, Jean-Yves Avenard jyaven...@gmail.com
wrote:
Then it becomes unreasonable for a piece of software to be compatible
with multiple version of the same library, and support all of those.
IMO it's not worth the effort to support multiple versions of the same
On 10 August 2014 18:53, Andrew Kelley superjo...@gmail.com wrote:
IMO it's not worth the effort to support multiple versions of the same
library. If you want to use an old library, use an old version of the
software.
In our case, we have very long release cycles. Usually only once a
year at
On 08/08/2014 09:22 PM, Matthias Urlichs wrote:
We'd also benefit from the fact that Upstream tends to use FFmpeg. I'd
hate to report some intractable codec bug which Upstream closes with
an it works with FFmpeg comment
Oh, btw, just a few days ago, that's exactly what happened on kdenlive
1 - 100 of 194 matches
Mail list logo
