From alex at fsn.hu  Sun Feb  1 00:44:44 2004
From: alex at fsn.hu (Alex Beregszaszi)
Date: Sun, 1 Feb 2004 00:44:44 +0100
Subject: [MPlayer-G2-dev] MID/VP
Message-ID: <20040201004444.0e6968d4@caprice.artificis.hu>

Hi,

what's the status of the above?

-- 
Alex Beregszaszi <alex at fsn.hu>
(MPlayer Core Developer -- http://www.mplayerhq.hu/)



From dalias at aerifal.cx  Sun Feb  1 01:01:45 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Sat, 31 Jan 2004 19:01:45 -0500
Subject: [MPlayer-G2-dev] Codec identifier (fourcc) handling proposal
In-Reply-To: <20040131222138.F3E72934@mail.mplayerhq.hu>
References: <20040131235933.7719c1f4@caprice.artificis.hu>
	<20040131222138.F3E72934@mail.mplayerhq.hu>
Message-ID: <20040201000145.GT257@brightrain.aerifal.cx>

On Sat, Jan 31, 2004 at 11:21:38PM +0100, Arpi wrote:
> Hi,
> 
> > There's a need for defining the way we're handling codec identifiers, in
> > G1 this wasn't such a big issue, as MEncoder could only handle AVI well.
> > 
> > 1, input layer - demuxer
> > 2, core
> > 3, output layer - muxer
> > 
> > Imho in core we should deal with fourcc's (four character codes) only,
> > both for audio and video. Maybe we should define better names for audio
> > codecs. You know that AVI uses twocc for audio, but others (real, qt)
> > uses fourcc for that too and nut is going to handle this situation well.
> > 
> > The input layer should wrap the known identifiers to fourccs known by
> > the core.
> 
> the second parameter to fourcc/format 'commands' of codecs.conf is for this
> maybe we should merge fourcc and format, to fourcc, and stuff in ' ' or
> " " would be always fourcc ("1234"), numbers (0x1234 or 1234) are formats,
> and the rest is fourcc too. this could be done for g1 too.

IMO most of codecs.conf is obsolete...

Rich



From dalias at aerifal.cx  Sun Feb  1 01:08:17 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Sat, 31 Jan 2004 19:08:17 -0500
Subject: [MPlayer-G2-dev] MID/VP
In-Reply-To: <20040201004444.0e6968d4@caprice.artificis.hu>
References: <20040201004444.0e6968d4@caprice.artificis.hu>
Message-ID: <20040201000817.GU257@brightrain.aerifal.cx>

On Sun, Feb 01, 2004 at 12:44:44AM +0100, Alex Beregszaszi wrote:
> Hi,
> 
> what's the status of the above?

MID: It's in VP, but renamed because "MID" isn't at all intuitive. To
me (and probably most callers) it suggests MIDI... :) For now I'm just
calling it fmtdesc.

Also, for now all the fmtdesc structures are local to one .c file, and
you obtain them via a lookup function using the fourcc. I did this to
avoid symbol pollution, but IMO it's inefficient and dumb. I'd
recommend instead exporting symbols like mplayer_fmtdesc_YV12 and then
having a .h file to #define IMGFMT_YV12 mplayer_fmtdesc_YV12 or
something similar.

VP: Same state it's been in for a while. The only _critical_ thing
missing is negotiating the image parameters for communication between
filters. It also needs some setup code and whatnot for the caller to
build the filterchain, but that's not a big deal. Slices are in place,
but I'm not sure the current slice system is actually very good.

Regarding VP, I'd _really_ appreciate it if the other devs would read
the past few threads about it and comment on some of my big questions
& concerns!

Rich



From syncmail at mplayerhq.hu  Sun Feb  1 01:04:53 2004
From: syncmail at mplayerhq.hu (Attila Kinali CVS)
Date: Sun,  1 Feb 2004 01:04:53 +0100 (CET)
Subject: [MPlayer-G2-dev] CVS: g2/DOCS cfg.txt,1.1.1.1,1.2
Message-ID: <20040201000453.4C6448DE@mail.mplayerhq.hu>

CVS change done by Attila Kinali CVS

Update of /cvsroot/mplayer/g2/DOCS
In directory mail:/var2/tmp/cvs-serv14051

Modified Files:
	cfg.txt 
Log Message:
fix the dynamic bug ;)
partial update


Index: cfg.txt
===================================================================
RCS file: /cvsroot/mplayer/g2/DOCS/cfg.txt,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- cfg.txt	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ cfg.txt	1 Feb 2004 00:04:50 -0000	1.2
@@ -16,6 +16,7 @@
   char *maintainer;
   char *author;
   char *comment;
+  unsigned int flags; // low 16 bits: generic flags  high 16: type dependent
   config_t *config;
   config_data_t *config_defaults;
   int  config_size;
@@ -31,9 +32,9 @@
   config_data_t *config_defaults;
   int  config_size;
 
-In g2, modules may have their own dinamically allocated config data structure.
+In g2, modules may have their own dynamically allocated config data structure.
 It means: no more globals! yeah. Of course globals can be used, too.
-The implementation of per-module dinamic config is the following:
+The implementation of per-module dynamic config is the following:
 A module (be it core layer or a plugin) will define its own config_data_t
 structure, containing its configuration variables. It can (optinally)
 define a set of default values, in the layout of config_data_t.
@@ -67,17 +68,18 @@
     "A'rpi",
     "Michael Niedermayer",
     "uses libswscale.a",
+    0,
     config_format, &config_defaults, sizeof(struct config_data_s)
 };
 
 What if I leave/ignore some of these fields?
-- if config_size>0 then config_data will be dinamically allocated,
+- if config_size>0 then config_data will be dynamically allocated,
   otherwise all options (in config_t array) are handled as globals,
   with absolute pointers.
 - if config_defaults!=NULL, then config_data will be cloned from it,
   instead of allocating zero-filled memory.
   option pointers targetting inside the config_defaults struct will be
-  handled as dinamic variables (relocated to cloned config_data), others
+  handled as dynamic variables (relocated to cloned config_data), others
   will be handled as globals.
 - if config_defaults==NULL and config_size>0, then pointers will be handled
   as struct offsets relative to the start of config_data_s structure.



From attila at kinali.ch  Sun Feb  1 01:07:07 2004
From: attila at kinali.ch (Attila Kinali)
Date: Sun, 1 Feb 2004 01:07:07 +0100
Subject: [MPlayer-G2-dev] CVS: g2/DOCS cfg.txt,1.1.1.1,1.2
In-Reply-To: <20040201000453.4C6448DE@mail.mplayerhq.hu>
References: <20040201000453.4C6448DE@mail.mplayerhq.hu>
Message-ID: <20040201010707.581bb82b.attila@kinali.ch>

On Sun,  1 Feb 2004 01:04:53 +0100 (CET)
syncmail at mplayerhq.hu (Attila Kinali CVS) wrote:

> Modified Files:
> 	cfg.txt 
> Log Message:
> fix the dynamic bug ;)
> partial update

Someone should review cfg.txt and update it.

			Attila Kinali
-- 
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
			-- reeler in +kaosu



From syncmail at mplayerhq.hu  Sun Feb  1 10:08:13 2004
From: syncmail at mplayerhq.hu (Sascha Sommer CVS)
Date: Sun,  1 Feb 2004 10:08:13 +0100 (CET)
Subject: [MPlayer-G2-dev] CVS: g2/libao2 ao_win32.c,1.1.1.1,1.2
Message-ID: <20040201090813.59F56A42@mail.mplayerhq.hu>

CVS change done by Sascha Sommer CVS

Update of /cvsroot/mplayer/g2/libao2
In directory mail:/var2/tmp/cvs-serv25789/libao2

Modified Files:
	ao_win32.c 
Log Message:
sync to g1 and make it compile again

Index: ao_win32.c
===================================================================
RCS file: /cvsroot/mplayer/g2/libao2/ao_win32.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- ao_win32.c	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ ao_win32.c	1 Feb 2004 09:08:10 -0000	1.2
@@ -1,6 +1,6 @@
 /******************************************************************************
  * ao_win32.c: Windows waveOut interface for MPlayer
- * Copyright (c) 2002 Sascha Sommer <saschasommer at freenet.de>.
+ * Copyright (c) 2002 - 2004 Sascha Sommer <saschasommer at freenet.de>.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -27,7 +27,7 @@
 #include "audio_out.h"
 #include "audio_out_internal.h"
 #include "../mp_msg.h"
-#include "../fastmemcpy.h"
+#include "../osdep/fastmemcpy.h"
 
 #define SAMPLESIZE   1024
 #define BUFFER_SIZE  4096
@@ -134,7 +134,7 @@
         ao_data.channels = wformat.nChannels = 2;
 	    ao_data.samplerate = wformat.nSamplesPerSec = 44100;
 	    ao_data.format = AFMT_S16_LE;
-	    ao_data.bps=ao_data.channels * ao_data.samplerate;
+	    ao_data.bps=ao_data.channels * ao_data.samplerate * 2;
 	    ao_data.buffersize=wformat.wBitsPerSample=16;
         wformat.nBlockAlign     = wformat.nChannels * (wformat.wBitsPerSample >> 3);
         wformat.nAvgBytesPerSec = wformat.nSamplesPerSec * wformat.nBlockAlign;



From syncmail at mplayerhq.hu  Sun Feb  1 10:13:11 2004
From: syncmail at mplayerhq.hu (Sascha Sommer CVS)
Date: Sun,  1 Feb 2004 10:13:11 +0100 (CET)
Subject: [MPlayer-G2-dev] CVS: g2/video/libmpeg2 Makefile,NONE,1.1
Message-ID: <20040201091311.D1105A52@mail.mplayerhq.hu>

CVS change done by Sascha Sommer CVS

Update of /cvsroot/mplayer/g2/video/libmpeg2
In directory mail:/var2/tmp/cvs-serv5856/video/libmpeg2

Added Files:
	Makefile 
Log Message:
add forgotten file

--- NEW FILE ---

LIBNAME = libmpeg2.a

include ../../config.mak

SRCS	= alloc.c cpu_accel.c cpu_state.c decode.c header.c idct.c idct_alpha.c idct_altivec.c idct_mlib.c idct_mmx.c motion_comp.c motion_comp_alpha.c motion_comp_altivec.c motion_comp_mlib.c motion_comp_mmx.c slice.c

OBJS	= $(SRCS:.c=.o)
INCLUDE = -I. -I../.. $(EXTRA_INC) $(MLIB_INC)
CFLAGS  = $(OPTFLAGS) $(INCLUDE)

.SUFFIXES: .c .o

# .PHONY: all clean

.c.o:
	$(CC) -c $(CFLAGS) -o $@ $<

$(LIBNAME):	$(OBJS)
	$(AR) sr $(LIBNAME) $(OBJS)

all:	$(LIBNAME)

clean:
	rm -f *.o *.a *~

distclean:
	rm -f Makefile.bak *.o *.a *~ .depend

dep:    depend

depend:
	$(CC) -MM $(CFLAGS) $(SRCS) 1>.depend

#
# include dependency files if they exist
#
ifneq ($(wildcard .depend),)
include .depend
endif



From raindel at techunix.technion.ac.il  Sun Feb  1 11:31:57 2004
From: raindel at techunix.technion.ac.il (Raindel Shachar)
Date: Sun, 1 Feb 2004 12:31:57 +0200 (IST)
Subject: [MPlayer-G2-dev] [PATCH][BUG-FIX] Prevent seeking to negative times
Message-ID: <Pine.GSO.4.44_heb2.09.0402011228540.3063-100000@techunix.technion.ac.il>

Hi,
  The attached patch prevents the demuxer from trying to seek to negative
offsets, or after the end of the file.

   Cheers,
   Shachar

BTW: G2 rocks - it uses only 10% CPU on my computer playing 2.5Mbps MPEG 2
video. It is the lowest CPU usage I have ever seen for playing back
these video clips.....



From raindel at techunix.technion.ac.il  Sun Feb  1 11:33:41 2004
From: raindel at techunix.technion.ac.il (Raindel Shachar)
Date: Sun, 1 Feb 2004 12:33:41 +0200 (IST)
Subject: [MPlayer-G2-dev] Re: [PATCH][BUG-FIX] Prevent seeking to negative
	times 
In-Reply-To: <Pine.GSO.4.44_heb2.09.0402011228540.3063-100000@techunix.technion.ac.il>
Message-ID: <Pine.GSO.4.44_heb2.09.0402011232400.3063-200000@techunix.technion.ac.il>

Ooops, Forgot the attachment....

On Sun, 1 Feb 2004, Raindel Shachar wrote:

> Hi,
> The attached patch prevents the demuxer from trying to seek to negative
> offsets, or after the end of the file.
>
>  Cheers,
>  Shachar
>
> BTW: G2 rocks - it uses only 10% CPU on my computer playing 2.5Mbps MPEG 2
> video. It is the lowest CPU usage I have ever seen for playing back
> these video clips.....
>
>
-------------- next part --------------
Index: demux/demuxer.c
===================================================================
RCS file: /cvsroot/mplayer/g2/demux/demuxer.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 demuxer.c
--- demux/demuxer.c	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ demux/demuxer.c	1 Feb 2004 10:16:14 -0000
@@ -483,6 +483,8 @@
 	    off_t newpos=(mode&1)?demuxer->movi_start:demuxer->filepos;
 	    if(mode&2){
 		// float seek 0..1
+	      if(pos>1) pos = 1;
+	      if(pos<0) pos = 0;
 		newpos+=(demuxer->movi_end-demuxer->movi_start)*pos;
 	    } else {
 		// time seek (secs)
@@ -492,7 +494,11 @@
 			if(demuxer->streams[i]->bitrate>0)
 			    br+=demuxer->streams[i]->bitrate;
 		br/=8; if(!br) br=800000/8; // 800 kbit
-        	newpos+=br*pos;
+		if(newpos<-br*pos) {
+		  newpos = 0;
+		}else {
+		  newpos+=br*pos;
+		}
 	    }
 	    stream_seek(demuxer->stream,newpos);
 	    ret=1;

From diego at biurrun.de  Sun Feb  1 11:34:11 2004
From: diego at biurrun.de (Diego Biurrun)
Date: Sun, 1 Feb 2004 07:34:11 -0300
Subject: [MPlayer-G2-dev] [PATCH][BUG-FIX] Prevent seeking to negative
	times
In-Reply-To: <Pine.GSO.4.44_heb2.09.0402011228540.3063-100000@techunix.technion.ac.il>
References: <Pine.GSO.4.44_heb2.09.0402011228540.3063-100000@techunix.technion.ac.il>
Message-ID: <16412.54819.444235.69255@biurrun.de>

Raindel Shachar writes:
 > BTW: G2 rocks - it uses only 10% CPU on my computer playing 2.5Mbps MPEG 2
 > video. It is the lowest CPU usage I have ever seen for playing back
 > these video clips.....

You know what, patches also rock ;-)

Diego



From raindel at techunix.technion.ac.il  Sun Feb  1 11:35:45 2004
From: raindel at techunix.technion.ac.il (Raindel Shachar)
Date: Sun, 1 Feb 2004 12:35:45 +0200 (IST)
Subject: [MPlayer-G2-dev] [PATCH] Select realtime scheduler
Message-ID: <Pine.GSO.4.44_heb2.09.0402011233580.3063-200000@techunix.technion.ac.il>

Hi,
  I attach a patch that allows mplayer to ask for realtime scheduler, so
that it will get it's CPU slice whenever it need it, preventing sleep
overruns.
     Cheers,
     Shachar
-------------- next part --------------
Index: configure.g1
===================================================================
RCS file: /cvsroot/mplayer/g2/configure.g1,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 configure.g1
--- configure.g1	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ configure.g1	1 Feb 2004 10:16:10 -0000
@@ -262,6 +262,7 @@
   --enable-sse2          build with sse2 support [autodetect]
   --disable-fastmemcpy   disable 3dnow/sse/mmx optimized memcpy() [enable]
   --disable-big-endian   Force byte order to little endian [autodetect]
+  --enable-realtime      enable realtime scheduling setting in mplayer [autodetected]
   --enable-big-endian    Force byte order to big endian [autodetect]
   --enable-debug[=1-3]   compile debugging information into mplayer [disable]
   --enable-profile       compile profiling information into mplayer [disable]
@@ -1101,6 +1102,7 @@
 _fribidiconfig='fribidi-config'
 _inet6=auto
 _gethostbyname2=auto
+_realtime=auto
 for ac_option do
   case "$ac_option" in
   # Skip 1st pass
@@ -1294,6 +1296,9 @@
   --enable-fribidi)     _fribidi=yes    ;;
   --disable-fribidi)    _fribidi=no     ;;
 
+  --enable-realtime)    _realtime=yes   ;;
+  --disable-realtime)   _realtime=no    ;;
+
   --enable-inet6)	_inet6=yes	;;
   --disable-inet6)	_inet6=no	;;
 
@@ -2065,6 +2070,32 @@
 echores "yes (using $_ld_pthread)"
 
 
+echocheck "realtime scheduler"
+if test "$_realtime" = no; then
+  _def_realtime='#undef HAVE_REALTIME'
+  echores "no"
+else
+  if linux ; then
+    cat > $TMPC << EOF
+#include <sched.h>
+int main(void) { struct sched_param sparam; 
+sparam.sched_priority = sched_get_priority_max(SCHED_RR); 
+sched_setscheduler(0, SCHED_RR, &sparam);
+return 0; }
+EOF
+    if cc_check || test "$_realtime" = yes && test "$_realtime" != no ; then
+      _def_realtime='#define HAVE_REALTIME 1'
+      echores "yes (with linux sched_setscheduler)"
+    else
+      _def_realtime='#undef HAVE_REALTIME'
+      echores "no"
+    fi
+  else
+    _def_realtime='#undef HAVE_REALTIME'
+    echores "no (not implemented for this OS)"
+  fi
+fi
+
 echocheck "sys/soundcard.h"
 cat > $TMPC << EOF
 #include <sys/soundcard.h>
@@ -5870,6 +5901,8 @@
 $_def_vesa
 $_def_xdpms
 $_def_aa
+/* Enables realtime scheduler setting */
+$_def_realtime
 
 /* used by GUI: */
 $_def_xshape
Index: test-play.c
===================================================================
RCS file: /cvsroot/mplayer/g2/test-play.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 test-play.c
--- test-play.c	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ test-play.c	1 Feb 2004 10:16:12 -0000
@@ -36,6 +36,8 @@
 
 static int autosync=30;
 
+static int realtime=0;
+
 // -vc/-vfm/-ac/-afm:
 static char** a_codec_name_list=NULL;
 static char** a_codec_fm_list=NULL;
@@ -63,6 +65,10 @@
 extern int divx_quality;
 
 static config_t main_config[]={
+
+	{"realtime", &realtime, CONF_TYPE_FLAG, 0, 0, 1, NULL, "Try to get realtime scheduler"},
+
+
 	{"dumpstream", &dumpstream, CONF_TYPE_FLAG, 0, 0, 1, NULL, "dump raw stream"},
 	{"sub",&sub_filename, CONF_TYPE_STRING, 0, 0, 0, NULL, "external subtitles stream"},
 	{"subdemuxer",&sub_demuxer_name, CONF_TYPE_STRING, 0, 0, 0, NULL, "force external subtitles demuxer"},
@@ -200,6 +206,14 @@
     }
   }
 
+  // INIT Realtime priority (if supported)
+#ifdef HAVE_REALTIME
+  if(realtime) {
+    mp_msg(MSGT_CPLAYER,MSGL_INFO,"Trying to set realtime priority...\n");
+    set_realtime();
+  }
+#endif  
+
 //INIT stream  
   stream=open_stream(filename);
   if(!stream){
Index: osdep/Makefile
===================================================================
RCS file: /cvsroot/mplayer/g2/osdep/Makefile,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile
--- osdep/Makefile	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ osdep/Makefile	1 Feb 2004 10:16:18 -0000
@@ -7,6 +7,7 @@
 
 getch = getch2.c
 timer = timer-lx.c
+realtime = realtime-lx.c
 ifeq ($(MACOSX),yes)
 timer = timer-macosx.c
 endif
@@ -22,7 +23,8 @@
 endif
 SRCS += $(timer)
 SRCS += $(getch)
+SRCS += $(realtime)
 
 OBJS=$(SRCS:.c=.o)
 
--- /dev/null   2003-01-30 12:24:37.000000000 +0200
+++ osdep/realtime-lx.c 2004-01-31 23:40:20.000000000 +0200
@@ -0,1 +1,13 @@
+#include "../config.h"
+
+#ifdef HAVE_REALTIME
+#include <sched.h>
+
+void set_realtime(void)
+{
+  struct sched_param sparam;
+  sparam.sched_priority = sched_get_priority_max(SCHED_RR);
+  sched_setscheduler(0, SCHED_FIFO, &sparam);
+}
+#endif
--- /dev/null   2003-01-30 12:24:37.000000000 +0200
+++ osdep/realtime.h    2004-01-31 23:40:25.000000000 +0200
@@ -0,0 +1,6 @@
+#ifndef REALTIME_H_
+#define REALTIME_H_ 1
+
+extern void set_realtime(void);
+
+#endif

From syncmail at mplayerhq.hu  Tue Feb  3 00:36:23 2004
From: syncmail at mplayerhq.hu (Diego Biurrun CVS)
Date: Tue,  3 Feb 2004 00:36:23 +0100 (CET)
Subject: [MPlayer-G2-dev] CVS: g2/DOCS cfg.txt,1.2,1.3
Message-ID: <20040202233623.CA8752C533@mail.mplayerhq.hu>

CVS change done by Diego Biurrun CVS

Update of /cvsroot/mplayer/g2/DOCS
In directory mail:/var2/tmp/cvs-serv15966

Modified Files:
	cfg.txt 
Log Message:
spelling cosmetics


Index: cfg.txt
===================================================================
RCS file: /cvsroot/mplayer/g2/DOCS/cfg.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- cfg.txt	1 Feb 2004 00:04:50 -0000	1.2
+++ cfg.txt	2 Feb 2004 23:36:21 -0000	1.3
@@ -12,7 +12,7 @@
   unsigned short type, version; // for loadable plugins
   void *entry; // pointer to module entry point (xxx_open() or xxx_functions_t*)
   char *name;
-  char *desc; // short description for commandline help and gui
+  char *desc; // short description for command line help and GUI
   char *maintainer;
   char *author;
   char *comment;
@@ -24,7 +24,7 @@
 
 Yes, it looks like the *_info_t of g1's plugins. No wonder, it is that.
 The difference is that in g2 not only actual plugins have such description,
-but core layers (like libdemux etc) and even the main application too.
+but core layers (like libdemux etc) and even the main application, too.
 Config handler and parser functions receive info in this module_info_t struct.
 
 So, look at this struct a bit closer:
@@ -33,13 +33,13 @@
   int  config_size;
 
 In g2, modules may have their own dynamically allocated config data structure.
-It means: no more globals! yeah. Of course globals can be used, too.
+It means: no more globals! Yeah. Of course globals can be used, too.
 The implementation of per-module dynamic config is the following:
 A module (be it core layer or a plugin) will define its own config_data_t
-structure, containing its configuration variables. It can (optinally)
+structure, containing its configuration variables. It can (optionally)
 define a set of default values, in the layout of config_data_t.
 Then it will define a config_t array, describing each option, with pointers
-into the config_data_t struct. It's a bit tricky: if you have config_defaults,
+into the config_data_t struct. It's a bit tricky: If you have config_defaults,
 your pointers should point into that. If you don't have defaults, your pointers
 will be struct offsets (NULL-based pointers).
 
@@ -73,24 +73,24 @@
 };
 
 What if I leave/ignore some of these fields?
-- if config_size>0 then config_data will be dynamically allocated,
+- If config_size>0 then config_data will be dynamically allocated,
   otherwise all options (in config_t array) are handled as globals,
   with absolute pointers.
-- if config_defaults!=NULL, then config_data will be cloned from it,
+- If config_defaults!=NULL, then config_data will be cloned from it,
   instead of allocating zero-filled memory.
-  option pointers targetting inside the config_defaults struct will be
+  Option pointers targetting inside the config_defaults struct will be
   handled as dynamic variables (relocated to cloned config_data), others
   will be handled as globals.
-- if config_defaults==NULL and config_size>0, then pointers will be handled
+- If config_defaults==NULL and config_size>0, then pointers will be handled
   as struct offsets relative to the start of config_data_s structure.
-  In this case you should use macros like ST_OFF() (from mplayer g1) or
+  In this case you should use macros like ST_OFF() (from MPlayer g1) or
   do it by hand:  &( ((struct config_data_s*)NULL)->field )
 
 Config layers:
 ~~~~~~~~~~~~~~
-The new config code is layered by functionality and dependancy:
+The new config code is layered by functionality and dependency:
 
-layer #0 is actually cfg.h and a small cfg-l0.c containing helper functions
+Layer #0 is actually cfg.h and a small cfg-l0.c containing helper functions
 to work with the cfg.h structs.
 It includes 2 functions:
 
@@ -103,17 +103,12 @@
 the module's defaults) or the user-supplied base (config_data_t* def).
 The later can be used for configtree/playtree implementation, when a given
 module inherits non-default config from a previous layer. 'def' may be NULL!
-Normally this function should be called only once (per url/file) by the app
+Normally this function should be called only once (per URL/file) by the app
 for only the top level module, assuming it has references (CONF_TYPE_MODULE
 or _MODLIST) to all other modules.
 
-layer #1 is the place for the string<->conf_type parsers/converters.
+Layer #1 is the place for the string<->conf_type parsers/converters.
 Currently it includes functions for string->conf_type conversion (parsing),
-an complete option parsing handler (including option serach and
+a complete option parsing handler (including option search and
 CONF_TYPE_MODULE recursion), and a subconfig-compatible syntax parser
 (already used for CONF_TYPE_MODLIST).
-
-
-
-
-



From ivan at cacad.com  Wed Feb  4 01:42:04 2004
From: ivan at cacad.com (Ivan Kalvachev)
Date: Wed, 4 Feb 2004 02:42:04 +0200 (EET)
Subject: [MPlayer-G2-dev] impostor yv12
Message-ID: <1085.213.16.61.174.1075855324.squirrel@mail.cacad.com>

Hello,
I had send few patches and few mails to xvid people
regarding their handling of YV12 format.
In short they claimed that it is reversed and they swaped the UV
planes. I had tracked a bug in DSHOW and VfW handling of
IYUV - they had mapped it to yv12, while IYUV is the same as I420.
Few weaks ago I checked the image.c routines and noticed that
the thing are unchanged, but later i found out that the VfW/DShow issues
have been sorted.

So,
In short the YV12 format is not the format that mplayer claims it is.
YV12 is in fact YVU / YCrCb /, that is in no way the default MPEG standart
color format. As you know in MPEG 0,1,2,3 blocks are Y, Cb is #4 block, Cr
is #5 block.
Yes, I know that all code over mplayer-g1 use IMGFMT_YV12 as YUV, but in
fact this format is the I420 or IYUV format. The real conversion is done
at vo_xv (in draw_slice around line 488). Same for vo_directx and probably
all that support planar formats. I should say that now I see the reason
mplayer to have always U as plane[1] and V as plane[2].

Well, I don't want to change all IMGFMT_YV12 to I420, or to IMGFMT_YUV,
as it is a too global change. But we should make G2 in the right way.
Of cource if it is not already done.

Best Regards
   Ivan Kalvachev
  iive



From arpi at thot.banki.hu  Wed Feb  4 02:44:18 2004
From: arpi at thot.banki.hu (Arpi)
Date: Wed,  4 Feb 2004 02:44:18 +0100 (CET)
Subject: [MPlayer-G2-dev] impostor yv12
In-Reply-To: <1085.213.16.61.174.1075855324.squirrel@mail.cacad.com>
Message-ID: <20040204014418.282582CDB0@mail.mplayerhq.hu>

Hi,

> In short the YV12 format is not the format that mplayer claims it is.
> YV12 is in fact YVU / YCrCb /, that is in no way the default MPEG standart
> color format. As you know in MPEG 0,1,2,3 blocks are Y, Cb is #4 block, Cr
> is #5 block.
> Yes, I know that all code over mplayer-g1 use IMGFMT_YV12 as YUV, but in
> fact this format is the I420 or IYUV format. The real conversion is done

probably time for you to read docs/tech/colorspaces.txt

YV12 is really Y, V, U plane order in memory, _if_ you have aligned planes.
although mplayer handles EVERY planar yuv formats (be it yv12, i420, iyuv,
y422, yvu9 etc) as array[3] of planes, where 0=Y 1=U 2=V always!

if you have 3 pointers, it doesnt matter if you call it yv12 or iyuv, it's
still planar yuv and planes[1] is always points to U plane wherever it is.
it only does matter, when you have single pointer only, and u+v are
calculated internally (in codec dll, for example) from the y pointer by
adding w*h and w*h*5/4 (this is the case with vfw/dshow, which uses single
pointer)

> at vo_xv (in draw_slice around line 488). Same for vo_directx and probably
> all that support planar formats. I should say that now I see the reason
> mplayer to have always U as plane[1] and V as plane[2].
> 
> Well, I don't want to change all IMGFMT_YV12 to I420, or to IMGFMT_YUV,

huh?
i cant see why do you want/need to change it.

> as it is a too global change. But we should make G2 in the right way.

???


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu



From dalias at aerifal.cx  Wed Feb  4 16:45:35 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Wed, 4 Feb 2004 10:45:35 -0500
Subject: [MPlayer-G2-dev] impostor yv12
In-Reply-To: <1085.213.16.61.174.1075855324.squirrel@mail.cacad.com>
References: <1085.213.16.61.174.1075855324.squirrel@mail.cacad.com>
Message-ID: <20040204154535.GU257@brightrain.aerifal.cx>

On Wed, Feb 04, 2004 at 02:42:04AM +0200, Ivan Kalvachev wrote:
> Hello,
> I had send few patches and few mails to xvid people
> regarding their handling of YV12 format.
> In short they claimed that it is reversed and they swaped the UV
> planes. I had tracked a bug in DSHOW and VfW handling of
> IYUV - they had mapped it to yv12, while IYUV is the same as I420.
> Few weaks ago I checked the image.c routines and noticed that
> the thing are unchanged, but later i found out that the VfW/DShow issues
> have been sorted.
> 
> So,
> In short the YV12 format is not the format that mplayer claims it is.
> YV12 is in fact YVU / YCrCb /, that is in no way the default MPEG standart
> color format. As you know in MPEG 0,1,2,3 blocks are Y, Cb is #4 block, Cr
> is #5 block.
> Yes, I know that all code over mplayer-g1 use IMGFMT_YV12 as YUV, but in
> fact this format is the I420 or IYUV format. The real conversion is done
> at vo_xv (in draw_slice around line 488). Same for vo_directx and probably
> all that support planar formats. I should say that now I see the reason
> mplayer to have always U as plane[1] and V as plane[2].
> 
> Well, I don't want to change all IMGFMT_YV12 to I420, or to IMGFMT_YUV,
> as it is a too global change. But we should make G2 in the right way.
> Of cource if it is not already done.

RTFM, this is all nonsense. MPlayer does not care about plane order,
except when allocating or exporting buffers for crappy external
codecs/filters/vo's that care.

Rich



From ivan at cacad.com  Thu Feb  5 00:21:29 2004
From: ivan at cacad.com (Ivan Kalvachev)
Date: Thu, 5 Feb 2004 01:21:29 +0200 (EET)
Subject: [MPlayer-G2-dev] impostor yv12
In-Reply-To: <20040204154535.GU257@brightrain.aerifal.cx>
References: <1085.213.16.61.174.1075855324.squirrel@mail.cacad.com>
	<20040204154535.GU257@brightrain.aerifal.cx>
Message-ID: <1116.213.16.61.120.1075936889.squirrel@mail.cacad.com>

D Richard Felker III said:
> On Wed, Feb 04, 2004 at 02:42:04AM +0200, Ivan Kalvachev wrote:
>> Hello,
>> I had send few patches and few mails to xvid people
>> regarding their handling of YV12 format.
>> In short they claimed that it is reversed and they swaped the UV
>> planes. I had tracked a bug in DSHOW and VfW handling of
>> IYUV - they had mapped it to yv12, while IYUV is the same as I420.
>> Few weaks ago I checked the image.c routines and noticed that
>> the thing are unchanged, but later i found out that the VfW/DShow issues
>> have been sorted.
>>
>> So,
>> In short the YV12 format is not the format that mplayer claims it is.
>> YV12 is in fact YVU / YCrCb /, that is in no way the default MPEG
>> standart
>> color format. As you know in MPEG 0,1,2,3 blocks are Y, Cb is #4 block,
>> Cr
>> is #5 block.
>> Yes, I know that all code over mplayer-g1 use IMGFMT_YV12 as YUV, but in
>> fact this format is the I420 or IYUV format. The real conversion is done
>> at vo_xv (in draw_slice around line 488). Same for vo_directx and
>> probably
>> all that support planar formats. I should say that now I see the reason
>> mplayer to have always U as plane[1] and V as plane[2].
>>
>> Well, I don't want to change all IMGFMT_YV12 to I420, or to IMGFMT_YUV,
>> as it is a too global change. But we should make G2 in the right way.
>> Of cource if it is not already done.
>
> RTFM, this is all nonsense. MPlayer does not care about plane order,
> except when allocating or exporting buffers for crappy external
> codecs/filters/vo's that care.
I DO RTFM and RTFS
Thx for you both explaining me things I know and explain too.
This what I say is that we always have Y U V order in planes
and YV12 should be with flag SWAPPED set becouse it have
its plains in YVU order.
I would like to avoid referencing to yv12 as defalut and normal standart.


Best Regards
   Ivan Kalvachev
  iive




From dalias at aerifal.cx  Thu Feb  5 08:26:51 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Thu, 5 Feb 2004 02:26:51 -0500
Subject: [MPlayer-G2-dev] impostor yv12
In-Reply-To: <1116.213.16.61.120.1075936889.squirrel@mail.cacad.com>
References: <1085.213.16.61.174.1075855324.squirrel@mail.cacad.com>
	<20040204154535.GU257@brightrain.aerifal.cx>
	<1116.213.16.61.120.1075936889.squirrel@mail.cacad.com>
Message-ID: <20040205072651.GH257@brightrain.aerifal.cx>

On Thu, Feb 05, 2004 at 01:21:29AM +0200, Ivan Kalvachev wrote:
> D Richard Felker III said:
> > On Wed, Feb 04, 2004 at 02:42:04AM +0200, Ivan Kalvachev wrote:
> >> Hello,
> >> I had send few patches and few mails to xvid people
> >> regarding their handling of YV12 format.
> >> In short they claimed that it is reversed and they swaped the UV
> >> planes. I had tracked a bug in DSHOW and VfW handling of
> >> IYUV - they had mapped it to yv12, while IYUV is the same as I420.
> >> Few weaks ago I checked the image.c routines and noticed that
> >> the thing are unchanged, but later i found out that the VfW/DShow issues
> >> have been sorted.
> >>
> >> So,
> >> In short the YV12 format is not the format that mplayer claims it is.
> >> YV12 is in fact YVU / YCrCb /, that is in no way the default MPEG
> >> standart
> >> color format. As you know in MPEG 0,1,2,3 blocks are Y, Cb is #4 block,
> >> Cr
> >> is #5 block.
> >> Yes, I know that all code over mplayer-g1 use IMGFMT_YV12 as YUV, but in
> >> fact this format is the I420 or IYUV format. The real conversion is done
> >> at vo_xv (in draw_slice around line 488). Same for vo_directx and
> >> probably
> >> all that support planar formats. I should say that now I see the reason
> >> mplayer to have always U as plane[1] and V as plane[2].
> >>
> >> Well, I don't want to change all IMGFMT_YV12 to I420, or to IMGFMT_YUV,
> >> as it is a too global change. But we should make G2 in the right way.
> >> Of cource if it is not already done.
> >
> > RTFM, this is all nonsense. MPlayer does not care about plane order,
> > except when allocating or exporting buffers for crappy external
> > codecs/filters/vo's that care.
> I DO RTFM and RTFS
> Thx for you both explaining me things I know and explain too.
> This what I say is that we always have Y U V order in planes
> and YV12 should be with flag SWAPPED set becouse it have
> its plains in YVU order.
> I would like to avoid referencing to yv12 as defalut and normal standart.

In G1, I420 gets the "swapped" flag and YV12 is "normal". I agree this
is backwards, but it doesn't particularly matter.

G2 cares even less about plane order; it's just there so that codecs
or vo's which have the "common plane" stride restriction will have it
honored.

Rich



From syncmail at mplayerhq.hu  Thu Feb  5 08:58:04 2004
From: syncmail at mplayerhq.hu (Gabucino)
Date: Thu,  5 Feb 2004 08:58:04 +0100 (CET)
Subject: [MPlayer-G2-dev] CVS: g2/confiG2ure target, 1.2, 1.3 target.h,
	1.1.1.1, 1.2
Message-ID: <20040205075804.9741B2D90A@mail.mplayerhq.hu>

CVS change done by Gabucino

Update of /cvsroot/mplayer/g2/confiG2ure
In directory mail:/var2/tmp/cvs-serv22822

Modified Files:
	target target.h 
Log Message:
VAX architecture support (tested on VAXstation 4000/VLC)



Index: target
===================================================================
RCS file: /cvsroot/mplayer/g2/confiG2ure/target,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- target	31 Jan 2004 21:57:57 -0000	1.2
+++ target	5 Feb 2004 07:58:02 -0000	1.3
@@ -31,7 +31,7 @@
   # host's CPU/instruction set
    host_arch=`( uname -p ) 2>&1`
    case "$host_arch" in
-   i386|sparc|ppc|alpha|arm|mips)
+   i386|sparc|ppc|alpha|arm|mips|vax)
      ;;
    powerpc) # Darwin returns 'powerpc'
      host_arch=ppc
@@ -501,6 +501,16 @@
     _mcpu=''
     ;;
 
+  vax)
+    _def_arch='#define ARCH_VAX 1'
+    _target_arch='TARGET_ARCH_VAX = yes'
+    iproc='vax'
+    proc=''
+    _march=''
+    _mcpu=''
+    _optimizing=''
+    ;;
+
   *)
     echo "The architecture of your CPU ($host_arch) is not supported by this configure script"
     echo "It seems nobody has ported MPlayer to your OS or CPU type yet."

Index: target.h
===================================================================
RCS file: /cvsroot/mplayer/g2/confiG2ure/target.h,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- target.h	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ target.h	5 Feb 2004 07:58:02 -0000	1.2
@@ -7,9 +7,9 @@
 /* Extension defines */
 #undef HAVE_3DNOW	// only define if you have 3DNOW (AMD k6-2, AMD Athlon, iDT WinChip, etc.)
 #undef HAVE_3DNOWEX	// only define if you have 3DNOWEX (AMD Athlon, etc.)
-#define HAVE_MMX 1	// only define if you have MMX (newer x86 chips, not P54C/PPro)
-#define HAVE_MMX2 1	// only define if you have MMX2 (Athlon/PIII/4/CelII)
-#define HAVE_SSE 1	// only define if you have SSE (Intel Pentium III/4 or Celeron II)
-#define HAVE_SSE2 1	// only define if you have SSE2 (Intel Pentium 4)
+#undef HAVE_MMX	// only define if you have MMX (newer x86 chips, not P54C/PPro)
+#undef HAVE_MMX2	// only define if you have MMX2 (Athlon/PIII/4/CelII)
+#undef HAVE_SSE	// only define if you have SSE (Intel Pentium III/4 or Celeron II)
+#undef HAVE_SSE2	// only define if you have SSE2 (Intel Pentium 4)
 #undef HAVE_ALTIVEC	// only define if you have Altivec (G4)
 



From gabucino at mplayerhq.hu  Thu Feb  5 09:01:53 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Thu, 5 Feb 2004 09:01:53 +0100
Subject: [MPlayer-G2-dev] CVS: g2/confiG2ure target, 1.2, 1.3 target.h,
	1.1.1.1, 1.2
In-Reply-To: <20040205075804.9741B2D90A@mail.mplayerhq.hu>
References: <20040205075804.9741B2D90A@mail.mplayerhq.hu>
Message-ID: <20040205080153.GA3813@woodstock.localdomain>

Gabucino wrote:
> Index: target.h
> ===================================================================
Shouldn't this automatically generated file be removed from CVS?

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040205/de9aa377/attachment.pgp>

From syncmail at mplayerhq.hu  Thu Feb  5 09:07:56 2004
From: syncmail at mplayerhq.hu (Gabucino)
Date: Thu,  5 Feb 2004 09:07:56 +0100 (CET)
Subject: [MPlayer-G2-dev] CVS: g2 configure.g1,1.1.1.1,1.2
Message-ID: <20040205080756.679982D925@mail.mplayerhq.hu>

CVS change done by Gabucino

Update of /cvsroot/mplayer/g2
In directory mail:/var2/tmp/cvs-serv18331

Modified Files:
	configure.g1 
Log Message:
VAX architecture support (tested on VAXstation 4000/VLC)


Index: configure.g1
===================================================================
RCS file: /cvsroot/mplayer/g2/configure.g1,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- configure.g1	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ configure.g1	5 Feb 2004 08:07:53 -0000	1.2
@@ -388,7 +388,7 @@
   # host's CPU/instruction set
    host_arch=`( uname -p ) 2>&1`
    case "$host_arch" in
-   i386|sparc|ppc|alpha|arm|mips)
+   i386|sparc|ppc|alpha|arm|mips|vax)
      ;;
    powerpc) # Darwin returns 'powerpc'
      host_arch=ppc
@@ -932,6 +932,16 @@
     _mcpu=''
     ;;
 
+  vax)
+    _def_arch='#define ARCH_VAX 1'
+    _target_arch='TARGET_ARCH_VAX = yes'
+    iproc='vax'
+    proc=''
+    _march=''
+    _mcpu=''
+    _optimizing=''
+    ;;                              
+
   *)
     echo "The architecture of your CPU ($host_arch) is not supported by this configure script"
     echo "It seems nobody has ported MPlayer to your OS or CPU type yet."



From syncmail at mplayerhq.hu  Thu Feb  5 09:08:24 2004
From: syncmail at mplayerhq.hu (Gabucino)
Date: Thu,  5 Feb 2004 09:08:24 +0100 (CET)
Subject: [MPlayer-G2-dev] CVS: g2 configure.g1,1.2,1.3
Message-ID: <20040205080824.726962D934@mail.mplayerhq.hu>

CVS change done by Gabucino

Update of /cvsroot/mplayer/g2
In directory mail:/var2/tmp/cvs-serv915

Modified Files:
	configure.g1 
Log Message:
removing pthread dependency


Index: configure.g1
===================================================================
RCS file: /cvsroot/mplayer/g2/configure.g1,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- configure.g1	5 Feb 2004 08:07:53 -0000	1.2
+++ configure.g1	5 Feb 2004 08:08:21 -0000	1.3
@@ -2066,14 +2066,17 @@
     elif ( cc_check -pthread ) ; then
      _ld_pthread='-pthread'
     else
-      die "Static lib pthread not found (needed by Windows and networking stufff)."
+      echores "no static pthread found (v4l, vo_gl, ao_alsa, ao_nas, ao_macosx, Win32 loader disabled)"
+      _ld_pthread='' ; _nas=no ; _tv_v4l=no ; _tv_v4l=no ; _macosx=no ; _win32=no
     fi
   else
-    die "Lib pthread not found (needed by Windows and networking stuff)."
+    echores "no (v4l, vo_gl, ao_alsa, ao_nas, ao_macosx, win32 loader disabled)"
+    _ld_pthread='' ; _nas=no ; _tv_v4l=no ; _tv_v4l=no ; _macosx=no ; _win32=no
   fi
 fi
-echores "yes (using $_ld_pthread)"
-
+if test "$_ld_pthread" != '' ; then
+  echores "yes (using $_ld_pthread)"
+fi
 
 echocheck "sys/soundcard.h"
 cat > $TMPC << EOF



From saschasommer at freenet.de  Sat Feb  7 16:29:51 2004
From: saschasommer at freenet.de (Sascha Sommer)
Date: Sat, 7 Feb 2004 16:29:51 +0100
Subject: [MPlayer-G2-dev] [PATCH] Windows GUI
Message-ID: <004001c3ed8f$3c2e9d60$03000004@oemcomputer>

I was bored so I decided to write a simple windows gui
for mplayer G2.
Get the patch from
http://www.mplayerhq.hu/~faust3/g2-windows-gui.diff
apply it and run configure.g1
Then add -lcomdlg32 to WIN32_LIB in config.mak.
Type make and you should get an app called test-ui.exe
The patch also includes a windows timer, vo directx 2,
and window helper code. Due to the bugs in the later one
the gui won't play more than 1 video file. This
is not the case for audio.
Ok, the gui sucks. Hopefully this will change when I added
skin support.
Meanwhile it would be cool if someone could fix configure to build only the
supported vos.


Sascha



From diego at biurrun.de  Tue Feb 10 06:08:25 2004
From: diego at biurrun.de (Diego Biurrun)
Date: Tue, 10 Feb 2004 02:08:25 -0300
Subject: [MPlayer-G2-dev] [PATCH] Select realtime scheduler
In-Reply-To: <Pine.GSO.4.44_heb2.09.0402011233580.3063-200000@techunix.technion.ac.il>
References: <Pine.GSO.4.44_heb2.09.0402011233580.3063-200000@techunix.technion.ac.il>
Message-ID: <16424.26441.546394.810353@biurrun.de>

Raindel Shachar writes:
 >   I attach a patch that allows mplayer to ask for realtime scheduler, so
 > that it will get it's CPU slice whenever it need it, preventing sleep
 > overruns.

Hey, is the g2 list as unresponsive as dev-eng now?  Come on..

I remember playing with realtime scheduling on my old notebook
(Pentium 120) it really helped on this machine.

Have you tried porting your patch to G1?  I think this would be a
useful feature.

Diego



From diego at biurrun.de  Tue Feb 10 06:13:58 2004
From: diego at biurrun.de (Diego Biurrun)
Date: Tue, 10 Feb 2004 02:13:58 -0300
Subject: [MPlayer-G2-dev] [PATCH] Select realtime scheduler
In-Reply-To: <Pine.GSO.4.44_heb2.09.0402011233580.3063-200000@techunix.technion.ac.il>
References: <Pine.GSO.4.44_heb2.09.0402011233580.3063-200000@techunix.technion.ac.il>
Message-ID: <16424.26774.946818.628780@biurrun.de>

Raindel Shachar writes:
 >   I attach a patch that allows mplayer to ask for realtime scheduler, so
 > that it will get it's CPU slice whenever it need it, preventing sleep
 > overruns.

Anyway, it does not apply anymore ...  It would be nice if you could
resend it.

Diego



From syncmail at mplayerhq.hu  Thu Feb 12 11:11:01 2004
From: syncmail at mplayerhq.hu (Gabucino)
Date: Thu, 12 Feb 2004 11:11:01 +0100 (CET)
Subject: [MPlayer-G2-dev] CVS: g2/!P g2.osd.diff,1.1.1.1,1.2
Message-ID: <20040212101101.696DC30FB1@mail.mplayerhq.hu>

CVS change done by Gabucino

Update of /cvsroot/mplayer/g2/!P
In directory mail:/var2/tmp/cvs-serv25421

Modified Files:
	g2.osd.diff 
Log Message:
updated to current CVS


Index: g2.osd.diff
===================================================================
RCS file: /cvsroot/mplayer/g2/!P/g2.osd.diff,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- g2.osd.diff	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ g2.osd.diff	12 Feb 2004 10:10:59 -0000	1.2
@@ -1,5 +1,6 @@
---- /home/alban/MP/g2/Makefile	Thu Jul 10 22:54:15 2003
-+++ /home/alban/MP/g2.dev/Makefile	Sat Jul 19 20:40:02 2003
+diff -Naur g2.van/Makefile g2/Makefile
+--- g2.van/Makefile	Sat Jan 31 21:16:18 2004
++++ g2/Makefile	Thu Feb 12 11:07:49 2004
 @@ -10,7 +10,7 @@
  STREAM_DEPS = demux/libmpdemux.a stream/libmpstream.a stream/mpdvdkit2/libmpdvdkit.a
  CODECS_DEPS = audio/libmpacodecs.a video/libmpvcodecs.a libavcodec/libavcodec.a libavcodec/libpostproc/libpostproc.a \
@@ -13,13 +14,14 @@
  	$(CC) $(OBJS) test-codecs.o osdep/cpudetect.o -o test-codecs $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) $(EXTRA_LIB) $(CDPARANOIA_LIB) osdep/libosdep.a $(SMBCLIENT_LIB) $(AO_LIBS) $(VO_LIBS) $(THEORA_LIB) $(VORBIS_LIB) $(I18NLIBS) -lm
  
  test-play: $(OBJS) $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) osdep/libosdep.a test-play.o input/libinput.a 
--	$(CC) $(OBJS) test-play.o -o test-play $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) input/libinput.a osdep/libosdep.a $(EXTRA_LIB) $(CDPARANOIA_LIB)  $(SMBCLIENT_LIB) $(AO_LIBS) $(VO_LIBS) $(TERMCAP_LIB) $(LIRC_LIB) $(THEORA_LIB) $(VORBIS_LIB) $(I18NLIBS) -lm
-+	$(CC) $(OBJS) test-play.o -o test-play $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) input/libinput.a osdep/libosdep.a $(EXTRA_LIB) $(CDPARANOIA_LIB)  $(SMBCLIENT_LIB) $(AO_LIBS) $(VO_LIBS) $(TERMCAP_LIB) $(LIRC_LIB) $(THEORA_LIB) $(VORBIS_LIB) $(I18NLIBS) -lm `freetype-config --libs`
+-	$(CC) $(OBJS) test-play.o -o test-play $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) input/libinput.a osdep/libosdep.a $(EXTRA_LIB) $(CDPARANOIA_LIB)  $(SMBCLIENT_LIB) $(AO_LIBS) $(VO_LIBS) $(TERMCAP_LIB) $(LIRC_LIB) $(THEORA_LIB) $(VORBIS_LIB) $(I18NLIBS) $(WIN32_LIB) -lm
++	$(CC) $(OBJS) test-play.o -o test-play $(CODECS_DEPS) $(STREAM_DEPS) $(PLAYER_DEPS) input/libinput.a osdep/libosdep.a $(EXTRA_LIB) $(CDPARANOIA_LIB)  $(SMBCLIENT_LIB) $(AO_LIBS) $(VO_LIBS) $(TERMCAP_LIB) $(LIRC_LIB) $(THEORA_LIB) $(VORBIS_LIB) $(I18NLIBS) $(WIN32_LIB) -lm `freetype-config --libs`
  
  test-input: test-input.o input/libinput.a osdep/libosdep.a mp_msg.o get_path.o
- 	$(CC) test-input.o -o test-input input/libinput.a osdep/libosdep.a mp_msg.o get_path.o $(EXTRA_LIB) $(TERMCAP_LIB) $(LIRC_LIB) $(I18NLIBS) $(MACOSX_FRAMEWORKS)
---- /dev/null	Mon Jul 18 01:46:18 1994
-+++ /home/alban/MP/g2.dev/osd/Makefile	Sat Jul 19 20:26:17 2003
+ 	$(CC) test-input.o -o test-input input/libinput.a osdep/libosdep.a mp_msg.o get_path.o $(EXTRA_LIB) $(TERMCAP_LIB) $(LIRC_LIB) $(I18NLIBS) $(MACOSX_FRAMEWORKS) $(WIN32_LIB)
+diff -Naur g2.van/osd/Makefile g2/osd/Makefile
+--- g2.van/osd/Makefile	Thu Jan  1 01:00:00 1970
++++ g2/osd/Makefile	Thu Feb 12 11:06:55 2004
 @@ -0,0 +1,46 @@
 +
 +BASE=..
@@ -67,8 +69,9 @@
 +include .depend
 +endif
 +
---- /dev/null	Mon Jul 18 01:46:18 1994
-+++ /home/alban/MP/g2.dev/osd/obj_test.c	Sun Jul 20 18:13:50 2003
+diff -Naur g2.van/osd/obj_test.c g2/osd/obj_test.c
+--- g2.van/osd/obj_test.c	Thu Jan  1 01:00:00 1970
++++ g2/osd/obj_test.c	Thu Feb 12 11:06:55 2004
 @@ -0,0 +1,192 @@
 +
 +#include "config.h"
@@ -262,8 +265,9 @@
 +  0,
 +  cfg_opts, &cfg_def, sizeof(struct config_data_s)
 +};
---- /dev/null	Mon Jul 18 01:46:18 1994
-+++ /home/alban/MP/g2.dev/osd/osd.c	Sun Jul 20 16:57:10 2003
+diff -Naur g2.van/osd/osd.c g2/osd/osd.c
+--- g2.van/osd/osd.c	Thu Jan  1 01:00:00 1970
++++ g2/osd/osd.c	Thu Feb 12 11:06:55 2004
 @@ -0,0 +1,469 @@
 +#include "config.h"
 +
@@ -734,8 +738,9 @@
 +  
 +}
 +
---- /dev/null	Mon Jul 18 01:46:18 1994
-+++ /home/alban/MP/g2.dev/osd/osd.h	Sun Jul 20 16:48:41 2003
+diff -Naur g2.van/osd/osd.h g2/osd/osd.h
+--- g2.van/osd/osd.h	Thu Jan  1 01:00:00 1970
++++ g2/osd/osd.h	Thu Feb 12 11:06:55 2004
 @@ -0,0 +1,118 @@
 +
 +// TEMP:
@@ -855,34 +860,37 @@
 +void osd_display_free(osd_display_t* disp);
 +
 +module_info_t* find_osd_obj(char* name);
---- /home/alban/MP/g2/video/Makefile	Mon May 12 01:47:03 2003
-+++ /home/alban/MP/g2.dev/video/Makefile	Fri Jul 18 18:13:06 2003
+diff -Naur g2.van/video/Makefile g2/video/Makefile
+--- g2.van/video/Makefile	Sat Jan 31 21:16:18 2004
++++ g2/video/Makefile	Thu Feb 12 11:08:38 2004
 @@ -12,7 +12,7 @@
  VIDEO_SRCS=dec_video.c vd.c $(VIDEO_SRCS_NAT) $(VIDEO_SRCS_LIB) $(VIDEO_SRCS_OPT)
  
  # vf_vo.c 
--VFILTER_SRCS=vf.c vf_scale.c vf_vo2.c vf_vd.c vf_pp.c vf_format.c vf_tfields.c # vf_crop.c vf_expand.c # vf_format.c vf_flip.c vf_rgb2bgr.c vf_rotate.c vf_mirror.c vf_palette.c vf_lavc.c vf_dvbscale.c vf_cropdetect.c vf_test.c vf_noise.c vf_rectangle.c vf_eq.c vf_eq2.c vf_halfpack.c vf_dint.c vf_1bpp.c vf_bmovl.c vf_2xsai.c vf_unsharp.c vf_swapuv.c vf_il.c vf_boxblur.c vf_sab.c vf_smartblur.c vf_perspective.c vf_down3dright.c vf_field.c vf_denoise3d.c vf_hqdn3d.c vf_detc.c vf_telecine.c vf_tfields.c 
-+VFILTER_SRCS=vf.c vf_scale.c vf_vo2.c vf_vd.c vf_pp.c vf_format.c vf_tfields.c vf_osd.c # vf_crop.c vf_expand.c # vf_format.c vf_flip.c vf_rgb2bgr.c vf_rotate.c vf_mirror.c vf_palette.c vf_lavc.c vf_dvbscale.c vf_cropdetect.c vf_test.c vf_noise.c vf_rectangle.c vf_eq.c vf_eq2.c vf_halfpack.c vf_dint.c vf_1bpp.c vf_bmovl.c vf_2xsai.c vf_unsharp.c vf_swapuv.c vf_il.c vf_boxblur.c vf_sab.c vf_smartblur.c vf_perspective.c vf_down3dright.c vf_field.c vf_denoise3d.c vf_hqdn3d.c vf_detc.c vf_telecine.c vf_tfields.c 
+-VFILTER_SRCS=vf.c vf_remcirc.c vf_scale.c vf_vo2.c vf_vd.c vf_pp.c vf_format.c vf_tfields.c vf_madei.c # vf_crop.c vf_expand.c # vf_format.c vf_flip.c vf_rgb2bgr.c vf_rotate.c vf_mirror.c vf_palette.c vf_lavc.c vf_dvbscale.c vf_cropdetect.c vf_test.c vf_noise.c vf_rectangle.c vf_eq.c vf_eq2.c vf_halfpack.c vf_dint.c vf_1bpp.c vf_bmovl.c vf_2xsai.c vf_unsharp.c vf_swapuv.c vf_il.c vf_boxblur.c vf_sab.c vf_smartblur.c vf_perspective.c vf_down3dright.c vf_field.c vf_denoise3d.c vf_hqdn3d.c vf_detc.c vf_telecine.c vf_tfields.c 
++VFILTER_SRCS=vf.c vf_remcirc.c vf_scale.c vf_vo2.c vf_vd.c vf_pp.c vf_format.c vf_tfields.c vf_madei.c vf_osd.c # vf_crop.c vf_expand.c # vf_format.c vf_flip.c vf_rgb2bgr.c vf_rotate.c vf_mirror.c vf_palette.c vf_lavc.c vf_dvbscale.c vf_cropdetect.c vf_test.c vf_noise.c vf_rectangle.c vf_eq.c vf_eq2.c vf_halfpack.c vf_dint.c vf_1bpp.c vf_bmovl.c vf_2xsai.c vf_unsharp.c vf_swapuv.c vf_il.c vf_boxblur.c vf_sab.c vf_smartblur.c vf_perspective.c vf_down3dright.c vf_field.c vf_denoise3d.c vf_hqdn3d.c vf_detc.c vf_telecine.c vf_tfields.c 
  ENCODER_SRCS=ve.c # ve_lavc.c # ve_divx4.c ve_vfw.c ve_rawrgb.c ve_libdv.c ve_xvid.c ve_qtvideo.c ve_nuv.c
  
  # NATIVE_SRCS=native/RTjpegN.c native/cinepak.c native/fli.c native/minilzo.c native/msvidc.c native/nuppelvideo.c native/qtrle.c native/qtrpza.c native/qtsmc.c native/roqav.c native/xa_gsm.c native/svq1.c
---- /home/alban/MP/g2/video/vf.c	Sun Jul 13 23:52:25 2003
-+++ /home/alban/MP/g2.dev/video/vf.c	Sat Jul 19 16:07:52 2003
-@@ -60,11 +60,13 @@
- extern vf_info_t vf_info_detc;
- extern vf_info_t vf_info_telecine;
+diff -Naur g2.van/video/vf.c g2/video/vf.c
+--- g2.van/video/vf.c	Sat Jan 31 21:16:18 2004
++++ g2/video/vf.c	Thu Feb 12 11:09:30 2004
+@@ -62,12 +62,14 @@
  extern vf_info_t vf_info_tfields;
+ extern vf_info_t vf_info_madei;
+ extern vf_info_t vf_info_remcirc;
 +extern vf_info_t vf_info_osd;
  
  //char** vo_plugin_args=(char**) NULL;
  
  // list of available filters:
  static vf_info_t* filter_list[]={
+     &vf_info_remcirc,
 +    &vf_info_osd,
      &vf_info_scale,
      &vf_info_vo2,
      &vf_info_vd,
-@@ -128,7 +130,7 @@
+@@ -132,7 +134,7 @@
      int y;
      if(mpi->flags&MP_IMGFLAG_PLANAR){
  	y0&=~1;h+=h&1;
@@ -891,8 +899,9 @@
  	    // full width clear:
  	    memset(mpi->planes[0]+mpi->stride[0]*y0,0,mpi->stride[0]*h);
  	    memset(mpi->planes[1]+mpi->stride[1]*(y0>>mpi->chroma_y_shift),128,mpi->stride[1]*(h>>mpi->chroma_y_shift));
---- /dev/null	Mon Jul 18 01:46:18 1994
-+++ /home/alban/MP/g2.dev/video/vf_osd.c	Sun Jul 20 18:07:01 2003
+diff -Naur g2.van/video/vf_osd.c g2/video/vf_osd.c
+--- g2.van/video/vf_osd.c	Thu Jan  1 01:00:00 1970
++++ g2/video/vf_osd.c	Thu Feb 12 11:06:55 2004
 @@ -0,0 +1,253 @@
 +
 +#include <stdio.h>



From arpi at thot.banki.hu  Thu Feb 12 22:10:56 2004
From: arpi at thot.banki.hu (Arpi)
Date: Thu, 12 Feb 2004 22:10:56 +0100 (CET)
Subject: [MPlayer-G2-dev] slices
Message-ID: <20040212211056.61F303103E@mail.mplayerhq.hu>

Hi,

Slices. The thing we like and hate most.
I think the real issue is that we don't even know what slices are!
It's trivial that we can't live in g2 without slices, but it's not
easy to live with them.

Let's see what kind of slices we had, have or will have.

1. libmpeg2 B-frame style (also supported by libjpeg & libpng):

decoder decodes a part of the image (a slice, or a macroblock) to a
small (smaller than image size) internal (allocated by decoder) buffer,
then calls next vf to process it (copy it out to image/screen) and
then re-uses teh same buffer memory area for the next chunk of data.

2. notification style (libavcodec, libmpeg2 I/P frames):

decoder decodes to an image-sized buffer (it may be allocated by decoder
or it may be direct rendering) and after decoding a small area (MB or slice)
it notifies (via callback) the next vf about finishing that part.
so the next vf can process that part immediatelly from cache.

actually 2. is 2.a and 2.b, each for internal and DR buffer.
so we end up with 3 different kind of slices.

for using 1. style slices, we need to know (before the decoding) if the
next vf supports this kind of slices.
type-2. slices are simpler, it's optional to call next vf's notification
callback. it can have such callbacks to do some optimizations, or don't
have for normal whole-buffer process.

to implement it in g2, we need 2 different things:
- a negotation system for type-1. slices support
  (also negotiate slice type, ie. line(s) of pixels, line(s) of macroblocks,
   single macroblock, other)
- an optional function to vf API for slice-finished notifications (type 2.)


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu



From dalias at aerifal.cx  Fri Feb 13 00:08:17 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Thu, 12 Feb 2004 18:08:17 -0500
Subject: [MPlayer-G2-dev] slices
In-Reply-To: <20040212211056.61F303103E@mail.mplayerhq.hu>
References: <20040212211056.61F303103E@mail.mplayerhq.hu>
Message-ID: <20040212230817.GC7862@brightrain.aerifal.cx>

On Thu, Feb 12, 2004 at 10:10:56PM +0100, Arpi wrote:
> Hi,
> 
> Slices. The thing we like and hate most.
> I think the real issue is that we don't even know what slices are!
> It's trivial that we can't live in g2 without slices, but it's not
> easy to live with them.

Thanks for the email!

> Let's see what kind of slices we had, have or will have.
> 
> 1. libmpeg2 B-frame style (also supported by libjpeg & libpng):
> 
> decoder decodes a part of the image (a slice, or a macroblock) to a
> small (smaller than image size) internal (allocated by decoder) buffer,
> then calls next vf to process it (copy it out to image/screen) and
> then re-uses teh same buffer memory area for the next chunk of data.

The current vp spec (and mostly-functional) code implements this by
requesting an INDIRECT type buffer from the next filter (or vo). It
then uses draw_slice to draw into it.

It's also allowed for the next filter to return a DIRECT type buffer
when INDIRECT is requested. Then the vp layer uses a default
draw_slice implementation that just copies into the DIRECT buffer.

Does this sound ok?

> 2. notification style (libavcodec, libmpeg2 I/P frames):
> 
> decoder decodes to an image-sized buffer (it may be allocated by decoder
> or it may be direct rendering) and after decoding a small area (MB or slice)
> it notifies (via callback) the next vf about finishing that part.
> so the next vf can process that part immediatelly from cache.

I see one potential problem with this. If enough filters actually
support per-slice _processing_, then the whole filterchain will get
called for each slice. If it's long (or if the slice is small, e.g. a
single macroblock), this might thrash the instruction cache (or branch
prediction, etc.)and make it slower, rather than faster...?

Also, in principle a filter should try to _output_ an image in slices,
even if the input came all as one image.

> actually 2. is 2.a and 2.b, each for internal and DR buffer.
> so we end up with 3 different kind of slices.

Actually three: internal buffer, DR buffer, and vp-allocated buffer.
But from the receiving filter's end, internal and vp-allocated (EXPORT
and AUTO) are the same, so it reduced to two like you say.

> for using 1. style slices, we need to know (before the decoding) if the
> next vf supports this kind of slices.

For this, it just needs to request an INDIRECT buffer (perhaps with
special flags for which style slices it wants to do...?).

> type-2. slices are simpler, it's optional to call next vf's notification
> callback. it can have such callbacks to do some optimizations, or don't
> have for normal whole-buffer process.

IMO it can't be this flexible. If you're going to report slice
completion, you should have to call the slice callback for every
single part of the image. Otherwise the dest filter has to compute
which region the slice callback never got called for, and process this
at the end, which is painful...

> to implement it in g2, we need 2 different things:
> - a negotation system for type-1. slices support
>   (also negotiate slice type, ie. line(s) of pixels, line(s) of macroblocks,
>    single macroblock, other)

How complicated should the negotiation system be?

> - an optional function to vf API for slice-finished notifications (type 2.)

Agree. This also requires some way of registering with the destination
filter that you're going to be passing the image with slices, so that
it can in turn allocate an output buffer to put its filtered output
into (possibly also with slices).

BTW, one really nasty issue you didn't bring up, which also comes into
this, is the whole buffer-age thing... When using type-2 slices, you
have _two_ buffer ages: the age of the buffer you have direct access
to, and the age of the buffer that the destination filter is rendering
its slice output into. Think of vd->scale(colorspace_only)->vo. It
would be very nice if the decoder could skip rendering unchanged
macroblocks in its yuv output buffers, and also if the scale filter
could skip converting unchanged macroblocks into framebuffer. But
which blocks are "unchanged" for each target may be different!! :/

IMO the only viable solution is some sort of powerful buffer-age
management at the vp layer level...

Rich




From dalias at aerifal.cx  Fri Feb 13 00:13:02 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Thu, 12 Feb 2004 18:13:02 -0500
Subject: [MPlayer-G2-dev] slices
In-Reply-To: <20040212211056.61F303103E@mail.mplayerhq.hu>
References: <20040212211056.61F303103E@mail.mplayerhq.hu>
Message-ID: <20040212231302.GD7862@brightrain.aerifal.cx>

Uhg, one more nasty issue about slices too!!

Consider vf_expand with osd rendering. You want to alpha-blend osd
onto the image during the slice rendering, so you don't have to read
video memory later to add osd! But here you run into a big problem.
Slice rendering takes place in decoding order, whereas osd contents
will be known in display order. It would look really stupid for the
clock to jump backwards for one frame, etc. How do we solve this??

I hate slices! No, actually slices are good. I hate B-frames!!! :/

Rich




From michaelni at gmx.at  Mon Feb 16 03:25:46 2004
From: michaelni at gmx.at (Michael Niedermayer)
Date: Mon, 16 Feb 2004 03:25:46 +0100
Subject: [MPlayer-G2-dev] slices
In-Reply-To: <20040212231302.GD7862@brightrain.aerifal.cx>
References: <20040212211056.61F303103E@mail.mplayerhq.hu>
	<20040212231302.GD7862@brightrain.aerifal.cx>
Message-ID: <200402160325.46952.michaelni@gmx.at>

Hi

On Friday 13 February 2004 00:13, D Richard Felker III wrote:
> Uhg, one more nasty issue about slices too!!
>
> Consider vf_expand with osd rendering. You want to alpha-blend osd
> onto the image during the slice rendering, so you don't have to read
> video memory later to add osd! But here you run into a big problem.
> Slice rendering takes place in decoding order, whereas osd contents
> will be known in display order. It would look really stupid for the
> clock to jump backwards for one frame, etc. How do we solve this??
>
> I hate slices! No, actually slices are good. I hate B-frames!!! :/
maybe i have an idea how to fix the slice mess, but more likely i missed many 
serious problems as iam a bit tired :), anyway, the idea is:
a pure pull system but not of frames but slices, there would be 2 different 
types of pull requests (more if we want, but its probably not worth)
type 1: single slice pull (only 1 slice, nothing above, nothing below)
type 2: all slices upto slice x
a filter needs to support just one of them, if a filter asks for a single 
slice but the previous filter supports just 0-x slice style then thats 
trivial, on the other hand if a filter asks for slice 0-x but the previous 
filter only supports single slice output then a simple buffering filter needs 
to be inserted which would then combine the slices upto that point

slice sizes ...
very easy too, during config each filter just asks the previous one(s) what 
slice size it can provide, slice size can be specified with a single integer 
pair (x,y) which splits a frame into rectangular tiles which will always be 
requested in raster scan (left->right, top->bottom) order
many filters will probably require x=width though, iam not sure if we should 
support x!=width at all, maybe not, if we do then we also must deal with the 
case of converting x!=width slices to x==width

slice draw callback from the codecs
well, arghhh
i probably would have to change libavcodec to support normally returning after 
each slice and resuming, dunno how easy that would be, but i dont see an 
alternative unless we use threads but the overhead would cancel any advantage 
slices provide

b frames
each frame gets a PTS and picture type and the slice pull can ask either for 
the next picture in display order or dont care order, so if the vo and 
filters dont care about the order then frames could be passed in coded order 
and the vo would do the reordering
so we have a special case again, where a filter asks for display-order but the 
previous one provides any-order, in which case a IPB frame reorder filter 
needs to be inserted

btw if anything mentioned here has already been suggested/implemented/rejected 
then sorry, i didnt follow the discussion about the VP lately, tell me to 
RTFwhatever

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en



From dalias at aerifal.cx  Mon Feb 16 05:58:19 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Sun, 15 Feb 2004 23:58:19 -0500
Subject: [MPlayer-G2-dev] slices
In-Reply-To: <200402160325.46952.michaelni@gmx.at>
References: <20040212211056.61F303103E@mail.mplayerhq.hu>
	<20040212231302.GD7862@brightrain.aerifal.cx>
	<200402160325.46952.michaelni@gmx.at>
Message-ID: <20040216045819.GF9096@brightrain.aerifal.cx>

On Mon, Feb 16, 2004 at 03:25:46AM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Friday 13 February 2004 00:13, D Richard Felker III wrote:
> > Uhg, one more nasty issue about slices too!!
> >
> > Consider vf_expand with osd rendering. You want to alpha-blend osd
> > onto the image during the slice rendering, so you don't have to read
> > video memory later to add osd! But here you run into a big problem.
> > Slice rendering takes place in decoding order, whereas osd contents
> > will be known in display order. It would look really stupid for the
> > clock to jump backwards for one frame, etc. How do we solve this??
> >
> > I hate slices! No, actually slices are good. I hate B-frames!!! :/
> maybe i have an idea how to fix the slice mess, but more likely i missed many 
> serious problems as iam a bit tired :), anyway, the idea is:

:)

> a pure pull system but not of frames but slices, there would be 2 different 
> types of pull requests (more if we want, but its probably not worth)
> type 1: single slice pull (only 1 slice, nothing above, nothing below)
> type 2: all slices upto slice x
> a filter needs to support just one of them, if a filter asks for a single 
> slice but the previous filter supports just 0-x slice style then thats 
> trivial, on the other hand if a filter asks for slice 0-x but the previous 
> filter only supports single slice output then a simple buffering filter needs 
> to be inserted which would then combine the slices upto that point

Read what I just said about B frames. They're the bane of video
processing! :( Here, the problem is that you want to request frames in
display-order but have them get processed (via callbacks) in decode
order, when possible. If you pull slices, this doesn't really work.

Also, most codecs (or at least libavcodec, which is all that counts :)
don't support an api for "pulling" slices. Instead the slice function
is a callback. IMO the callback style makes more sense, but from an
API perspective, it would be nice if lavc offered both.

> slice sizes ...
> very easy too, during config each filter just asks the previous one(s) what 
> slice size it can provide, slice size can be specified with a single integer 
> pair (x,y) which splits a frame into rectangular tiles which will always be 
> requested in raster scan (left->right, top->bottom) order

Definitely not possible. Think of upside-down codecs, or flip filter
(which would swap the order slices would be drawn...), or a left-right
mirror filter, or down3dright, etc.

> many filters will probably require x=width though, iam not sure if we should 
> support x!=width at all, maybe not, if we do then we also must deal with the 
> case of converting x!=width slices to x==width

This sort of thing is the exact problem I was running into. It gets
worse when you think of something like a scale filter wanting to draw
in slices, where input pixels correspond to a factional number of
output pixels! :(

> slice draw callback from the codecs
> well, arghhh
> i probably would have to change libavcodec to support normally returning after 
> each slice and resuming, dunno how easy that would be, but i dont see an 
> alternative unless we use threads but the overhead would cancel any advantage 
> slices provide

Right, very ugly... But IMO it should be supported if it can be done
without hurting performance in the old callback mode. I really hate
when libraries take a lot of cpu time without offering to return to
the calling application, since it can force you to use threads... :(

> b frames
> each frame gets a PTS and picture type and the slice pull can ask either for 
> the next picture in display order or dont care order, so if the vo and 
> filters dont care about the order then frames could be passed in coded order 
> and the vo would do the reordering
> so we have a special case again, where a filter asks for display-order but the 
> previous one provides any-order, in which case a IPB frame reorder filter 
> needs to be inserted

Have you even thought about how any of this works with buffer
management / direct rendering? IMO there are lots of problems.

> btw if anything mentioned here has already been suggested/implemented/rejected 
> then sorry, i didnt follow the discussion about the VP lately, tell me to 
> RTFwhatever

:)))))))))))))

Actually the only thing to RTF is the secret proposal/code at
http://brightrain.aerifal.cx/~dalias/vp-in-progress/

Basically, my design right now is that we "pull" frames, but "push"
slices and buffer allocation, i.e. slices and buffer allocation happen
via callback from the previous filter(s)/codec(s). This probably has
both advantages and disadvantages. One thing I like is that it allows
filters which need to see frames in display-order to still do _some_
processing in decode-order, during the slice callback. For instance
you could compute some local noise metrics during the slice callback,
then apply denoising (including temporal denoising) only where it's
needed once you get the final frame from the previous filter.

On the other hand, it makes it impossible to do decode-order
processing of images when slices aren't supported. This could be
useful with low-resoltion movies, where a whole frame fits in the
cache as one "big slice". But if filters always use slices when
possible, this situation shouldn't arise...

Rich



From syncmail at mplayerhq.hu  Wed Feb 18 13:37:22 2004
From: syncmail at mplayerhq.hu (Alex Beregszaszi)
Date: Wed, 18 Feb 2004 13:37:22 +0100 (CET)
Subject: [MPlayer-G2-dev] 
	CVS: g2 config.h, 1.1.1.1, NONE config.mak, 1.1.1.1, NONE
Message-ID: <20040218123722.8B48C31586@mail.mplayerhq.hu>

CVS change done by Alex Beregszaszi

Update of /cvsroot/mplayer/g2
In directory mail:/var2/tmp/cvs-serv461

Removed Files:
	config.h config.mak 
Log Message:
removed auto generated code

--- config.h DELETED ---

--- config.mak DELETED ---



From attila at kinali.ch  Fri Feb 20 14:44:03 2004
From: attila at kinali.ch (Attila Kinali)
Date: Fri, 20 Feb 2004 14:44:03 +0100
Subject: [MPlayer-G2-dev] slices
In-Reply-To: <20040212231302.GD7862@brightrain.aerifal.cx>
References: <20040212211056.61F303103E@mail.mplayerhq.hu>
	<20040212231302.GD7862@brightrain.aerifal.cx>
Message-ID: <20040220144403.4030e49d.attila@kinali.ch>

On Thu, 12 Feb 2004 18:13:02 -0500
D Richard Felker III <dalias at aerifal.cx> wrote:

> Consider vf_expand with osd rendering. You want to alpha-blend osd
> onto the image during the slice rendering, so you don't have to read
> video memory later to add osd! But here you run into a big problem.
> Slice rendering takes place in decoding order, whereas osd contents
> will be known in display order. It would look really stupid for the
> clock to jump backwards for one frame, etc. How do we solve this??

I wouldn't mind that. There is at least one subtitle format
around that does not require time sorted entries, thus the osd
reader/renderer needs to sort and chache them anyways.
And i'm sure there are more such stupid formats out there. [1]

Also i think even if we leave those fileformats aside and
only look at odered subs (ie by preordering those shit formats)
it's still not hard to provide a few frameduration long backlog
of subtitles [2].

But, the more important question here is, how do you plan
to integrate the subtitle renderer into your vp/vo design ?
The current "every vo needs draw_alpha" doesn't work quite
well as we all know. Beside i'd like to have colored subs
with any shape. One stupid solution would be to do everything
in a vp_expand, but then we'd lose potential acceleration by
the graphics card for alpha only subs (or is there also a way
for fast coloured subs rendering ?)


[1] There are a few more issues here as it's not always possible
to read the whole subfile at once as it might be a stream
embeded in ogm/mkv/nut/whatever file or come over a network
stream. 

[2] This rises of course the question of how many consecutive
B frames are allowed/possible. So far i haven't seen more
than 2 consecutive B frames, but that doesn't mean someone
outthere thinks he could encode a file consisting of
one I frame at the beginning, a P frame at the end and
the whole rest constisting of B frames.


			Attila Kinali
-- 
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
			-- reeler in +kaosu



From dalias at aerifal.cx  Fri Feb 20 16:49:29 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Fri, 20 Feb 2004 10:49:29 -0500
Subject: [MPlayer-G2-dev] slices
In-Reply-To: <20040220144403.4030e49d.attila@kinali.ch>
References: <20040212211056.61F303103E@mail.mplayerhq.hu>
	<20040212231302.GD7862@brightrain.aerifal.cx>
	<20040220144403.4030e49d.attila@kinali.ch>
Message-ID: <20040220154929.GD9096@brightrain.aerifal.cx>

On Fri, Feb 20, 2004 at 02:44:03PM +0100, Attila Kinali wrote:
> On Thu, 12 Feb 2004 18:13:02 -0500
> D Richard Felker III <dalias at aerifal.cx> wrote:
> 
> > Consider vf_expand with osd rendering. You want to alpha-blend osd
> > onto the image during the slice rendering, so you don't have to read
> > video memory later to add osd! But here you run into a big problem.
> > Slice rendering takes place in decoding order, whereas osd contents
> > will be known in display order. It would look really stupid for the
> > clock to jump backwards for one frame, etc. How do we solve this??
> 
> I wouldn't mind that. There is at least one subtitle format
> around that does not require time sorted entries, thus the osd
> reader/renderer needs to sort and chache them anyways.
> And i'm sure there are more such stupid formats out there. [1]
> 
> Also i think even if we leave those fileformats aside and
> only look at odered subs (ie by preordering those shit formats)
> it's still not hard to provide a few frameduration long backlog
> of subtitles [2].
> 
> But, the more important question here is, how do you plan
> to integrate the subtitle renderer into your vp/vo design ?
> The current "every vo needs draw_alpha" doesn't work quite
> well as we all know. Beside i'd like to have colored subs
> with any shape. One stupid solution would be to do everything
> in a vp_expand, but then we'd lose potential acceleration by
> the graphics card for alpha only subs (or is there also a way
> for fast coloured subs rendering ?)

All subs are done by vf_expand unless the vo supports subtitles. The
difference from G1 is that vo's are not allowed to implement their own
stupid draw_alpha blending. Support in the vo is ONLY for hardware
subpic devices.

> [1] There are a few more issues here as it's not always possible
> to read the whole subfile at once as it might be a stream
> embeded in ogm/mkv/nut/whatever file or come over a network
> stream. 

Yes, well don't just think of subtitles. Also the clock, or OSD menu,
or anything like that...

> [2] This rises of course the question of how many consecutive
> B frames are allowed/possible. So far i haven't seen more
> than 2 consecutive B frames, but that doesn't mean someone
> outthere thinks he could encode a file consisting of
> one I frame at the beginning, a P frame at the end and
> the whole rest constisting of B frames.

ROTFL! :)

For files with B frames, we could only do the slice-time OSD blending
for B frames or for the first frame in a closed GOP, and then blend
onto other frames right before displaying them. But there are some
difficulties about how to do it correctly if the frame is in video
memory. Do you:

(a) keep the frame buffered in system memory entirely until time to
display? This sounds slow.

(b) somehow know in advance the bounding boxes of OSD elements (just
not their contents) and save these in system memory during the
draw_slice, then use them to alpha-blend OSD at display time?

(c) violate READABLE flag and alpha-blend in video memory, like G1
does... :(

Unfortunately (c) is probably the fastest (but also the stupidest in
principle) assuming the OSD area is small...

Rich




From attila at kinali.ch  Fri Feb 20 17:08:22 2004
From: attila at kinali.ch (Attila Kinali)
Date: Fri, 20 Feb 2004 17:08:22 +0100
Subject: [MPlayer-G2-dev] slices
In-Reply-To: <20040220154929.GD9096@brightrain.aerifal.cx>
References: <20040212211056.61F303103E@mail.mplayerhq.hu>
	<20040212231302.GD7862@brightrain.aerifal.cx>
	<20040220144403.4030e49d.attila@kinali.ch>
	<20040220154929.GD9096@brightrain.aerifal.cx>
Message-ID: <20040220170822.1c4cc573.attila@kinali.ch>

On Fri, 20 Feb 2004 10:49:29 -0500
D Richard Felker III <dalias at aerifal.cx> wrote:

 
> All subs are done by vf_expand unless the vo supports subtitles. The
> difference from G1 is that vo's are not allowed to implement their own
> stupid draw_alpha blending. Support in the vo is ONLY for hardware
> subpic devices.

Ok, then we can leave the hw accelareted case out for the
first implementation.

 
> > [1] There are a few more issues here as it's not always possible
> > to read the whole subfile at once as it might be a stream
> > embeded in ogm/mkv/nut/whatever file or come over a network
> > stream. 
> 
> Yes, well don't just think of subtitles. Also the clock, or OSD menu,
> or anything like that...

Juup, i didnt forget them.

> For files with B frames, we could only do the slice-time OSD blending
> for B frames or for the first frame in a closed GOP, and then blend
> onto other frames right before displaying them. But there are some
> difficulties about how to do it correctly if the frame is in video
> memory. Do you:
> 
> (a) keep the frame buffered in system memory entirely until time to
> display? This sounds slow.

Bad idea.
 
> (b) somehow know in advance the bounding boxes of OSD elements (just
> not their contents) and save these in system memory during the
> draw_slice, then use them to alpha-blend OSD at display time?

Should be possible.
I thought about a intermediate representation of the OSD
elements where their size and position is already known.
Actualy i'm thinking about keeping already rendered
elements (as RGBA resp YUVA picutres) in memory, so that
only the last step of blending has to be performed.
But i dont know how much memory this needs and whether
it would be faster to render it again for every frame.


> (c) violate READABLE flag and alpha-blend in video memory, like G1
> does... :(

I really dont want that mess again. IMHO it's better to
sacrifice a few cpu cycles to keep the vo code clean
otherwise we'll end up again with an vo-hell.


			Attila Kinali
-- 
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
			-- reeler in +kaosu



From ivan at cacad.com  Fri Feb 20 17:28:27 2004
From: ivan at cacad.com (Ivan Kalvachev)
Date: Fri, 20 Feb 2004 18:28:27 +0200 (EET)
Subject: [MPlayer-G2-dev] slices
In-Reply-To: <200402160325.46952.michaelni@gmx.at>
References: <20040212211056.61F303103E@mail.mplayerhq.hu><20040212231302.GD7862@brightrain.aerifal.cx>
	<200402160325.46952.michaelni@gmx.at>
Message-ID: <2080.212.116.154.214.1077294507.squirrel@mail.cacad.com>

Michael Niedermayer said:
> Hi
>
> On Friday 13 February 2004 00:13, D Richard Felker III wrote:
>> Uhg, one more nasty issue about slices too!!
>> Consider vf_expand with osd rendering. You want to alpha-blend osd onto
>> the image during the slice rendering, so you don't have to read video
>> memory later to add osd! But here you run into a big problem. Slice
>> rendering takes place in decoding order, whereas osd contents will be
>> known in display order. It would look really stupid for the clock to
>> jump backwards for one frame, etc. How do we solve this?? I hate slices!
>> No, actually slices are good. I hate B-frames!!! :/
> maybe i have an idea how to fix the slice mess, but more likely i missed
> many
> serious problems as iam a bit tired :), anyway, the idea is:
> a pure pull system but not of frames but slices, there would be 2

Hmm you start thinking like me (if you have seen my vo3 drafts in this
maillist ;)
I also ask arpi: In G1 slices are treated separatly than the frames,
and we see that very few filters honnor them, and even less work right
with them (including vf_crop and vf_expand) . What is the point of
creating another slice mechanism  that nobody will use ?


> different
> types of pull requests (more if we want, but its probably not worth) type
>  1: single slice pull (only 1 slice, nothing above, nothing below)
> type 2: all slices upto slice x
> a filter needs to support just one of them, if a filter asks for a
> single  slice but the previous filter supports just 0-x slice style then
> thats trivial, on the other hand if a filter asks for slice 0-x but the
> previous
> filter only supports single slice output then a simple buffering filter
> needs
> to be inserted which would then combine the slices upto that point
I'm not quite sure but an MPEG-1 picture could be encoded
with one slice - from top to bottom. In this case we may
be unable to work with MPEG-1 streams.
j/k

>
> slice sizes ...
> very easy too, during config each filter just asks the previous one(s)
> what
> slice size it can provide, slice size can be specified with a single
> integer
> pair (x,y) which splits a frame into rectangular tiles which will always
> be requested in raster scan (left->right, top->bottom) order
> many filters will probably require x=width though, iam not sure if we
> should
> support x!=width at all, maybe not, if we do then we also must deal with
> the case of converting x!=width slices to x==width

Well it looks like slice size is a big issue. As dalias commented vf_scale
filter Will change  slice size.
But I think about shooting 2 problems at once. Slices are made of
macroblocks, so we could count macroblocks. This will allow us to use
mb_skip[] to jump skipped blocks. The problem is that in this case
we loose both slices and mb_skip after vf_scale (or it becomes a real
mess). Of cource we may have different blocks size (16x16, 8x8) but
this won't help with vf_slice or vf_crop/vf_expand that are not multiple of
block size.


>
> slice draw callback from the codecs
> well, arghhh
> i probably would have to change libavcodec to support normally returning
> after each slice and resuming, dunno how easy that would be, but i dont
> see an
It is easy, I believe libmpeg2 and xvid do this. At least in ffmpeg12
decode_slice() is called in infinite loop (that terminate on last slice).
But I wonder if this will give any advantage.


> alternative unless we use threads but the overhead would cancel any
> advantage
> slices provide

I still cannot get used to new thread functionality in libavcodec ;)

>
> b frames
> each frame gets a PTS and picture type and the slice pull can ask either
> for the next picture in display order or dont care order, so if the vo
> and filters dont care about the order then frames could be passed in coded
> order and the vo would do the reordering

As I said in my proposiol of vo3 the video system should act like decoder 
and work in decode order when possible. The B frame delay should be
handled by vf_vo or whatever.

> so we have a special case again, where a filter asks for display-order
> but the previous one provides any-order, in which case a IPB frame reorder
> filter needs to be inserted
>
> btw if anything mentioned here has already been
> suggested/implemented/rejected
> then sorry, i didnt follow the discussion about the VP lately, tell me
> to RTFwhatever
Don't worry the archive is not very big ;)

I also sorry that i cannot work on my video system at the moment, but
I hope that in 2 weeks I will.

I would like to ask, from what comes the advantage of one slice size
buffers, as they are first written and then readed (no blocking,
probably preventing cache polution?).
I know that they are faster becouse I made experiment by disableing them
in ffmpeg12.

And final words to dalias.
I'm not sure how L2 cache works, but the CPU cache is always separated on
instruction and data cache. So you cannot polute code by data and vise
versa. This is so from the first Pentium and probably for 486 too (if they
have cache at all;)

And about OSD and timer. We actually don't need astronomicat time to
display the PTS is enough. I even have HDTV samples that start from  8:30
oclock ;)
The real problem are the user events. And thats why I want a frame rebuild
mechanism in my vo3.

Best Regards
   Ivan Kalvachev
  iive



From michaelni at gmx.at  Fri Feb 20 18:44:04 2004
From: michaelni at gmx.at (Michael Niedermayer)
Date: Fri, 20 Feb 2004 18:44:04 +0100
Subject: [MPlayer-G2-dev] slices
In-Reply-To: <2080.212.116.154.214.1077294507.squirrel@mail.cacad.com>
References: <20040212211056.61F303103E@mail.mplayerhq.hu>
	<200402160325.46952.michaelni@gmx.at>
	<2080.212.116.154.214.1077294507.squirrel@mail.cacad.com>
Message-ID: <200402201844.04587.michaelni@gmx.at>

Hi

On Friday 20 February 2004 17:28, Ivan Kalvachev wrote:
[...]
> > slice draw callback from the codecs
> > well, arghhh
> > i probably would have to change libavcodec to support normally returning
> > after each slice and resuming, dunno how easy that would be, but i dont
> > see an
>
> It is easy, I believe libmpeg2 and xvid do this. At least in ffmpeg12
> decode_slice() is called in infinite loop (that terminate on last slice).
> But I wonder if this will give any advantage.
mpeg2 is the only standard where encoded slices must end at the right border, 
in mpeg1, mpeg4, h263, ... slices are larger and its quite likely that theres 
just a single slice per image, so encoded slices != filter slices

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en



From dalias at aerifal.cx  Fri Feb 20 23:33:00 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Fri, 20 Feb 2004 17:33:00 -0500
Subject: [MPlayer-G2-dev] slices
In-Reply-To: <20040220170822.1c4cc573.attila@kinali.ch>
References: <20040212211056.61F303103E@mail.mplayerhq.hu>
	<20040212231302.GD7862@brightrain.aerifal.cx>
	<20040220144403.4030e49d.attila@kinali.ch>
	<20040220154929.GD9096@brightrain.aerifal.cx>
	<20040220170822.1c4cc573.attila@kinali.ch>
Message-ID: <20040220223300.GG9096@brightrain.aerifal.cx>

On Fri, Feb 20, 2004 at 05:08:22PM +0100, Attila Kinali wrote:
> > For files with B frames, we could only do the slice-time OSD blending
> > for B frames or for the first frame in a closed GOP, and then blend
> > onto other frames right before displaying them. But there are some
> > difficulties about how to do it correctly if the frame is in video
> > memory. Do you:
> > 
> > (a) keep the frame buffered in system memory entirely until time to
> > display? This sounds slow.
> 
> Bad idea.

I tend to agree.

> > (b) somehow know in advance the bounding boxes of OSD elements (just
> > not their contents) and save these in system memory during the
> > draw_slice, then use them to alpha-blend OSD at display time?
> 
> Should be possible.
> I thought about a intermediate representation of the OSD
> elements where their size and position is already known.
> Actualy i'm thinking about keeping already rendered
> elements (as RGBA resp YUVA picutres) in memory, so that
> only the last step of blending has to be performed.
> But i dont know how much memory this needs and whether
> it would be faster to render it again for every frame.

AFAIK OSD elements are already prerendered and reused each frame...

> > (c) violate READABLE flag and alpha-blend in video memory, like G1
> > does... :(
> 
> I really dont want that mess again. IMHO it's better to
> sacrifice a few cpu cycles to keep the vo code clean
> otherwise we'll end up again with an vo-hell.

This doesn't "dirty" the vo. I's still done entirely in the expand
filter. It just violates the protocol by reading from a non-READABLE
buffer...

Rich




From dalias at aerifal.cx  Fri Feb 20 23:37:23 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Fri, 20 Feb 2004 17:37:23 -0500
Subject: [MPlayer-G2-dev] slices
In-Reply-To: <2080.212.116.154.214.1077294507.squirrel@mail.cacad.com>
References: <200402160325.46952.michaelni@gmx.at>
	<2080.212.116.154.214.1077294507.squirrel@mail.cacad.com>
Message-ID: <20040220223722.GH9096@brightrain.aerifal.cx>

On Fri, Feb 20, 2004 at 06:28:27PM +0200, Ivan Kalvachev wrote:
> And final words to dalias.
> I'm not sure how L2 cache works, but the CPU cache is always separated on
> instruction and data cache. So you cannot polute code by data and vise
> versa. This is so from the first Pentium and probably for 486 too (if they
> have cache at all;)

Yes, but if you run too many filters, the _decoder_ instructions will
no longer be in the instruction cache/branch prediction. Thus the next
slice will be decoded very slowly! This is bad...

> And about OSD and timer. We actually don't need astronomicat time to
> display the PTS is enough. I even have HDTV samples that start from  8:30
> oclock ;)
> The real problem are the user events. And thats why I want a frame rebuild
> mechanism in my vo3.

Frame rebuild is slow and bloated, especially if you used it for
correcting osd data on misordered frames...

Rich



From syncmail at mplayerhq.hu  Sat Feb 21 22:27:33 2004
From: syncmail at mplayerhq.hu (Arpi of Ize)
Date: Sat, 21 Feb 2004 22:27:33 +0100 (CET)
Subject: [MPlayer-G2-dev] CVS: g2/confiG2ure target.h,1.2,NONE
Message-ID: <20040221212733.A1F6531B0E@mail.mplayerhq.hu>

CVS change done by Arpi of Ize

Update of /cvsroot/mplayer/g2/confiG2ure
In directory mail:/var2/tmp/cvs-serv30182

Removed Files:
	target.h 
Log Message:
generated file


--- target.h DELETED ---



From syncmail at mplayerhq.hu  Sat Feb 21 23:10:54 2004
From: syncmail at mplayerhq.hu (Arpi of Ize)
Date: Sat, 21 Feb 2004 23:10:54 +0100 (CET)
Subject: [MPlayer-G2-dev] CVS: g2/demux demux_avi.c,1.2,1.3
Message-ID: <20040221221054.8126F31705@mail.mplayerhq.hu>

CVS change done by Arpi of Ize

Update of /cvsroot/mplayer/g2/demux
In directory mail:/var2/tmp/cvs-serv30346

Modified Files:
	demux_avi.c 
Log Message:
correctly skip unknown chunks (fixes some opendml files)


Index: demux_avi.c
===================================================================
RCS file: /cvsroot/mplayer/g2/demux/demux_avi.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- demux_avi.c	31 Jan 2004 22:29:18 -0000	1.2
+++ demux_avi.c	21 Feb 2004 22:10:52 -0000	1.3
@@ -116,24 +116,6 @@
   return ds?1:0;
 }
 
-// Select ds from ID
-static demux_stream_t* demux_avi_select_stream(demuxer_t *demux,unsigned int id){
-  int stream_id=avi_stream_id(id);
-
-//  printf("demux_avi_select_stream(%d)  {a:%d/v:%d}\n",stream_id,
-//       demux->audio->id,demux->video->id);
-
-  if(demux->streams[stream_id]) return demux->streams[stream_id];
-  
-  if(id!=mmioFOURCC('J','U','N','K')){
-     // unknown
-     mp_msg(MSGT_DEMUX,MSGL_DBG2,"Unknown chunk: %.4s (%X)\n",(char *) &id,id);
-     //abort();
-  }
-  return NULL;
-}
-
-
 // return value:
 //     0 = EOF or no stream found
 //     1 = successfully read a packet
@@ -158,8 +140,7 @@
       continue;
     }
 
-    ds=demux_avi_select_stream(demuxer,id);
-    if(ds){
+    if((ds=demuxer->streams[avi_stream_id(id)])){
 	if(ds->packs+1>=MAX_PACKS || ds->bytes+len>=MAX_PACK_BYTES){
 	    // avoid buffer overflow! switch to NI parser...
 	    mp_msg(MSGT_DEMUX,MSGL_WARN,MSGTR_SwitchToNi);
@@ -167,6 +148,11 @@
 	    return -1;
 	}
 	ret=demux_avi_read_packet(demuxer,ds,id,len,demuxer->priv->idx_pos-1,flags);
+    } else {
+        // unknown
+	if(id!=mmioFOURCC('J','U','N','K'))
+	    mp_msg(MSGT_DEMUX,MSGL_DBG2,"AVI: Unknown chunk: %.4s (%X) at 0x%X\n",(char *) &id,id, demuxer->filepos);
+	stream_skip(demuxer->stream,(len+1)&(~1));
     }
     
   } while(ret!=1);
@@ -224,7 +210,7 @@
       mp_msg(MSGT_HEADER,MSGL_V,"Found movie at 0x%X - 0x%X\n",(int)demuxer->movi_start,(int)demuxer->movi_end);
       if(demuxer->stream->end_pos>demuxer->movi_end) demuxer->movi_end=demuxer->stream->end_pos;
 //      if(index_mode==-2 || index_mode==2 || index_mode==0)
-//        break; // reading from non-seekable source (stdin) or forced index or no index forced
+        break; // reading from non-seekable source (stdin) or forced index or no index forced
       if(list_end>0) stream_seek(demuxer->stream,list_end); // skip movi
       list_end=0;
     }



From arpi at thot.banki.hu  Sat Feb 21 23:57:11 2004
From: arpi at thot.banki.hu (Arpi)
Date: Sat, 21 Feb 2004 23:57:11 +0100 (CET)
Subject: [MPlayer-G2-dev] dual licensing
Message-ID: <20040221225711.6462D312D4@mail.mplayerhq.hu>

Hi,

I know some of you refuse such things by reflex, including me.
But we should consider it in case of g2, at least for the
core code and stream/demuxer layer (at least for main formats).

Why?

There are many companies using mplayer g1 in closed products.
Either by stealing it silently (KiSS etc) or by calling it via
the slavemode interface so not hurting the gpl.
The rest of them just wants to use g1, but for some reason
they can't accept gpl, and we can't accept non-gpl, so they
don't use it (or fallback to stealing code).
Some of them would even sponsor or pay mplayer team/developers
for implementing custom features for them.
(some actually do, who accept the custom changes to be released)

As G2 is planned to be *the* media api (!= CWJ's media-api)
in a few years, we should provide a way to limited users to use
the core legally. They can choose, between free (as beer) under
gpl, or for money under a bsd-like license (which allows them
to link into closed source code).
Even if we refuse this way, only we loose. Why? They will either
- steal code, for free, ignoring gpl
- use other 'products', like libavifile, media-api, gstreamer etc.
  which (may) allow other licensing form for us

I have no experience in such licensing/legal mess, but what I
plan to reach:
- free use under GPL, _or_
- use with a paid custom license, something similar to BSD one
  (allows linking to closed src products, but keep credits)

We don't have to dual-license all of the g2 code/files.
only the core library files (including special modules, like
vo_null, vf_vo2) and some of the basic plugins
(like demux_avi, demux_mpeg, vf_scale, vf_expand etc)
mostly required for any use.


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu



From lgb at lgb.hu  Sun Feb 22 00:59:34 2004
From: lgb at lgb.hu (=?iso-8859-2?B?R+Fib3IgTOlu4XJ0?=)
Date: Sun, 22 Feb 2004 00:59:34 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040221225711.6462D312D4@mail.mplayerhq.hu>
References: <20040221225711.6462D312D4@mail.mplayerhq.hu>
Message-ID: <20040221235934.GA8181@lgb.hu>

Re,

Dunno a lot about this topic, but probably MySQL should be checked, since
it's dual licensed as well (one license is GPL). Also, - of course -
every developer or other source of even a single line code should accept
this. IMHO but IANAL.

On Sat, Feb 21, 2004 at 11:57:11PM +0100, Arpi wrote:
> I know some of you refuse such things by reflex, including me.
> But we should consider it in case of g2, at least for the
> core code and stream/demuxer layer (at least for main formats).
[...]

- G?bor (larta'H)



From syncmail at mplayerhq.hu  Sun Feb 22 01:03:58 2004
From: syncmail at mplayerhq.hu (Arpi of Ize)
Date: Sun, 22 Feb 2004 01:03:58 +0100 (CET)
Subject: [MPlayer-G2-dev] CVS: g2/demux demux_avi.c, 1.3, 1.4 demuxer.h,
	1.1.1.1, 1.2
Message-ID: <20040222000358.065C9317DD@mail.mplayerhq.hu>

CVS change done by Arpi of Ize

Update of /cvsroot/mplayer/g2/demux
In directory mail:/var2/tmp/cvs-serv30290

Modified Files:
	demux_avi.c demuxer.h 
Log Message:
avi_stream_id() moved to the right place


Index: demux_avi.c
===================================================================
RCS file: /cvsroot/mplayer/g2/demux/demux_avi.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- demux_avi.c	21 Feb 2004 22:10:52 -0000	1.3
+++ demux_avi.c	22 Feb 2004 00:03:56 -0000	1.4
@@ -41,6 +41,19 @@
 // PTS:  0=interleaved  1=BPS-based
 int pts_from_bps=1;
 
+static inline int avi_stream_id(unsigned int id){
+  unsigned char *p=(unsigned char *)&id;
+  unsigned char a,b;
+#if WORDS_BIGENDIAN
+  a=p[3]-'0'; b=p[2]-'0';
+#else
+  a=p[0]-'0'; b=p[1]-'0';
+#endif
+  if(a>9 || b>9) return 100; // invalid ID
+  return a*10+b;
+}
+
+
 static int demux_avi_read_packet(demuxer_t *demux,demux_stream_t *ds,unsigned int id,unsigned int len,int idxpos,int flags){
   int skip;
   int pts=0;

Index: demuxer.h
===================================================================
RCS file: /cvsroot/mplayer/g2/demux/demuxer.h,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- demuxer.h	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ demuxer.h	22 Feb 2004 00:03:56 -0000	1.2
@@ -275,18 +275,6 @@
 // This is defined here because demux_stream_t ins't defined in stream.h
 stream_t* new_ds_stream(demux_stream_t *ds);
 
-static inline int avi_stream_id(unsigned int id){
-  unsigned char *p=(unsigned char *)&id;
-  unsigned char a,b;
-#if WORDS_BIGENDIAN
-  a=p[3]-'0'; b=p[2]-'0';
-#else
-  a=p[0]-'0'; b=p[1]-'0';
-#endif
-  if(a>9 || b>9) return 100; // invalid ID
-  return a*10+b;
-}
-
 //demuxer_t*  new_demuxers_demuxer(demuxer_t* vd, demuxer_t* ad, demuxer_t* sd);
 
 demuxer_t* demux_open(stream_t *stream,char* name,int flags);



From gsbarbieri at yahoo.com.br  Sun Feb 22 06:14:48 2004
From: gsbarbieri at yahoo.com.br (=?iso-8859-1?q?Gustavo=20Sverzut=20Barbieri?=)
Date: Sun, 22 Feb 2004 02:14:48 -0300 (ART)
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040221225711.6462D312D4@mail.mplayerhq.hu>
Message-ID: <20040222051448.42430.qmail@web20916.mail.yahoo.com>

 --- Arpi <arpi at thot.banki.hu> escreveu: 
> Hi,
> 
> I know some of you refuse such things by reflex, including me.
> But we should consider it in case of g2, at least for the
> core code and stream/demuxer layer (at least for main formats).
> 
> Why?
> 
> There are many companies using mplayer g1 in closed products.
> Either by stealing it silently (KiSS etc) or by calling it via
> the slavemode interface so not hurting the gpl.
> The rest of them just wants to use g1, but for some reason
> they can't accept gpl, and we can't accept non-gpl, so they
> don't use it (or fallback to stealing code).
> Some of them would even sponsor or pay mplayer team/developers
> for implementing custom features for them.
> (some actually do, who accept the custom changes to be released)
> 
> As G2 is planned to be *the* media api (!= CWJ's media-api)
> in a few years, we should provide a way to limited users to use
> the core legally. They can choose, between free (as beer) under
> gpl, or for money under a bsd-like license (which allows them
> to link into closed source code).
> Even if we refuse this way, only we loose. Why? They will either
> - steal code, for free, ignoring gpl
> - use other 'products', like libavifile, media-api, gstreamer etc.
>   which (may) allow other licensing form for us
> 
> I have no experience in such licensing/legal mess, but what I
> plan to reach:
> - free use under GPL, _or_
> - use with a paid custom license, something similar to BSD one
>   (allows linking to closed src products, but keep credits)
> 
> We don't have to dual-license all of the g2 code/files.
> only the core library files (including special modules, like
> vo_null, vf_vo2) and some of the basic plugins
> (like demux_avi, demux_mpeg, vf_scale, vf_expand etc)
> mostly required for any use.
> 
> 
> A'rpi / Astral & ESP-team
> 

Hi Arpi,

Could you consider L-GPL? Since you want the core (library) to be used
everywhere, it's a better approach.
   I agree with you about preventing code stealing, I also hate that,
but puting the code in such liberal license (BSD) is too much, it will
be no different from code stealing, aside it will carry your name in
some piece of paper no one will ever read.
   Using LGPL you enforce the core remains open and that changes to it
to be back to community.
   Another problem I see is having every developer who contributed code
to accept the new license. I know you mean just the core, filters and
stuff could have their own; the core is being rewritten but how you
will deal with future contributions? You will force people to write BSD
code?  It's a difficult stuff.
   GPL -> LGPL is not that hard to convince, since the code you wrote
will remain open and under that license... some may not agree to
contribute since they don't want to help who don't want to cooperate
bi-directionally (I respect these RMS-like people).
   GPL -> BSD is much more difficult.

   And whatever you do, please add the license to EVERY file (even .h),
so if people submit changes to that file, they will be in agreement
with that license.

   I hope you won't choose BSD... today we can fight suckers like KISS,
using BSD we won't.

Gustavo

______________________________________________________________________

Yahoo! Mail - O melhor e-mail do Brasil! Abra sua conta agora:
http://br.yahoo.com/info/mail.html



From dalias at aerifal.cx  Sun Feb 22 07:34:13 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Sun, 22 Feb 2004 01:34:13 -0500
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040221225711.6462D312D4@mail.mplayerhq.hu>
References: <20040221225711.6462D312D4@mail.mplayerhq.hu>
Message-ID: <20040222063412.GQ9096@brightrain.aerifal.cx>

On Sat, Feb 21, 2004 at 11:57:11PM +0100, Arpi wrote:
> Hi,
> 
> I know some of you refuse such things by reflex, including me.
> But we should consider it in case of g2, at least for the
> core code and stream/demuxer layer (at least for main formats).

I disagree strongly.

> Why?
> 
> There are many companies using mplayer g1 in closed products.
> Either by stealing it silently (KiSS etc) or by calling it via
> the slavemode interface so not hurting the gpl.
> The rest of them just wants to use g1, but for some reason
> they can't accept gpl, and we can't accept non-gpl, so they
> don't use it (or fallback to stealing code).
> Some of them would even sponsor or pay mplayer team/developers
> for implementing custom features for them.
> (some actually do, who accept the custom changes to be released)
> 
> As G2 is planned to be *the* media api (!= CWJ's media-api)
> in a few years, we should provide a way to limited users to use
> the core legally. They can choose, between free (as beer) under

Why? Why should they even exist?? Why should we help them make money
by witholding code???????

> gpl, or for money under a bsd-like license (which allows them
> to link into closed source code).
> Even if we refuse this way, only we loose. Why? They will either

We don't lose when these things happen. _THEY_ lose. Here's why:

> - steal code, for free, ignoring gpl

If they steal code, at the very least they'll have their name dragged
through the mud and anyone respecting free software will know not to
buy from them. At best, one of more MPlayer developers sues their
asses off.

> - use other 'products', like libavifile, media-api, gstreamer etc.
>   which (may) allow other licensing form for us

If they use other systems, then their products will suck. Which means
MPlayer will be much better than them. They lose, we win. This is the
whole point of GPL.

> I have no experience in such licensing/legal mess, but what I
> plan to reach:
> - free use under GPL, _or_
> - use with a paid custom license, something similar to BSD one
>   (allows linking to closed src products, but keep credits)

BSD is absolutely totally unacceptable. I couldn't care less about
credit. The only purpose of a free software license (as opposed to
public domain) is to ensure that the code STAYS free. LGPL is open to
discussion, but IMO it sucks too.

> We don't have to dual-license all of the g2 code/files.
> only the core library files (including special modules, like
> vo_null, vf_vo2) and some of the basic plugins
> (like demux_avi, demux_mpeg, vf_scale, vf_expand etc)
> mostly required for any use.

This is still way too much. Proprietary lamers deserve NOTHING.

Rich



From gsbarbieri at yahoo.com.br  Sun Feb 22 08:51:52 2004
From: gsbarbieri at yahoo.com.br (=?iso-8859-1?q?Gustavo=20Sverzut=20Barbieri?=)
Date: Sun, 22 Feb 2004 04:51:52 -0300 (ART)
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222063412.GQ9096@brightrain.aerifal.cx>
Message-ID: <20040222075152.49491.qmail@web20908.mail.yahoo.com>

 --- D Richard Felker III <dalias at aerifal.cx> escreveu: 
> On Sat, Feb 21, 2004 at 11:57:11PM +0100, Arpi wrote:
> > Hi,
> > 
> > I know some of you refuse such things by reflex, including me.
> > But we should consider it in case of g2, at least for the
> > core code and stream/demuxer layer (at least for main formats).
> 
> I disagree strongly.
> 
> > Why?
> > 
> > There are many companies using mplayer g1 in closed products.
> > Either by stealing it silently (KiSS etc) or by calling it via
> > the slavemode interface so not hurting the gpl.
> > The rest of them just wants to use g1, but for some reason
> > they can't accept gpl, and we can't accept non-gpl, so they
> > don't use it (or fallback to stealing code).
> > Some of them would even sponsor or pay mplayer team/developers
> > for implementing custom features for them.
> > (some actually do, who accept the custom changes to be released)
> > 
> > As G2 is planned to be *the* media api (!= CWJ's media-api)
> > in a few years, we should provide a way to limited users to use
> > the core legally. They can choose, between free (as beer) under
> 
> Why? Why should they even exist?? Why should we help them make money
> by witholding code???????
> 
> > gpl, or for money under a bsd-like license (which allows them
> > to link into closed source code).
> > Even if we refuse this way, only we loose. Why? They will either
> 
> We don't lose when these things happen. _THEY_ lose. Here's why:
> 
> > - steal code, for free, ignoring gpl
> 
> If they steal code, at the very least they'll have their name dragged
> through the mud and anyone respecting free software will know not to
> buy from them. At best, one of more MPlayer developers sues their
> asses off.
> 
> > - use other 'products', like libavifile, media-api, gstreamer etc.
> >   which (may) allow other licensing form for us
> 
> If they use other systems, then their products will suck. Which means
> MPlayer will be much better than them. They lose, we win. This is the
> whole point of GPL.
> 
> > I have no experience in such licensing/legal mess, but what I
> > plan to reach:
> > - free use under GPL, _or_
> > - use with a paid custom license, something similar to BSD one
> >   (allows linking to closed src products, but keep credits)
> 
> BSD is absolutely totally unacceptable. I couldn't care less about
> credit. The only purpose of a free software license (as opposed to
> public domain) is to ensure that the code STAYS free. LGPL is open to
> discussion, but IMO it sucks too.
> 
> > We don't have to dual-license all of the g2 code/files.
> > only the core library files (including special modules, like
> > vo_null, vf_vo2) and some of the basic plugins
> > (like demux_avi, demux_mpeg, vf_scale, vf_expand etc)
> > mostly required for any use.
> 
> This is still way too much. Proprietary lamers deserve NOTHING.
> 
> Rich

   I beg to agree to Rich. This complements what I said in my other
email - no BSD, PLEASE!

Gustavo


______________________________________________________________________

Yahoo! Mail - O melhor e-mail do Brasil! Abra sua conta agora:
http://br.yahoo.com/info/mail.html



From gabucino at mplayerhq.hu  Sun Feb 22 10:57:06 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Sun, 22 Feb 2004 10:57:06 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222075152.49491.qmail@web20908.mail.yahoo.com>
References: <20040222063412.GQ9096@brightrain.aerifal.cx>
	<20040222075152.49491.qmail@web20908.mail.yahoo.com>
Message-ID: <20040222095706.GA9230@woodstock.localdomain>

Gustavo Sverzut Barbieri wrote:
>    I beg to agree to Rich. This complements what I said in my other
> email - no BSD, PLEASE!
Stop quoting whole mail messages!

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040222/28e7349c/attachment.pgp>

From gabucino at mplayerhq.hu  Sun Feb 22 11:15:23 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Sun, 22 Feb 2004 11:15:23 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040221225711.6462D312D4@mail.mplayerhq.hu>
References: <20040221225711.6462D312D4@mail.mplayerhq.hu>
Message-ID: <20040222101523.GB9230@woodstock.localdomain>

Having handled the Kiss Technology case, I absolutely agree with the
dual-licensing. Its point is what Richard and the other guy didn't notice:
we lose nothing with it. We have all the advantages of the GPL (we can
sue anybody who fucking steals it), _BUT_ if the "offender" firm plays nice
they will pay big bucks to us for using our code.

On the other hand - if we don't have dual-licensing -, the just steal it period
and we'll have to go to the court to get the compensation (and justice) we
deserve.

For us, for firms, dual-licensing is a _possibility_ and not a _restriction_.
Either we use it, or we don't. I suggest we do, and advertise it. So firms
can purchase their sorry ass - but save headaches for both sides.

(FYI: libmad is dual-licensed, and I already know about a firm which has a
dual-license contract on it. _And_, that very same firm has stolen a big GPL
code because it wasn't available on a second license, and then a large war
erupted nearly stopping the project's development.. My (and Arpi's) point is:

 - firms DO steal -> court -> lotsa time+money consumed -> success doubtful
 - firms use the second license -> money receipt or whatever

About developer agreement about the second license: Fabrice already sells
ffmpeg since years (with no advertised duallicensing), and I don't remember
ever asking anybody for his agreement.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040222/ca53e85b/attachment.pgp>

From attila at kinali.ch  Sun Feb 22 11:40:22 2004
From: attila at kinali.ch (Attila Kinali)
Date: Sun, 22 Feb 2004 11:40:22 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222101523.GB9230@woodstock.localdomain>
References: <20040221225711.6462D312D4@mail.mplayerhq.hu>
	<20040222101523.GB9230@woodstock.localdomain>
Message-ID: <20040222114022.27818ca1.attila@kinali.ch>

On Sun, 22 Feb 2004 11:15:23 +0100
Gabucino <gabucino at mplayerhq.hu> wrote:

> 
>  - firms DO steal -> court -> lotsa time+money consumed -> success doubtful
>  - firms use the second license -> money receipt or whatever

I have to agree here. Although we are a large project, we're still
only individuals. We cannot really defend ourselfs at court if we
have to. On the otherhand if we can prevent companies from stealing
our code by a dual license, we might get some contributions from their
side.

Now the discussion whether it should be gpl/bsd or gpl/lgpl
isn't one at all (fortnunately or unfortunately ?). We already
use a lot of third party gpl/lgpl code which we cannot relicense
under bsd, thus we have to stick with gpl/lgpl.

Something else we should keep in mind is the exact terms when
we allow the use of one or the other license. Ie whether we 
allow people to use the license they want or whether we restrict
it depending on the use of the code.

And if we choose a dual license, we should apply it to the whole
projcet, not just parts of it. Otherwise we'll end up in a
license hell where nobody knows what may be used and what not.

			Attila Kinali

-- 
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
			-- reeler in +kaosu



From gabucino at mplayerhq.hu  Sun Feb 22 12:06:03 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Sun, 22 Feb 2004 12:06:03 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222114022.27818ca1.attila@kinali.ch>
References: <20040221225711.6462D312D4@mail.mplayerhq.hu>
	<20040222101523.GB9230@woodstock.localdomain>
	<20040222114022.27818ca1.attila@kinali.ch>
Message-ID: <20040222110603.GB9691@woodstock.localdomain>

Attila Kinali wrote:
> Now the discussion whether it should be gpl/bsd or gpl/lgpl
> isn't one at all (fortnunately or unfortunately ?). We already
> use a lot of third party gpl/lgpl code which we cannot relicense
> under bsd, thus we have to stick with gpl/lgpl.
Let's continue this thread on mplayer-legal mailing list IMHO.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040222/5a8cf407/attachment.pgp>

From arpi at thot.banki.hu  Sun Feb 22 14:23:19 2004
From: arpi at thot.banki.hu (Arpi)
Date: Sun, 22 Feb 2004 14:23:19 +0100 (CET)
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222114022.27818ca1.attila@kinali.ch>
Message-ID: <20040222132319.AAC0B31878@mail.mplayerhq.hu>

Hi,


Rich: you misunderstood my mail. read it again please.
i do NOT want it to be under the BSD license.
I proposed something to dual-license it under GPL (or LGPL) and
a commercial license, which allows the license buyer similar things
like the BSD one (compile into closedsrc code, preserve credits)

The key point here is that they cannot use that bsd-like thing for free,
they have to buy it, for lots of money. Ie they dont steal your code, they
buy it. (it's the next topic, to how to handle the money. we clearly need
a company for that, and what to do with the money: share between
developers, buy hw for developers, buy hw for server etc...)

> On Sun, 22 Feb 2004 11:15:23 +0100
> Gabucino <gabucino at mplayerhq.hu> wrote:
> 
> > 
> >  - firms DO steal -> court -> lotsa time+money consumed -> success doubtful

Sure. In case of Kiss, we were lucky. It was quite easy to prove they steal
code, as they steal mpalyer's internal format mpsub, and the 'unknown' sub,
and had the sscanf() strings unmodified. Anywya it would be still
problematic to prove this at the court.

Also, the best we can reach with gpl license, is that they will remove
the gpl'ed code from their product (ie. pay someone to re-write from
scratch, but they'll still using our ideas and algorithms, as they are
not patented).

If we have a dual license, we can sue them for causing monetary damage,
by not buying license, or sell them licenses.

> >  - firms use the second license -> money receipt or whatever
> 
> I have to agree here. Although we are a large project, we're still
> only individuals. We cannot really defend ourselfs at court if we
> have to. On the otherhand if we can prevent companies from stealing
> our code by a dual license, we might get some contributions from their
> side.

Yes.

> Now the discussion whether it should be gpl/bsd or gpl/lgpl
> isn't one at all (fortnunately or unfortunately ?). We already
> use a lot of third party gpl/lgpl code which we cannot relicense
> under bsd, thus we have to stick with gpl/lgpl.

Don't mix g1 and g2.
I'm talking about g2 only, dual licensing of g1 is impossible.

g2 code is mostly clean, most of the core was written by me alone,
some of the plugins was written/ported by someone else.
it's not too late to ask agreement from contributors now, and
remove code if they don't agree. future contributors have to
accept the dual licensing. they did in the past for libavcodec,
which has such license since years.
(as Fabrice's employer company is using it in closedsrc product)

> Something else we should keep in mind is the exact terms when
> we allow the use of one or the other license. Ie whether we 
> allow people to use the license they want or whether we restrict
> it depending on the use of the code.

yes

> And if we choose a dual license, we should apply it to the whole
> projcet, not just parts of it. Otherwise we'll end up in a
> license hell where nobody knows what may be used and what not.

it cannot be done. we won't be able to get Michael to dual-license
his code, or get libmpeg2 to do so.
it will be even problematic to get swscaler under such license, which
is required for g2 to work...

so we can keep the core and required plugins under dual license,
and let optional parts, codecs, libs, plugins to be gpl only.
plugins can even be under incompatible license (think of 3rd
party binary codecs, like the 3ivx ones for xanim/openqt).


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu



From attila at kinali.ch  Sun Feb 22 14:41:40 2004
From: attila at kinali.ch (Attila Kinali)
Date: Sun, 22 Feb 2004 14:41:40 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
References: <20040222114022.27818ca1.attila@kinali.ch>
	<20040222132319.AAC0B31878@mail.mplayerhq.hu>
Message-ID: <20040222144140.3fc8a306.attila@kinali.ch>

On Sun, 22 Feb 2004 14:23:19 +0100 (CET)
Arpi <arpi at thot.banki.hu> wrote:


> Rich: you misunderstood my mail. read it again please.
> i do NOT want it to be under the BSD license.
> I proposed something to dual-license it under GPL (or LGPL) and
> a commercial license, which allows the license buyer similar things
> like the BSD one (compile into closedsrc code, preserve credits)
> 
> The key point here is that they cannot use that bsd-like thing for free,
> they have to buy it, for lots of money. Ie they dont steal your code, they
> buy it. (it's the next topic, to how to handle the money. we clearly need
> a company for that, and what to do with the money: share between
> developers, buy hw for developers, buy hw for server etc...)

Hmm... This makes things a bit complicated.
Ie we'll need, as Kis Gergely suggested, a company or rather
a small foundation to handle that.
What i dont like about this idea is, that we'll get quite
an amount of legal stuff to handle which takes a lot of time.


> > And if we choose a dual license, we should apply it to the whole
> > projcet, not just parts of it. Otherwise we'll end up in a
> > license hell where nobody knows what may be used and what not.
> 
> it cannot be done. we won't be able to get Michael to dual-license
> his code, or get libmpeg2 to do so.
> it will be even problematic to get swscaler under such license, which
> is required for g2 to work...

That was what i meant with the problems of dual licensing.
 
> so we can keep the core and required plugins under dual license,
> and let optional parts, codecs, libs, plugins to be gpl only.
> plugins can even be under incompatible license (think of 3rd
> party binary codecs, like the 3ivx ones for xanim/openqt).

Remember that discussion about whether we may legaly use
dlls together with mplayer ?


			Attila Kinali

-- 
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
			-- reeler in +kaosu



From michaelni at gmx.at  Sun Feb 22 15:24:28 2004
From: michaelni at gmx.at (Michael Niedermayer)
Date: Sun, 22 Feb 2004 15:24:28 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
References: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
Message-ID: <200402221524.28906.michaelni@gmx.at>

Hi

On Sunday 22 February 2004 14:23, Arpi wrote:
[...]
> it's not too late to ask agreement from contributors now, and
> remove code if they don't agree. future contributors have to
> accept the dual licensing. they did in the past for libavcodec,
> which has such license since years.
> (as Fabrice's employer company is using it in closedsrc product)
if anyone tells me enough to verify that, actually i dont even know who 
fabrices employer company is, and if he is seriously violating it, like 
keeping improvements closed source then ill ensure he stops, but i wont 
complain if hes just ignoring some detail of the lgpl like everyone else

btw, IMHO dual licensing will mean mplayer G2s death, ppl simply wont 
contribute anymore, or would u contribute to a project for which someone else 
gets alot of money?

[...]

-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en



From gabucino at mplayerhq.hu  Sun Feb 22 15:54:09 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Sun, 22 Feb 2004 15:54:09 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <200402221524.28906.michaelni@gmx.at>
References: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
	<200402221524.28906.michaelni@gmx.at>
Message-ID: <20040222145409.GA1310@woodstock.localdomain>

Michael Niedermayer wrote:
> btw, IMHO dual licensing will mean mplayer G2s death, ppl simply wont 
> contribute anymore, or would u contribute to a project for which someone else 
> gets alot of money?
The question is: would _you_ ?

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040222/d5bf6b52/attachment.pgp>

From arpi at thot.banki.hu  Sun Feb 22 15:58:17 2004
From: arpi at thot.banki.hu (Arpi)
Date: Sun, 22 Feb 2004 15:58:17 +0100 (CET)
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <200402221524.28906.michaelni@gmx.at>
Message-ID: <20040222145817.B89A43187E@mail.mplayerhq.hu>

Hi,

> btw, IMHO dual licensing will mean mplayer G2s death, ppl simply wont 
> contribute anymore, or would u contribute to a project for which someone else 
> gets alot of money?

It depends.
I would, if
- it's only a small contribution (few-liner fix etc)
- it's a feature i need, and i want it to be in the cvs
- i know that the money they (the developers, not "someone else") receive
  is all spent on the development (buying server hardware/hosting, hardware
  for developers, documents (ieee/iso standards, chip specs...) etc)
  don't worry, it won't be spent on malaysian bitches for gabucino :)

Anyway contributions to core is very rare, and even then it's either a
big cosmetics mess or something broken code :)
Most contributions are plugins/modules, ie. new codecs, demuxers, vo
drivers, filters, and they may be single-licensed too.
(ie license buyers are not allowed to use them in closed code)
Although i vote for dual-licensing as much as possible.


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu



From r_togni at tiscali.it  Sun Feb 22 16:31:04 2004
From: r_togni at tiscali.it (Roberto Togni)
Date: Sun, 22 Feb 2004 16:31:04 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222132319.AAC0B31878@mail.mplayerhq.hu> (from
	arpi@thot.banki.hu on Sun, Feb 22, 2004 at 14:23:19 +0100)
References: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
Message-ID: <20040222153104.GC1267@tower2.myhome.qwe>

On 2004.02.22 14:23, Arpi wrote:
> Hi,
Hi all.
[...]
> buy it. (it's the next topic, to how to handle the money. we clearly
> need
> a company for that, and what to do with the money: share between
> developers,
I see it very difficult. Thinking about Italian laws, a company won't  
pay you with a suitcase full of currency, you will need some legal  
entity (a company, a foundation, a single-man company, ..) to receive  
the money. Then you have to redistribute them to developers, that will  
have to receive them and pay income taxes on them. Speaking for myself,  
unless it's a big amount, i probably won't take them.
> buy hw for developers, buy hw for server etc...)
That's probably easier, but you still have to receive the money first.
>
[...]
> > >  - firms DO steal -> court -> lotsa time+money consumed ->  
> success
> doubtful
Not possible in real world. Think about sueing a company (let's hope  
it's not a big one), maybe in a foreign country, and having to prove  
that they stole your code: it will take lot of money, time and  
resources. It's not doable by an individual. The only hope (if any) is  
to have some association like FSF to support you, but going commercial  
is not the best way to encourage them to help you.

> 
> Also, the best we can reach with gpl license, is that they will  
> remove
> the gpl'ed code from their product (ie. pay someone to re-write from
> scratch, but they'll still using our ideas and algorithms, as they  
> are
> not patented).
The opposite is also true: we're able to use other people ideas and  
patents because we don't make money on it, else they'll probably sue  
us.

> g2 code is mostly clean, most of the core was written by me alone,
> some of the plugins was written/ported by someone else.
> it's not too late to ask agreement from contributors now, and
> remove code if they don't agree. future contributors have to
> accept the dual licensing. they did in the past for libavcodec,
> which has such license since years.
> (as Fabrice's employer company is using it in closedsrc product)
??? Do you mean using code in violation of LGPL?
AFAIK libavcodec does not have a double license, it just contains some  
optional GPL'd code. At least there's no mention of a double licence in  
the docs, and noone asked me if i agreed to double licence my  
contributions (i speak only for myself, i don't know if other developer  
agreed to such a double licence).

If we're going to a double licence system , it has to be made very  
clear to every contributor.

 
> > And if we choose a dual license, we should apply it to the whole
> > projcet, not just parts of it. Otherwise we'll end up in a
> > license hell where nobody knows what may be used and what not.
Agree, see below. We can only make an exception for some very optional  
features noone cares about.
> 
> it cannot be done. we won't be able to get Michael to dual-license
> his code, or get libmpeg2 to do so.
> it will be even problematic to get swscaler under such license, which
> is required for g2 to work...
I think that's the main thing, that have to be discussed before we  
start fighting about the licence: what capabilities will the core have?
Suppose a company buys a licence for the code, what will that code be  
able to do?
- No codecs: native codecs are mostly in libavcodec, win32 loader is on  
the edge of legality (and it comes form avilib anyway, so can't be  
relicensed), xanim and real loaders are legal, but the use of the  
binary codecs outside the program they come with is not. External  
libraries (xvid, libmad, ...) are outside our control, i don't know if  
they have a double licence. They will probably be able to buy a licence  
for DivX.
- Which demuxers? Surely not asf (patented, legal problems in the past,  
don't know if things are different now), avi, probably mpeg.
- Filters: it depends on the filter authors, if they agree on the  
double license, and assuming that the filter algorithm is not patented.
- Input: no DVD (css mess), no streaming (no Real, doubtly mms, rstp  
uses external library).
- And so on, this list is surely incomplete.

For most existing stuff (filters, demuxers, input modules, vo, ao, ..),  
unless we want to rewrite everything from scratch, we need agreement  
from every contributor.

So, what will you be able to do with the core alone? Buy a licence for  
it and then steal all other stuff, assuming that the MPlayer team won't  
go after you because you licenced the core? :)))))

And remember that the company will also have to get a licence for all  
the patented stuff (supposing they can do it), if they want to use the  
code commercially: we're getting away with it only because we make no  
money with MPlayer.

MPlayer is used because of what's able to do: if it can't do anything,  
noone will care about licensing it.


IMHO, the only viable option is putting the code on a licence more  
"commercial friendly" than GPL, but still accepted as free, like LGPL,  
and have companies pay developers to enhance/mantain/bugfix the code.
That will solve a lot of problems:
- No legal entity required for MPlayer team, companies interact with  
developers at a personal level
- Companies will be on their own with the patents/trade secrets/ 
intellectual property mess (we are not selling the code)
- MPlayer will remain a free software project: not upsetting  
developers, not scaring away contributors, with no obligation to the  
users of the code
- no "religion wars" from free sw fundamentalists against MPlayer (bad  
publicity, less contributors)

But we still need agreement from developers, and we must be sure that  
this will bring us enough advantages to compensate the troubles.


> A'rpi / Astral & ESP-team
Ciao,
 Roberto



From michaelni at gmx.at  Sun Feb 22 16:56:26 2004
From: michaelni at gmx.at (Michael Niedermayer)
Date: Sun, 22 Feb 2004 16:56:26 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222145409.GA1310@woodstock.localdomain>
References: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
	<200402221524.28906.michaelni@gmx.at>
	<20040222145409.GA1310@woodstock.localdomain>
Message-ID: <200402221656.26596.michaelni@gmx.at>

Hi

On Sunday 22 February 2004 15:54, Gabucino wrote:
> Michael Niedermayer wrote:
> > btw, IMHO dual licensing will mean mplayer G2s death, ppl simply wont
> > contribute anymore, or would u contribute to a project for which someone
> > else gets alot of money?
>
> The question is: would _you_ ?
no, but there may be exceptions like a few line change like arpi said but 
anyway i dont know enough about the mplayer-g2 core to contribute any 
non-trivial things

-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en



From syncmail at mplayerhq.hu  Sun Feb 22 17:19:09 2004
From: syncmail at mplayerhq.hu (Arpi of Ize)
Date: Sun, 22 Feb 2004 17:19:09 +0100 (CET)
Subject: [MPlayer-G2-dev] CVS: g2/audio dec_audio.c,1.1.1.1,1.2
Message-ID: <20040222161909.8754331818@mail.mplayerhq.hu>

CVS change done by Arpi of Ize

Update of /cvsroot/mplayer/g2/audio
In directory mail:/var2/tmp/cvs-serv28061/audio

Modified Files:
	dec_audio.c 
Log Message:
- demuxer: changed PTS handling, export native PTS (based on rate_m/rate_d)
instead of scaled up by rate_m
- demux_avi: fixed nobps sync mode, when video chunkc come before audio ones
- demux_mpg: div native pts by 4, to fit 33 bits pts into 31 bits (signed int)


Index: dec_audio.c
===================================================================
RCS file: /cvsroot/mplayer/g2/audio/dec_audio.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- dec_audio.c	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ dec_audio.c	22 Feb 2004 16:19:07 -0000	1.2
@@ -417,7 +417,8 @@
           float d=(sh_audio->a_in_buffer_len)/(float)sh_audio->i_bps;
           float d2=(sh_audio->ds->flags&DEMUX_STREAM_FLAG_PTS_FOR_BLOCK) ? 0.0 : 
 	    (dl2/(float)sh_audio->i_bps);
-          sh_audio->pts=(double)sh_audio->ds->pts/(double)sh_audio->ds->rate_m + d2 - d;
+          sh_audio->pts=(double)sh_audio->ds->pts*(double)sh_audio->ds->rate_d/(double)sh_audio->ds->rate_m + d2 - d;
+//	  printf("ZZZ a_pts=%8.8f\n",(float)sh_audio->pts);
           mp_msg(MSGT_AVSYNC,MSGL_DBG2,"dec_audio: a_pts=%8.3f+%5.3f-%5.3f=%8.3f [+%d-%d] \n",
 	    (float)sh_audio->ds->pts,d2,d,(float)sh_audio->pts, dl2, sh_audio->a_in_buffer_len);
 	  sh_audio->ds->pts=0;



From syncmail at mplayerhq.hu  Sun Feb 22 17:19:09 2004
From: syncmail at mplayerhq.hu (Arpi of Ize)
Date: Sun, 22 Feb 2004 17:19:09 +0100 (CET)
Subject: [MPlayer-G2-dev] CVS: g2/video vd_libmpeg2.c, 1.1.1.1, 1.2 vf_vd.c,
	1.1.1.1, 1.2
Message-ID: <20040222161909.CFFFC317C1@mail.mplayerhq.hu>

CVS change done by Arpi of Ize

Update of /cvsroot/mplayer/g2/video
In directory mail:/var2/tmp/cvs-serv28061/video

Modified Files:
	vd_libmpeg2.c vf_vd.c 
Log Message:
- demuxer: changed PTS handling, export native PTS (based on rate_m/rate_d)
instead of scaled up by rate_m
- demux_avi: fixed nobps sync mode, when video chunkc come before audio ones
- demux_mpg: div native pts by 4, to fit 33 bits pts into 31 bits (signed int)


Index: vd_libmpeg2.c
===================================================================
RCS file: /cvsroot/mplayer/g2/video/vd_libmpeg2.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- vd_libmpeg2.c	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ vd_libmpeg2.c	22 Feb 2004 16:19:07 -0000	1.2
@@ -209,7 +209,8 @@
         	    mpi->qstride=info->sequence->picture_width>>4;
 #endif
 		    if((info->display_picture->flags&PIC_FLAG_PTS)){
-			mpi->pts=(double)info->display_picture->pts/(double)sh->ds->rate_m;
+			mpi->pts=(double)((int)info->display_picture->pts)*(double)sh->ds->rate_d/(double)sh->ds->rate_m;
+//			printf("ZZZ v_pts=%8.8f\n",(float)mpi->pts);
 			if(delay_flag) mpi->pts-=info->sequence->frame_period/(2*2*27000000.0);
 			mpi->pts_flags|=MP_PTSFLAG_PTS_AVAIL;
 		    }

Index: vf_vd.c
===================================================================
RCS file: /cvsroot/mplayer/g2/video/vf_vd.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- vf_vd.c	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ vf_vd.c	22 Feb 2004 16:19:07 -0000	1.2
@@ -61,7 +61,7 @@
 	in_size=ds_get_packet(vf->priv->sh->ds,&start);
 	if(in_size<0) return NULL; // demux error / EOF
 	if(sh->ds->pts_packs==0)   // we have fresh pts
-	    pts=(double)sh->ds->pts/(double)sh->ds->rate_m;
+	    pts=(double)sh->ds->pts*(double)sh->ds->rate_d/(double)sh->ds->rate_m;
     }
     
     if(sh->ds->rate_m) frametime=(float)sh->ds->rate_d/(float)sh->ds->rate_m;



From syncmail at mplayerhq.hu  Sun Feb 22 17:19:09 2004
From: syncmail at mplayerhq.hu (Arpi of Ize)
Date: Sun, 22 Feb 2004 17:19:09 +0100 (CET)
Subject: [MPlayer-G2-dev] 
	CVS: g2/demux demux_asf.c, 1.1.1.1, 1.2 demux_avi.c,
	1.4, 1.5 demux_mpeg.c, 1.1.1.1, 1.2 demux_ogg.c, 1.2, 1.3
Message-ID: <20040222161909.D899F31818@mail.mplayerhq.hu>

CVS change done by Arpi of Ize

Update of /cvsroot/mplayer/g2/demux
In directory mail:/var2/tmp/cvs-serv28061/demux

Modified Files:
	demux_asf.c demux_avi.c demux_mpeg.c demux_ogg.c 
Log Message:
- demuxer: changed PTS handling, export native PTS (based on rate_m/rate_d)
instead of scaled up by rate_m
- demux_avi: fixed nobps sync mode, when video chunkc come before audio ones
- demux_mpg: div native pts by 4, to fit 33 bits pts into 31 bits (signed int)


Index: demux_asf.c
===================================================================
RCS file: /cvsroot/mplayer/g2/demux/demux_asf.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- demux_asf.c	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ demux_asf.c	22 Feb 2004 16:19:07 -0000	1.2
@@ -440,7 +440,7 @@
       switch(ASF_LOAD_GUID_PREFIX(streamh.type)){
       case ASF_GUID_PREFIX_audio_stream: {
         demux_stream_t* ds=new_demuxer_stream(demuxer,streamh.stream_no & 0x7F,DEMUX_STREAM_TYPE_AUDIO);
-	ds->rate_m=1000; // PTS is 1/1000 seconds based
+	ds->rate_d=1;ds->rate_m=1000; // PTS is 1/1000 seconds based
 	ds->priv=calloc(sizeof(struct demux_stream_priv_s),1);
 	ds->ms_header_size=(streamh.type_size<sizeof(WAVEFORMATEX))?sizeof(WAVEFORMATEX):streamh.type_size;
 	ds->ms_header=calloc(ds->ms_header_size,1);
@@ -464,7 +464,7 @@
       case ASF_GUID_PREFIX_video_stream: {
         demux_stream_t* ds=new_demuxer_stream(demuxer,streamh.stream_no & 0x7F,DEMUX_STREAM_TYPE_VIDEO);
         unsigned int len=streamh.type_size-(4+4+1+2);
-	ds->rate_m=1000; // PTS is 1/1000 seconds based
+	ds->rate_d=1;ds->rate_m=1000; // PTS is 1/1000 seconds based
 	ds->priv=calloc(sizeof(struct demux_stream_priv_s),1);
 	ds->ms_header_size=(len<sizeof(BITMAPINFOHEADER))?sizeof(BITMAPINFOHEADER):len;
 	ds->ms_header=calloc(ds->ms_header_size,1);

Index: demux_avi.c
===================================================================
RCS file: /cvsroot/mplayer/g2/demux/demux_avi.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- demux_avi.c	22 Feb 2004 00:03:56 -0000	1.4
+++ demux_avi.c	22 Feb 2004 16:19:07 -0000	1.5
@@ -68,18 +68,18 @@
 	      float delay=0;
 	      if(ds->bitrate)
 	          delay=ds->priv->pts_corr_bytes*8/(float)ds->bitrate;
-	      mp_msg(MSGT_DEMUX,MSGL_V,"XXX initial  v_pts=%5.3f  a_pos=%d (%5.3f) \n",ds->priv->avi_audio_pts,ds->priv->pts_corr_bytes,delay);
 	      //priv->pts_correction=-priv->avi_audio_pts+delay;
-	      ds->priv->pts_correction=delay*(float)ds->rate_m-ds->priv->avi_audio_pts;
-	      ds->priv->avi_audio_pts+=ds->priv->pts_correction;
+	      ds->priv->pts_correction=(delay - demux->priv->avi_video_pts)*(float)ds->rate_m/(float)ds->rate_d;
+	      mp_msg(MSGT_DEMUX,MSGL_V,"XXX initial  v_pts=%5.8f  a_pos=%d (%5.8f) corr=%d  \n",demux->priv->avi_video_pts,ds->priv->pts_corr_bytes,delay,ds->priv->pts_correction);
+//	      ds->priv->avi_audio_pts+=ds->priv->pts_correction;
 	      ds->priv->pts_corrected=1;
 	  } else
 	      ds->priv->pts_corr_bytes+=len;
       }
       if(pts_from_bps){
-	  pts = ds->priv->audio_block_no * (float)ds->rate_d; // / (float)ds->rate_m;
+	  pts = ds->priv->audio_block_no;
       } else {
-	  pts=demux->priv->avi_video_pts*(float)ds->rate_m;
+	  pts=demux->priv->avi_video_pts*(float)ds->rate_m/(float)ds->rate_d;
 	  pts+=ds->priv->pts_correction;
 	  if(pts==ds->priv->avi_audio_pts)
 	      pts=0;
@@ -101,10 +101,9 @@
        ++ds->priv->video_pack_no;
        ds=NULL;
      } else {
-       pts = ds->priv->video_pack_no * ds->rate_d;
-       demux->priv->avi_video_pts = ds->priv->video_pack_no *
-         (float)ds->rate_d/(float)ds->rate_m;
-//          printf("\rYYY-V  A: %5.3f  V: %5.3f  \n",priv->avi_audio_pts,priv->avi_video_pts);
+       pts = ds->priv->video_pack_no;
+       demux->priv->avi_video_pts = pts * (float)ds->rate_d/(float)ds->rate_m;
+//       printf("\rYYY-V  Vpts: %5.8f  \n",demux->priv->avi_video_pts);
        demux->priv->pts_has_video=1;
        ++ds->priv->video_pack_no;
      }
@@ -118,7 +117,7 @@
   
   if(ds && !ds->ignore){
     mp_dbg(MSGT_DEMUX,MSGL_DBG2,"DEMUX_AVI: Read %d data bytes from packet %04X\n",len,id);
-//    printf("READ[%c] %5.3f  (%d)   \n",ds==demux->video?'V':'A',pts,len);
+//    printf("READ[%d] %d  (%d)   \n",ds->type,pts,len);
     ds_read_packet(ds,demux->stream,len,pts,idxpos,flags);
     skip-=len;
   }

Index: demux_mpeg.c
===================================================================
RCS file: /cvsroot/mplayer/g2/demux/demux_mpeg.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- demux_mpeg.c	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ demux_mpeg.c	22 Feb 2004 16:19:07 -0000	1.2
@@ -140,7 +140,8 @@
     ++mpeg_pts_error;
     return 0; // invalid pts
   }
-  pts=(((c>>1)&7)<<30)|((d>>1)<<15)|(e>>1); // 33 bits, MSB lost
+//  pts=(((c>>1)&7)<<30)|((d>>1)<<15)|(e>>1); // 33 bits, 1 MSB lost
+  pts=(((c>>1)&7)<<28)|((d>>1)<<13)|((e>>1)>>2); // 31 bits, 2 LSB lost
   mp_dbg(MSGT_DEMUX,MSGL_DBG3,"{%d}",pts);
   return pts;
 }
@@ -354,7 +355,8 @@
     if(!ds){
 	// register new stream!
 	ds=new_demuxer_stream(demuxer, (pid<0) ? id : pid, type);
-	ds->rate_m=90000; // PTS base
+	ds->rate_d=1;
+	ds->rate_m=90000/4; // PTS base
 	ds->format=format;
 	ds->flags|=ds_flags;
 	ds->priv=calloc(sizeof(struct demux_stream_priv_s),1);

Index: demux_ogg.c
===================================================================
RCS file: /cvsroot/mplayer/g2/demux/demux_ogg.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- demux_ogg.c	31 Jan 2004 22:27:11 -0000	1.2
+++ demux_ogg.c	22 Feb 2004 16:19:07 -0000	1.3
@@ -251,7 +251,7 @@
 	    if(granule_pos){
 		// we have a pts!
 		if(ds->rate_m)
-		    dp->pts=(granule_pos+1)*(double)ds->rate_d;
+		    dp->pts=(granule_pos+1); //*(double)ds->rate_d;
 		//    dp->pts=(granule_pos+1)*(double)ds->rate_d/(double)ds->rate_m;
 		//printf("OGG: #%d %8d  %5.3f\n",ds->id,(int)granule_pos,(float)dp->pts);
 		granule_pos=0; // !!!!!!!



From gabucino at mplayerhq.hu  Sun Feb 22 17:24:36 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Sun, 22 Feb 2004 17:24:36 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222153104.GC1267@tower2.myhome.qwe>
References: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
	<20040222153104.GC1267@tower2.myhome.qwe>
Message-ID: <20040222162436.GA7486@woodstock.localdomain>

Roberto Togni wrote:
> pay you with a suitcase full of currency, you will need some legal  
> entity (a company, a foundation, a single-man company, ..) to receive  
> the money.
Assuming it is true, I could think about UHU Linux (a hungarian Linux
distributor), it has the neccessary stuff to receive dough for us.


> that they stole your code: it will take lot of money, time and  
> resources. It's not doable by an individual.
No it isn't. But MPlayer is much more than a project of certain individuals.
That became very clear for me during the Kiss case.


> The only hope (if any) is to have some association like FSF to support you,
> but going commercial is not the best way to encourage them to help you.
FSF = 0


> >(as Fabrice's employer company is using it in closedsrc product)
> ??? Do you mean using code in violation of LGPL?
Good morning!


> AFAIK libavcodec does not have a double license
It does (unpublic), you can see that in the archives too afair.


> So, what will you be able to do with the core alone? Buy a licence for  
> it and then steal all other stuff, assuming that the MPlayer team won't  
> go after you because you licenced the core? :)))))
That's not our problem, is it.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040222/28e29a88/attachment.pgp>

From dalias at aerifal.cx  Sun Feb 22 17:58:30 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Sun, 22 Feb 2004 11:58:30 -0500
Subject: [MPlayer-G2-dev] CVS: g2/audio dec_audio.c,1.1.1.1,1.2
In-Reply-To: <20040222161909.8754331818@mail.mplayerhq.hu>
References: <20040222161909.8754331818@mail.mplayerhq.hu>
Message-ID: <20040222165830.GR9096@brightrain.aerifal.cx>

On Sun, Feb 22, 2004 at 05:19:09PM +0100, Arpi of Ize wrote:
> CVS change done by Arpi of Ize
> 
> Update of /cvsroot/mplayer/g2/audio
> In directory mail:/var2/tmp/cvs-serv28061/audio
> 
> Modified Files:
> 	dec_audio.c 
> Log Message:
> - demuxer: changed PTS handling, export native PTS (based on rate_m/rate_d)
> instead of scaled up by rate_m
> - demux_avi: fixed nobps sync mode, when video chunkc come before audio ones
> - demux_mpg: div native pts by 4, to fit 33 bits pts into 31 bits (signed int)

PTS needs to be 64bit anyway... IMO this dividing is unnecessary.

Rich



From dalias at aerifal.cx  Sun Feb 22 18:03:03 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Sun, 22 Feb 2004 12:03:03 -0500
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222101523.GB9230@woodstock.localdomain>
References: <20040221225711.6462D312D4@mail.mplayerhq.hu>
	<20040222101523.GB9230@woodstock.localdomain>
Message-ID: <20040222170303.GS9096@brightrain.aerifal.cx>

On Sun, Feb 22, 2004 at 11:15:23AM +0100, Gabucino wrote:
> Having handled the Kiss Technology case, I absolutely agree with the
> dual-licensing. Its point is what Richard and the other guy didn't notice:
> we lose nothing with it. We have all the advantages of the GPL (we can
> sue anybody who fucking steals it), _BUT_ if the "offender" firm plays nice
> they will pay big bucks to us for using our code.

And everyone in the world loses freedom. Getting big bucks is not the
purpose. Maybe you want big bucks to impress teenie girls on the
beach, but I couldn't care less about such nonsense.

> On the other hand - if we don't have dual-licensing -, the just steal it period
> and we'll have to go to the court to get the compensation (and justice) we
> deserve.

If we go to court, we get the _real_ compensation we deserve: freedom
of the code. Or at least the court forces them to halt distribution,
in which case their product sucks and more people will use MPlayer
instead.

> About developer agreement about the second license: Fabrice already sells
> ffmpeg since years (with no advertised duallicensing), and I don't remember
> ever asking anybody for his agreement.

AFAIK Fabrice does this under the terms of the LGPL. This is very
different. He only holds copyright to a minority portion of libavcodec
and cannot relicense it at will.

So, now to make it more clear. I hate to issue ultimatums, but this
one is going to be very simple. If there's going to be ANY proprietary
licensing of mplayer code, I'm off the project, forever.

Rich



From dalias at aerifal.cx  Sun Feb 22 18:03:37 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Sun, 22 Feb 2004 12:03:37 -0500
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
References: <20040222114022.27818ca1.attila@kinali.ch>
	<20040222132319.AAC0B31878@mail.mplayerhq.hu>
Message-ID: <20040222170337.GT9096@brightrain.aerifal.cx>

On Sun, Feb 22, 2004 at 02:23:19PM +0100, Arpi wrote:
> Hi,
> 
> 
> Rich: you misunderstood my mail. read it again please.
> i do NOT want it to be under the BSD license.
> I proposed something to dual-license it under GPL (or LGPL) and
> a commercial license, which allows the license buyer similar things
> like the BSD one (compile into closedsrc code, preserve credits)

I understood totally. This is not acceptable.

Rich



From dalias at aerifal.cx  Sun Feb 22 18:04:30 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Sun, 22 Feb 2004 12:04:30 -0500
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <200402221524.28906.michaelni@gmx.at>
References: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
	<200402221524.28906.michaelni@gmx.at>
Message-ID: <20040222170430.GU9096@brightrain.aerifal.cx>

On Sun, Feb 22, 2004 at 03:24:28PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Sunday 22 February 2004 14:23, Arpi wrote:
> [...]
> > it's not too late to ask agreement from contributors now, and
> > remove code if they don't agree. future contributors have to
> > accept the dual licensing. they did in the past for libavcodec,
> > which has such license since years.
> > (as Fabrice's employer company is using it in closedsrc product)
> if anyone tells me enough to verify that, actually i dont even know who 
> fabrices employer company is, and if he is seriously violating it, like 
> keeping improvements closed source then ill ensure he stops, but i wont 
> complain if hes just ignoring some detail of the lgpl like everyone else
> 
> btw, IMHO dual licensing will mean mplayer G2s death, ppl simply wont 
> contribute anymore, or would u contribute to a project for which someone else 
> gets alot of money?

I won't. Even if I get some or all of the money.

Rich



From dalias at aerifal.cx  Sun Feb 22 18:14:45 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Sun, 22 Feb 2004 12:14:45 -0500
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222110603.GB9691@woodstock.localdomain>
References: <20040221225711.6462D312D4@mail.mplayerhq.hu>
	<20040222101523.GB9230@woodstock.localdomain>
	<20040222114022.27818ca1.attila@kinali.ch>
	<20040222110603.GB9691@woodstock.localdomain>
Message-ID: <20040222171445.GV9096@brightrain.aerifal.cx>

On Sun, Feb 22, 2004 at 12:06:03PM +0100, Gabucino wrote:
> Attila Kinali wrote:
> > Now the discussion whether it should be gpl/bsd or gpl/lgpl
> > isn't one at all (fortnunately or unfortunately ?). We already
> > use a lot of third party gpl/lgpl code which we cannot relicense
> > under bsd, thus we have to stick with gpl/lgpl.
> Let's continue this thread on mplayer-legal mailing list IMHO.

This looks like a convenient way to move the discussion behind closed
doors and keep people who don't care about legal crap (mostly
packaging, codec patent, etc. issues) but who do care that the code
remain free from participating in the discussion...

Rich



From joey at nicewarrior.org  Sun Feb 22 18:14:50 2004
From: joey at nicewarrior.org (Joey Parrish)
Date: Sun, 22 Feb 2004 11:14:50 -0600
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222162436.GA7486@woodstock.localdomain>
References: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
	<20040222153104.GC1267@tower2.myhome.qwe>
	<20040222162436.GA7486@woodstock.localdomain>
Message-ID: <20040222171450.GA9734@nicewarrior.org>

On Sun, Feb 22, 2004 at 05:24:36PM +0100, Gabucino wrote:
> > So, what will you be able to do with the core alone? Buy a licence for  
> > it and then steal all other stuff, assuming that the MPlayer team won't  
> > go after you because you licenced the core? :)))))

> That's not our problem, is it.

Yes, it is.  If there's no functionality in what you can license, then
it's better never to offer the license.  It will complicate things
legally.  If it's not very functional, then no one will buy it and it
offers us no benefit.

--Joey

-- 
All philosophy is naive.



From michaelni at gmx.at  Sun Feb 22 18:36:28 2004
From: michaelni at gmx.at (Michael Niedermayer)
Date: Sun, 22 Feb 2004 18:36:28 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222162436.GA7486@woodstock.localdomain>
References: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
	<20040222153104.GC1267@tower2.myhome.qwe>
	<20040222162436.GA7486@woodstock.localdomain>
Message-ID: <200402221836.28136.michaelni@gmx.at>

Hi

On Sunday 22 February 2004 17:24, Gabucino wrote:
[...]
> > >(as Fabrice's employer company is using it in closedsrc product)
> >
> > ??? Do you mean using code in violation of LGPL?
>
> Good morning!
>
> > AFAIK libavcodec does not have a double license
>
> It does (unpublic), you can see that in the archives too afair.
hmm, i assume u try to point towards some license fabrice commited by mistake 
and then reversed that, after _alot_ of searching i finally found it 
(http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/ffmpeg.c.diff?r1=1.34&r2=1.35&cvsroot=FFMpeg)
AFAIR back when ffmpeg was GPL fabrice first wanted to change it to BSD or a 
commercial dual license or some other commercially friendlier license but i 
(and others too) didnt agree, so after some long disscussions we decided to 
switch to LGPL, i assumed that the commited license was some draft of what 
fabrice suggested during these disscussions, it would also match the timing, 
as the GPL->LGPL change was done shortly afterwards

>
> > So, what will you be able to do with the core alone? Buy a licence for
> > it and then steal all other stuff, assuming that the MPlayer team won't
> > go after you because you licenced the core? :)))))
>
> That's not our problem, is it.
no directly, allthough the lack of commercial interrest in mplayer G2 as a 
result of the lack of contributions which will result from it may be, it 
depends probably u dont care anyway

-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en



From arpi at thot.banki.hu  Sun Feb 22 18:38:30 2004
From: arpi at thot.banki.hu (Arpi)
Date: Sun, 22 Feb 2004 18:38:30 +0100 (CET)
Subject: [MPlayer-G2-dev] dual licensing try 2
Message-ID: <20040222173830.0614E31818@mail.mplayerhq.hu>

Hi,

Ok, it seems that the codec/filter developers are against dual licensing.
Not a big surprise :)

So, I'm restricting dual license mess to the stream/demuxer layer only.
The audio/video pipeline (including codecs, filters, ao/vo) will remain free.

Why?

Most of the possible licensers are using hardware decoders, so they
don't need the ap/vp stuff anyway. And if they need sw codecs, they
can still buy libdivx and libmad (both are available for commercial
licensing). Maybe i'll even implement a sample program using stream/demux
layers only and libdivx+libmad for decoding (maybe using minimal
fbdev or xv output code for display).

Also, they mostly want to modify stream/demux code only, not the
vp/ap stuff. So they can do their propietrary changes (ie. encrypted
streaming, authentication, pay-per-view, secret fileformat etc) to it
and link the GPL mplayer-g2 to the modified closedsource demuxer lib.
(dunno if GPL really allows linking of closedsource libs, but if it isnt
then we're already in trouble with codec DLLs, libdivx and others)

As you refusers (Michael, Rich) don't develop demuxers anyway, it
shouldn't hurt you. It may hurt Albeu, but who cares? :) (sorry)


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu



From dalias at aerifal.cx  Sun Feb 22 18:52:35 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Sun, 22 Feb 2004 12:52:35 -0500
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040222173830.0614E31818@mail.mplayerhq.hu>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
Message-ID: <20040222175235.GX9096@brightrain.aerifal.cx>

On Sun, Feb 22, 2004 at 06:38:30PM +0100, Arpi wrote:
> Hi,
> 
> Ok, it seems that the codec/filter developers are against dual licensing.
> Not a big surprise :)
> 
> So, I'm restricting dual license mess to the stream/demuxer layer only.
> The audio/video pipeline (including codecs, filters, ao/vo) will remain free.
> 
> Why?
> 
> Most of the possible licensers are using hardware decoders, so they
> don't need the ap/vp stuff anyway. And if they need sw codecs, they
> can still buy libdivx and libmad (both are available for commercial
> licensing). Maybe i'll even implement a sample program using stream/demux
> layers only and libdivx+libmad for decoding (maybe using minimal
> fbdev or xv output code for display).
> 
> Also, they mostly want to modify stream/demux code only, not the
> vp/ap stuff. So they can do their propietrary changes (ie. encrypted
> streaming, authentication, pay-per-view, secret fileformat etc) to it
> and link the GPL mplayer-g2 to the modified closedsource demuxer lib.
> (dunno if GPL really allows linking of closedsource libs, but if it isnt
> then we're already in trouble with codec DLLs, libdivx and others)
> 
> As you refusers (Michael, Rich) don't develop demuxers anyway, it
> shouldn't hurt you. It may hurt Albeu, but who cares? :) (sorry)

It's very simple. I am opposed to involvement in any project which
will result in the increase of non-free software, and I have no
interest in being involved in a dual-licensed MPlayer.

Besides, it was already brought up that if non-free licenses are sold
for only part of MPlayer, then lame proprietary software companies
will just steal the rest of MPlayer too, and then the core developers
won't pursue legal action against these companies because they're
being paid by them. It's a clear conflict of interest.

So: drop dual-license, or drop me. It's your choice.

Rich



From joey at nicewarrior.org  Sun Feb 22 18:59:03 2004
From: joey at nicewarrior.org (Joey Parrish)
Date: Sun, 22 Feb 2004 11:59:03 -0600
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040222175235.GX9096@brightrain.aerifal.cx>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040222175235.GX9096@brightrain.aerifal.cx>
Message-ID: <20040222175903.GB10042@nicewarrior.org>

On Sun, Feb 22, 2004 at 12:52:35PM -0500, D Richard Felker III wrote:
> It's very simple. I am opposed to involvement in any project which
> will result in the increase of non-free software, and I have no
> interest in being involved in a dual-licensed MPlayer.
> 
> Besides, it was already brought up that if non-free licenses are sold
> for only part of MPlayer, then lame proprietary software companies
> will just steal the rest of MPlayer too, and then the core developers
> won't pursue legal action against these companies because they're
> being paid by them. It's a clear conflict of interest.

I agree with this principle fully.

--Joey

-- 
"I know Kung Fu." --Darth Vader



From arpi at thot.banki.hu  Sun Feb 22 19:08:47 2004
From: arpi at thot.banki.hu (Arpi)
Date: Sun, 22 Feb 2004 19:08:47 +0100 (CET)
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040222175235.GX9096@brightrain.aerifal.cx>
Message-ID: <20040222180847.517DB3151B@mail.mplayerhq.hu>

Hi,

> > As you refusers (Michael, Rich) don't develop demuxers anyway, it
> > shouldn't hurt you. It may hurt Albeu, but who cares? :) (sorry)
> 
> It's very simple. I am opposed to involvement in any project which
> will result in the increase of non-free software, and I have no

Why will it be non-free?
The whole code is under GPL, only they have the option to license
demuxer/stream code and modify it without releasing the changes.

> interest in being involved in a dual-licensed MPlayer.

Ok.

> Besides, it was already brought up that if non-free licenses are sold
> for only part of MPlayer, then lame proprietary software companies
> will just steal the rest of MPlayer too, and then the core developers

they will be sued then.

> won't pursue legal action against these companies because they're
> being paid by them. It's a clear conflict of interest.

wrong.
they will be sued by stopping (invalidate) their license
(think of what sco did with ibm)

the other option would be releasing demuxer+stream under BSD(-like)
license, but it wouldn't left any right to us.

now, companies interested in using demuxer/stream core for their
streaing, converion, etc applications can't use it, so they
don't support us developers implementing custom features, and they
don't implement features themself. instead they're using concurrent
projects and support them, so if i follow your thinking, the
other project will be imporved faster and people will use it and
contributions will go there, and mplayer g2 will die :)

> So: drop dual-license, or drop me. It's your choice.

sorry, but if i have to choose, i'll drop you.
(unless you finish VP layer asap, then i'll re-consider :)


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu



From gabucino at mplayerhq.hu  Sun Feb 22 19:28:58 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Sun, 22 Feb 2004 19:28:58 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040222175235.GX9096@brightrain.aerifal.cx>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040222175235.GX9096@brightrain.aerifal.cx>
Message-ID: <20040222182858.GC7762@woodstock.localdomain>

D Richard Felker III wrote:
> for only part of MPlayer, then lame proprietary software companies
> will just steal the rest of MPlayer too, and then the core developers
> won't pursue legal action against these companies because they're
> being paid by them.
Huh? This has 0 sense. Please elaborate.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040222/c7fa7e3f/attachment.pgp>

From gabucino at mplayerhq.hu  Sun Feb 22 19:13:10 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Sun, 22 Feb 2004 19:13:10 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <200402221836.28136.michaelni@gmx.at>
References: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
	<20040222153104.GC1267@tower2.myhome.qwe>
	<20040222162436.GA7486@woodstock.localdomain>
	<200402221836.28136.michaelni@gmx.at>
Message-ID: <20040222181310.GA7762@woodstock.localdomain>

Michael Niedermayer wrote:
> hmm, i assume u try to point towards some license fabrice commited by mistake 
> and then reversed that, after _alot_ of searching i finally found it 
No, I mean QuickView, but there were/are probably a lot more cases like that.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040222/8cd4daf6/attachment.pgp>

From gabucino at mplayerhq.hu  Sun Feb 22 19:21:10 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Sun, 22 Feb 2004 19:21:10 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222170303.GS9096@brightrain.aerifal.cx>
References: <20040221225711.6462D312D4@mail.mplayerhq.hu>
	<20040222101523.GB9230@woodstock.localdomain>
	<20040222170303.GS9096@brightrain.aerifal.cx>
Message-ID: <20040222182110.GB7762@woodstock.localdomain>

D Richard Felker III wrote:
> > they will pay big bucks to us for using our code.
> And everyone in the world loses freedom.
AFAIK MPlayer was never a 'freedom' project.. I like free code, but I also like
OpenVMS just as much. But I don't really like freedom-at-all-cost viewpoint
(RMS, etc).


> Getting big bucks is not the purpose.
But you need big bucks to fight for freedom (i.e. court).


> If we go to court, we get the _real_ compensation we deserve: freedom
> of the code.
Assuming we win... Don't focus on Freedom, see the difficulties too. And,
as I said, court needs money.


> AFAIK Fabrice does this under the terms of the LGPL. This is very
> different.
Read QuickView's license (including - and especially - the Indeo part).


> one is going to be very simple. If there's going to be ANY proprietary
> licensing of mplayer code, I'm off the project, forever.
I admire you being frank. We'll see what is going to happen at the end
of this thread.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040222/36fca8a5/attachment.pgp>

From michaelni at gmx.at  Sun Feb 22 20:01:56 2004
From: michaelni at gmx.at (Michael Niedermayer)
Date: Sun, 22 Feb 2004 20:01:56 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222181310.GA7762@woodstock.localdomain>
References: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
	<200402221836.28136.michaelni@gmx.at>
	<20040222181310.GA7762@woodstock.localdomain>
Message-ID: <200402222001.56705.michaelni@gmx.at>

Hi

On Sunday 22 February 2004 19:13, Gabucino wrote:
> Michael Niedermayer wrote:
> > hmm, i assume u try to point towards some license fabrice commited by
> > mistake and then reversed that, after _alot_ of searching i finally found
> > it
>
> No, I mean QuickView, but there were/are probably a lot more cases like
> that.
do u have any proof/evidence/...? or are u trying SCOs business model?

-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en



From michaelni at gmx.at  Sun Feb 22 20:08:10 2004
From: michaelni at gmx.at (Michael Niedermayer)
Date: Sun, 22 Feb 2004 20:08:10 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222182110.GB7762@woodstock.localdomain>
References: <20040221225711.6462D312D4@mail.mplayerhq.hu>
	<20040222170303.GS9096@brightrain.aerifal.cx>
	<20040222182110.GB7762@woodstock.localdomain>
Message-ID: <200402222008.10905.michaelni@gmx.at>

Hi

On Sunday 22 February 2004 19:21, Gabucino wrote:
[...]
> > AFAIK Fabrice does this under the terms of the LGPL. This is very
> > different.
>
> Read QuickView's license (including - and especially - the Indeo part).
what do u mean? the reverse engeneering is not allowed part? it has no legal 
meaning, its not enforceable IANAL/AFAIK
btw, speaking of indeo, doesnt mplayer support the binary indeo thing too? not 
that i complain or even care at all, its just funny that its legal in MPlayer

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en



From gabucino at mplayerhq.hu  Sun Feb 22 20:14:28 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Sun, 22 Feb 2004 20:14:28 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <200402222001.56705.michaelni@gmx.at>
References: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
	<200402221836.28136.michaelni@gmx.at>
	<20040222181310.GA7762@woodstock.localdomain>
	<200402222001.56705.michaelni@gmx.at>
Message-ID: <20040222191428.GD7762@woodstock.localdomain>

Michael Niedermayer wrote:
> > No, I mean QuickView, but there were/are probably a lot more cases like
> > that.
> do u have any proof/evidence/...? or are u trying SCOs business model?
What do you want from me? Ask Fabrice instead. He's silent, and QV is still
unchanged and contains violating licenses.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040222/a44ee602/attachment.pgp>

From gabucino at mplayerhq.hu  Sun Feb 22 20:15:45 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Sun, 22 Feb 2004 20:15:45 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <200402222008.10905.michaelni@gmx.at>
References: <20040221225711.6462D312D4@mail.mplayerhq.hu>
	<20040222170303.GS9096@brightrain.aerifal.cx>
	<20040222182110.GB7762@woodstock.localdomain>
	<200402222008.10905.michaelni@gmx.at>
Message-ID: <20040222191545.GE7762@woodstock.localdomain>

Michael Niedermayer wrote:
> btw, speaking of indeo, doesnt mplayer support the binary indeo thing too? not 
> that i complain or even care at all, its just funny that its legal in MPlayer
Huh? Since when did we receive official Indeo sources from Intel? Or from
anywhere else.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040222/cc355eec/attachment.pgp>

From michaelni at gmx.at  Sun Feb 22 20:38:55 2004
From: michaelni at gmx.at (Michael Niedermayer)
Date: Sun, 22 Feb 2004 20:38:55 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222191428.GD7762@woodstock.localdomain>
References: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
	<200402222001.56705.michaelni@gmx.at>
	<20040222191428.GD7762@woodstock.localdomain>
Message-ID: <200402222038.55197.michaelni@gmx.at>

Hi

On Sunday 22 February 2004 20:14, Gabucino wrote:
> Michael Niedermayer wrote:
> > > No, I mean QuickView, but there were/are probably a lot more cases like
> > > that.
> >
> > do u have any proof/evidence/...? or are u trying SCOs business model?
>
> What do you want from me? Ask Fabrice instead. He's silent, and QV is still
> unchanged and contains violating licenses.
u said theres a dual license, so i ask u for a proof, so i can use that proof 
to do something against it, but if u have no proof i cant do anything, and 
asking fabrice is pointless he wont tell me that there is a illegal license 
if theres one, which i seriously doubt
and about the license violation, yes qv did violate the fineprint of the LGPL 
(not providing object files for relinking IIRC) and i & fabrice ignored it, 
ignoring it is not illegal or morally wrong or is it?

-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en



From gabucino at mplayerhq.hu  Sun Feb 22 20:54:19 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Sun, 22 Feb 2004 20:54:19 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <200402222038.55197.michaelni@gmx.at>
References: <20040222132319.AAC0B31878@mail.mplayerhq.hu>
	<200402222001.56705.michaelni@gmx.at>
	<20040222191428.GD7762@woodstock.localdomain>
	<200402222038.55197.michaelni@gmx.at>
Message-ID: <20040222195419.GC8086@woodstock.localdomain>

Michael Niedermayer wrote:
> u said theres a dual license, so i ask u for a proof, so i can use that proof 
> to do something against it, but if u have no proof i cant do anything, and 
I'm not particularly bothered and I'm too lazy to search my CDs for mail
archives so it's your task to investigate.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040222/a0c5d9c7/attachment.pgp>

From mitya at school.ioffe.ru  Sun Feb 22 22:58:38 2004
From: mitya at school.ioffe.ru (Dmitry Baryshkov)
Date: Mon, 23 Feb 2004 00:58:38 +0300
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040222175235.GX9096@brightrain.aerifal.cx>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040222175235.GX9096@brightrain.aerifal.cx>
Message-ID: <20040222215838.GA15657@school.ioffe.ru>

Hello,
On Sun, Feb 22, 2004 at 12:52:35PM -0500, D Richard Felker III wrote:
> On Sun, Feb 22, 2004 at 06:38:30PM +0100, Arpi wrote:
[skipped]

Arpi, could you please clarify, what do you want to achiev by dual-licensing G2 core:
a lot of money or a better (legal) widespread of G2's core?

If first, then you are on your own. Many people will think, why should
work for giving you money. Even if they won't contribute to core, some
of them won't contribute any.

If second, then probably LGPL is the best. I suppose, it's the LGPL's
target: to provide license for such 'core' libraries as 'G2 core' can be
for media software.

> It's very simple. I am opposed to involvement in any project which
> will result in the increase of non-free software, and I have no
> interest in being involved in a dual-licensed MPlayer.

And don't you think, that even GPL can (and I suppose is) results in
increase of non-free software: any company can use some type of
optimizations/etc. from open-source code. Thay wan't use code (ideally)
they will use ideas from such code. So to stop helping non-free
software, you must stop writing ANY software. Even simple printf("Hello
world!\n"); can help non-free software :)

> Besides, it was already brought up that if non-free licenses are sold
> for only part of MPlayer, then lame proprietary software companies
> will just steal the rest of MPlayer too, and then the core developers
> won't pursue legal action against these companies because they're
> being paid by them. It's a clear conflict of interest.

Here is another point about getting money. What's more important: money
or open source?

> So: drop dual-license, or drop me. It's your choice.

So you should drop people because of some mythic company? In Russian we
say: "A tit in the hands is better than a crave in the sky". I don't
remember English analogue, but you get the point.

Arpi, IMHO good, proven coders are better that mythic companies.
People are always better.

Or maybe companies aren't so mythic? And they simply don't like LGPL :)

-- 
With best wishes
Dmitry Baryshkov



From gabucino at mplayerhq.hu  Sun Feb 22 23:10:31 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Sun, 22 Feb 2004 23:10:31 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040222215838.GA15657@school.ioffe.ru>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040222175235.GX9096@brightrain.aerifal.cx>
	<20040222215838.GA15657@school.ioffe.ru>
Message-ID: <20040222221031.GA17710@woodstock.localdomain>

Dmitry Baryshkov wrote:
> Here is another point about getting money. What's more important: money
> or open source?
That's not a choice to make, those things can happen together. Read GPL
license for example.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040222/e2c83c2d/attachment.pgp>

From dalias at aerifal.cx  Mon Feb 23 06:00:21 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Mon, 23 Feb 2004 00:00:21 -0500
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040222180847.517DB3151B@mail.mplayerhq.hu>
References: <20040222175235.GX9096@brightrain.aerifal.cx>
	<20040222180847.517DB3151B@mail.mplayerhq.hu>
Message-ID: <20040223050021.GY9096@brightrain.aerifal.cx>

On Sun, Feb 22, 2004 at 07:08:47PM +0100, Arpi wrote:
> > So: drop dual-license, or drop me. It's your choice.
> 
> sorry, but if i have to choose, i'll drop you.

If this is the way you feel, then so be it.

> (unless you finish VP layer asap, then i'll re-consider :)

I won't finish the VP layer until (a) the other core developers stop
talking about idiotic dual-licensing crap and instead help me work out
the remaining problems with slices, buffer-age, etc. so we get a
system that works well and is acceptable to everyone, and (b) I know
I'm not working on a dual-licensed project to help Arpi and Gabucino
make money to take teenie girls to the beach.

IMO it's totally stupid that you guys are shoving this
proprietary-friendly system onto the rest of us (when almost all the
other developers agree it's bad!) and wasting everyone's time talking
about it instead of getting G2 working!!!

Rich



From lgb at lgb.hu  Mon Feb 23 11:30:58 2004
From: lgb at lgb.hu (=?iso-8859-2?B?R+Fib3IgTOlu4XJ0?=)
Date: Mon, 23 Feb 2004 11:30:58 +0100
Subject: [MPlayer-G2-dev] dual licensing
In-Reply-To: <20040222144140.3fc8a306.attila@kinali.ch>
References: <20040222114022.27818ca1.attila@kinali.ch>
	<20040222132319.AAC0B31878@mail.mplayerhq.hu>
	<20040222144140.3fc8a306.attila@kinali.ch>
Message-ID: <20040223103058.GE13037@lgb.hu>

On Sun, Feb 22, 2004 at 02:41:40PM +0100, Attila Kinali wrote:
> On Sun, 22 Feb 2004 14:23:19 +0100 (CET)
> Arpi <arpi at thot.banki.hu> wrote:
> 
> 
> > Rich: you misunderstood my mail. read it again please.
> > i do NOT want it to be under the BSD license.
> > I proposed something to dual-license it under GPL (or LGPL) and
> > a commercial license, which allows the license buyer similar things
> > like the BSD one (compile into closedsrc code, preserve credits)
> > 
> > The key point here is that they cannot use that bsd-like thing for free,
> > they have to buy it, for lots of money. Ie they dont steal your code, they
> > buy it. (it's the next topic, to how to handle the money. we clearly need
> > a company for that, and what to do with the money: share between
> > developers, buy hw for developers, buy hw for server etc...)
> 
> Hmm... This makes things a bit complicated.
> Ie we'll need, as Kis Gergely suggested, a company or rather
> a small foundation to handle that.
> What i dont like about this idea is, that we'll get quite
> an amount of legal stuff to handle which takes a lot of time.

So what should be done if SCO sue mplayer staff for developing on Linux thus
they may handle mplayer as a derivate work of original UNIX somehow ;-) Ok
this sounds VERY stupid, but SCO may do that since they're totally crazy. If
you collect money, you should sign contracts. So lawayer may be an issue,
you can't say 'IANAL' anymore, you NEED at least one lawayer. And what about
patents, and what about the issue when patent holder sue you ... Maybe at
the PRESENT time they say 'oh well, those free software guys, who cares'.
But if you start to SELL stuff for money, maybe this situation will change
... I don't think so this is a simple issue.

For non commercial method:

You should read license GPL/LGPL if you want to redistribute (possibly modified)
source, but you can use original BSD license (or whatever?) if you want to
embedd mplayer into a project which is *CLOSED* source (distributing only
binary code) and the project is not a media player software only a part
of it, like firmware of a DVD player.

This would be a quite nice MPlayer license, because someone may use mplayer
in his project without the need of release his source as well, but if somone
wants to redistrute the source of even a derivate work of MPlayer they must
take care of GPL instead. Or something similar?

- G?bor (larta'H)



From attila at kinali.ch  Mon Feb 23 12:16:59 2004
From: attila at kinali.ch (Attila Kinali)
Date: Mon, 23 Feb 2004 12:16:59 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040222173830.0614E31818@mail.mplayerhq.hu>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
Message-ID: <20040223121659.2c81face.attila@kinali.ch>

Heyo,

Let's put this stuff here a bit together:

Fact 1:
There are companies that use MPlayer in modified or unmodified
manner w/o releasing their source or giving credits, thus violating
GPL

Fact 2:
If we switch to a dual licensing model that allows companies
to develop closed source software based on mplayer we'll lose
some important developers.

Fact 3:
Developers are the heart of any OSS project.
No active developers, no project.

Fact 4:
This discussion is way too heated and has too many
religous components.

Conclusion 1:
We should resolve this issue as soon as possible.

Conclusion 2:
Switching to a dual license gpl/comercial is out
of question as we'd lose developers.

Conclusion 3:
There can't be any MPlayer foundation or something
that makes money out of MPlayer directly.

Conclusion 4:
MPlayer has to stay either completely gpl or
gpl/lgpl.


Poll 1:
So, we have 2 options:
1) Leave MPlayer GPL
2) Make MPlayer GPL/LGPL

I vote for 1.


			Attila Kinali

-- 
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
			-- reeler in +kaosu



From gabucino at mplayerhq.hu  Mon Feb 23 12:20:19 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Mon, 23 Feb 2004 12:20:19 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223050021.GY9096@brightrain.aerifal.cx>
References: <20040222175235.GX9096@brightrain.aerifal.cx>
	<20040222180847.517DB3151B@mail.mplayerhq.hu>
	<20040223050021.GY9096@brightrain.aerifal.cx>
Message-ID: <20040223112019.GC1266@woodstock.localdomain>

D Richard Felker III wrote:
> I'm not working on a dual-licensed project to help Arpi and Gabucino
> make money to take teenie girls to the beach.
Don't get me wrong, dual licensing is not my idea - I don't do coding in
MPlayer. I'm just (as PR/lawsuit manager or whaddayacallit) trying to further
describe Arpi's viewpoint.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040223/6b59d28d/attachment.pgp>

From joey at nicewarrior.org  Mon Feb 23 15:06:57 2004
From: joey at nicewarrior.org (Joey Parrish)
Date: Mon, 23 Feb 2004 08:06:57 -0600
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223121659.2c81face.attila@kinali.ch>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223121659.2c81face.attila@kinali.ch>
Message-ID: <20040223140657.GB13326@nicewarrior.org>

On Mon, Feb 23, 2004 at 12:16:59PM +0100, Attila Kinali wrote:
> Poll 1:
> So, we have 2 options:
> 1) Leave MPlayer GPL
> 2) Make MPlayer GPL/LGPL
3) LGPL only

What's wrong with 3?

--Joey

-- 
"Of the seven dwarves, the only one who shaved was Dopey.
That should tell us something about the wisdom of shaving."



From rsnel at cube.dyndns.org  Mon Feb 23 15:06:15 2004
From: rsnel at cube.dyndns.org (rsnel at cube.dyndns.org)
Date: Mon, 23 Feb 2004 15:06:15 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040222173830.0614E31818@mail.mplayerhq.hu>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
Message-ID: <20040223140615.GA32683@cube.dyndns.org>

Hello,

I am just a minor contributor to g1 (and in the future possibly to g2),
but I would like to voice my opinion on this matter. (short version: I
am from the RMS camp)

> A'rpi said:
> Also, they mostly want to modify stream/demux code only, not the
> vp/ap stuff. So they can do their propietrary changes (ie. encrypted
> streaming, authentication, pay-per-view, secret fileformat etc) to it
> [...] 
Is there a really good reason for you to help companies doing those
nefarious things? I consider limiting the end user by crippling software
(and/or denying the user the four basic rights that are granted by the
GPL (in short: unlimited usage, distribution, modification and
redistribution of a program and all derivatives)) morally wrong (and
therefore, I don't want any involvement in it).

Possible outcome (hypothetical):

Mplayer-g2 will be forked, the fork will be singly licensed. The fork
can benefit from updates of the original version. The other way around
is very difficult, since most of the contributions to the fork will be
GPL-only. The two will go out of sync while the mplayer-g2 maintainers
are re-implementing wanted code that was added to the fork (which will
be a giant waste of resources and a legal minefield).

The question is which will draw the best/most developers. My guess is
that it will be the forked version.

So the companies using the original mplayer-g2 can't legally benefit
from the continuing maintenance of the fork of mplayer-g2 (which will in
the near future probably contain support for those 'secret file formats'
and 'pay-per-view', by the way), so they will have to do all the
maintenance themselves and be tempted to use the forked version and
hope no-one will notice. 

Which is almost the same problem we are having now... 

As an answer to Atilla's poll:

I vote for keeping MPlayer-g2 GPL'd. (specifically not the Lesser GPL,
because LGPL'ing MPlayer-g2 will be a motivation for softwaremakers to
keep making proprietary software which serves no-one but said
softwaremakers (and I don't find that a worthy goal, obviously)).

Greetings,

Rik.

-- 
Nothing is ever a total loss; it can always serve as a bad example.



From gabucino at mplayerhq.hu  Mon Feb 23 15:46:43 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Mon, 23 Feb 2004 15:46:43 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223140615.GA32683@cube.dyndns.org>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
Message-ID: <20040223144643.GA3622@woodstock.localdomain>

rsnel at cube.dyndns.org wrote:
> I am from the RMS camp
That doesn't mean you shouldn't think.


> Is there a really good reason for you to help companies doing those
> nefarious things?
It helps the developers.


> I consider limiting the end user by crippling software
What crippling? Read the thread again.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040223/9e905cd2/attachment.pgp>

From attila at kinali.ch  Mon Feb 23 16:06:45 2004
From: attila at kinali.ch (Attila Kinali)
Date: Mon, 23 Feb 2004 16:06:45 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223140657.GB13326@nicewarrior.org>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223121659.2c81face.attila@kinali.ch>
	<20040223140657.GB13326@nicewarrior.org>
Message-ID: <20040223160645.530a406a.attila@kinali.ch>

On Mon, 23 Feb 2004 08:06:57 -0600
Joey Parrish <joey at nicewarrior.org> wrote:

> 3) LGPL only
> 
> What's wrong with 3?

Not possible as MPlayer makes use of GPL code.

			Attila Kinali

-- 
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
			-- reeler in +kaosu



From dalias at aerifal.cx  Mon Feb 23 16:45:49 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Mon, 23 Feb 2004 10:45:49 -0500
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223144643.GA3622@woodstock.localdomain>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
Message-ID: <20040223154549.GZ9096@brightrain.aerifal.cx>

On Mon, Feb 23, 2004 at 03:46:43PM +0100, Gabucino wrote:
> rsnel at cube.dyndns.org wrote:
> > I am from the RMS camp
> That doesn't mean you shouldn't think.

We do think. It's you who doesn't think. You just act on greed.

> > Is there a really good reason for you to help companies doing those
> > nefarious things?
> It helps the developers.

It DOES NOT HELP THE DEVELOPERS. Unless you mean paying Arpi and
possibly yourself, which the other developers DO NOT CONSIDER HELPFUL.

> > I consider limiting the end user by crippling software
> What crippling? Read the thread again.

He's not saying that WE will be crippling software. Rather, we would
be auiding proprietary software companies in crippling their software
(by including DRM, no source code, etc. while taking advantage of
MPlayer code). This is bad!!

Rich



From dalias at aerifal.cx  Mon Feb 23 16:51:18 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Mon, 23 Feb 2004 10:51:18 -0500
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223160645.530a406a.attila@kinali.ch>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223121659.2c81face.attila@kinali.ch>
	<20040223140657.GB13326@nicewarrior.org>
	<20040223160645.530a406a.attila@kinali.ch>
Message-ID: <20040223155118.GA9096@brightrain.aerifal.cx>

On Mon, Feb 23, 2004 at 04:06:45PM +0100, Attila Kinali wrote:
> On Mon, 23 Feb 2004 08:06:57 -0600
> Joey Parrish <joey at nicewarrior.org> wrote:
> 
> > 3) LGPL only
> > 
> > What's wrong with 3?
> 
> Not possible as MPlayer makes use of GPL code.

The original MPlayer code could still be LGPL; when combined they're
then under GPL. But IMO it shouldn't be. LGPL is only appropriate for
(a) making free replacements for an already-existing non-free api, or
(b) encouraging adoption of an open standard (but BSD is often more
strategic for this).

And before Arpi or someone brings up the G2 demuxer/stream system as
an open standard we're trying to get adopted, let me say this is
nonsense. This is an internal mechanism, and we have no reason to care
what internal mechanism or API proprietary software uses. On the other
hand, I agree wholeheartedly that there should be a BSD-licensed
implementation of NUT, because (a) it's simple, and (b) we want
everyone to adopt NUT and abandon the current horrible container
formats. BUT G2 is not a file format or codec or anything that needs
to be standardized between players. The ONLY party that benefits when
a proprietary program includes the MPlayer G2 core is the information
hoarder stealing concepts away from the public in the form of
exclusive pseudo-rights.

Rich



From rsnel at cube.dyndns.org  Mon Feb 23 16:46:31 2004
From: rsnel at cube.dyndns.org (rsnel at cube.dyndns.org)
Date: Mon, 23 Feb 2004 16:46:31 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223144643.GA3622@woodstock.localdomain>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
Message-ID: <20040223154631.GA11043@cube.dyndns.org>

On Mon, Feb 23, 2004 at 03:46:43PM +0100, Gabucino wrote:
> > Is there a really good reason for you to help companies doing those
> > nefarious things?
> It helps the developers.
It helps the developers doing bad things (at least: things I consider
bad), unless you consider misfeatures like 'unable to save' to be good
things, more justification is needed.

> > I consider limiting the end user by crippling software
> What crippling? Read the thread again.
Suppose MPlayer is licensed to some 'pay-per-view' company, and that
company is given the right to distribute modified versions of MPlayer
to their users without giving the right to distribute modified versions
to their users (and withholding the sourcecode to the changes).

This company will probably add code to MPlayer to prevent it from saving
the downloaded data in an open format (a format which does not require
the user to pay up again if the user wants to see what he/she already
downloaded). (something which would be easy to counter if the company was
required to redistribute the source along with the binaries).

So the user gets software from which useful (and trivial)
functionality has been removed (i.e. has been crippled).

Companies are of course free to create crippled computers (Xbox, for
example which runs only 'approved' software) and software (RealPlayer,
which disallows saving certain rtsp streams), but I will not help them 
because I find it 'wrong'; they would have to hire programmers with
different moral standards (or that are in financial troubles and have a
family to feed) than me. (and allowing such companies to make
proprietary changes to a well-maintained softwarepackage helps them a
great deal; they only have to maintain their own changes)

Let me clarify the GPL/LGPL point. I can live with GPL/LGPL as long as
contributors are allowed to contribute GPL-only code. (as in
libavcodec). (but the LGPL encourages the creation of proprietary
software, so I like the GPL better)

Greetings,

Rik.

-- 
Nothing is ever a total loss; it can always serve as a bad example.



From gabucino at mplayerhq.hu  Mon Feb 23 17:18:01 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Mon, 23 Feb 2004 17:18:01 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223154631.GA11043@cube.dyndns.org>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
Message-ID: <20040223161801.GD4401@woodstock.localdomain>

rsnel at cube.dyndns.org wrote:
> > It helps the developers.
> It helps the developers doing bad things
It helps the developers avoiding potentially harmful and time+money consuming
lawsuits.


> Suppose MPlayer is licensed to some 'pay-per-view' company, and that
> company is given the right to distribute modified versions of MPlayer
> to their users without giving the right to distribute modified versions
So what? They already do/can do it right now! MPlayer's source is open,
and everyone feels free to steal, in case you haven't noticed.

Would _you_ support a lawsuit?

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040223/21301f1d/attachment.pgp>

From gabucino at mplayerhq.hu  Mon Feb 23 17:22:39 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Mon, 23 Feb 2004 17:22:39 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223154549.GZ9096@brightrain.aerifal.cx>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154549.GZ9096@brightrain.aerifal.cx>
Message-ID: <20040223162239.GE4401@woodstock.localdomain>

D Richard Felker III wrote:
> > > I am from the RMS camp
> > That doesn't mean you shouldn't think.
> We do think. It's you who doesn't think. You just act on greed.
You said yourself that you don't want money from duallicensing, so stop
saying this.


> > It helps the developers.
> It DOES NOT HELP THE DEVELOPERS. Unless you mean paying Arpi and
> possibly yourself
...
Dual-licensing money would be available for every developer - if they (you)
refuse accepting it due to religious RMS-Rulez-Free-Like-Beer/Whatever reasons,
that is entirely your problem.


> He's not saying that WE will be crippling software. Rather, we would
> be auiding proprietary software companies in crippling their software
> (by including DRM, no source code, etc. while taking advantage of
> MPlayer code). This is bad!!
We already do. The only way we won't help them is closing the source entirely.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040223/ed175c97/attachment.pgp>

From dalias at aerifal.cx  Mon Feb 23 18:11:27 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Mon, 23 Feb 2004 12:11:27 -0500
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223161801.GD4401@woodstock.localdomain>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
Message-ID: <20040223171127.GB9096@brightrain.aerifal.cx>

On Mon, Feb 23, 2004 at 05:18:01PM +0100, Gabucino wrote:
> rsnel at cube.dyndns.org wrote:
> > > It helps the developers.
> > It helps the developers doing bad things
> It helps the developers avoiding potentially harmful and time+money consuming
> lawsuits.

This is completely a non sequitur.

> > Suppose MPlayer is licensed to some 'pay-per-view' company, and that
> > company is given the right to distribute modified versions of MPlayer
> > to their users without giving the right to distribute modified versions
> So what? They already do/can do it right now! MPlayer's source is open,
> and everyone feels free to steal, in case you haven't noticed.

No, a couple lamers do, and they're losing business because of it.
Also once you get off your asses and figure out how to file suit in
whatever country KISS is in, rather than wasting time thinking up
stupid ways to help them abuse the code even more.

Keep in mind: PAYING someone to be able to release proprietary
derivative works does not make it any more acceptable to do so. It's
wrong whether they pay or not!!

> Would _you_ support a lawsuit?

What kind of support do you need?

BTW, if your real concern is not being able to defend the copyright,
then we should assign copyright to the FSF so they will defend it for
us. Selling non-free licenses is NOT going to make defending it any
easier.

Rich



From dalias at aerifal.cx  Mon Feb 23 18:19:42 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Mon, 23 Feb 2004 12:19:42 -0500
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223162239.GE4401@woodstock.localdomain>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154549.GZ9096@brightrain.aerifal.cx>
	<20040223162239.GE4401@woodstock.localdomain>
Message-ID: <20040223171942.GC9096@brightrain.aerifal.cx>

On Mon, Feb 23, 2004 at 05:22:39PM +0100, Gabucino wrote:
> D Richard Felker III wrote:
> > > > I am from the RMS camp
> > > That doesn't mean you shouldn't think.
> > We do think. It's you who doesn't think. You just act on greed.
> You said yourself that you don't want money from duallicensing, so stop
> saying this.

??

> > > It helps the developers.
> > It DOES NOT HELP THE DEVELOPERS. Unless you mean paying Arpi and
> > possibly yourself
> ...
> Dual-licensing money would be available for every developer - if they (you)
> refuse accepting it due to religious RMS-Rulez-Free-Like-Beer/Whatever reasons,
> that is entirely your problem.

Actually it's your problem when they decide not to code, or to code
their own player instead.

> > He's not saying that WE will be crippling software. Rather, we would
> > be auiding proprietary software companies in crippling their software
> > (by including DRM, no source code, etc. while taking advantage of
> > MPlayer code). This is bad!!
> We already do. The only way we won't help them is closing the source entirely.

Now you're being a complete idiot. WAAAH WAAAAAH THEY STOLE R CODE NOW
WE NOT DEVELOP ANYMORE AND U ALL LOOZE ROTFL!!! This is the way stupid
shareware authors work when their appz are cracked.

The purpose with MPlayer, and the ONLY purpose, is to make a free
movie player that works. As soon as you stop this for whatever petty
reason, YOU LOSE and "THEY" WIN (they being the proprietary lamers).
As a side goal, we should be preventing the development of non-free
software as much as possible, by (a) making MPlayer as good as
possible so no one has any reason to use something else, and (b)
taking legal action against anyone who uses MPlayer code for
proprietary purposes. But acting out in spite and revenge is just
irrational bloodlust, and these things should never come in the way of
your actual goal.

If this is about selfish purposes like getting credited and screwing
over people who "mess with you" then you should go back to the
oldskool k-rad demo scene where these ideals belong. When developing
free software, the goal is making good free software, and making sure
it's better than the proprietary junk. Not boosting your ego or
getting paid.

Rich




From rsnel at cube.dyndns.org  Mon Feb 23 18:14:05 2004
From: rsnel at cube.dyndns.org (rsnel at cube.dyndns.org)
Date: Mon, 23 Feb 2004 18:14:05 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223161801.GD4401@woodstock.localdomain>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
Message-ID: <20040223171405.GA14268@cube.dyndns.org>

On Mon, Feb 23, 2004 at 05:18:01PM +0100, Gabucino wrote:
> rsnel at cube.dyndns.org wrote:
> > > It helps the developers.
> > It helps the developers doing bad things
> It helps the developers avoiding potentially harmful and time+money consuming
> lawsuits.
I understand your point. I thought you meant the developers of e.g.
KiSS.

> > Suppose MPlayer is licensed to some 'pay-per-view' company, and that
> > company is given the right to distribute modified versions of MPlayer
> > to their users without giving the right to distribute modified versions
> So what? They already do/can do it right now! MPlayer's source is open,
> and everyone feels free to steal, in case you haven't noticed.
If something is ethically and legally wrong (using MPlayer code for nefarious
purposes and thereby infringing on copyright) then it won't become
ethically right by making it legally right. Dual-licensing doesn't
solve the ethical problem; it makes the ethical problem unsolvable (it can't
even be solved through legal means anymore).

> Would _you_ support a lawsuit?
Well, I am not a lawyer, so I don't know what it takes to take such a
case to court, and what it takes to convince a judge that code was
copied while in non-compliance with the license and therefore
the company (e.g. KiSS) is guilty of copyright infringement. Maybe we
should ask for legal counsel on the 'donations page'... 

(And, what Rich just said, we could assign copyright to the FSF, then
they will fight the legal battles)

Greetings,

Rik.

-- 
Nothing is ever a total loss; it can always serve as a bad example.



From dalias at aerifal.cx  Mon Feb 23 18:26:49 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Mon, 23 Feb 2004 12:26:49 -0500
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223171405.GA14268@cube.dyndns.org>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
	<20040223171405.GA14268@cube.dyndns.org>
Message-ID: <20040223172649.GG9096@brightrain.aerifal.cx>

On Mon, Feb 23, 2004 at 06:14:05PM +0100, rsnel at cube.dyndns.org wrote:
> On Mon, Feb 23, 2004 at 05:18:01PM +0100, Gabucino wrote:
> > rsnel at cube.dyndns.org wrote:
> > > > It helps the developers.
> > > It helps the developers doing bad things
> > It helps the developers avoiding potentially harmful and time+money consuming
> > lawsuits.
> I understand your point. I thought you meant the developers of e.g.
> KiSS.

I don't understand his point. IMO there will be at least as many or
more legal disputes if we start licensing MPlayer for proprietary use,
and it will be just as hard or harder to resolve them.

Rich



From rsnel at cube.dyndns.org  Mon Feb 23 18:57:13 2004
From: rsnel at cube.dyndns.org (rsnel at cube.dyndns.org)
Date: Mon, 23 Feb 2004 18:57:13 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223172649.GG9096@brightrain.aerifal.cx>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
	<20040223171405.GA14268@cube.dyndns.org>
	<20040223172649.GG9096@brightrain.aerifal.cx>
Message-ID: <20040223175713.GB14268@cube.dyndns.org>

On Mon, Feb 23, 2004 at 12:26:49PM -0500, D Richard Felker III wrote:
> On Mon, Feb 23, 2004 at 06:14:05PM +0100, rsnel at cube.dyndns.org wrote:
> > On Mon, Feb 23, 2004 at 05:18:01PM +0100, Gabucino wrote:
> > > It helps the developers avoiding potentially harmful and time+money 
> > > consuming lawsuits.
> > I understand your point. I thought you meant the developers of e.g.
> > KiSS.
> 
> I don't understand his point. IMO there will be at least as many or
> more legal disputes if we start licensing MPlayer for proprietary use,
> and it will be just as hard or harder to resolve them.

Well, Gabucino could argue that the licensing business brings in some
money, and that money can be used in legal battles. So it would save
money, but not time. (but I don't know how much A'rpi will ask for a
commercial license, and I also don't know what a worst-case lawsuit
costs) So his point, while it may have some merit, needs further
elaboration. 

However, I do think that most companies would pay for a license, just to
be free of the hassle of dealing with e-mails from customers who want
the source code and the wrath of the slashdot crowd. 

Those customers would be the real losers, in the case of proprietary
licensing KiSS et al could just say 'no, we don't have to give you the
source because we bought a license from The MPlayer Foundation'. The
MPlayer Foundation would, in that case, have publicly sacrificed the
right of that costumer (and all other customers) to look at the source
for some money/hardware/whatever.

I'd personally rather have KiSS lying about their copyright infringement
then them saying 'we have permission because we payed The MPlayer
Foundation money to be legally able to DENY you the freedoms you would
have had if they hadn't sold out (maniacal laughter)'.

Greetings,

Rik.

-- 
Nothing is ever a total loss; it can always serve as a bad example.



From dalias at aerifal.cx  Mon Feb 23 19:11:28 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Mon, 23 Feb 2004 13:11:28 -0500
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223175713.GB14268@cube.dyndns.org>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
	<20040223171405.GA14268@cube.dyndns.org>
	<20040223172649.GG9096@brightrain.aerifal.cx>
	<20040223175713.GB14268@cube.dyndns.org>
Message-ID: <20040223181128.GH9096@brightrain.aerifal.cx>

On Mon, Feb 23, 2004 at 06:57:13PM +0100, rsnel at cube.dyndns.org wrote:
> On Mon, Feb 23, 2004 at 12:26:49PM -0500, D Richard Felker III wrote:
> > On Mon, Feb 23, 2004 at 06:14:05PM +0100, rsnel at cube.dyndns.org wrote:
> > > On Mon, Feb 23, 2004 at 05:18:01PM +0100, Gabucino wrote:
> > > > It helps the developers avoiding potentially harmful and time+money 
> > > > consuming lawsuits.
> > > I understand your point. I thought you meant the developers of e.g.
> > > KiSS.
> > 
> > I don't understand his point. IMO there will be at least as many or
> > more legal disputes if we start licensing MPlayer for proprietary use,
> > and it will be just as hard or harder to resolve them.
> 
> Well, Gabucino could argue that the licensing business brings in some
> money, and that money can be used in legal battles. So it would save
> money, but not time. (but I don't know how much A'rpi will ask for a
> commercial license, and I also don't know what a worst-case lawsuit
> costs) So his point, while it may have some merit, needs further
> elaboration. 
> 
> However, I do think that most companies would pay for a license, just to
> be free of the hassle of dealing with e-mails from customers who want
> the source code and the wrath of the slashdot crowd. 
> 
> Those customers would be the real losers, in the case of proprietary
> licensing KiSS et al could just say 'no, we don't have to give you the
> source because we bought a license from The MPlayer Foundation'. The
> MPlayer Foundation would, in that case, have publicly sacrificed the
> right of that costumer (and all other customers) to look at the source
> for some money/hardware/whatever.
> 
> I'd personally rather have KiSS lying about their copyright infringement
> then them saying 'we have permission because we payed The MPlayer
> Foundation money to be legally able to DENY you the freedoms you would
> have had if they hadn't sold out (maniacal laughter)'.

Agree totally.

Rich



From gabucino at mplayerhq.hu  Mon Feb 23 21:26:56 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Mon, 23 Feb 2004 21:26:56 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223171942.GC9096@brightrain.aerifal.cx>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154549.GZ9096@brightrain.aerifal.cx>
	<20040223162239.GE4401@woodstock.localdomain>
	<20040223171942.GC9096@brightrain.aerifal.cx>
Message-ID: <20040223202656.GB5009@woodstock.localdomain>

D Richard Felker III wrote:
> > Dual-licensing money would be available for every developer - if they (you)
> > refuse accepting it due to religious RMS-Rulez-Free-Like-Beer/Whatever reasons,
> > that is entirely your problem.
> Actually it's your problem when they decide not to code, or to code
> their own player instead.
That stuff happens quite often either way. And there are not too many
really active developers whose code is everywhere.


> > We already do. The only way we won't help them is closing the source
> > entirely.
> Now you're being a complete idiot. WAAAH WAAAAAH THEY STOLE R CODE NOW
> WE NOT DEVELOP ANYMORE AND U ALL LOOZE ROTFL!!!
Calm down, this is just a fact, and a discussion. Not the way to go, that's
acknowledged.


> movie player that works. As soon as you stop this for whatever petty
> reason, YOU LOSE and "THEY" WIN (they being the proprietary lamers).
I don't see the world in black and white.


> (b) taking legal action against anyone who uses MPlayer code for
> proprietary purposes
Gosh, Richard, legal action doesn't "just happen" by the Fellow OSS Community!
Who is going to support it? You? No offense but you're a Free Software guy, who
can't stand the air of a courtroom, so I guess the answer is no.


> When developing free software, the goal is making good free software, and
> making sure it's better than the proprietary junk. Not boosting your ego or
> getting paid.
And another goal is not letting "them" steal your work easily. GPL doesn't
protect against that no matter what RMS says, unless you have big bucks to back
it up.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040223/9cf50064/attachment.pgp>

From gabucino at mplayerhq.hu  Mon Feb 23 21:34:26 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Mon, 23 Feb 2004 21:34:26 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223171405.GA14268@cube.dyndns.org>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
	<20040223171405.GA14268@cube.dyndns.org>
Message-ID: <20040223203426.GC5009@woodstock.localdomain>

rsnel at cube.dyndns.org wrote:
> Dual-licensing doesn't solve the ethical problem; it makes the ethical
> problem unsolvable (it can't even be solved through legal means anymore).
In case you (and Richard) think I'm (or Arpi is) a fan of proprietary stuff, I
assure you are mistaken. I just think there is a way of least disturbance.


> > Would _you_ support a lawsuit?
> Well, I am not a lawyer, so I don't know what it takes to take such a
> case to court, and what it takes to convince a judge that code was
> copied while in non-compliance with the license and therefore
> the company (e.g. KiSS) is guilty of copyright infringement. Maybe we
> should ask for legal counsel on the 'donations page'... 
I've consulted a lot of lawyers, and each one of them suggested a deal, not
a lawsuit. I'd have enjoyed the later one, but I understand the first one
is a smaller mess.


> (And, what Rich just said, we could assign copyright to the FSF, then
> they will fight the legal battles)
Now that's disturbing :)

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040223/d21be3b0/attachment.pgp>

From gabucino at mplayerhq.hu  Mon Feb 23 21:34:54 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Mon, 23 Feb 2004 21:34:54 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223172649.GG9096@brightrain.aerifal.cx>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
	<20040223171405.GA14268@cube.dyndns.org>
	<20040223172649.GG9096@brightrain.aerifal.cx>
Message-ID: <20040223203454.GD5009@woodstock.localdomain>

D Richard Felker III wrote:
> more legal disputes if we start licensing MPlayer for proprietary use,
> and it will be just as hard or harder to resolve them.
BTW libmad is dual licensed, and it's part of the core Debian..

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040223/5ac14a4e/attachment.pgp>

From Reimar.Doeffinger at stud.uni-karlsruhe.de  Mon Feb 23 21:38:03 2004
From: Reimar.Doeffinger at stud.uni-karlsruhe.de (=?ISO-8859-15?Q?Reimar_D=F6ffinger?=)
Date: Mon, 23 Feb 2004 21:38:03 +0100
Subject: [MPlayer-G2-dev] [PATCH] vo_x11_fullscreen check width and height
Message-ID: <403A64AB.6090509@stud.uni-karlsruhe.de>

Hello,

I want to propose the following patch that makes sure that the window 
width and height are set to values != 0
I think this would be helpfull as X errors are a bit hard to track down 
(at least I needed some time to find it), and additionally it will 'fix' 
vo_gl2 until I get around to really fix it (which starts directly in 
fullscreen mode and thus vo_old_width and vo_old_height aren't set).
Comments are welcome.

Greetings,
Reimar D?ffinger
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fullscreen_check.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040223/9c8c87d9/attachment.asc>

From arpi at thot.banki.hu  Mon Feb 23 21:45:07 2004
From: arpi at thot.banki.hu (Arpi)
Date: Mon, 23 Feb 2004 21:45:07 +0100 (CET)
Subject: [MPlayer-G2-dev] [PATCH] vo_x11_fullscreen check width and height
In-Reply-To: <403A64AB.6090509@stud.uni-karlsruhe.de>
Message-ID: <20040223204507.65D813FA@mail.mplayerhq.hu>

Hi,

> This is a multi-part message in MIME format.
> 
> Hello,
> 
> I want to propose the following patch that makes sure that the window 
> width and height are set to values != 0
> I think this would be helpfull as X errors are a bit hard to track down 
> (at least I needed some time to find it), and additionally it will 'fix' 
> vo_gl2 until I get around to really fix it (which starts directly in 
> fullscreen mode and thus vo_old_width and vo_old_height aren't set).
> Comments are welcome.

i gues sthis belongs to -dev-eng, not to -g2-dev
(as g2 has no gl2 driver, nor fullscreen mode)


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu



From Reimar.Doeffinger at stud.uni-karlsruhe.de  Mon Feb 23 21:50:38 2004
From: Reimar.Doeffinger at stud.uni-karlsruhe.de (=?ISO-8859-1?Q?Reimar_D=F6ffinger?=)
Date: Mon, 23 Feb 2004 21:50:38 +0100
Subject: [MPlayer-G2-dev] [PATCH] vo_x11_fullscreen check width and height
In-Reply-To: <20040223204507.65D813FA@mail.mplayerhq.hu>
References: <20040223204507.65D813FA@mail.mplayerhq.hu>
Message-ID: <403A679E.7000508@stud.uni-karlsruhe.de>

> 
> i gues sthis belongs to -dev-eng, not to -g2-dev
> (as g2 has no gl2 driver, nor fullscreen mode)

Ooops, sorry my mouse hit the wrong place :-(



From gabucino at mplayerhq.hu  Mon Feb 23 21:53:38 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Mon, 23 Feb 2004 21:53:38 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223175713.GB14268@cube.dyndns.org>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
	<20040223171405.GA14268@cube.dyndns.org>
	<20040223172649.GG9096@brightrain.aerifal.cx>
	<20040223175713.GB14268@cube.dyndns.org>
Message-ID: <20040223205338.GE5009@woodstock.localdomain>

rsnel at cube.dyndns.org wrote:
> Those customers would be the real losers, in the case of proprietary
> licensing KiSS et al could just say 'no, we don't have to give you the
> source because we bought a license from The MPlayer Foundation'. The
> MPlayer Foundation would, in that case, have publicly sacrificed the
> right of that costumer (and all other customers) to look at the source
> for some money/hardware/whatever.
I - personally - don't believe in that stuff.

Why would anyone want to recompile his DVD player's MPlayerG2, when he can
have it for free on his computer? :o


> I'd personally rather have KiSS lying about their copyright infringement
> then them saying 'we have permission because we payed The MPlayer
> Foundation money to be legally able to DENY you the freedoms you would
> have had if they hadn't sold out (maniacal laughter)'.
Now, that's exaggerated.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040223/da439d61/attachment.pgp>

From dalias at aerifal.cx  Mon Feb 23 23:21:12 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Mon, 23 Feb 2004 17:21:12 -0500
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223202656.GB5009@woodstock.localdomain>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154549.GZ9096@brightrain.aerifal.cx>
	<20040223162239.GE4401@woodstock.localdomain>
	<20040223171942.GC9096@brightrain.aerifal.cx>
	<20040223202656.GB5009@woodstock.localdomain>
Message-ID: <20040223222112.GM9096@brightrain.aerifal.cx>

On Mon, Feb 23, 2004 at 09:26:56PM +0100, Gabucino wrote:
> > (b) taking legal action against anyone who uses MPlayer code for
> > proprietary purposes
> Gosh, Richard, legal action doesn't "just happen" by the Fellow OSS Community!
> Who is going to support it? You? No offense but you're a Free Software guy, who
> can't stand the air of a courtroom, so I guess the answer is no.

I expect if MPlayer asks for donations to pay for a lawyer, many many
users would donate. I'd be happy to work on legal logistics if the
matter were in my country, but IIRC KISS is somewhere in Europe, so
one of the Europeans should probably take care of it.

> > When developing free software, the goal is making good free software, and
> > making sure it's better than the proprietary junk. Not boosting your ego or
> > getting paid.
> And another goal is not letting "them" steal your work easily. GPL doesn't
> protect against that no matter what RMS says, unless you have big bucks to back
> it up.

Or you take the easy approach and assign copyright to someone who can
and will take action to back it up. This could be the FSF, but doesn't
necessarily have to be.

Rich



From dalias at aerifal.cx  Mon Feb 23 23:23:09 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Mon, 23 Feb 2004 17:23:09 -0500
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223203426.GC5009@woodstock.localdomain>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
	<20040223171405.GA14268@cube.dyndns.org>
	<20040223203426.GC5009@woodstock.localdomain>
Message-ID: <20040223222309.GN9096@brightrain.aerifal.cx>

On Mon, Feb 23, 2004 at 09:34:26PM +0100, Gabucino wrote:
> > > Would _you_ support a lawsuit?
> > Well, I am not a lawyer, so I don't know what it takes to take such a
> > case to court, and what it takes to convince a judge that code was
> > copied while in non-compliance with the license and therefore
> > the company (e.g. KiSS) is guilty of copyright infringement. Maybe we
> > should ask for legal counsel on the 'donations page'... 
> I've consulted a lot of lawyers, and each one of them suggested a deal, not
> a lawsuit. I'd have enjoyed the later one, but I understand the first one
> is a smaller mess.

A deal is good, as long as it involves them releasing their whole
program under GPL or at least halting all production permenantly.
Otherwise those wronged gain nothing. (Money only goes to the
developers, who are NOT the ones wronged. The ones wronged are all the
people of the world who are unable to use their sources, whether or
not they want to, because of proprietary restrictions.)

Rich



From dalias at aerifal.cx  Mon Feb 23 23:26:02 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Mon, 23 Feb 2004 17:26:02 -0500
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223205338.GE5009@woodstock.localdomain>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
	<20040223171405.GA14268@cube.dyndns.org>
	<20040223172649.GG9096@brightrain.aerifal.cx>
	<20040223175713.GB14268@cube.dyndns.org>
	<20040223205338.GE5009@woodstock.localdomain>
Message-ID: <20040223222602.GO9096@brightrain.aerifal.cx>

On Mon, Feb 23, 2004 at 09:53:38PM +0100, Gabucino wrote:
> rsnel at cube.dyndns.org wrote:
> > Those customers would be the real losers, in the case of proprietary
> > licensing KiSS et al could just say 'no, we don't have to give you the
> > source because we bought a license from The MPlayer Foundation'. The
> > MPlayer Foundation would, in that case, have publicly sacrificed the
> > right of that costumer (and all other customers) to look at the source
> > for some money/hardware/whatever.
> I - personally - don't believe in that stuff.
> 
> Why would anyone want to recompile his DVD player's MPlayerG2, when he can
> have it for free on his computer? :o

Maybe we want to recompile our DVD player to add support for file
formats that are missing, so we don't have to pay the vendor to buy a
whole new player. Think of NUT support. Maybe they don't support NUT,
so we want to add it.

Now, a much more realistic scenario: The vendor wants to add some
nasty DRM/pay-per-view/etc. type functionality to their product based
on G2. Under GPL, they MUST release all their source, which renders
their evil DRM scheme useless. If they can just license MPlayer, then
they're able to make their DRM-enabled player, AND benefit from the
robustness and features of MPlayer. This is wrong!

Rich



From rsnel at cube.dyndns.org  Tue Feb 24 00:17:45 2004
From: rsnel at cube.dyndns.org (rsnel at cube.dyndns.org)
Date: Tue, 24 Feb 2004 00:17:45 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223205338.GE5009@woodstock.localdomain>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
	<20040223171405.GA14268@cube.dyndns.org>
	<20040223172649.GG9096@brightrain.aerifal.cx>
	<20040223175713.GB14268@cube.dyndns.org>
	<20040223205338.GE5009@woodstock.localdomain>
Message-ID: <20040223231745.GA25338@cube.dyndns.org>

On Mon, Feb 23, 2004 at 09:53:38PM +0100, Gabucino wrote:
> > Those customers would be the real losers, in the case of proprietary
> > licensing KiSS et al could just say 'no, we don't have to give you the
> > source because we bought a license from The MPlayer Foundation'. The
> > MPlayer Foundation would, in that case, have publicly sacrificed the
> > right of that costumer (and all other customers) to look at the source
> > for some money/hardware/whatever.
> I - personally - don't believe in that stuff.
> 
> Why would anyone want to recompile his DVD player's MPlayerG2, when he can
> have it for free on his computer? :o
The customer would want to see the source, because the vendor obviously
has something to hide (misfeatures/DRM/spyware). If they have nothing to
hide, why would they not contribute back their changes? 

> > I'd personally rather have KiSS lying about their copyright infringement
> > then them saying 'we have permission because we payed The MPlayer
> > Foundation money to be legally able to DENY you the freedoms you would
> > have had if they hadn't sold out (maniacal laughter)'.
> Now, that's exaggerated.
I'm trying to make a point here... maybe the maniacal laughter was
exaggerated, but I find 'sold out' appropriate. 'sold out' is meant in
the sense of 'betraying a cause for personal advancement' (It could be
that you/A'rpi find the cause for free software not _that_ important,
then it is for you no big deal to 'betray' it. If that is the case then
this is where we disagree.)

Greetings,

Rik.

-- 
Nothing is ever a total loss; it can always serve as a bad example.



From gabucino at mplayerhq.hu  Tue Feb 24 00:38:17 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Tue, 24 Feb 2004 00:38:17 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223222112.GM9096@brightrain.aerifal.cx>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154549.GZ9096@brightrain.aerifal.cx>
	<20040223162239.GE4401@woodstock.localdomain>
	<20040223171942.GC9096@brightrain.aerifal.cx>
	<20040223202656.GB5009@woodstock.localdomain>
	<20040223222112.GM9096@brightrain.aerifal.cx>
Message-ID: <20040223233817.GB6359@woodstock.localdomain>

D Richard Felker III wrote:
> > can't stand the air of a courtroom, so I guess the answer is no.
> I expect if MPlayer asks for donations to pay for a lawyer, many many
> users would donate.
 - assuming the violation is ever found
 - "expect" ... "would"
What you say is nice, but I can't agree wholeheartedly.


> Or you take the easy approach and assign copyright to someone who can
> and will take action to back it up. This could be the FSF, but doesn't
> necessarily have to be.
Like I trust them to do so... And I guess A'rpi wants to hold the copyright.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040224/fce57ef8/attachment.pgp>

From gabucino at mplayerhq.hu  Tue Feb 24 00:42:51 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Tue, 24 Feb 2004 00:42:51 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223222602.GO9096@brightrain.aerifal.cx>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
	<20040223171405.GA14268@cube.dyndns.org>
	<20040223172649.GG9096@brightrain.aerifal.cx>
	<20040223175713.GB14268@cube.dyndns.org>
	<20040223205338.GE5009@woodstock.localdomain>
	<20040223222602.GO9096@brightrain.aerifal.cx>
Message-ID: <20040223234251.GC6359@woodstock.localdomain>

D Richard Felker III wrote:
> Maybe we want to recompile our DVD player to add support for file
> formats that are missing, so we don't have to pay the vendor to buy a
> whole new player. Think of NUT support. Maybe they don't support NUT,
> so we want to add it.
It's known that I hate DVD players.. Get a dualhead card for Linux, it's
more versatile.


> If they can just license MPlayer, then they're able to make their DRM-enabled
> player, AND benefit from the robustness and features of MPlayer.
You left out something: developers are compensated.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040224/ec9430b3/attachment.pgp>

From gabucino at mplayerhq.hu  Tue Feb 24 00:46:05 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Tue, 24 Feb 2004 00:46:05 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223231745.GA25338@cube.dyndns.org>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
	<20040223171405.GA14268@cube.dyndns.org>
	<20040223172649.GG9096@brightrain.aerifal.cx>
	<20040223175713.GB14268@cube.dyndns.org>
	<20040223205338.GE5009@woodstock.localdomain>
	<20040223231745.GA25338@cube.dyndns.org>
Message-ID: <20040223234605.GD6359@woodstock.localdomain>

rsnel at cube.dyndns.org wrote:
> exaggerated, but I find 'sold out' appropriate. 'sold out' is meant in
> the sense of 'betraying a cause for personal advancement' (It could be
Well then make bread free, because the crops are free!

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040224/443208bc/attachment.pgp>

From gabucino at mplayerhq.hu  Tue Feb 24 00:48:52 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Tue, 24 Feb 2004 00:48:52 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223222309.GN9096@brightrain.aerifal.cx>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
	<20040223171405.GA14268@cube.dyndns.org>
	<20040223203426.GC5009@woodstock.localdomain>
	<20040223222309.GN9096@brightrain.aerifal.cx>
Message-ID: <20040223234852.GE6359@woodstock.localdomain>

D Richard Felker III wrote:
> A deal is good, as long as it involves them releasing their whole
> program under GPL or at least halting all production permenantly.
This is why I suggested mplayer-legal..


> The ones wronged are all the people of the world who are unable to use their
> sources, whether or not they want to, because of proprietary restrictions.)
This is the RMS-ish viewpoint which is IMHO bullshit and every time I hear
it, I get an itch.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040224/a7dc5084/attachment.pgp>

From dalias at aerifal.cx  Tue Feb 24 01:42:19 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Mon, 23 Feb 2004 19:42:19 -0500
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223234852.GE6359@woodstock.localdomain>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
	<20040223171405.GA14268@cube.dyndns.org>
	<20040223203426.GC5009@woodstock.localdomain>
	<20040223222309.GN9096@brightrain.aerifal.cx>
	<20040223234852.GE6359@woodstock.localdomain>
Message-ID: <20040224004219.GS9096@brightrain.aerifal.cx>

On Tue, Feb 24, 2004 at 12:48:52AM +0100, Gabucino wrote:
> D Richard Felker III wrote:
> > A deal is good, as long as it involves them releasing their whole
> > program under GPL or at least halting all production permenantly.
> This is why I suggested mplayer-legal..
> 
> 
> > The ones wronged are all the people of the world who are unable to use their
> > sources, whether or not they want to, because of proprietary restrictions.)
> This is the RMS-ish viewpoint which is IMHO bullshit and every time I hear
> it, I get an itch.

Assuming an upper bound on program size, there are a finite number of
programs. Every time someone makes and holds copyright on a new
program, and doesn't make it free, a chunk of this pie is stolen from
what others could potentially create in the future. One out of this
gigantic finite number might seems insignificant, but once you
consider that copyright covers anything similar/derived, and once you
consider the sheer amount of proprietary software being produced, it
IS significant.

If you don't believe me, look at patents. Every useful idea (even
trivial ones) gets scooped up and "owned" by someone, so no one else
can use the same idea even if it comes to them freely. The only reason
this is so blatently obvious with patents is that their scope is so
much broader. Given time, exactly the same thing will happy with
copyright. It's naive to underestimate the anti-creative power of
copyright, and outright counterproductive to mock those who fight it.

BTW, here's another argument against dual-licensing. Suppose you add a
new feature to MPlayer, and this new feature is in the GPL-only part.
Now your greedy licensee comes and says "hey, you didn't write that!
it's part of our closed-source mplayer and someone ported it back to
yours without our permission!" This is very hard to argue against, and
the party with more money wins. Of course the greedy licensee can't
make this argument when the only license is GPL, since they're
required to license any derivative work they make under the GPL.

Rich



From gabucino at mplayerhq.hu  Tue Feb 24 10:36:49 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Tue, 24 Feb 2004 10:36:49 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040224004219.GS9096@brightrain.aerifal.cx>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223140615.GA32683@cube.dyndns.org>
	<20040223144643.GA3622@woodstock.localdomain>
	<20040223154631.GA11043@cube.dyndns.org>
	<20040223161801.GD4401@woodstock.localdomain>
	<20040223171405.GA14268@cube.dyndns.org>
	<20040223203426.GC5009@woodstock.localdomain>
	<20040223222309.GN9096@brightrain.aerifal.cx>
	<20040223234852.GE6359@woodstock.localdomain>
	<20040224004219.GS9096@brightrain.aerifal.cx>
Message-ID: <20040224093649.GA7058@woodstock.localdomain>

D Richard Felker III wrote:
> BTW, here's another argument against dual-licensing. Suppose you add a
> new feature to MPlayer, and this new feature is in the GPL-only part.
> Now your greedy licensee comes and says "hey, you didn't write that!
> it's part of our closed-source mplayer and someone ported it back to
> yours without our permission!" This is very hard to argue against, and
> the party with more money wins. Of course the greedy licensee can't
> make this argument when the only license is GPL, since they're
> required to license any derivative work they make under the GPL.
This is not a good example, because a greedy licensee either:
 - steals it silently
 - can already attack even GPL code, like SCO does
 - doesn't argue, because they are partly dependant on our code improvements
 - is already filthly rich while we are dirt poor, so they gain nothing even
   if they won.

Remember, the GPL licensed version of the code is already "out there", and they
can't kill everyone using it.

Can you come up with an example where a duallicensed opensource code had such
problems?

BTW we can state the second license is valid only while a licensee doesn't
raise a lawsuit against us. :) Or sth.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040224/c2cc4a9b/attachment.pgp>

From gsbarbieri at yahoo.com.br  Wed Feb 25 04:37:31 2004
From: gsbarbieri at yahoo.com.br (=?iso-8859-1?q?Gustavo=20Sverzut=20Barbieri?=)
Date: Wed, 25 Feb 2004 00:37:31 -0300 (ART)
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223121659.2c81face.attila@kinali.ch>
Message-ID: <20040225033731.64697.qmail@web20911.mail.yahoo.com>

 --- Attila Kinali <attila at kinali.ch> escreveu: 
> Poll 1:
> So, we have 2 options:
> 1) Leave MPlayer GPL
> 2) Make MPlayer GPL/LGPL 

I vote for 1.


Gustavo


______________________________________________________________________

Yahoo! Mail - O melhor e-mail do Brasil! Abra sua conta agora:
http://br.yahoo.com/info/mail.html



From dalias at aerifal.cx  Wed Feb 25 05:57:00 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Tue, 24 Feb 2004 23:57:00 -0500
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040225033731.64697.qmail@web20911.mail.yahoo.com>
References: <20040223121659.2c81face.attila@kinali.ch>
	<20040225033731.64697.qmail@web20911.mail.yahoo.com>
Message-ID: <20040225045700.GD9096@brightrain.aerifal.cx>

On Wed, Feb 25, 2004 at 12:37:31AM -0300, Gustavo Sverzut Barbieri wrote:
>  --- Attila Kinali <attila at kinali.ch> escreveu: 
> > Poll 1:
> > So, we have 2 options:
> > 1) Leave MPlayer GPL
> > 2) Make MPlayer GPL/LGPL 
> 
> I vote for 1.

In case it wasn't already obvious, I vote for 1 as well.

Rich



From gsbarbieri at yahoo.com.br  Wed Feb 25 06:39:44 2004
From: gsbarbieri at yahoo.com.br (=?iso-8859-1?q?Gustavo=20Sverzut=20Barbieri?=)
Date: Wed, 25 Feb 2004 02:39:44 -0300 (ART)
Subject: [MPlayer-G2-dev] Legal issues: would companies really pay?
Message-ID: <20040225053944.40206.qmail@web20916.mail.yahoo.com>

Hello,

Gabuccino is really sure companies will pay for mplayer licenses. Would
they?

Imagine mplayer license the core under BSD to them... to make it worth,
it need to be a good amount of money, since we want to help developers
AND have a fund to fight lawsuits.

Now this company find some bugs and fixes them, no code back to
mplayer.

Then a second company comes along and instead of licensing from
mplayer, it licenses from the company who licensed from mplayer, for
90% of the price and with bugfixes.

The company who first licensed could even start to port from current
mplayer to its own copy, they will be stealing, but as they have some
licensed parts, it will be difficult to prove to non-tech people
(court) that they did steal code.

In a even worst scenario, the second company maybe didn't know mplayer,
bought the code and later discover mplayer and argue someone is giving
the same code they bought for free (GPL version) and make a real mess.

So, together with other points argued by Rich and Rik, 2-licenses will
not help at all.

I liked Rich's idea of MPlayer developers being employed to help
improve mplayer, or customize it, etc... so they could have some money.

In the worst case, we should have the core licensed under LGPL, so the
damn-closed codecs (like pay-per-view, etc) could use their non-free
modules linked with mplayer. 
   But we need to know how many devs will want this, how many want to
make a living from mplayer this way and stuff like this.

Maybe you are elluded with the success mplayer have? MPlayer success
maybe make you thougth: Wow, what a piece of software! Many other
software are really worse than it and make money, shoudn't I make money
from it?
    Well, you really should make some money from it, it's really a
excellent piece of software, but the money should come other way than
that.
    And you should know (I know you know) that main reason for mplayer
success is being FREE, being OPEN [FOREVER], being GPL. Maybe if you
were BSD, many users wouldn't send you code, collaborating to other
project instead.

    MPlayer was bought to play things made by enterprise who care
nothing about us, people. You devs worked hard and now your player is
the best cost/benefit out there and they want your code, should you
give it to them? So what, they will put more bad things in the world so
then you will reverse-engineer the whole thing to be able to play it?


Gustavo

______________________________________________________________________

Yahoo! Mail - O melhor e-mail do Brasil! Abra sua conta agora:
http://br.yahoo.com/info/mail.html



From ajh at watri.org.au  Wed Feb 25 06:56:01 2004
From: ajh at watri.org.au (Anders Johansson)
Date: Wed, 25 Feb 2004 13:56:01 +0800
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040222173830.0614E31818@mail.mplayerhq.hu>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
Message-ID: <20040225055601.GB22170@watri.org.au>

Hi,

I am against dual licensing as well, and will not let af become
non-GPL, I could however consider LGPL.

If you want to earn money from MPlayer try to sell the service of
adopting MPlayer to a specific platform instead of trying to sell the
code itself. If you really want to be able to interface mplayer to
closed source stuff - then just make every module dynamically
loadable (that's what I have done in my professional work).

Sorry and good luck,
//Anders



From dalias at aerifal.cx  Wed Feb 25 07:28:41 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Wed, 25 Feb 2004 01:28:41 -0500
Subject: [MPlayer-G2-dev] Legal issues: would companies really pay?
In-Reply-To: <20040225053944.40206.qmail@web20916.mail.yahoo.com>
References: <20040225053944.40206.qmail@web20916.mail.yahoo.com>
Message-ID: <20040225062841.GE9096@brightrain.aerifal.cx>

On Wed, Feb 25, 2004 at 02:39:44AM -0300, Gustavo Sverzut Barbieri wrote:
> Hello,
> 
> Gabuccino is really sure companies will pay for mplayer licenses. Would
> they?
> 
> Imagine mplayer license the core under BSD to them... to make it worth,
> it need to be a good amount of money, since we want to help developers
> AND have a fund to fight lawsuits.

BSD license? Of course not, this would be stupid. Instead you use an
entirely non-free license.

> Now this company find some bugs and fixes them, no code back to
> mplayer.
> 
> Then a second company comes along and instead of licensing from
> mplayer, it licenses from the company who licensed from mplayer, for
> 90% of the price and with bugfixes.

Not possible. As opposed to a free one, a commercial license never
gives the recipient permission to sublicense. Do you think you can
take your copy of Windows from M$, and relicense it to people cheap?
Good luck trying it, but M$'s lawyers will have you in no time!

> The company who first licensed could even start to port from current
> mplayer to its own copy, they will be stealing, but as they have some
> licensed parts, it will be difficult to prove to non-tech people
> (court) that they did steal code.

I agree this is a big problem.

> I liked Rich's idea of MPlayer developers being employed to help
> improve mplayer, or customize it, etc... so they could have some money.

At least a couple lavc developers already have been hired to add
features, which businesses intend to use under the LGPL.

>     MPlayer was bought to play things made by enterprise who care
> nothing about us, people. You devs worked hard and now your player is
> the best cost/benefit out there and they want your code, should you
> give it to them? So what, they will put more bad things in the world so
> then you will reverse-engineer the whole thing to be able to play it?

Hahaha, well said! :)

Rich



From dalias at aerifal.cx  Wed Feb 25 07:32:49 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Wed, 25 Feb 2004 01:32:49 -0500
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040225055601.GB22170@watri.org.au>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040225055601.GB22170@watri.org.au>
Message-ID: <20040225063249.GF9096@brightrain.aerifal.cx>

On Wed, Feb 25, 2004 at 01:56:01PM +0800, Anders Johansson wrote:
> Hi,
> 
> I am against dual licensing as well, and will not let af become
> non-GPL, I could however consider LGPL.

I hate to start a disagreement between the anti-dual-license people,
but FYI libaf is slated for replacement/removal in G2...

> If you want to earn money from MPlayer try to sell the service of
> adopting MPlayer to a specific platform instead of trying to sell the
> code itself.

I agree totally, but I don't think the goal was to make money. Rather
the goal was to try to get "something" rather than "nothing" from the
lamers already stealing mplayer code. But IMO this is selling out and
won't work anyway.

> If you really want to be able to interface mplayer to
> closed source stuff - then just make every module dynamically
> loadable (that's what I have done in my professional work).

Dynamically loading GPL code does not get around the GPL. If your
proprietary program is using the GPL code, it must be fully GPL or (a
technicality here) you must refrain from distributing the GPL'd code
AT ALL (since you have forfeited your rights under the GPL by not
releasing your program under the GPL).

Rich



From ajh at watri.org.au  Wed Feb 25 08:26:28 2004
From: ajh at watri.org.au (Anders Johansson)
Date: Wed, 25 Feb 2004 15:26:28 +0800
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040225063249.GF9096@brightrain.aerifal.cx>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040225055601.GB22170@watri.org.au>
	<20040225063249.GF9096@brightrain.aerifal.cx>
Message-ID: <20040225072628.GB14006@watri.org.au>

> > If you really want to be able to interface mplayer to
> > closed source stuff - then just make every module dynamically
> > loadable (that's what I have done in my professional work).
> 
> Dynamically loading GPL code does not get around the GPL. If your
> proprietary program is using the GPL code, it must be fully GPL or (a
> technicality here) you must refrain from distributing the GPL'd code
> AT ALL (since you have forfeited your rights under the GPL by not
> releasing your program under the GPL).

I meant loading proprietary libs from GPL applications, the way
mplayer loads windows DLLs. If all parts of MPlayer were dynamically
loadable it would be easy to mix proprietary modules with non
proprietary as long as the core (module loader) was still GPL. I guess
this is what is commonly called the gray area of GPL, and the loophole
which allows driver writers to release closed source drivers for the
Linux kernel for example.

> Rich

//Anders





From jjermann at gmx.net  Wed Feb 25 08:35:32 2004
From: jjermann at gmx.net (Jonas Jermann)
Date: Wed, 25 Feb 2004 08:35:32 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040225033731.64697.qmail@web20911.mail.yahoo.com>
References: <20040223121659.2c81face.attila@kinali.ch>
	<20040225033731.64697.qmail@web20911.mail.yahoo.com>
Message-ID: <20040225073531.GA8488@morannon>

On Wed, Feb 25, 2004 at 12:37:31AM -0300, Gustavo Sverzut Barbieri wrote:
>  --- Attila Kinali <attila at kinali.ch> escreveu: 
> > Poll 1:
> > So, we have 2 options:
> > 1) Leave MPlayer GPL
> > 2) Make MPlayer GPL/LGPL 
> 
> I vote for 1.

Me too (if my vote counts).

Best Regards
	Jonas



From noisyb at gmx.net  Wed Feb 25 11:07:42 2004
From: noisyb at gmx.net (Dirk)
Date: Wed, 25 Feb 2004 11:07:42 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040225045700.GD9096@brightrain.aerifal.cx>
References: <20040223121659.2c81face.attila@kinali.ch>	<20040225033731.64697.qmail@web20911.mail.yahoo.com>
	<20040225045700.GD9096@brightrain.aerifal.cx>
Message-ID: <403C73EE.5070802@gmx.net>

D Richard Felker III wrote:

>On Wed, Feb 25, 2004 at 12:37:31AM -0300, Gustavo Sverzut Barbieri wrote:
>  
>
>> --- Attila Kinali <attila at kinali.ch> escreveu: 
>>    
>>
>>>Poll 1:
>>>So, we have 2 options:
>>>1) Leave MPlayer GPL
>>>2) Make MPlayer GPL/LGPL 
>>>      
>>>
>>I vote for 1.
>>    
>>
>
>In case it wasn't already obvious, I vote for 1 as well.
>
>Rich
>
>_______________________________________________
>MPlayer-G2-dev mailing list
>MPlayer-G2-dev at mplayerhq.hu
>http://mplayerhq.hu/mailman/listinfo/mplayer-g2-dev
>
>
>  
>
Sorry, that I dare to butt in to this important discussion, but to me it
seemes that the real problem is about the money that could be donated
(in option 2) and how it should be handled.

If you don't know how to divide it w/o loosing developers or the whole
project because of a fork then why don't you request patches instead of
money? And if someone HAS to donate money.. Why not forget about the
whole "I earn money with MPlayer" thing and pass all the cash to a
charity or http://www.eff.org (or a similar european org.) instead? You
could even save the rainforest...

However, let me (again) point the OBVIOUS thing out... Money is a
serious threat to everything where you expect people to contribute for
free (even if they're your friends)..

Dirk



From gabucino at mplayerhq.hu  Wed Feb 25 11:17:12 2004
From: gabucino at mplayerhq.hu (Gabucino)
Date: Wed, 25 Feb 2004 11:17:12 +0100
Subject: [MPlayer-G2-dev] Legal issues: would companies really pay?
In-Reply-To: <20040225053944.40206.qmail@web20916.mail.yahoo.com>
References: <20040225053944.40206.qmail@web20916.mail.yahoo.com>
Message-ID: <20040225101712.GA2353@woodstock.localdomain>

Gustavo Sverzut Barbieri wrote:
> Then a second company comes along and instead of licensing from
> mplayer, it licenses from the company who licensed from mplayer, for
> 90% of the price and with bugfixes.
As Richard said, this is nonsense.


>     And you should know (I know you know) that main reason for mplayer
> success is being FREE, being OPEN [FOREVER], being GPL.
Not true, MPlayer was already the most successful media player while it
wasn't even GPL (although marillat lied it as being so;).
People use MPlayer plainly because it's so fucking good.


> Maybe if you were BSD, many users wouldn't send you code, collaborating to
> other project instead.
BSD was just Arpi's bad wording, it'd definitely need much improvements to
fit our needs. Don't think of it as "plain" BSDL.


> give it to them? So what, they will put more bad things in the world so
> then you will reverse-engineer the whole thing to be able to play it?
Then again, what could they add to make harm? Who cares about DRM or pay/view?
Those things will fall eventually and I haven't heard any more arguments.

-- 
Gabucino
MPlayer Core Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040225/390fd274/attachment.pgp>

From albeu at free.fr  Wed Feb 25 12:34:16 2004
From: albeu at free.fr (Alban Bedel)
Date: Wed, 25 Feb 2004 12:34:16 +0100
Subject: [MPlayer-G2-dev] Re: dual licensing try 2
References: <20040223121659.2c81face.attila@kinali.ch>
	<20040225033731.64697.qmail@web20911.mail.yahoo.com>
	<20040225073531.GA8488@morannon>
Message-ID: <20040225123416.6e78d818.albeu@free.fr>

Hi Jonas Jermann,

on Wed, 25 Feb 2004 08:35:32 +0100 you wrote:

> On Wed, Feb 25, 2004 at 12:37:31AM -0300, Gustavo Sverzut Barbieri
> wrote:
> >  --- Attila Kinali <attila at kinali.ch> escreveu: 
> > > Poll 1:
> > > So, we have 2 options:
> > > 1) Leave MPlayer GPL
> > > 2) Make MPlayer GPL/LGPL 
> > 
> > I vote for 1.
> 
> Me too (if my vote counts).
me too.
	Albeu
-- 

Everything is controlled by a small evil group
to which, unfortunately, no one we know belongs.




From michaelni at gmx.at  Wed Feb 25 15:35:02 2004
From: michaelni at gmx.at (Michael Niedermayer)
Date: Wed, 25 Feb 2004 15:35:02 +0100
Subject: [MPlayer-G2-dev] Re: dual licensing try 2
In-Reply-To: <20040225123416.6e78d818.albeu@free.fr>
References: <20040223121659.2c81face.attila@kinali.ch>
	<20040225073531.GA8488@morannon>
	<20040225123416.6e78d818.albeu@free.fr>
Message-ID: <200402251535.02928.michaelni@gmx.at>

Hi

On Wednesday 25 February 2004 12:34, Alban Bedel wrote:
> Hi Jonas Jermann,
>
> on Wed, 25 Feb 2004 08:35:32 +0100 you wrote:
> > On Wed, Feb 25, 2004 at 12:37:31AM -0300, Gustavo Sverzut Barbieri
> >
> > wrote:
> > >  --- Attila Kinali <attila at kinali.ch> escreveu:
> > > > Poll 1:
> > > > So, we have 2 options:
> > > > 1) Leave MPlayer GPL
> > > > 2) Make MPlayer GPL/LGPL
> > >
> > > I vote for 1.
> >
> > Me too (if my vote counts).
>
> me too.
even though everyone already knows what i would vote ... i didnt yet, so 
vote: 1) Leave MPlayer GPL

-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en



From flodt8 at yahoo.de  Wed Feb 25 18:05:32 2004
From: flodt8 at yahoo.de (=?iso-8859-1?q?florian=20dietrich?=)
Date: Wed, 25 Feb 2004 18:05:32 +0100 (CET)
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040225063249.GF9096@brightrain.aerifal.cx>
Message-ID: <20040225170532.36246.qmail@web21408.mail.yahoo.com>

 --- D Richard Felker III <dalias at aerifal.cx> wrote:

> Dynamically loading GPL code does not get around the GPL. If your
> proprietary program is using the GPL code, it must be fully GPL or
> (a technicality here) you must refrain from distributing the GPL'd
> code AT ALL (since you have forfeited your rights under the GPL by
> not releasing your program under the GPL).

Hmm, so would a proprietary program be allowed to use mplayer G2 as
its "back-end"? If it is not, then that would clearly be more
restrictive than using mplayer G1, because it's fine to use mplayer
G1 in slave mode using a proprietary program (the way I understand
things).
I'm saying this without prejudice whether I think it's "right" or
"wrong" allowing a proprietary program to do that or not - though I
think that if there's people stupid enough paying for a simple
frontend, why not let them?

Anyway, I think we should get back to the question that A'rpi asked
in the beginning: What could be done to make mplayer G2 *THE* video
architecture for linux (or *ix in general)? And make it that not ony
for the users but for the companies too?

Let's try to evaluate what companies might want from such an
architecture then.

First, there's the (commercial) codec writers and filter writers.
The license of the mplayer core is probably not their concern, since
they don't need to use or change it (instead mplayer will use them,
right?). Of course it helps them if writing codec/filter interfaces
for mplayer is easy and doesn't change every once in a while (since
that means work (=money) for them). For the same reason, they might
want to be sure that it really is THE video architecture, because
otherwise they have to write several of those interfaces for
different back-ends. I'm not too worried about that though, because
of the performance and popularity of mplayer :-)

Then there's those wanting to write media players (basically
front-ends). I think there's probably two or three kinds of
front-ends they might want to write.

One kind (a and b) would a player that actually uses mplayer as its
back-end, but adds a certain amount of front-end functionality.
Simple players (a) might just be the user interface itself, looking
nice and having some neat playlist functionality etc., but basically
leaving file reading and processing and displaying completely to
mplayer itself. So all they do is pass file names.

Advanced players (b) might want to do more things that mplayer would
usually do, for example read the files themselves because they think
they can do better, or read from proprietary files/protocols, or do
the decoding themselves etc. Then they just let mplayer do the things
they don't want to do (only reading and displaying files, or only
reading or only decoding and so on). Of course mplayer would need to
be flexible enough to do that. Maybe to allow proprietary programs to
to both, the mplayer core would need to be LGPL then (as far as I
understand it).
This way, I guess mplayer would become something like DirectShow: A
back-end that you can use as much or as little as you want and that
is pretty universal. And if enough people use it, it's going to be
hard to imagine video on linux without mplayer G2 :-P

Then there's a second kind of media players, and that would be those
who want to do everything themselves. This is what I think A'rpi had
in mind. If you want to do everything yourself, they need to have a
player core, writing it themselves or taking (buying?) it from
someone.
This is of course only necessary if they are not allowed to
dynamically use a different core (your program is proprietary and the
core is GPL) or they actually *can* use it (your program is
proprietary and the core is LGPL or maybe it is possible under GPL?),
but it simply isn't enough for them. (Would it actually be possible
to use a GPL core if you access a LGPL lib that calls the GPL core?
Dunno.)
What you have to bear in mind though is, that if it isn't enough for
someone to simply use a core (which would be possible in the LGPL
case) and they instead buy it, the only reason I can think of why
they would do that is because they want to modify it or combine it
with your own proprietary code.
The question is whather that would really have the desired effect of
strenthening mplayer as a standard. Instead it might actually weaken
mplayer, because if someone adds their decoders to "their" core, or
changes interfaces etc., then they don't need to use "standard"
mplayer at all, and even could be incompatible. Well, at least that's
not what I think strenthening is. Sure, mplayers code is used, but
mplayer as a video standard doesn't benefit. In the worst case, even
their modified mplayer might become a proprietary "standard", if it
becomes popular enough (and benefits from the stability of mplayer).

If someone wants to use codecs and filters written for mplayer G2,
then they can still write their own application using them, without
needing mplayers core, because the interfaces are all open and not
patented and can be used by anyone, even commercial people. If
someone wants the functionality of mplayer in standalone devices etc,
it would probably be enough for them to link dynamically to mplayer
(if it were LGPL?) if it is universal enough. And changes to it would
come back to mplayer.

Well, that's my thoughts for now :-)
Florian


	
		
Mit sch?nen Gr??en von Yahoo! Mail - http://mail.yahoo.de



From pnis at coder.hu  Wed Feb 25 18:24:19 2004
From: pnis at coder.hu (Balatoni Denes)
Date: Wed, 25 Feb 2004 18:24:19 +0100
Subject: [MPlayer-G2-dev] Re: dual licensing try 2
In-Reply-To: <200402251535.02928.michaelni@gmx.at>
References: <20040223121659.2c81face.attila@kinali.ch>
	<20040225123416.6e78d818.albeu@free.fr>
	<200402251535.02928.michaelni@gmx.at>
Message-ID: <200402251824.19233.pnis@coder.hu>

Hi!

> > > > > Poll 1:
> > > > > So, we have 2 options:
> > > > > 1) Leave MPlayer GPL
> > > > > 2) Make MPlayer GPL/LGPL

As much as my vote may matter, I vote for 2, but 1 is fine too.

bye
Denes


-- 
- Use the Source Luke ! -



From dalias at aerifal.cx  Wed Feb 25 19:28:53 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Wed, 25 Feb 2004 13:28:53 -0500
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040225170532.36246.qmail@web21408.mail.yahoo.com>
References: <20040225063249.GF9096@brightrain.aerifal.cx>
	<20040225170532.36246.qmail@web21408.mail.yahoo.com>
Message-ID: <20040225182853.GK9096@brightrain.aerifal.cx>

On Wed, Feb 25, 2004 at 06:05:32PM +0100, florian dietrich wrote:
>  --- D Richard Felker III <dalias at aerifal.cx> wrote:
> 
> > Dynamically loading GPL code does not get around the GPL. If your
> > proprietary program is using the GPL code, it must be fully GPL or
> > (a technicality here) you must refrain from distributing the GPL'd
> > code AT ALL (since you have forfeited your rights under the GPL by
> > not releasing your program under the GPL).
> 
> Hmm, so would a proprietary program be allowed to use mplayer G2 as
> its "back-end"? If it is not, then that would clearly be more
> restrictive than using mplayer G1, because it's fine to use mplayer
> G1 in slave mode using a proprietary program (the way I understand
> things).
> I'm saying this without prejudice whether I think it's "right" or
> "wrong" allowing a proprietary program to do that or not - though I
> think that if there's people stupid enough paying for a simple
> frontend, why not let them?

This is perfectly fine. Note that it's not possible to do nasty DRM
stuff with a method like this. The unencrypted data gets passed
directly into MPlayer, which the user is able to modify, so they can
make it dump the unencrypted video.

Even if they modify MPlayer so it accepts encrypted data, they have to
release the code to decrypt (which they are linking into MPlayer), so
they still lose.

> Anyway, I think we should get back to the question that A'rpi asked
> in the beginning: What could be done to make mplayer G2 *THE* video
> architecture for linux (or *ix in general)? And make it that not ony
> for the users but for the companies too?

Why on earth would we want it to be used that way???? This does not
benefit us.

> Let's try to evaluate what companies might want from such an
> architecture then.

No, let's not. It's not our job to satisfy commercial software
vendors, and I want no part in doing so.

> First, there's the (commercial) codec writers and filter writers.
> The license of the mplayer core is probably not their concern, since
> they don't need to use or change it (instead mplayer will use them,
> right?).

MPlayer will use them extralegally without their permission. :)

> Of course it helps them if writing codec/filter interfaces
> for mplayer is easy and doesn't change every once in a while (since
> that means work (=money) for them). For the same reason, they might
> want to be sure that it really is THE video architecture, because
> otherwise they have to write several of those interfaces for
> different back-ends.

This is nonsense. They will never (and should never!) write MPlayer
codec modules. They should just make a decent shared lib, which
someone else wraps for MPlayer.

Or rather, what they SHOULD do is LGPL their codec and submit it to
libavcodec, but they're too lame to do that. In any case someone will
reverse engineer it and do that for them.

> If someone wants to use codecs and filters written for mplayer G2,

Then their entire application needs to be GPL. Dynamic loading GPL
modules does NOT exempt you from having to follow the conditions of
the GPL if you intend to distribute or prepare derivative works of the
GPL'd program.

Rich



From flodt8 at yahoo.de  Wed Feb 25 21:38:01 2004
From: flodt8 at yahoo.de (=?iso-8859-1?q?florian=20dietrich?=)
Date: Wed, 25 Feb 2004 21:38:01 +0100 (CET)
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040225182853.GK9096@brightrain.aerifal.cx>
Message-ID: <20040225203801.23739.qmail@web21411.mail.yahoo.com>

 --- D Richard Felker III <dalias at aerifal.cx> wrote:
> 
> > Let's try to evaluate what companies might want from such an
> > architecture then.
> 
> No, let's not. It's not our job to satisfy commercial software
> vendors, and I want no part in doing so.

Well, I don't think we should either. Still, why not try to imagine
what they might want and what they might do with it when they get it.

Maybe it'll be more clear what I was trying to say with this little
example: It doesn't hurt Linux, if commercial programs use it. On the
contrary, the more programs use it, the harder it will be not to use
it if you want a certain program, so that strengthens the project.
They might even contribute back, so there's more and better features,
so more people use their programs.
But on the other hand, if you hand Linux to a commercial company, who
knows what's going to happen? If IBM (random example) had bought
Linux  (and saved a lot of work that way) and then put all their
improvements into that ("99% compatible, you only need to
recompile!", better and faster), sure some people would buy it, and
more people would use "Linux". But would that strengthen the position
of the original Linux? I think not.
So in my opinion, building on top of mplayer is fine for everyone,
but allowing them to own it might not be such a good idea at all.

> This is nonsense. They will never (and should never!) write MPlayer
> codec modules. They should just make a decent shared lib, which
> someone else wraps for MPlayer.

Hmm, I don't think it's *such* a big difference, except it might save
some work. Of course it sucks, when you realize that you want to
change the interface... maybe the best solution is to make them have
to supply GPL'd wrapper code or offer to write that for money :-)

> > If someone wants to use codecs and filters written for mplayer
> G2,
> 
> Then their entire application needs to be GPL. Dynamic loading GPL
> modules does NOT exempt you from having to follow the conditions of
> the GPL if you intend to distribute or prepare derivative works of
> the GPL'd program.

Hmm, doesn't that depend though? Can't they use 'open interfaces' if
they are offered? Anyhow, like I said, I was just trying to think
through what might become possible in which cases. Leaving the
decisions to those who actually have the power (and would have to
live with the consequences like everyone else) :-)

Florian


	
		
Mit sch?nen Gr??en von Yahoo! Mail - http://mail.yahoo.de



From xizard at enib.fr  Wed Feb 25 23:20:14 2004
From: xizard at enib.fr (xi)
Date: Wed, 25 Feb 2004 22:20:14 +0000
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223222112.GM9096@brightrain.aerifal.cx>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>	<20040223140615.GA32683@cube.dyndns.org>	<20040223144643.GA3622@woodstock.localdomain>	<20040223154549.GZ9096@brightrain.aerifal.cx>	<20040223162239.GE4401@woodstock.localdomain>	<20040223171942.GC9096@brightrain.aerifal.cx>	<20040223202656.GB5009@woodstock.localdomain>
	<20040223222112.GM9096@brightrain.aerifal.cx>
Message-ID: <403D1F9E.4050703@enib.fr>

D Richard Felker III wrote:
> On Mon, Feb 23, 2004 at 09:26:56PM +0100, Gabucino wrote:
> 
>>>(b) taking legal action against anyone who uses MPlayer code for
>>>proprietary purposes
>>
>>Gosh, Richard, legal action doesn't "just happen" by the Fellow OSS Community!
>>Who is going to support it? You? No offense but you're a Free Software guy, who
>>can't stand the air of a courtroom, so I guess the answer is no.
> 
> 
> I expect if MPlayer asks for donations to pay for a lawyer, many many
> users would donate. I'd be happy to work on legal logistics if the
> matter were in my country, but IIRC KISS is somewhere in Europe, so
> one of the Europeans should probably take care of it.
> 
> 

I am following mplayer G2 list since a while and I am quite sad of what 
is happening :
Not only kiss has stolen mplayer code, but also kiss is going to divide 
mplayer team. Please fight, don't let them win !

Kiss must adapt to free software rules and not the contrary ; if free 
sofware don't suit them, then they have to use something else. But 
please don't give up.

I am quite sure if you ask for donations, many users will donate.
In the main linux site of my contry ( http://www.linuxfr.org ), there 
are two news about the code stolen to mplayer and several people are 
agreed to donate mplayer for a lawsuit.
As for the country, AFAIK Hungary is going to join europe soon, so it 
should be feasible.


If it wasn't clear enough I won't participate to a project which permit 
kiss and other companies to use code without contribution to free sofware.

I hope my message will give a bit of hope. Just ask for donations and I 
think you will receive a lot.

Regards,
						Xavier



From gsbarbieri at yahoo.com.br  Wed Feb 25 22:53:51 2004
From: gsbarbieri at yahoo.com.br (=?iso-8859-1?q?Gustavo=20Sverzut=20Barbieri?=)
Date: Wed, 25 Feb 2004 18:53:51 -0300 (ART)
Subject: [MPlayer-G2-dev] Legal issues: would companies really pay?
In-Reply-To: <20040225101712.GA2353@woodstock.localdomain>
Message-ID: <20040225215351.21172.qmail@web20902.mail.yahoo.com>

 --- Gabucino <gabucino at mplayerhq.hu> escreveu: 
> Gustavo Sverzut Barbieri wrote:
> > Then a second company comes along and instead of licensing from
> > mplayer, it licenses from the company who licensed from mplayer,
> for
> > 90% of the price and with bugfixes.
> As Richard said, this is nonsense.

Sorry, I'm dummy :D

 
> 
> >     And you should know (I know you know) that main reason for
> mplayer
> > success is being FREE, being OPEN [FOREVER], being GPL.
> Not true, MPlayer was already the most successful media player while
> it
> wasn't even GPL (although marillat lied it as being so;).
> People use MPlayer plainly because it's so fucking good.

Yes, you have a point. It's good.
But you need to be careful with the future... nowadays many players
work (almost, eheheh) and for many users speed is not an issue anymore
(ghz machines are very common nowadays).


> 
> > Maybe if you were BSD, many users wouldn't send you code,
> collaborating to
> > other project instead.
> BSD was just Arpi's bad wording, it'd definitely need much
> improvements to
> fit our needs. Don't think of it as "plain" BSDL.

Now I understand.


> > give it to them? So what, they will put more bad things in the
> world so
> > then you will reverse-engineer the whole thing to be able to play
> it?
> Then again, what could they add to make harm? Who cares about DRM or
> pay/view?
> Those things will fall eventually and I haven't heard any more
> arguments.

I don't think they will fall. Just if companies fall (gota communism?)
or they change their business model, which is more likely to happen,
but will take some time.

Gustavo

______________________________________________________________________

Yahoo! Mail - O melhor e-mail do Brasil! Abra sua conta agora:
http://br.yahoo.com/info/mail.html



From alex at fsn.hu  Sat Feb 28 10:47:10 2004
From: alex at fsn.hu (Alex Beregszaszi)
Date: Sat, 28 Feb 2004 10:47:10 +0100
Subject: [MPlayer-G2-dev] dual licensing try 2
In-Reply-To: <20040223121659.2c81face.attila@kinali.ch>
References: <20040222173830.0614E31818@mail.mplayerhq.hu>
	<20040223121659.2c81face.attila@kinali.ch>
Message-ID: <20040228104710.380d6797@caprice.artificis.hu>

Hi,

> Poll 1:
> So, we have 2 options:
> 1) Leave MPlayer GPL
> 2) Make MPlayer GPL/LGPL
> 
> I vote for 1.
I'm absolutely against everything non-GPL. I vote for 1.

-- 
Alex Beregszaszi 			e-mail: alex at fsn.hu
Free Software Network
ISOs: http://www.fsn.hu/?f=download	cell: +36 70 3144424



From Reimar.Doeffinger at stud.uni-karlsruhe.de  Sun Feb 29 20:38:02 2004
From: Reimar.Doeffinger at stud.uni-karlsruhe.de (=?ISO-8859-15?Q?Reimar_D=F6ffinger?=)
Date: Sun, 29 Feb 2004 20:38:02 +0100
Subject: [MPlayer-G2-dev] specifing visual for X11 window
Message-ID: <40423F9A.2040607@stud.uni-karlsruhe.de>

Hello,
I've been working on an OpenGL vo module for G2.
What I need is a way to make sure the window that is passed to the 
config function is usable for OpenGL.
The best idea I had so far was adding a XVisualInfo* part to 
vo_instance_t and if it's set the window will be created using this visual.
Would this be acceptable / do you have any other ideas (except creating 
the window in the vo module, this would give the same mess as in G1).

Greetings,
Reimar D?ffinger



From dalias at aerifal.cx  Sun Feb 29 21:49:54 2004
From: dalias at aerifal.cx (D Richard Felker III)
Date: Sun, 29 Feb 2004 15:49:54 -0500
Subject: [MPlayer-G2-dev] specifing visual for X11 window
In-Reply-To: <40423F9A.2040607@stud.uni-karlsruhe.de>
References: <40423F9A.2040607@stud.uni-karlsruhe.de>
Message-ID: <20040229204954.GJ9096@brightrain.aerifal.cx>

On Sun, Feb 29, 2004 at 08:38:02PM +0100, Reimar D?ffinger wrote:
> Hello,
> I've been working on an OpenGL vo module for G2.
> What I need is a way to make sure the window that is passed to the 
> config function is usable for OpenGL.

Is there any case where the normal native visual type for the display
wouldn't be the best? IMO the X code should always use this type of
visual anyway. And sometimes, the window will be created well before
the vo is known (think of playing in an existing window) so I think
the vo driver just has to fail if it can't use the visual given to
it...

> The best idea I had so far was adding a XVisualInfo* part to 
> vo_instance_t and if it's set the window will be created using this visual.
> Would this be acceptable / do you have any other ideas (except creating 
> the window in the vo module, this would give the same mess as in G1).

No, X-specific stuff is definitely not acceptable in the generic vo
api... Some of us will even be building --without-x! Of course you can
use #ifdefs but that's a mess, especially if we want vo modules to be
dynamic loaded plugins (in which case the structs need to be
binary-compatible).

Rich



From Reimar.Doeffinger at stud.uni-karlsruhe.de  Sun Feb 29 23:06:06 2004
From: Reimar.Doeffinger at stud.uni-karlsruhe.de (=?ISO-8859-1?Q?Reimar_D=F6ffinger?=)
Date: Sun, 29 Feb 2004 23:06:06 +0100
Subject: [MPlayer-G2-dev] specifing visual for X11 window
In-Reply-To: <20040229204954.GJ9096@brightrain.aerifal.cx>
References: <40423F9A.2040607@stud.uni-karlsruhe.de>
	<20040229204954.GJ9096@brightrain.aerifal.cx>
Message-ID: <4042624E.5070904@stud.uni-karlsruhe.de>

Hello,

>>I've been working on an OpenGL vo module for G2.
>>What I need is a way to make sure the window that is passed to the 
>>config function is usable for OpenGL.
> 
> Is there any case where the normal native visual type for the display
> wouldn't be the best? IMO the X code should always use this type of
> visual anyway. And sometimes, the window will be created well before
> the vo is known (think of playing in an existing window) so I think
> the vo driver just has to fail if it can't use the visual given to
> it...

I don't really know. I just tried it the way the G1 vo's do it, but the 
visual returned by glXMatchVisual didn't work with the one the window had...

>>The best idea I had so far was adding a XVisualInfo* part to 
>>vo_instance_t and if it's set the window will be created using this visual.
>>Would this be acceptable / do you have any other ideas (except creating 
>>the window in the vo module, this would give the same mess as in G1).
> 
> No, X-specific stuff is definitely not acceptable in the generic vo
> api... Some of us will even be building --without-x! Of course you can
> use #ifdefs but that's a mess, especially if we want vo modules to be
> dynamic loaded plugins (in which case the structs need to be
> binary-compatible).

I though/feared so. But I found a way around the problem. Do you know a 
way to find out which visual a window uses?
I currently use
     XMatchVisualInfo(mDisplay, mScreen, depth, TrueColor, &vinfo);
(copyed from x11_helper.c, create_window function), but that sure isn't 
really good...
In case someone's interested I attached this vo (but please consider it 
pre-alpha ;-) )

Greetings,
Reimar D?ffinger
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vo_gl.c
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-g2-dev/attachments/20040229/bddbf7ac/attachment.asc>

From syncmail at mplayerhq.hu  Wed Feb 18 13:40:38 2004
From: syncmail at mplayerhq.hu (Alex Beregszaszi)
Date: Wed, 18 Feb 2004 12:40:38 -0000
Subject: [MPlayer-G2-dev] CVS: g2 test-play.c,1.1.1.1,1.2
Message-ID: <20040218124037.5E25B315A1@mail.mplayerhq.hu>

CVS change done by Alex Beregszaszi

Update of /cvsroot/mplayer/g2
In directory mail:/var2/tmp/cvs-serv29761

Modified Files:
	test-play.c 
Log Message:
use g2codecs.conf to avoid conflict

Index: test-play.c
===================================================================
RCS file: /cvsroot/mplayer/g2/test-play.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- test-play.c	31 Jan 2004 20:16:18 -0000	1.1.1.1
+++ test-play.c	18 Feb 2004 12:40:34 -0000	1.2
@@ -193,8 +193,8 @@
   mp_msg_set_level(verbose+MSGL_STATUS);
 
 //INIT codecs-config
-  if(!parse_codec_cfg(get_path("codecs.conf"))){
-    if(!parse_codec_cfg(MPLAYER_CONFDIR"/codecs.conf")){
+  if(!parse_codec_cfg(get_path("g2codecs.conf"))){
+    if(!parse_codec_cfg(MPLAYER_CONFDIR"/g2codecs.conf")){
       mp_msg(MSGT_CPLAYER,MSGL_HINT,MSGTR_CopyCodecsConf);
       exit(0);
     }