though it's not a drop-in 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
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.
>
> 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 theo
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:
> https://git.ffmp
> 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 subj
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
ll not be
supported by upstream at least 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 "u
etings,
Reimar Döffinger
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ch/056938.html
> the patch fixes the same problem in a different way like the
> diff from the xine-lib repository.
I did not check myself I admit, I just assumed from explanations
elsewhere that the xine version was missing some checks on stream_id as
well.
Sorry if I misunderstood (and thus
might be caused by the default value of CFLAGS now set by
> dpkg-buildpackage. Maybe this code doesn't build with -O2 ?
No, certainly not. From the MPlayer developers side, only the build
flags chosen by MPlayer's configure are acceptable and anything else
is unsupported and very likely to fail.
In particular, -fomit-frame-pointer is mandatory. While there is
alternative code that works without, it is (for H.264 about 10%) slower
and thus not really acceptable.
Also, -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
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
t tried 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 cho
On 1 Jan 2012, at 15:26, Reinhard Tartler 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, that is
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
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 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
> >> wrote:
> >> > Package: mplayer
> >> >
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
> wrote:
> > What would constitute a constructive comment?
>
> Ideally "I am interested in making mplayer work against the libavcodec
> that we have
what you 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
> wr
On 14.12.2013, at 23:53, John Paul Adrian Glaubitz
wrote:
> On 12/14/2013 11:07 PM, Reinhard Tartler wrote:
>> On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff wrote:
>>> Package: mplayer
>>> Severity: serious
>>>
>>> Should this package be removed? If so, please reassign to ftp.debian.org
>
18 matches
Mail list logo
