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
>> think discussing the Libav-FFmpeg split and ways to resolve it at VDD
>> makes a lot of sense, quite litterally more than 90% of the developers
>> wont be there. I also wont be there
Lame excuse. You're the leader and the main reason why people want you there.
>> also iam quite confident that
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
> 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.
___
ffmpeg-devel mailing list
ffm
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
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
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
___
ffmpeg-dev
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 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
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 18 August 2014 23:15, Andreas Cadhalpun
wrote:
> Why is FFmpeg treated differently than MariaDB/PerconaDB?
>
That's a very good question really.
But reading some of the comments in regards to having a nay for
including project that duplicate code, my guess is that it's a totally
irrational d
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
On Sat, 16 Aug 2014, Thomas Goirand wrote:
> 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-review and gerrit is so much better.
Strong NAK here.
First: it breaks th
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
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
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 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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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.
On Sat, 16 Aug 2014 11:59:20 -0700
Russ Allbery wrote:
> Two, the security team has already said that FFmpeg is not just "one
> more package," and that no, they can't handle the substantial
> incremental load from adding FFmpeg without removing libav. You may
> be leery for a while. To change t
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 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
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
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 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
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.
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
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 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
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
_
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 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
-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 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
-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 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
> 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, 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, 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
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 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
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
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
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, 10 Aug 2014 09:43:03 +0200
Matthias Urlichs wrote:
> 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.
AFAIK such a thing existed, but it's possible that th
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
On Sun, Aug 10, 2014 at 1:48 AM, Jean-Yves Avenard
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
library. If you want t
On Sun, Aug 10, 2014 at 12:01 AM, Matthias Urlichs
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 interfaces around for
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 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 Sun, Aug 10, 2014 at 01:38:06PM +0200, Nicolas George wrote:
> Le tridi 23 thermidor, an CCXXII, wm4 a écrit :
> > You seem to be under the impression that this matters.
>
> That is the only thing that matters in FFmpeg: people work on what they
> consider important.
>
> > I don't want to have
Le tridi 23 thermidor, an CCXXII, wm4 a écrit :
> You seem to be under the impression that this matters.
That is the only thing that matters in FFmpeg: people work on what they
consider important.
> I don't want to have to develop for two slightly similar but
> different APIs, the end. And I don'
On Sun, 10 Aug 2014 13:25:03 +0200
Nicolas George wrote:
> Le tridi 23 thermidor, an CCXXII, wm4 a écrit :
> > Unfortunately, FFmpeg vehemently resists against enabling lavr by
> > default.
>
> If someone cared enough, they would be making their case: posting
> benchmarks, listing features prese
Le tridi 23 thermidor, an CCXXII, wm4 a écrit :
> Unfortunately, FFmpeg vehemently resists against enabling lavr by
> default.
If someone cared enough, they would be making their case: posting
benchmarks, listing features present in each library but absent in the
other, comparing the APIs to see w
On Sat, 09 Aug 2014 20:25:09 +0200
Andreas Cadhalpun wrote:
> Hi Kieran,
>
> On 09.08.2014 19:26, Kieran Kunhya wrote:
> > The reality is that in the current state of affairs static linking is
> > the *only* way you are guaranteed to have the features you expect and
> > avoid ABI mismatches. It'
On 10 August 2014 18:53, Andrew Kelley 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 best. We have users
Hi
On 10 August 2014 17:01, Matthias Urlichs 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 multiple version of t
On 9 August 2014 17:03, Matthias Urlichs wrote:
> Most forks cause additional work which, in the long term, is better spent
> elsewhere. The ffmpeg/libav split is ample proof of that; in an ideal
> world, you wouldn't need the mythtv fork either.
>
> Debian's position is that we _really_ want to
On 9 August 2014 19:25, Andreas Cadhalpun
wrote:
> I can understand that statically linking is easier from an upstream point of
> view, but it has important disadvantages for a distribution such as Debian
> and thus should be avoided if possible.
> It is also the responsibility of a distribution t
Hi Kieran,
On 09.08.2014 19:26, Kieran Kunhya wrote:
The reality is that in the current state of affairs static linking is
the *only* way you are guaranteed to have the features you expect and
avoid ABI mismatches. It's very complicated when your users complain
about bugs in an underlying librar
> Most forks cause additional work which, in the long term, is better spent
> elsewhere. The ffmpeg/libav split is ample proof of that; in an ideal
> world, you wouldn't need the mythtv fork either.
>
> Debian's position is that we _really_ want to avoid having multiple copies
> of essentially the
Hi,
Jean-Yves Avenard:
> We have attempted for many years to get our changes merged in FFmpeg
> but gave up.
>
It might be a good idea to restart this effort.
> To end this message: I fail to see how debian's decision on which
> version of FFmpeg or LibAV would have any impact on MythTV, we use
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
Hi
On 9 August 2014 11:57, wm4 wrote:
> On Sat, 9 Aug 2014 11:46:40 +1000
> Off-topic, but: it might be easier nowadays?
>
> The strangest things that are not even related to video decoding are
> getting merged - surely it's possible to merge things such as teletext.
In all honesty, we spent mon
On Sat, 9 Aug 2014 11:46:40 +1000
Jean-Yves Avenard wrote:
> MythTV do not work against stock FFmpeg and never will. We run a
> heavily modified version of FFmpeg, you can call it a fork.
> In particular, we use our own mpeg-ts demuxer, we support things like
> MHEG, DVB/ATSC/Teletext subtitles t
Hi.
Only going to reply to some of the misinformation provided in the post
from Reinhard Tartler
(https://lists.debian.org/debian-devel/2014/08/msg00160.html)
For the background: I am the de-facto maintainer of the MythTV's FFmpeg fork.
> To the best of my knowledge, there are only two high-pro
Quoting Matthias Urlichs (2014-08-08 21:22:38)
> Alessio Treglia:
>> We've spent a lot of time over the past months talking to upstreams,
>> forwarding them our patches and make sure their programs and
>> libraries work with libav.
>> We've spent ***months*** in making the whole thing work, and d
On Fri, 8 Aug 2014 15:06:20 +0100
Alessio Treglia wrote:
> Hi,
>
> On Fri, Aug 8, 2014 at 12:13 PM, Matthias Urlichs wrote:
> > That leaves the question of the "official" opinion of the libav
> > maintainers (pkg-multimedia-maintain...@lists.alioth.debian.org).
> > Did none of them write anythi
Alessio Treglia debian.org> writes:
> Many Jessie's multimedia framework and packages
> have been developed and QA'd with libav.
Could you name one framework or package that does
not work with FFmpeg (or does not have less bugs
with FFmpeg than with avconv libraries)?
I have never tested GSt
Hi,
Alessio Treglia:
> We've spent a lot of time over the past months talking to upstreams,
> forwarding them our patches and make sure their programs and libraries
> work with libav.
> We've spent ***months*** in making the whole thing work, and dropping
> libav in favour of FFmpeg at this point,
On Aug 08, Matthias Urlichs wrote:
> IMHO the best idea at this point would be to toss out libav, and rebuild
> the rdeps with ffmpeg. Now, before it's too late for jessie.
Agreed. The interested parties should really raise this with the CTTE
ASAP.
--
ciao,
Marco
signature.asc
Description: D
1 - 100 of 107 matches
Mail list logo
