[PATCH] Avoid freeing of unallocated memory in tv.c

Hi, All
I have found small bug in tv.c.
If tvi_init_* function return NULL (e.g. fails to initialize driver)
demuxer->priv  will not point to allocated memory, but demux_close_tv does not
check this case and MPLayer will crash.
Attached trivial patch fixes this.

-- 
Regards,
Vladimir Voroshilov mailto:voroshil <at> gmail.com
Omsk State University
JID: voroshil <at> jabber.ru
ICQ: 95587719

Index: tv.c
===================================================================
--- tv.c	(revision 21808)
+++ tv.c	(working copy)
 <at>  <at>  -480,6 +480,7  <at>  <at> 
     sh_audio_t *sh_audio = NULL;
     tvi_functions_t *funcs;

+    demuxer->priv=NULL;
     if(!(tvh=tv_begin())) return NULL;
     if (!tv_init(tvh)) return NULL;
     if (!open_tv(tvh)){
 <at>  <at>  -625,7 +626,9  <at>  <at> 
 static void demux_close_tv(demuxer_t *demuxer)

Re: [PATCH] SVN revision 21802, --enable-cpudetection failure in configure

Jean-Luc Coulon (f5ibh) wrote: 
> Hi,
> 
> With the latest SVN version (and probably most of the versions newer  
> than about 21740), configure fails when launched with  
> --enable-runtime-cpudetection on a x68_64 system.
> 
> In configure, the test for the correct architecture is done just before  
> OS and $host_arch determination.
> 
> Moving the test after the OS and architecture detection fixes the  
> problem.
> 
> Patch is attached.
> 
> 
> Happy 2007, thanks for all your work
> 
> Regards
> 
> Jean-Luc

Diego, what about this patch? 
It looks a bit better then my version.

 
--

-- 
Regards,
Vladimir Voroshilov mailto:voroshil <at> gmail.com
Omsk State University

Re: [FIX] tdfx_vid driver for newer kernels (tested with 2.6.17)

Bernhard Gruber wrote:
> The only drawback I found was, that I get quite a lot of horizontal "lines" in
> movies on my Voodoo3 3000 when there's a lot of motion in a scene (it seems like
> the video above this fictious lines are a frame further than the video below
> them). The XV-driver is hell slow here (HDTV videos don't even play without
> stuttering whereas the tdfx_vid-driver only needs 60% CPU usage) but these lines
> appear a little bit less. Has anoyne experienced such effects or knows how to
> solve that? As already said: I also have this using the XV driver so it should
> not be an issue with tdfx_vid itself...perhaps a general problem of the Voodoo3?

The effect you describe is called "tearing".

> Could anyone look over my file (the issue with the floating point arithmetic is
> marked with a "FIXME"-comment) and perhaps merge it into CVS if it's
> ok?
> Note: The Makefile is only for this module; the mga driver is not compiled and
> also seems to be incompatible with current kernels...
> 
> I put up the two files here:
> http://www-nw.uni-regensburg.de/~.grb19435.5.stud.uni-regensburg.de/tdfx_vid.tar
> Usage:
> 1. Copy it in the drivers folder and do a "make" and "make install"
> 2. "mknod /dev/tdfx_vid c 178 0" and "modprobe tdfx_vid" to activate
> 3. Now use mplayer with "-vo tdfx_vid" or "-vo xover:tdfx_vid"

I cannot help you myself, and I think tdfx_vid is not currently 
maintained. It would be a shame if your efforts went to /dev/null, 
however; you might be able to increase your chances of getting 
assistance by posting a patch according to the instructions in 
.../DOCS/tech/patches.txt.

Re: [PATCH] SVN revision 21802, --enable-cpudetection failure in configure

On Tue, Jan 02, 2007 at 03:35:30PM +0600, Vladimir Voroshilov wrote:
> Jean-Luc Coulon (f5ibh) wrote: 
> > 
> > With the latest SVN version (and probably most of the versions newer  
> > than about 21740), configure fails when launched with  
> > --enable-runtime-cpudetection on a x68_64 system.
> > 
> > In configure, the test for the correct architecture is done just before  
> > OS and $host_arch determination.
> > 
> > Moving the test after the OS and architecture detection fixes the  
> > problem.
> > 
> > Patch is attached.
> 
> Diego, what about this patch? 
> It looks a bit better then my version.

I'll review in mid-January, when I'm back.

Diego

[PATCH] Allow Makefile to recognize changes in pci.db

Hi!

Changes in libdha/oth/pci.db should trigger the call to awk. Patch attached.

Question: Should the following line be moved from distclean to clean in 
libdha/Makefile?
rm -f pci_dev_ids.c pci_ids.h pci_names.c pci_names.h pci_vendors.h pci.db

Greetings, Carl Eugen

Index: libdha/Makefile
===================================================================
--- libdha/Makefile	(Revision 21821)
+++ libdha/Makefile	(Arbeitskopie)
 <at>  <at>  -63,7 +63,7  <at>  <at> 

 all:    $(LIBNAME) $(SHORTNAME)

-pci_names.c:
+pci_names.c:	oth/pci.db
 	LC_ALL=C $(AWK) -f pci_db2c.awk oth/pci.db

 test:

_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng <at> mplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Re: [PATCH] musepack native decoder

Hello,
On Sun, Dec 24, 2006 at 05:52:33PM +0100, uoti.urpala <at> pp1.inet.fi wrote:
> Aurelien Jacobs wrote:
> > It currently require -demuxer lavf to work. I don't know how to
> > fix this nicely ? My idea would be to totaly remove libmpcdec
> 
> Why does it require -remuxer lavf? How does the output differ from
> demux_mpc?

Because the Musepack format use a "little-endian" bitstream, which means
that both you ended up doing bswap a few times and would waste 3 bytes
per frame and in general is idiotic. Also due to the way the libmpcdec
code worked then, this is converted to a proper bitstream in the
demuxer. Unfortunately while they optimized libmpcdec they also broke
the function that MPlayer uses, so that MPlayer does not work with
recent libmpcdec versions anyway...
The extradata is likely to be different, too, btw.

Greetings,
Reimar Döffinger

Re: [PATCH] shared libavutil support

Hello,
On Fri, Dec 29, 2006 at 05:32:50PM +0200, Ivan Kalvachev wrote:
> 2006/12/28, Dominik 'Rathann' Mierzejewski <dominik <at> rangers.eu.org>:
> >On Thursday, 28 December 2006 at 01:53, Aurelien Jacobs wrote:
> >> On Tue, 26 Dec 2006 22:08:50 +0100
> >> Dominik 'Rathann' Mierzejewski <dominik <at> rangers.eu.org> wrote:
> >>
> >> > Fixes build with shared libavutil.
> >> >
> >> > I'll apply this tomorrow evening if there are no objections.
> >>
> >> I havn't really looked at it, but seeing the patch, I would guess
> >> that the problem is in fact in configure. Maybe it should find
> >> the path of installed ffmpeg header and add something like
> >> -I/usr/include/ffmpeg.
> >> Well, that's only wild guessing and rough idea. Don't trust it
> >> too much.
> >
> >The same is already done for shared libavcodec.
> >
> >Regards,
> >R.
> 
> I donno why, but I have the feeling that libavutil is not meant  to be
> used as shared by MPlayer.

It is not, since MPlayer needs some headers that are not installed for
the shared version. It can only compile by combining code from shared
libavutil and the code in the libavutil/ subdir, which is at least
risky...

Re: [PATCH] shared libavutil support

On Thursday, 04 January 2007 at 19:46, Reimar Döffinger wrote:
> Hello,
> On Fri, Dec 29, 2006 at 05:32:50PM +0200, Ivan Kalvachev wrote:
> > 2006/12/28, Dominik 'Rathann' Mierzejewski <dominik <at> rangers.eu.org>:
> > >On Thursday, 28 December 2006 at 01:53, Aurelien Jacobs wrote:
> > >> On Tue, 26 Dec 2006 22:08:50 +0100
> > >> Dominik 'Rathann' Mierzejewski <dominik <at> rangers.eu.org> wrote:
> > >>
> > >> > Fixes build with shared libavutil.
> > >> >
> > >> > I'll apply this tomorrow evening if there are no objections.
> > >>
> > >> I havn't really looked at it, but seeing the patch, I would guess
> > >> that the problem is in fact in configure. Maybe it should find
> > >> the path of installed ffmpeg header and add something like
> > >> -I/usr/include/ffmpeg.
> > >> Well, that's only wild guessing and rough idea. Don't trust it
> > >> too much.
> > >
> > >The same is already done for shared libavcodec.
> > >
> > >Regards,
> > >R.
> > 
> > I donno why, but I have the feeling that libavutil is not meant  to be
> > used as shared by MPlayer.
> 
> It is not, since MPlayer needs some headers that are not installed for
> the shared version. It can only compile by combining code from shared
> libavutil and the code in the libavutil/ subdir, which is at least

[PATCH] support for pthreadw32 static

Attached a patch that enables support for static pthread win32
it needs some initializations in executables.
The detection is based on the fact that the static needs ws2_32 lib,
so first check fails, then if pthreads is no and platform is win32
another check is made ld_pthreads becomes -lpthreadsGC2 -lws32_32
and -DPTW32_STATIC_LIB is added to CFLAGS, this trigger some code
init/unint in mplayer/mencoder executables, I'm using atexit
to ensure the unint gets called, also the check prog needs these
init/uninit or it will crash.

I've tested it with mencoder using 8 threads, obiviously you need
x264 linked against static pthread if you want to enable also x264
support.

I'll test it on mplayer, I've posted it now so someone can make
additional tests.

Bye

--

-- 
Gianluigi Tiesi <sherpya <at> netfarm.it>
EDP Project Leader
Netfarm S.r.l. - http://www.netfarm.it/
Free Software: http://oss.netfarm.it/

diff -NuBr -x.svn -xhelp_mp.h -xlibdha -x'*.so' -x'*.log' -x'*.a' -x'*.exe' -x'*.o' -xconfigure.log
-xconfig.mak -x.cvsignore -xconfig.h -xcodecs.conf.h -xversion.h -x.depend main/configure sherpya/configure
--- main/configure	2007-01-05 02:14:45.991153600 +0100
+++ sherpya/configure	2007-01-05 09:59:00.496728000 +0100

Re: [PATCH] Fix --enable-runtime-cpudetection under MinGW

On Fri, Dec 29, 2006 at 02:18:46PM +0600, Vladimir Voroshilov wrote:
> Currently, under MinGW on Pentium4, running ./configure
> --enable-runtime-cpudetection gives following error message:
> =============cut=====================
> Error: Runtime CPU detection only works for x86, x86-64 and PPC!
> 
> Check "" if you do not understand why it failed.
> =============cut=====================

This patch doesn't work for me:
#define __CPU__

in libavutil/bswap.h
there is:

#if __CPU__ != 386

that fails to compile

Bye

--

-- 
Gianluigi Tiesi <sherpya <at> netfarm.it>
EDP Project Leader
Netfarm S.r.l. - http://www.netfarm.it/
Free Software: http://oss.netfarm.it/