- MPlayer-dev-eng - lists.mplayerhq.hu

[PATCH] Build with current FFmpeg Git head
by Nicolas George 28 Jul '26

28 Jul '26

This is what I needed to build with current FFmpeg Git. I also had to disable VDPAU, I did not fix it. I tested mplayer succinctly, it works. I did not test mencoder. I also needed to patch the Makefiles in ffmpeg for missing dependencies. Some (most? all?) of the missing dependencies are expressed in ffmpeg's configure as whatever_select="…", we probably should hack configure to use them. I will send the diff in reply to this mail. Regards, -- Nicolas George

1 19

[PATCH] Fix dvdread and dvdnav is not found if --enable-static
by KO Myung-Hun 27 Jul '26

27 Jul '26

--- configure | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configure b/configure index b6c17ec7f..4deb3f159 100755 --- a/configure +++ b/configure @@ -6475,6 +6475,7 @@ echores "$_bluray" echocheck "dvdread" if test "$_dvdread" = auto ; then _dvdread=no + test -n "$ld_static" && _dvdreadconfig="$_dvdreadconfig --static" _dvdreadcflags=$($_dvdreadconfig --cflags 2> /dev/null) _dvdreadlibs=$($_dvdreadconfig --libs 2> /dev/null) if statement_check dvdread/dvd_reader.h 'DVDOpen("test")' $_dvdreadcflags $_dvdreadlibs ; then @@ -8414,6 +8415,7 @@ CXXFLAGS=" $CFLAGS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMI echocheck "DVD support (libdvdnav)" if test "$_dvdnav" = auto ; then _dvdnav=no + test -n "$ld_static" && _dvdnavconfig="$_dvdnavconfig --static" _dvdnavdir=$($_dvdnavconfig --cflags) _dvdnavlibs=$($_dvdnavconfig --libs) statement_check_broken stdint.h dvdnav/dvdnav.h 'dvdnav_t *dvd = 0; dvdnav_open(&dvd, 0)' $_dvdnavdir $_dvdnavlibs $ld_dl $ld_pthread && _dvdnav=yes -- 2.50.1

2 2

[PATCH] Check libpng with pkg-config as well
by KO Myung-Hun 27 Jul '26

27 Jul '26

--- configure | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/configure b/configure index ae2861848..b6c17ec7f 100755 --- a/configure +++ b/configure @@ -5536,13 +5536,14 @@ int main(void) { return strcmp(PNG_LIBPNG_VER_STRING, png_libpng_ver); } EOF - cc_check -lpng -lz && _png=yes + for ld_tmp in "$($_pkg_config --libs libpng)" "-lpng -lz"; do + cc_check $ld_tmp && _png=yes && extra_ldflags="$extra_ldflags $ld_tmp" && break + done fi fi echores "$_png" if test "$_png" = yes ; then def_png='#define CONFIG_PNG 1' - extra_ldflags="$extra_ldflags -lpng -lz" else def_png='#undef CONFIG_PNG' fi -- 2.50.1

2 2

None
by None 10 Sep '25

10 Sep '25

long-term delayed patches: shift_fix.diff+ckey_fix.diff - (vidix radeon fixes from mpxp) needs to be applied by hand, they don't apply at all The vidix patch for radeon by Nick Kurshev to the mplayerxp vidix driver has been contributed by Carl (mlist.mplayer.users(a)urs.us) to the users list. I have further modified by the patch to fix the shift problem and the pink screen problem for my card (Mobility M6 LY). At least for him (Radeon 7500) and for me the vidix driver works. Other cards should be tested too, the changes needed are obvious from the patch. I only have access to the Mobility M6 LY and a Mach64 (the vidix driver works already for this card) Thanks, Svante Index: vidix/drivers/radeon_vid.c =================================================================== RCS file: /cvsroot/mplayer/main/vidix/drivers/radeon_vid.c,v retrieving revision 1.53 diff -u -b -r1.53 radeon_vid.c --- vidix/drivers/radeon_vid.c 20 Nov 2002 15:48:34 -0000 1.53 +++ vidix/drivers/radeon_vid.c 19 Dec 2002 08:54:30 -0000 @@ -23,13 +23,15 @@ #define X_ADJUST 0 #else #define RADEON_MSG "Radeon_vid:" -#define X_ADJUST (!IsR200 ? 8 : 0) +#define X_ADJUST (is_shift_required ? 8 : 0) #ifndef RADEON #define RADEON #endif #endif static int __verbose = 0; +static int rage_ckey_model=0; +static int is_shift_required; typedef struct bes_registers_s { @@ -927,6 +929,28 @@ printf(RADEON_MSG" Video memory = %uMb\n",radeon_ram_size/0x100000); err = mtrr_set_type(pci_info.base0,radeon_ram_size,MTRR_TYPE_WRCOMB); if(!err) printf(RADEON_MSG" Set write-combining type of video memory\n"); + + switch(def_cap.device_id) + { + case DEVICE_ATI_RADEON_QW: + case DEVICE_ATI_RADEON_MOBILITY_M6: + case DEVICE_ATI_RADEON_MOBILITY_M62: + case DEVICE_ATI_RADEON_MOBILITY_M63: + case DEVICE_ATI_RADEON_MOBILITY_M64: + rage_ckey_model=1; + is_shift_required=1; + break; + case DEVICE_ATI_RADEON_QD: + case DEVICE_ATI_RADEON_QE: + case DEVICE_ATI_RADEON_QF: + case DEVICE_ATI_RADEON_QG: + case DEVICE_ATI_RADEON_VE_QY: + case DEVICE_ATI_RADEON_VE_QZ: + is_shift_required=1; + break; + default: break; + } + if(__verbose > 1) radeon_vid_dump_regs(); return 0; } @@ -1677,8 +1701,16 @@ besr.graphics_key_msk=(1<<dbpp)-1; besr.ckey_cntl = VIDEO_KEY_FN_TRUE|GRAPHIC_KEY_FN_NE|CMP_MIX_AND; #else + if(rage_ckey_model) + { + besr.graphics_key_msk=besr.graphics_key_clr; + besr.ckey_cntl = VIDEO_KEY_FN_TRUE|GRAPHIC_KEY_FN_NE|CMP_MIX_AND; + } + else + { besr.graphics_key_msk=besr.graphics_key_clr; besr.ckey_cntl = VIDEO_KEY_FN_TRUE|GRAPHIC_KEY_FN_EQ|CMP_MIX_AND; + } #endif } else

1 0

None
by None 10 Sep '25

10 Sep '25

no special handling for the combination of menu and pause. Could someone please explain, how it was originally thought or could we come to an uniform position how it should be, so it's possible to fix it. Andreas

1 0

None
by None 10 Sep '25

10 Sep '25

So I figured -r would be a good choice. :-) > Why not simply use GNU install? Could be an option. But to bring down the "dependencies" and just let it run on standard IRIX software it would be nice to keep using the OS applied install. > Yes, you sound like the perfect person to provide a patch :-) I'll give it a shot. :-) Don't yell at me if I fuckup the first time :-p Steffen

1 0

None
by None 10 Sep '25

10 Sep '25

The GNU ranlib program is another form of GNU ar; running ranlib is completely equivalent to executing ar -s. Does ar -s work for you? Then we might switch to this more portable form.. > cp etc/codecs.conf . > cp DOCS/mplayer.1 . > > Then I edited the Makefile and modified these lines: > > $(INSTALL) -c -m DOCS/mplayer.1 $(MANDIR)/man1/mplayer.1 > changed to > $(INSTALL) -m mplayer.1 $(MANDIR)/man1/ > > $(INSTALL) -c -m etc/codecs.conf $(CONFDIR)/codecs.conf > changed to > $(INSTALL) -m codecs.conf $(CONFDIR)/ > > This should be done because the "install" program on IRIX gives a weird "file > not found" error when specifying a destination file instead of a destination > dir. (Well, no, obviously, you didn't install the file yet, so ofcourse it > isn't there yet! Duh.) > And when doing the install with specifying the destination dir, it will also > create the subdirs where the original file is located in (so there would be a > $(MANDIR)/man1/DOCS/mplayer.1 instead of the required > $(MANDIR)/man1/mplayer.1) Why not simply use GNU install? > Things to note about mplayer on IRIX: > - Video output on x11 seems to be not supported. The error "RGB32 not > supported on big-endian systems, please contact the developers. FATAL: Cannot > initialize video driver!" is shown > - Only video outputs on the screen that are left then are gl and gl2 (OpenGL > outputs) which are extremely slow. > - Audio output using "-ao sgi": everything initialises fine. "Start > playing..." appears. Then immediately *crash* with error: "MPlayer > interrupted by signal 11 in module: decode_audio. (the other available -ao > option "mpegpes" gives error "couldn't open/init audio device -> no sound" > > Overall not realy that useful yet, but hey, atleast it compiled :-))) > > Maybe worth to put the hints on building it, in the documentation. Yes, you sound like the perfect person to provide a patch :-) Diego

1 0

None
by None 10 Sep '25

10 Sep '25

ANSI C requires that a file positioning function intervene between output and input, unless an input operation encounters end-of-file. Here's a patch which fix xvid 2 passes encoding, which was broken at least on FreeBSD : --- xvid_vbr.c 18 Sep 2002 01:32:32 -0000 1.2 +++ xvid_vbr.c 2 Nov 2002 11:13:03 -0000 @@ -593,6 +593,7 @@ { int c, i; + long pos; vbr_control_t *state = sstate; if(state->pass1_file == NULL) @@ -601,7 +602,7 @@ /* Goto to the file beginning */ fseek(state->pass1_file, 0, SEEK_SET); - /* Skip the version line and the empty line */ + /* Skip the version line and the empty line */ c = i = 0; do { c = fgetc(state->pass1_file); @@ -610,6 +611,8 @@ if(c == '\n') i++; }while(i < 2); + pos = ftell( state->pass1_file ); + fseek( state->pass1_file, pos, SEEK_SET ); /* Overwrite the frame field - safe as we have written extra spaces */ fprintf(state->pass1_file, "# frames : %.10d\n", state->nb_frames); -- Rémi

1 0

None
by None 10 Sep '25

10 Sep '25

that to keep MPlayer growing in it's current speed (is that desirable?) one needs either enforce more strict release control or split the project into smaller parts. If that isn't done the quality of the releases will decrease, which will lead to less users and thereby less bug reports and patches. This will in turn lead to slower developement cause the developers will have to find the bugs them selfs. Personally I would be very happy if the project was split in small parts the following way: 1. Throw out the GUI. 2. Remove all commandline parameters except --help, --version and --debug-level. 3. Write a unified hirarcic control and configuration library. 4. Throw out the playlist and runtime control (i.e lirc, mouse and keyboard) and control the player kernel through a socket or shared ram using the config language described above. 5. Use an external program for reading and writing the config file and send the config parameters to the player kernel according to 4. (alsa does this, very nice). But who am I to say (i.e. sorry for pissing everyone off :). > > Rich > //Anders

1 0

None
by None 10 Sep '25

10 Sep '25

* WARNING! WARNING! * This is an OSS (Linux) audio emulator. > > Those lines seems to have ben patched in to make oss work on OpenBSD; see > > http://mplayerhq.hu/pipermail/mplayer-dev-eng/2002-April/007335.html > > i can't see the relation > that patch added #ifdef SOUNDCARD_H, and it was ok. It seems to me as if the purpose of it was to get oss_audio to work, but i can be wrong. > but i can't see why should we check for OSSAUDIO, when the availablity of > soundcard.h is already checked? > and even if OSS support is disabled, we can sue the soundcard.h for defining > the standard AFMT constants. Well, on OpenBSD you shouldn't (besides, all constants except AFMT_QUERY are defined in afmt.h) > does this patch fixes any compilation error? i can't imagine, but possible. > or was it just cosmetics? It won't compile (or rather link) if --disable-ossaudio is used. I could fix it in configure (by undefing HAVE_SOUNDCARD_H if --disable-ossaudio is specified) if you prefer that. -- Björn Sandell DCE/DFS Sysadmin IT department Chalmers University of Technology www.dce.chalmers.se

1 0