Hi!
> CVE-2022-38600[0]:
> | Mplayer SVN-r38374-13.0.1 is vulnerable to Memory Leak via vf.c and
> | vf_vo.c.
>
> https://trac.mplayerhq.hu/ticket/2390#comment:2
> https://git.ffmpeg.org/gitweb/mplayer.git/commit/59792bad144c11b21b27171a93a36e3fbd21eb5e
> (r38380)
> Followup:
>
> On 28 Feb 2022, at 19:12, Ian Jackson wrote:
> It seems to me that at #1004579 (ffmpeg 5.0) and #939032 (giflib)
> would need to be addressed,
These are definitely fixed in 1.5, and the fix for giflib should be not hard to
cherry-pick for 1.4 if there is a need.
> and #958865 (crash on
On Thu, Feb 17, 2022 at 08:45:59PM +0100, Sebastian Ramacher wrote:
> On 2022-02-17 19:13:08 +0100, Reimar Döffinger wrote:
> >
> > > On 16 Feb 2022, at 23:25, Sebastian Ramacher wrote:
> > >
> > > Let's stop pretending that mplayer is maintained.
> >
n replacement (different command-line) and
supposedly it aims more at modern computers, so might not be so great a
replacement for legacy hardware.
Best regards,
Reimar Döffinger
I see there is some progress upstream so it may be
reasonable to just wait it out.
But since I hacked it up for myself anyway (well, only
the grep expression really, did not test the rules file).
The following quick hack patch would remove the questionable
headers and ensure only properly licensed
to avoid this license mess, however
that activity seems to have died...
Given the popularity of the library and the regularity of license
slip-ups a more long-term solution than manual review/fixing would
be nice to have.
And apologies if Severity: serious was the incorrect choice.
Thanks,
Reimar
wrote sounded more like it's at least also
2) MPlayer has packaging issues
I've mentioned this a few times over the years, I'd be interested in
improving 2), and that is regardless of the status of this ticket.
On Mon, Feb 17, 2014 at 6:52 PM, Reimar Döffinger
reimar.doeffin...@gmx.de wrote
On Sun, Feb 16, 2014 at 03:25:08PM -0500, Reinhard Tartler wrote:
On Sun, Feb 16, 2014 at 12:58 PM, Reimar Döffinger
reimar.doeffin...@gmx.de wrote:
What would constitute a constructive comment?
Ideally I am interested in making mplayer work against the libavcodec
that we have in Debian
On Sun, Feb 16, 2014 at 12:16:59PM -0500, Reinhard Tartler wrote:
On Sun, Feb 16, 2014 at 11:21 AM, Moritz Mühlenhoff j...@inutil.org wrote:
On Sat, Dec 14, 2013 at 05:07:36PM -0500, Reinhard Tartler wrote:
On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff j...@debian.org
wrote:
On 14.12.2013, at 23:53, John Paul Adrian Glaubitz
glaub...@physik.fu-berlin.de wrote:
On 12/14/2013 11:07 PM, Reinhard Tartler wrote:
On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff j...@debian.org wrote:
Package: mplayer
Severity: serious
Should this package be removed? If so, please
On 1 Jan 2012, at 15:26, Reinhard Tartler siret...@tauware.de wrote:
On So, Jan 01, 2012 at 15:08:03 (CET), Julien Cristau wrote:
On Sun, Jan 1, 2012 at 08:25:00 +0100, Reinhard Tartler wrote:
I really think this is a bug in mplayer. ff_codec_wav_tags is and always
was an internal symbol,
On Tue, Jul 14, 2009 at 05:38:54PM +0200, Reinhard Tartler wrote:
mplayer however contains a private copy of ffmpeg in its sources, and
has therefore no problem including headers that are not
installed. libavformat/riff.h is e.g. such a header. This is strictly
speaking a violation of usage
for now since MPlayer depends on some of
its internal functions that can not be exported cleanly (features that
depend on a FFmpeg-compatible config.h).
Greetings,
Reimar Döffinger
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
, -O2 compared to the default of -O4 (equivalent to -O3) has very
different inlining behaviour and might cause significant performance
differences as well.
Greetings,
Reimar Döffinger
assumed from explanations
elsewhere that the xine version was missing some checks on stream_id as
well.
Sorry if I misunderstood (and thus misrepresented) the issue.
Greetings,
Reimar Döffinger
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
,
Reimar Döffinger
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hello,
On Sat, Oct 13, 2007 at 03:25:06PM -0400, Sean Zimmermann wrote:
I found ALSA stopped working after the kernel upgrade. Any program that
tried to work with alsa (like xmms, totem, or gnome sound) stalled. I
recompiled the drivers and alsa now appears to be working.
While it does not
There is no difference at all in the outputs. I suspect this is not an
MPlayer problem.
Actually there is, in the later one audio gets stuck at 0.0 seconds.
My guess is that ALSA broke...
Greetings,
Reimar Döffinger
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
18 matches
Mail list logo
