On Fri, Aug 29, 2014 at 1:17 PM, Michael Niedermayer 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 tried having a
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 poli
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
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 m
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)GP
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 Source
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 probably
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 j
> 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 s
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 wrote:
>
> > By continuing old fights, inspite of the very clearly friendly and
> > open offers and suggestions byu Michael, you and others from AV continue
> >
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 li
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 ye
On Mon, 18 Aug 2014 13:42:36 +0200
Nicolas George 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 side after the
On Sat, 16 Aug 2014 17:11:29 +0200
Nicolas George 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 commit righ
Servus,
On Wed, 20 Aug 2014 18:43:18 +0900
Norbert Preining 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, Michael always of
On Thu, 14 Aug 2014 13:58:07 +0200
Stefano Sabatini 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 last 3 and a
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 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 y
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"
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 debian-devel-requ...@lists.
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 requirem
On 8/18/14, Moritz Mühlenhoff wrote:
> Andreas Cadhalpun 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
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/cla
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
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 t
Hi Moritz,
On 18.08.2014 14:05, Moritz Mühlenhoff wrote:
Andreas Cadhalpun 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 are
doing (nearly) the same thing
Andreas Cadhalpun 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 potentially the same securit
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
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 rat
❦ 18 août 2014 14:20 +0800, Thomas Goirand :
>> 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 associated action.
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 Stabl
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
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 migrate
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, wi
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 cont
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 "misrepresentatio
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 ongo
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 Nied
Derek Buitenhuis 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 flippant, but I have to sa
wm4 writes:
> Russ Allbery 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?
It's not. Nor was I trying to m
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
Hi,
On 16.08.2014 17:49, Pau Garcia i Quiles wrote:
On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George 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 suited for
thei
On Sat, 16 Aug 2014 11:59:20 -0700
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*.
That is very valuable advice.
Ivan Kalvachev 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 that the security te
Hi Russ,
2014-08-16 18:59 GMT+02:00 Russ Allbery :
> Cyril Brulebois writes:
>> Russ Allbery (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
Hi Nicolas,
2014-08-16 17:11 GMT+02:00 Nicolas George :
> 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 recen
On 8/16/14, Pau Garcia i Quiles wrote:
> On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George 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 devel
Cyril Brulebois writes:
> Russ Allbery (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 am
Hi Russ,
Russ Allbery (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 work involved.
Pau Garcia i Quiles 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 and ffmpeg rename t
On Sat, 16 Aug 2014 23:29:56 +0800
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 g
On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George 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 back on top
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 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 git-r
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
Hi,
2014-08-15 14:20 GMT+02:00 Michael Niedermayer :
> 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
-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
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,
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 off
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 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
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 "s
-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 leade
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 (w
2014-08-14 13:58 GMT+02:00 Stefano Sabatini :
> On date Wednesday 2014-08-13 16:27:20 +0200, Attila Kinali encoded:
>> On Wed, 13 Aug 2014 00:30:05 +0200
>> Michael Niedermayer wrote:
>>
>> > I never understood why people who once where friends
>> > became mutually so hostile
>>
>> You should know
On date Wednesday 2014-08-13 16:27:20 +0200, Attila Kinali encoded:
> On Wed, 13 Aug 2014 00:30:05 +0200
> Michael Niedermayer 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 t
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 pe
On Wed, 13 Aug 2014 00:30:05 +0200
Michael Niedermayer 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 my enemies, let
On Tue, 12 Aug 2014 21:45:37 +0200
Attila Kinali 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
debian. I ha
> 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 eleph
On Tue, Aug 12, 2014 at 09:45:37PM +0200, Attila Kinali wrote:
> On Tue, 12 Aug 2014 10:44:35 -0500
> Joe Neal 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 mail
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 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 stro
On Tue, 12 Aug 2014 10:44:35 -0500
Joe Neal 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
> pretty much everywhere el
On Tue, 12 Aug 2014 14:04:32 -0400
compn 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 not.
This is
On Tue, 12 Aug 2014 16:51:40 +0200
Matthias Urlichs 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.
> >
> > How
On Tue, 12 Aug 2014 17:13:17 +0200
Attila Kinali 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 site that I buil
Hi,
On Fri, 8 Aug 2014 08:16:24 -0500
Joe Neal 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 that tries to forcibly
On Tue, 12 Aug 2014 16:51:40 +0200
Matthias Urlichs 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 use AV and av
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
: :' :
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
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
On Tue, 12 Aug 2014 02:54:39 +0200
Matthias Urlichs 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 is.)
>
>
On Mon, 11 Aug 2014 18:34:23 -0400
Theodore Ts'o 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 st
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
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 AV
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 wrote:
[...]
> > IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
> > deprecated interfaces around for another release or two.
>
> This is exactly wh
On Mon, 11 Aug 2014 20:40:28 +0200
Reimar Döffinger 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 Kelley 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 Kelley wrote:
> >
> > High quality libraries must iterate on their API. Especially for a libr
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,
Wookey 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 thought we were
> clos
+++ 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 (pro
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-
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 Sun, 2014-08-10 at 23:02 +0200, Andreas Cadhalpun wrote:
[...]
> * dvswitch: Still uses CodecID (and also avcodec_encode_video, but
> that is still present in FFmpeg.) [3]
[...]
dvswitch was also broken by the removal of support for downscaled
decoding of DV video. I don't know whether t
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
> trying to solve such a complex problem as audio and video encoding and
> decoding for every codec and format. It is unreasonable to expect no
> incompatib
Hi Reinhard,
On 10.08.2014 15:10, Reinhard Tartler wrote:
On Sun, Aug 10, 2014 at 3:01 AM, Matthias Urlichs wrote:
IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
deprecated interfaces around for another release or two.
This is exactly what Libav is doing: The depr
On Sun, Aug 10, 2014 at 3:01 AM, Matthias Urlichs wrote:
> Hi,
>
> Jean-Yves Avenard:
>> Including rename of constants (code enums id for example).
>
> Another nail in libav's coffin, then.
That's one way to see it. To me, this makes mythtv unsuitable for
inclusion into Debian. Let me explain why
On 10 August 2014 13:38, Michael Niedermayer wrote:
> On Sat, Aug 09, 2014 at 06:26:19PM +0100, Kieran Kunhya wrote:
> [...]
>
>> ... and was designed by a larger
>> group instead of libswresample which was basically one person (and
>> literally appeared in git out of nowhere).
http://git.videola
On Sat, Aug 09, 2014 at 06:26:19PM +0100, Kieran Kunhya wrote:
[...]
> ... and was designed by a larger
> group instead of libswresample which was basically one person (and
> literally appeared in git out of nowhere).
For the record:
$ git shortlog libswresample/ | grep '^[^ ]'
Alexander Strasser
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
