Out of curiosity, I tested the performance impact of --disable-asm on
i386 with gcc 7.3.
Without --disable-asm:
$ ffmpeg -i BigBuckBunny_320x180.mp4 -f null -benchmark -
[...]
bench: utime=5.136s
bench: maxrss=46660kB
$ ffmpeg -i big_buck_bunny_1080p_stereo.avi -f null -benchmark -
[...]
bench: u
On Sun, Feb 18, 2018 at 10:04 PM, Carl Eugen Hoyos wrote:
> (Since two bugs were reopened and the status was set to "forwarded":)
My modifications don't change anything about the wontfixness of the
situation. The objective was only to indicate that ffmpeg itself
would need to be changed before st
control: affects -1 chromium-browser
Since the question was asked about how the chromium package handles
this, it does use libvpx as a shared library, but we have to disable
support for vp9 because of this bug.
Best wishes,
Mike
___
pkg-multimedia-main
control: tag -1 help, confirmed
control: severity -1 grave
x-debbugs-cc: pkg-multimedia-maintainers@lists.alioth.debian.org
Jose A. Fernandez Gonzalez wrote:
> Version 49 of Chromium and earlier versions depend on ffmpeg libraries
> (libavcodec, libavformat, libavutil, ...) and it seems version 50
package: src:libav
version: 6:0.8.16-1
severity: serious
tags: security
Hi,
the following vulnerabilities were published for libav.
CVE-2014-8541[0]:
| libavcodec/mjpegdec.c in FFmpeg before 2.4.2 considers only dimension
| differences, and not bits-per-pixel differences, when determining
| whet
package: vlc
version: 2.0.5-2
severity: minor
vlc supports cdda:// type URIs on its command-line, but that currently
isn't documented in its manpage. It would be useful to provide that as
documentation.
Best wishes,
Mike
___
pkg-multimedia-maintainers
package: src:libav
severity: grave
version: 6:0.8.5-1
Hi, the following vulnerabilities were published for libav. These are
currently unfixed in 0.8.5-1.
CVE-2013-0894[0]:
| Buffer overflow in the vorbis_parse_setup_hdr_floors function in the
| Vorbis decoder in vorbisdec.c in libavcodec in FFmp
package: libavutil51
version: 6:0.8.3-1+b1
severity: important
user: multiarch-de...@lists.alioth.debian.org
usertags: multiarch
Hi,
The libav package just got a binnmu, which broke multi-arch
co-installability (since the changelog files differ between
architectures):
dpkg: error processing
/var
tag 654534 patch
thanks
Note patches are available on the CVE pages for these issues:
http://security-tracker.debian.org/tracker/source-package/libav
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http:/
Package: libav
Version: 4:0.7.3-2
Severity: serious
Tags: security
Hi,
the following CVE (Common Vulnerabilities & Exposures) ids were
published for libav.
CVE-2011-3892[0]:
| Double free vulnerability in the Theora decoder in Google Chrome
| before 15.0.874.120 allows remote attackers to cause a
On Fri, Oct 28, 2011 at 9:20 AM, Mehdi Dogguy wrote:
> Package: mplayer2
> Version: 2.0-134-g84d8671-8
> Severity: grave
> Tags: security
> Justification: user security hole
>
> Please see:
> http://www.openwall.com/lists/oss-security/2011/10/14/1
> http://labs.mwrinfosecurity.com/files/Advisories/
the second issue doesn't affect 0.5.2 since classifs isn't a pointer
in that version. the first issue is a fuzzing crash, so i don't know
if it should be considered that important since its not clearly
exploitable. it does however affect 0.5.2.
best wishes,
mike
__
notfound 610550 4:0.5.2-6
tag 610550 -unreproducible
thanks
it looks like you're using a newer svn version of ffmpeg. at least
0.5.2 in unstable doesn't yet support webm, so it isn't affected. i
haven't checked 0.6.1 in experimental.
best wishes,
mike
package: vlc
severity: important
tags: security
a stack overflow exploit was published for vlc [0]. i tried the poc on
unstable, and it didn't work, which is why i've set the severity only to
important. that may be due to payload being windows-only? you may want
to check with upstream to make s
On Wed, 12 May 2010 08:17:27 +0200 Reinhard Tartler wrote:
> On Wed, May 12, 2010 at 00:25:52 (CEST), Michael Gilbert wrote:
> > an integer underflow was fixed in a recent DSA, but is still vulnerable
> > in the latest mplayer in unstable. see:
> > http://lists.debia
package: mplayer
severity: serious
version: 2:1.0~rc3+svn20100502-2
tags: security
an integer underflow was fixed in a recent DSA, but is still vulnerable
in the latest mplayer in unstable. see:
http://lists.debian.org/debian-security-announce/2010/msg00085.html
___
hi,
the latest upstream version (svn20100405) of mplayer fixes a
long-standing open security issue [0]. if this version were to be
packaged and uploaded, would it have a chance of getting through the
ftp-master new queue in a reasonable time frame? the current version
has already been delayed 10
On Tue, 06 Apr 2010 07:32:36 +0200 Reinhard Tartler wrote:
> On Tue, Apr 06, 2010 at 06:33:12 (CEST), Michael Gilbert wrote:
>
> > fyi, i've just tested upstream mplayer svn 20100405. it does not crash
> > with lol-mplayer.mpg. on the other hand, the currently packaged
&g
fyi, i've just tested upstream mplayer svn 20100405. it does not crash
with lol-mplayer.mpg. on the other hand, the currently packaged
version, svn 20090405, still crashes. does it make sense to upgrade to
a newer upstream version? thanks.
mike
___
> would it be wise to plan to ship squeeze with their stable point
> releases rather than their latest svn?
oops, i just read an earlier message where you mentioned that was your
plan all along. good to hear.
mike
___
pkg-multimedia-maintainers mail
fyi, upstream just released version 0.5.1 [0], and it looks like they
backported all of these security fixes, so it may be easier to figure
out the needed patches from the diff there.
would it be wise to plan to ship squeeze with their stable point
releases rather than their latest svn?
thanks fo
package: ffmpeg
version: 0.svn20080206-18
severity: serious
tags: security
hi, i have just tested the latest ffmpeg update against the original
proof of concepts [0] reported in bug #550442 [1]. many of them are
still effective. there is some good news though; i've found that
upstream has addres
On Sun, 13 Dec 2009 19:33:59 +0100 David Henningsson wrote:
> Michael Gilbert wrote:
> > Hi all,
> >
> > In order to guarantee that the system expat is used, the
> > '--with-expat=sys' configure argument must be used. If you think
> > your package i
reopen 560919
thanks
On Sun, 13 Dec 2009 12:12:19 +0100 David Henningsson wrote:
> Audacity already uses the system version of expat. Upstream ships expat
> included, but we configure the packages to build with the system
> versions instead.
please update your scripts to use --with-expat=sys. t
Hi all,
In order to guarantee that the system expat is used, the
'--with-expat=sys' configure argument must be used. If you think
your package is already using the system expat, or if you are updating
your package to use the system expat, please check to make sure that
this option is being used.
package: audacity
severity: serious
tags: security
Hi,
The following CVE (Common Vulnerabilities & Exposures) ids were
published for expat. I have determined that this package embeds a
vulnerable copy of xmlparse.c and xmltok_impl.c. However, since this is
a mass bug filing (due to so many pack
26 matches
Mail list logo