On 29.12.2013 06:04, Xiangyu Liu wrote:
For some specific MKV files, mplayer2 has problem to sync A/V, but
mplayer works fine. I've filed a bug.
( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731937 )
MPlayer and MPlayer2 use different Matroska demuxers by default. Try
passing both "-demu
On Tue, Jul 14, 2009 at 04:01:16PM +0100, Christophe Mutricy wrote:
> 2009/7/14 Reinhard Tartler :
> >
> > r19254 | diego | 2009-06-23 01:09:34 +0200 (Di, 23. Jun 2009) | 3 lines
> >
> > Add ff_ prefixes to exported symbols in
On Thu, Mar 26, 2009 at 11:23:18AM +0100, Reinhard Tartler wrote:
> Diego Biurrun writes:
>
> > On Thu, Mar 26, 2009 at 07:36:24AM +0100, Reinhard Tartler wrote:
> >>
> >> > maybe --enable-debug in combination with our debian patch that replaces
> &g
On Thu, Mar 26, 2009 at 07:36:24AM +0100, Reinhard Tartler wrote:
>
> > maybe --enable-debug in combination with our debian patch that replaces
> > libavfoo/libavfoo.a with /usr/lib/libfoo.so?
May I suggest dropping this monstrously ugly patch and instead replacing
it by the use of the proper con
On Wed, Mar 25, 2009 at 09:32:45AM +0100, Sune Vuorela wrote:
>
> I tried building it with the ifeq(mipsel)... -fPIC -DPIC hack applied on -2
>
> Fails the same way. build log attached.
The options you guys pass to configure look suspicious:
--prefix=/usr
--confdir=/etc/mplayer --datadir=/u
On Sat, Mar 21, 2009 at 03:05:13PM +0100, Reinhard Tartler wrote:
> mennu...@users.alioth.debian.org writes:
> > --- a/debian/rules
> > +++ b/debian/rules
> > @@ -174,6 +174,11 @@ ifeq (powerpc,$(DEB_HOST_ARCH_CPU))
> > mv config.mak config.mak~~
> > sed '/FLAGS/s/ -O[0-9] / -O /' config.m
On Fri, Mar 20, 2009 at 08:40:54AM +0100, Fabian Greffrath wrote:
>
> manpages-zh contains an outdated mplayer manpage dating back to 2003. It
> it besides the only manpages.* package that ships its own mplayer
> manpage:
> http://packages.debian.org/search?searchon=contents&keywords=mplayer.1
On Thu, Jun 19, 2008 at 09:50:24AM +0200, Fabian Greffrath wrote:
>
> (1) Ffmpeg should finally decide about a stable API, or at least one
> that is stable for more than two weeks.
It is commonly believed myth that FFmpeg does not have a stable API, but
a myth nonetheless.
Diego
--
To UNSUB
Note that I am upstream for both MPlayer and FFmpeg.
On Thu, Jun 19, 2008 at 01:35:49PM +0200, Fabian Greffrath wrote:
> Reinhard Tartler schrieb:
> >I know that it is tricky, but I still think that for the problem we are
> >facing, this is an acceptable solution. YMMV of course.
>
> Fine, but ho
On Thu, Jun 19, 2008 at 01:35:49PM +0200, Fabian Greffrath wrote:
> Reinhard Tartler schrieb:
> >FFMpeg and Mplayer developers have a rather large overlap.
>
> BTW, how large is the overlap of ffmpeg developers with vlc or xine?
Practically zero.
Diego
signature.asc
Description: Digital signat
On Mon, Apr 14, 2008 at 04:38:47PM +0200, Lucas Nussbaum wrote:
>
> Don't blame gcc 4.3. It built that code fine last week. Blame dpkg (see
> my other mail)
If gcc fails to allocate registers, it is a bug in gcc. Report it to
them.
Diego
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
On Mon, Apr 14, 2008 at 12:48:56PM +0200, Lucas Nussbaum wrote:
>
> During a rebuild of all packages in sid, your package failed to build on i386.
>
> This rebuild was done with gcc 4.3 instead of gcc 4.2, because gcc 4.3 is now
> the default on most architectures (even if it's not the case on i3
On Fri, Nov 02, 2007 at 04:38:14PM +0100, Siegfrid Brandstätter wrote:
>
> Maintainer: Christian Marillat
I think you are reporting the bug in the wrong place. Christian's
packages are not the same as the official Debian ones.
Diego
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subj
There is no difference at all in the outputs. I suspect this is not an
MPlayer problem.
Diego
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Mon, Oct 08, 2007 at 09:20:26AM +0200, A Mennucc wrote:
>
> please send us the output of 'mplayer -v -v -v file...'
> (with both kernels if possible)
I don't think megabytes of log files are really helpful. I never found
more than a single -v useful.
Diego
--
To UNSUBSCRIBE, email to [EM
On Sun, Nov 05, 2006 at 02:58:25PM +0100, Aurélien GÉRÔME wrote:
> On Sun, Nov 05, 2006 at 01:30:08PM +0100, Diego Biurrun wrote:
> > On Sun, Nov 05, 2006 at 12:33:07PM +0100, Aurélien GÉRÔME wrote:
> > > It just happens that I have a lot of H.264-encoded videos which
&g
On Sun, Nov 05, 2006 at 12:33:07PM +0100, Aurélien GÉRÔME wrote:
> On Sun, Nov 05, 2006 at 11:52:48AM +0100, Diego Biurrun wrote:
> > On Sat, Nov 04, 2006 at 12:31:26AM +0100, Aurélien GÉRÔME wrote:
> > > This is a false argument. Come one please, do not attempt to tell me
On Wed, Nov 01, 2006 at 12:05:46AM +0100, Moritz Muehlenhoff wrote:
> A Mennucc wrote:
> > So I think that
> > [O] is not worth the effort: we ruin MPlayer (for sure) for hope of a
> > (not sure) benefit in security.
>
> I don't buy the argument of a completely crippled MPlayer. E.g. the
> libavco
On Sat, Nov 04, 2006 at 12:31:26AM +0100, Aurélien GÉRÔME wrote:
> On Fri, Nov 03, 2006 at 11:34:37PM +0100, Diego Biurrun wrote:
> > That benchmark was done on x86. But let's face it, it's the
> > architecture that counts. Mind that I am writing this from a PPC, whi
On Tue, Oct 31, 2006 at 10:43:17PM +0100, Aurélien GÉRÔME wrote:
>
> On Tue, Oct 31, 2006 at 07:46:01PM +0100, Diego Biurrun wrote:
> > Removing the embedded copies of FFmpeg libraries from MPlayer is a bad
> > idea.
>
> For the workload on the security team and the o
On Thu, Nov 02, 2006 at 03:17:49PM +0100, Loïc Minier wrote:
> On Thu, Nov 02, 2006, Diego Biurrun wrote:
> > Just to clarify: MPlayer does not contain an embedded fork of FFmpeg,
> > the FFmpeg libraries used in MPlayer are unmodified.
>
> I really fail to see why the same
On Wed, Nov 01, 2006 at 11:08:19AM +0100, Loïc Minier wrote:
>
> My opinion on this matter was requested, so I'm documenting it here.
> gst-ffmpeg suffers from a very similar problem, since it has an
> embedded fork of ffmpeg.
Just to clarify: MPlayer does not contain an embedded fork of FFmpe
able several video
filters, so there would be even more feature loss.
Plus I expect random bugs to creep up. As mentioned above FFmpeg is
highly volatile and fast-moving. Backwards-compatibility is not a
priority.
regards
Diego Biurrun
MPlayer / FFmpeg developer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
23 matches
Mail list logo
