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
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 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
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 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
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
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
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
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 10 August 2014 13:38, Michael Niedermayer michae...@gmx.at 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).
On Sun, Aug 10, 2014 at 3:01 AM, Matthias Urlichs matth...@urlichs.de 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
Hi Reinhard,
On 10.08.2014 15:10, 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 is exactly what
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
incompatible
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
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
Hi,
2014-08-08 20:06 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com:
Hi Reinhard,
On 08.08.2014 14:29, Reinhard Tartler wrote:
On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs matth...@urlichs.de
wrote:
I intended to come up with a more timely full response, but I just
Quoting Bálint Réczey (2014-08-09 11:38:54)
XBMC works with Libav for most use-cases while it fails in the rest,
notably it can not use VDPAU acceleration which is being
(understandably) complained about very often (#742896). Another issue
is Libav crashing on bad input which makes
2014-08-09 13:41 GMT+02:00 Jonas Smedegaard d...@jones.dk:
Quoting Bálint Réczey (2014-08-09 11:38:54)
XBMC works with Libav for most use-cases while it fails in the rest,
notably it can not use VDPAU acceleration which is being
(understandably) complained about very often (#742896). Another
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 same
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
On 9 August 2014 19:25, Andreas Cadhalpun
andreas.cadhal...@googlemail.com 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
Quoting Bálint Réczey (2014-08-09 14:39:09)
2014-08-09 13:41 GMT+02:00 Jonas Smedegaard d...@jones.dk:
Quoting Bálint Réczey (2014-08-09 11:38:54)
Upstream makes sure all their use-cases work well with FFmpeg and
not interested in Libav-related issues.
According to XBMC, they only make sure
On 9 August 2014 17:03, Matthias Urlichs matth...@urlichs.de 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
Hi,
Andreas Cadhalpun:
Once FFmpeg is back in the archive, it'll be easy to reintroduce MPlayer. It
has been removed from sid, since it fails to build against Libav, but it
builds fine against FFmpeg.
(It uses some of the features only provided by FFmpeg.)
Yet another reason why solely
On Aug 08, Matthias Urlichs matth...@urlichs.de 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
On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs matth...@urlichs.de wrote:
Hi,
Andreas Cadhalpun:
Once FFmpeg is back in the archive, it'll be easy to reintroduce MPlayer. It
has been removed from sid, since it fails to build against Libav, but it
builds fine against FFmpeg.
(It uses some
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 steal the name and infrastructure from
the original project while
Quoting Reinhard Tartler (2014-08-08 14:29:59)
For now, please refer to http://lwn.net/Articles/607662/,
http://codecs.multimedia.cx/?p=370 (rather old, but still true), and
http://codecs.multimedia.cx/?p=674 (recent update on that matter)
Regarding Marco's argument that libav had few
1 - 100 of 163 matches
Mail list logo