From xvid-devel@xvid.org Sat Feb 1 07:08:25 2003 From: xvid-devel@xvid.org (frydmans) Date: Sat, 1 Feb 2003 09:08:25 +0200 Subject: [XviD-devel] Codec Message-ID: <000901c2c9c0$b762bb40$643fe650@0.0.0> This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C2C9D1.7A86D600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Shalom I have on Film"The pianist" and i don't find the Codec xvid...Please = give me on solution Thanks ------=_NextPart_000_0006_01C2C9D1.7A86D600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Shalom
 I have on Film"The pianist" =  and i don't=20 find the Codec xvid...Please give me on solution
Thanks
------=_NextPart_000_0006_01C2C9D1.7A86D600-- From xvid-devel@xvid.org Sat Feb 1 10:21:54 2003 From: xvid-devel@xvid.org (Marco "elcabesa" Belli) Date: Sat, 1 Feb 2003 11:21:54 +0100 Subject: [XviD-devel] XVID_REDUCED question/bug In-Reply-To: <20030201083912.7AD0.SUXEN_DROL@hotmail.com> References: <200301311935.04347.elcabesa@inwind.it> <20030201083912.7AD0.SUXEN_DROL@hotmail.com> Message-ID: <200302011121.54629.elcabesa@inwind.it> Alle Friday 31 January 2003 22:54, suxen_drol ha scritto: > btw. you should not combine reduced with ASP profile features: ie. > * bvops > * quarterpel > * gmc > * interlacing thak you=) From xvid-devel@xvid.org Sat Feb 1 13:02:38 2003 From: xvid-devel@xvid.org (Marco "elcabesa" Belli) Date: Sat, 1 Feb 2003 14:02:38 +0100 Subject: [XviD-devel] SKAL new gmc code BUG Message-ID: <200302011402.38296.elcabesa@inwind.it> i simply have not time for investigate until 4/2/2003, so don't wait for a backtrace or something else, but new code make mencoder crash when enocding with gmc and lots of other oprion enabled, and make mplayer stop worknig adn NOT CLOSING neither using ctrl-c , only a kill on process make it stop if i not enable gmc or view avi without your new GMC code all is perfectly working is you code really new or is only a gruel code enanchement? bye From xvid-devel@xvid.org Sat Feb 1 13:30:27 2003 From: xvid-devel@xvid.org (Christoph Lampert) Date: Sat, 1 Feb 2003 14:30:27 +0100 (CET) Subject: [XviD-devel] SKAL new gmc code BUG In-Reply-To: <200302011402.38296.elcabesa@inwind.it> Message-ID: On Sat, 1 Feb 2003, Marco "elcabesa" Belli wrote: > i simply have not time for investigate until 4/2/2003, so don't wait for a > backtrace or something else, but new code make mencoder crash when enocding > with gmc and lots of other oprion enabled, and make mplayer stop worknig adn > NOT CLOSING neither using ctrl-c , only a kill on process make it stop > > if i not enable gmc or view avi without your new GMC code all is perfectly > working > > is you code really new or is only a gruel code enanchement? Both. It's a better version of my "ISO" implementation, and it has limited support for 3 warppoints (which mine didn't). In particular, there are a few new entries in GMC_DATA struct. So if e.g encoder.c wasn't recompiled, everything will crash. gruel From xvid-devel@xvid.org Sun Feb 2 09:56:51 2003 From: xvid-devel@xvid.org (Dirk Knop) Date: Sun, 02 Feb 2003 10:56:51 +0100 Subject: [XviD-devel] _real_ fix of 2pass.c Message-ID: <3E3CEB63.6090205@gwdg.de> This is a multi-part message in MIME format. --------------040006030009030103040101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, sorry that I didn't do this earlier, but I was very busy with work :( But here we go, as Foxer suggested, the fix for vfw/2pass encoding is very easy indeed - in line 1517 (roundabout, might be 1518 as well) of vfw/src/2pass.c there is an assignment of hlength to nnstats.dd_v . This breaks the whole 2pass thingy as dd_v is used to store the frame type. Simply setting this value to 0 restores the usual 2pass behaviour without any ugly hacks which cause i.e. "delayed" bitstreams (pad frames weren't passed to vdub and were inserted as real frames into the bitstream with my hack if i'm not mistaken). If someone already sent this "patch"ed file around then I'm sorry, I deleted most of the mailing list traffic in the last week due to the lack of time to read them all (and remember them ;) ). Best regards Koepi --------------040006030009030103040101 Content-Type: application/octet-stream; name="2pass.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="2pass.zip" UEsDBBQABAAIAAJXQi5p/9UpkiAAALXFAAAHAAAAMnBhc3MuY+09bXPbNtKfpZn7D4ifuUSy JNtS0vbOin2j2EriqWO7ttO0TyejoSTI4lgieSRlx5ekv/128UaABCnKL7n2zp7ElghgsbtY 7AuwADfX7+2nSvBf5ZefD/ZJ56R3dkb2jvf7+Gjkj+lIFJ9P3YgEoX8ROnMCHychpSTyJ/G1 E9IuufEXZOR4JKRjN4pDd7iIKXFj4njjTT8kc3/sTm4QDjxbeGMaknhKSUzDeUT8Cfvy5ug9 eUM9GjozcrIYztwROXRH1IsocaBrfBJN6ZgMGRxs8RpxOBM4kNc+AHZi1/e6hLpQHpIrGkbw nXRkHwJgk/ghAqk5MWIeEj/AdnVA94bMnDhpupFDfkLlmLgegz31A6BoCiCBxmt3NiNDShYR nSxmTQQBlcmHg/O3x+/PSe/oV/Khd3raOzr/tQuV46kPpfSKclDuPJi5ABnoCh0vvgH0EcK7 /uneW2jSe3VweHD+KxBBXh+cH/VhyF4fn5IeOemdnh/svT/snZKT96cnx2f9DULOKKJFEUAB iydslICNYxo77iyShP8KAxsBdrMxmTpXFAZ4RN0rwM0hIz+4WT54CMSZ+d4FIxMqJ4zsEndC PD9ukuvQBXmJfZIZVmyejGyTHHijjSb5/ofvyDsnikjvCgZzz5kPQ3d8AR/f9chWp/38703y /qwnaLivn81qdXNZnfI/gr9vQZD88GZbfG3/sLH1YqOztdWpjKaOdwGMbkcxCZDWfy5AFpBJ zuzauYlQvDqk1sGywSIABtFavY5AthIgzngMIObOJzJ04xCqwKh5ILqO6wHbfZDyycy/xodx 6M8iUpv4n2jIoDxvb2w951Bcz41hYMWc6N47W//P9UazxZiSl9euN/avo43prvZw7sRTfJI8 WmNUb0zXqtUqUEKYphpwViCyNVRhe+v8eb36uVo5/3DMdNt6fO0zbu6Qp6y0tSuedKuV/Q/H p/tKa+yQVmdLPQ2pM0ZB9WParVaBJXFlAjJMEdJWkwz1L4H+ZYQ6MY4G+jPX+AZzau56w8j9 F9UfBOkHrnwASA2Azvj7F6LfQezDAA3op1hHoOipjrX+xLV8SSC4g6HvR7FeJ4qdUJRSb6w9 G4wWISoKWaR91/Af08gN2dOaeFQXwwIyOXEvNkSFAaN9nbS3Oi+Q/2MftAyqDECkjTA3EKr+ tJN+Oh7exDRqir8dhLK5DphFC1B7aM9qdVTtI2c2A4QiZ0JnNwTEs2LKycYU0IQpRMES7JCj 94eH0IUoa+16XtQeoNq+sRd2UoUgSRNSM0nGDoDiOa1XKyC6hf3PAVt/VGtv4U8d4ekAbU14 zwCawa7s91+9f9M/Pa2tjVDLe8/AaCNI1BVzCibhhtuGK8KArEEf0Cqk8SL0yMEetBzA/+NT fPy1Cv+qlQg0/Wiapgp8AEHQyAGDs3/4ZvAOZumA+RyDNtkGAIpTIEFxhOO6B0jH9LU7oylw vEaTvOkf9U8P9gYfTg/O+00wiIf9wdnb3ml/cNrv7TdR+Pbg03l/0Dv80Pv1TFTpnZ+fHrx6 D4+Pjk/f9Q6hIqMMmZfBYoccHP3cOzzYH4D53YfW8OV9v06yPGQqiKAKIjQMgW8totg6YqQQ DnQZHxkiH9AsMtpTKDXJU6GlYLLBxPAnNaal6lDAVBSSg3hvkS9fuNIiT3bMqgn6ezM/om/B Vct2xLHMDouNH93yrFD2viQzhsC6S/hil53O4ODoHOXHXtj/5fyuwsVFySZbxyf9I+jh4Oz8 4OjNf062wPf0yjIT0TgFa7aqYHELqMkVPvhDiRVDaBL681VYIc39E2bv698ce5id4BxzkZO+ xxLEdWE2DE7t6OjsvHd+tl4XdkEMjXhcFwaUi6PdLN0aBIcwED4Kq5NTZUa9CwgFuCNgqxD4 ES+F4s1NPqwYGXAeTVBuI7DVHvrC2AC/wUhBRT8UsSWIAIsmbjiIkR+CDxWDQQ9pENKIoic9 RbPP3DAWtuF36qEiCHn8JmKdjWrFYqTRnOFMsKkbJUTZGd9BObPOeKzPGhWIXofLBZOAShrw Mn3WuV99lkdfkUZbSqCYW6tMrpK6IdGQHTG7cqYXUwxFSrJzT0ryQZixVHYsYnNX1qbUbmn+ ZjVv5XPlz82TAmWezw78fT0FQSO1tqYGkEVPCgy1YQKUJEo9rWSRefsWSVQK/csX1l0lr69O qq/O7fti1AnyRFwNnAN2v6HxoRPFfWRjTSgXzgFWvkMYv+Ro9I9fYydG0dn7vb3+2RnvQXah HMdKRchdpUJnETUrLZe2MjK0mkyuJnNLpM4FqzUPZlRFF5sCJlgwsIj/WFMo5sigZA6XRTSY ABJYF7GlQxUQjmVEiOt2YByjyAlvlKwKW7q7Q3LcAmP0lzkw0DtzPyz1moKYrGdSy+kZir4j m+QFaZB2XTJjmf9jw6DzYBiY7lMJKN3UiLHlWLa8ygbiWSTcJeYmsVFEMBGrDsM4gtq1pxbu /sbH8eNSDSOosMLqFMLq5MHi1RsNTTGe0Rh10omPiyJhVg2mDPCW8Fle9d8cHHGohRA6JSDg 3ECtgVy2hZ5VIdT/OR3+59Wrq+nMlbTgo/r7oykfVvs+dc9D6AsUhbuMDsmOC0ezVNBdZHTK QzbHk1fKqaOC8aRWsjfRxS0vAuPLhtaN0NtXki839CgZLSC6ZtswIYuWWcyuQvEkRhchOcHt WrFrKmvx+Btg0jDZZOSgDk5evYJ/JPbFd/b1BBGFeV9zd7a6xH2ZSxoUNhoqIhe8IzGdBwOo 2lSfOkyIcDfpskm8xXwwTDhiBrqavLofN8bjwRV5SgTgwavXp713ejSvgcJ1ESG4iPnljtto d8llEe6XHHelN/IQuSxCxMRCTBddY1cud/Jx0Ke622p1U7NYMdI6od2PeXN39SUVW7eZ4KSw X533W8h5fZwzvOad2RWV+zGP4EY7l+Tb0WzFo5OHR6cUHlIGxLAup1SN8r0PZhFdySBbu0VV /bWKW3TcBnmx6y1oopfQPXCdmfsvljywcYeFvBzXzjJpcO3S7gPw6ZTrBWjtxcpoxfCzioYq Rxbt4HPFwjoeOeK1Imh7dZRCVgyjF126AVl4iXXhs3LDyut2Wtmd/XhwwvSdWs0orH7S21+h 9n7/sPerrk2lpAnsmZPPUxBczD8YiC3/2lND0prSWhcr9A2e55F0/2Pf6Fy0q8id+oYpbJ0N tr3dVbX0HXt7XSISJdSUuKQ3PDGAtQWfr70lBTLhlKrEnGOYX9FvMq3ho+FO4E+jIcvEk9yg YelQm3ZNNqsYqQwpOtsmT4y6LLmhmIeVtOGU2OsWVCESrIBIsCIiQQ4iMnwxcWo0zNwTTVxX kThBmfQCAR90Auk4wg3cIZV7K3S8sZGI9JNUF5fD2SUEDubDOTysy5E0c1xyuZYQSVYSlc93 x21YHrf76jJY3iX702hos4uhseo8NdrM/SuX8oQdjE5qPIOmXstOnGyqUcPMEqqTTYZhmbbS RUOOiTnH2aEQc65o6FxQ4bMhbgK1DPRNlZK1SWx0JT0FhT0F6Z6CbE/Bkp50ocjQVtBlDtld giHZsMWrBc7oEtNiXZnhM3E/WeUwWTxhKx/bhBz5JGgJ3MEpHsrPLAiT26QiUJNpiBuEnIo8 QkwZxKxfz4/JZOGNULgwtzOg4ezmiVp1yVt0AdFlYwC0QAvwyufYJ/aBigXXcqgXYVfosGOq 4ibLHIYZ4XoX2FBgK3eKLb7dIqIDZyZS0TTfLWGsLBxgGqSF42IsWrkl60owzK4NyAPMF+Z2 dGOrW4ACVJxMSuKht8uFOXUvpgXwGnegC0GXI0zUTFFm4pjL4a6aNnmIsFFexH5G0Zs+gZn/ uEvKKCQOS9r2PARAUQ9COhuAHcWsyJrrxfUaYwmQpT7wv5sCVsWuVVNIgPYkq2jfer1O1lUP SwYQeTYApSHHT60PF3LbIPYlERu3K7CnI33JjA9YFoJyR7/mSdzcHavRaAPXG0ul2ehCMgQ+ dArkGusOxvQKUWJDXIDJcjFWemIXezeEmWdU5raMbwJqiirLhOtso504cz1K9pgpr7GZ5lxc gGqP3CvqwR85ekXkre8gG1AUOS/lgEeuV9vvv+mc9vaN1eeMKvk7k/wc3cU0Q12tTSwZzlxG J9g+CHoSO33ng3G5zbh8CFx2QlKbg8O9mN+dx5KGPKSLsb13Vt4KjVyWbTGW7fmRJppof+/M NSWZNU7byI/uTwIeQEIfBE1Du7LfhSkmCtjjGtad1rC0PUDM/bLzSIsi7RHh3/6GRudv3Wy7 4JbtZERdszVcJ51OHZpjQqfWHmnRY95dkqEgMzs10rSmGYCBBWCQBzAwAAZWgK4FoJsH0DUA ugnAZCvzf2ghkjx9yuGklydyF4QMqeYHaVKrE3JNsSAWBir5sZ3GjjiMoycmFHLAXPwTCKzn xzeb2RIRQ2s9LosZzcVJ0eluXp8SOdnGaJQb/ygnWhCF+WCSPN0iZA1OoalRJkv3shPUVnAs jWbCvXwYnBPzmHHhJB9zg8V6oZFUcahmyyumf1JRXt3DE1eCmiVkLCFi61sQYXVhSpBWdqA0 IuWyu/pQtA6vTbuX1mkHLlP+rHucN8VBWuXPN20y0VEODXeYNY3SNDzErLGFKvmTpnAHbmUj l3BKrWsJGI38gKYl2KqtWaWWgDhhuBbMAkPf44uFyYKVQZJVD3wzzDCCzUHs6638G0mCpMDm 5wxz/Rx99VQf1A55me/Na9zK1OmWlpt0F0GJLgKjC/5XnONWbmLH8NVTe174WwFMRmcQjZwZ 20zhPuemOB2ebBk8Web/cQIxM8yJbuZzGofuaCDZrHF5NHVCEv0GEvBRuJd59dUicZ78rZNc UoRsXUdBCCAmtahJ1kABjWfiNBuLXtmeSdI7YUCIJq3b5K/uWjOXINEJ2zLqnNQiPd/mTsnQ uvT/+Vcb7NX/i9JaVgkmd3bwpP3+AeJ93js9N8YtYtdEFKZDZNMV+CDib7Xff0uE+kf7Bjp4 VcXdkTGb5wbNesc5WTui80xKgPQ6SufnqOYlt/0FsW4OmQbqy6TVarxWyMtJp9nkWpqgPMzA CvNrIuG3GMPHTJj/+kwYlk5qJCA4V66wr5iKMKUOZqdX5PU1LdkcV1RfcBj2a1CkWhHXoQje sMBDKitmUk97532yreyIaCYMOa4CM+HfJPr9OOwMCOgCouoP8M4nzsjEoRBFUXJLj85XWayu 7CE7fCBKbViz9B/5SSh9vP2nnqCqfGoFUKBs5RMjQFikyLxXSN0YVOMdbZIiGoXJNm4iSiCg QdgsYEI9MelsOTM9EC3Jcb5jr19a1CKiP1nDHI5UrpVgieBQKU7LFKtKTYmjeQVTS7t/SRIi /CS78P30vsduVLkDyQ9HK0mTyenTRshx+X0RwqXVHWE+hcGPHi1mTAeA3obAzSZe7KtFaOBL GR6eHfy/PoE5pop0KbH8ryQoiZOWzNYU6yQ0vHWjnjuVOAgeZ0m0UO4VUD4J8HcJhDT9kEaH wylGBptrqDxO7Xuf2hVpE5NUqFulU5JvkkpJHtMoH9MoH9Mo/4hplFZ9tot5LmLqybisVG7d svxI6+Svl2CkJZ2xomgohdpjNuNjNuM9Z2EtGc4VcsXuFT2J3WM2Y2k0cln2mM34kGga2vV/ LZvRXv0x5TBL2mPKYdltn/vfJPpPpxzKbZLHlEPx12j0mHK4HOeHS516TDl8ACIeInnqMeXw jqNyv/PmMeWwJA2PKYcPntj3mHJo4PuYcviYcviNUw6rpbzmz5K9y1a4B0PfW0SDoeuIZZm8 Bkk9YF+ZtdauTSawPQdF5KZiGxUuE4oyK9saGptqmVxlY4gVALVNOVAPZHYLZ2WRpNasaHGL sTp2GN5LMJrwIxIY7QZ05ILlcr2Jz4VmJjbGtwlhYDiv8I0OLCoE4cIrIkGMpv5sDMKXzBDx aifhAtF50DScKWN6yBnlNolHrxnkJm6ZjagXJ6XQAw9F2V2NWbl3ri4I49pYhLSA3TYT7MLp VbeIdxZ4Qj2AJIyQLOC0UOWCFtdjtrvERX80jZ/h+q536ngXpbgqMxtvu0JPrmCpbcZ9eTCa DGVpF6hcOGoz1Kv41KpRyqO+b4Q183+/LrU9FDXd0ZRH/YC0lSCmdCRqoWHrm9DwEC61PRC9 hSe9PAS1sOZxthQFoH+2yWKJP+97rpSNPx9krljDz8xU4X9LZTLY1nczmU6VivQflFOteCX2 7zRGFvjVOvN4WdaqM7xVf4Crxbqq4ic7yn/JhMuaYyPrK5YJL0iRU3OLRySTqpGqogAb3g3r Ex0b5csRJ4aggGBkID2xNd07c5WDloBMBQiVlE4UW4Ri3BWC6lW36beO/fi6RNEgcEK8SdhS ZeCOPylfUU4u7NvI1zr+sVuFh+D9Hh2f97d5LCFeWHtB4wGjt1aXr1oeUvkaUu4fzzIvK9Ou UOc37Yu3omVeh5tA19+J2yT4vu9B/2hvwMJ/cZM8e1UuwoP4TbjWQ9Z4wF6y8NvzDvrRZoVg WQVN6lmlpALiOnOieDAU482+BEI2tZf2SkEjlrf2AlO1V/QCcITKpmO7SVQMz1x7MZriqwyX Aj+ST5wgoOMBBIhz59NAufdi1LHGj68xp8XxRrQJn1noJ5NYtcCTtfQWc7kri3OQRR5MSOSt 9QSvrX/egT+NhqviV4PfLp5LkClhQW6JEkdeY+QvvFjU6MqZkB6FpLk2ArKFNg7i0VdBoepq pf11pAxkf+J+YgL9sxvGYCH2F0NQvS822s9FgimZ4stCeFpiNo7HMZGJqLtkS+wkpln+Mh8R ULe5EBX/M9OWaxPhD7EqmQxQmEr9Y9L/Za/f3z8j7bNzgmL75IlM3ix8W+5DpQ9YGOgX33T+ UHcn2evyLAY+UYkpPupcT7V4d3zp2qbaGhcyqCqrbvmHbqasYy+T2d+WOgyr1i7M89CBguf4 LCtMMOjlTmzJbfpvj/mLO2JupAx8Y9y/y8W9Uq1ohj7rF7BMFCZv+Ch0x5QrC+KKBPHR1HdH FFNAqOegXQPzm6T9Z7nyz4KjhDrWO0hHOc6+sgPoCADp51vSLBlPd9piWFJ+D+oizSQSseC5 JK0jpX7ryhImkKQBLK+PDo6SNy/cyyk6a5k4oINOYwrj4qPMSgq5ryyEutQJleRYJEsZTA4n 3wq+foKFQ2d/UlOiJV45U+rAl2KGldvcvXAxzCiqEBjsEuhIZ8LA7h+8SqW4u+0StYI0gwtQ KAEnj4mCxUUarVinldNqVjdERDUF1y+AHa/mboPoU0YX8GT8k4n0LWUAUGk/CkJpQcBnUhgS +lRTw1dLjkd/VfYbBee1/4mG2wSindlNdp+O+Is4YvaPM4SrbxHM8YWOprbjwgNfpbNWUPHk H4JSsm3Hu1rJMV98PNXmRE3TlB3w8sWHMtcm1OUJO4VAKnUw7fyrTkUn+UmHatuypE2/c24h 21sL5cvS9RHlEZ8zCn2IoQPnZuiMLgdjOnOkM121TfmhG+Pp64FsMKfx1B+rVGPGjpSxykSZ 6eOfaZgMibqN0csgr8sFytT4ZVhWDgEEgiyYOcNISFIdwswJfk33Xdc0pYmmZa1DW43K0NCS YqRk3UQ2f4v7SWZWpLR3uU06oRdX2qK7xSJxqR267GbGChsOsom53XDfqOaexrnjOrZ1a85Y qTf3Gh6OrhKElN2Wy+K/9Q3wf4htBuuWXHbV2XrfSdnNOAtLHueFbRPuTzUtshtw9zsrSu6+ PcissG2+WSbFKh6QwYPb5R5WM5zUQWpBNHtabi9O3qsg/EvpcCaABf0aTG7fG0bvrZx2hiv/ +RZMK3AcSzIsTRqHWECWEp1sfT1MZWta6UhSgTMSbNOL89lqqC3Fqr/d/VHeUSnn53NWVPKl Q0ylu+TzLiMvm2ZsEYw/DrqZ3OPkspHSknsvs33ZtLzdrEyHIyvRdecJWTQfV5uOX0VkOHIC GbLGPpm4obiIhG3YNAmMJg0jfO/1kIbEn/DMy522GR8KALsibldzzoaSqNvSVzPEM32Fw8Zn S8Cv6UUBxMz31o5fCpcng1NrJ9tCoifSvC3rKOkzmxVtWq6yYr+MAD0n3opFkhCfYy+sYINl YAMDrNiTVBXsS1MdsVMCvbKLEOXCCsFLEX2fjGY+MAfEDNchPPopblb5O+HHixFUip9FDA4m NvjxnHox3zPIjDsoe/Iku5OQbMIna3gC4w3LHX+pGjxl4yNpMcG9XWsQm/ZHFbNr+LxMLzlN YpHqouaKgb32pZXenHa9AeCDt1jR8Eqmlqf625XHvrkYaCkJyQrVOr8TsJVBjY0HUlkn2hWi vIcEzkuVcmRCb5uuw46eD4GGRs1/7Tk6lBr28m6rPJ4t5YlYtzHFX6KrEGunxTtZAuXWUu2E uR4IqbgXDsRXaGahIiOfRHPMygllJs7Y957F5ILGDCRK/nwxmm7O3DjGzBm+0mTsO4r0KmGV VcG6ZTUxk1Kl4x1S98JDdBUI9tLz6eKCKo2tVrNkHVzPYg9UH6qkntkSzNTppnk3dy6BNYtQ 49/YpxGyJFx4xLl2bjgSqng3b2VWdMbSblTOlQu+BnxB/SDWajmSmm1UkF9KaVeLyrfthG8y aCNzGyBdc7s8QXMl3Mb0InTGXBo3ScvGgbuBS9BMw00NumH7E+uhJ0kJ1PJTqNgstJggvVoi Y4lwwTzEm9H4TGWXNTKzgnZ5vpgnhzCqFhetYA/+c7WUN1HoEHxdeeO+sNdhca9Ds9clwIJi YIHGbvWc1TQ2scyijAMAUnJDnkUg/zP6jLuML1u7mIrIBl3q0mjqBtX05lstZ6x+zwyWVI9t tFNJ/5qnyNty1Y9cSXXVTo2VUbxLnuc0e55uZ406saG2p+Yml2cyOOzwEgRNI5ftxAxviDMa Lebs9lHvAuqKAuajigEtJ0vc5hv5gjoBH3n0IE+JrcLtxK5rLK+DNdbhJ/5IAQq7Oyq5mnso BXVbrC53QsRBS9VVYr+NYCHIh/atiC9AIUN8Qd1yxAvleE2fgWIE74Nys682ahEhZglWzNoR YmxLnMpxzTVdlpqDWY/NZUVKYlOzLK8+o1sme68diCysZE6FjhvR8ZoK1i0TOwUaLM1KqKj6 y1BhwbOGS0ZDL8UrWBGvQOFlJd02Cit1oerzLqp8c3kxjOg/F+jlaByI8O5S4nuzG0xbb7RI R2BU07OIv3zRM71ZZJfrKuj7yyuoQzHJ0BPHoHSYHqUrJ3SZOZLVIMrAY8jMIdKv8YehhKmV 3L6UGj09X7pBOqxrueiQ4mqqKp/eiSS9ykgSGIor4C87XOrPSQi2AYwERhZRTGkwu5HXwX61 Y/fS6LJVHrvWLbCbQDBUhF7OOoWNnUF5diZV0wifLEP4tuwMyrMzqboydmXY+TVRyUumj1Q9 pR1iTpV5GCBjh8yDAeliY9W/7Kwt7lGKT2HHiiWGEmOlbDMUecIy3HgOEvyqGw7fBfUg1p6R LzuZ8X+BASU7K/PupP9GpEnyB2873z9nD7pZSE9zIP1utgRQv5vAb0XN4Kj/4RYU6WhksFiN Ip05v2e4k3ccKnNYaRFAfErLnFTSHjOJWufHoPQDTOICeH7/gDqmIySQoFQCavzk0HXoxxgN MXyS9cYmwe2AsXsFRXiVwDpJRkE9YuiIR8bAsYLUKaAEF5JkXetDq5is+J4aK+T52tsN+LrG lipqOQ3UiDBbm1Np7/3Z+fG7wU/veuenB7/U6ywPc21vEcUAnKwhjDWkyp6ELZKvgS62j53K 8Wsz9JLTHMm05adxunzNDK9+Z+V/wdNx528PzvgqGxkuLi5ASYJWAzePLALCRIRQD5AANfkE z31VEt2ywwWgtTvVwONrWgAGg181a291/6I9WcAT+flGDI0ovGTV5eeF9tmsONegzNNQ5lrL uWqZkCAVm6BBqT+jsMOSP4GsxQU4W/Iw1Wwxd8nciS7RdrieumGe8BmHTz16zSVXQoQ2A88H //m3rY8SreRZ+6OImSuJbO+ssTXXtW7VMJPJUj2zHhq6oHnSRoZZkBTI0FnLWA4TdkeHzQZP A/3KDpj7fssgPy+CrI4OZYDjeSRw9pcAf1EEXB7uycAOnPF4OezvimAnx28y0FmuowaetWeX sirJw29RIrZG2dwoWxhlC15WNVRcIz3lsZw5RO2z85pRJG45SRpv4utDmpp2bRpWv6mp4qaB fNNAF12MqpDZD6Eb09d4Tja1qcMa4Jk7JCxzhA2eM/vQBC3OdDkGM+wJJsGnKitHKjkkyKFv E9U9X+vJPxtYEcOjTmzY1CtLoUYVay/s/8KPc9zHiR7OvSdprtn8uuTAnUrUKNFKnXVbpZF2 zMyIFlMbhipxwoTIpYeflNXl6qN8UxyLYG1o5LrQRmzAdtz5S4YomfrXbGcI40vc/Ard4QIe B3InCdS2auWHaLGgIlsBB7OHOt7YZX0WqeX5Km+WQlNtNzQy26PJkfautalxGj5VltoLblnm NvwIj4kkRwFk+7Kbq2JrtnK33Vm5NciDIIFU9voE4Ljney0Q/oiOFrF7RRWfIzsW1lsB8tm4 mfQOaMlEOR5vWlI7UW7K47LKSBcO9dbSSukrEBIirGMgpxGvk06MBSr1eYBvePInbFtHpRLc WsSLxVS9i2ApoUsnSKuA5yaQvNWQ+yJKiHraMxSKULyMsnxnadEpIThLGZFU3eRvGIPxlshu SPawhcZVfc4SDmUJayIWJLIg81zJEjA1Y5gBi06k9CLTC0l86SjVgdqba9tKM3k6bR2wEH3x dFUyEuucoUJzV1cj4odSRPxgJeKH2xCheQtZMnS/eDU67mEwqnKN8GjfWGAxPVzdD7Yi0yxW GU1TY2Rqy/naJCn3STmhYzpxFrN4O3mWu65z5btjY11ngnvmU2Ndh63U4HqL262mrzHNGVN+ d4Ra6KK0oBLyNrcUmH/0/vCQUZDTWadMZ53CzjqWzrK1xIUY2pJQbh0lOYW11OtKbKuIRVeA YFhTsjY/oI+cQY91EQeLmFlvJrFsbVuZd9xcUS4sW7yhGyjzx6zVPh0uLs6gpndRW/spv3UH LAbSuc2jJu1my5c7z5N7K9nMtgyo7u27H7WowLif6qftv7r8Kk83Mz9SENiEttCQSoHnk4MN PUyLfwNQSwECFAAUAAQACAACV0Iuaf/VKZIgAAC1xQAABwAAAAAAAAABACAAAAAAAAAAMnBh c3MuY1BLBQYAAAAAAQABADUAAAC3IAAAAAA= --------------040006030009030103040101-- From xvid-devel@xvid.org Sun Feb 2 10:05:40 2003 From: xvid-devel@xvid.org (suxen_drol) Date: Sun, 02 Feb 2003 21:05:40 +1100 Subject: [XviD-devel] _real_ fix of 2pass.c In-Reply-To: <3E3CEB63.6090205@gwdg.de> References: <3E3CEB63.6090205@gwdg.de> Message-ID: <20030202210528.48E7.SUXEN_DROL@hotmail.com> On Sun, 02 Feb 2003 10:56:51 +0100 Dirk Knop wrote: > Hi, > > sorry that I didn't do this earlier, but I was very busy with work :( > > But here we go, as Foxer suggested, the fix for vfw/2pass encoding is > very easy indeed - in line 1517 (roundabout, might be 1518 as well) of > vfw/src/2pass.c there is an assignment of hlength to nnstats.dd_v . This > breaks the whole 2pass thingy as dd_v is used to store the frame type. > > Simply setting this value to 0 restores the usual 2pass behaviour > without any ugly hacks which cause i.e. "delayed" bitstreams (pad frames > weren't passed to vdub and were inserted as real frames into the > bitstream with my hack if i'm not mistaken). > > If someone already sent this "patch"ed file around then I'm sorry, I > deleted most of the mailing list traffic in the last week due to the > lack of time to read them all (and remember them ;) ). commited. -- pete; life is like a box of ammo From xvid-devel@xvid.org Sun Feb 2 13:31:03 2003 From: xvid-devel@xvid.org (Christoph Lampert) Date: Sun, 2 Feb 2003 14:31:03 +0100 (CET) Subject: [XviD-devel] Results of VQEG sequences Message-ID: Hi, I finally did the first run of VQEG sequences. For several reasons, I had to switch from full 720x576 / 720x486 to CIF format 352x288 / 352x240 You can find some results at http://andrei.myip.org:8000/users/chl/basic.html (nothing special) http://andrei.myip.org:8000/users/chl/chroma.html (CHROMA_ME) http://andrei.myip.org:8000/users/chl/gmc.html (GMC enabled) the rest should come later today or tomorrow, in total it'll be any combination of CHROMA, GMC, EPZS, PMV_EXTENDED and USE_SQUARES (32 tables, 8 HTML pages) for the 20 VQEG sequences. My first impression is, that "extra" features like EXTENDED search and SQUARES often don't help anything at all, or only in statistical margins. INTER4V mode as well. Heuristics for them has to be improved. Currently, switching them on in default high quality modes often is a waste of time and we should rather improve other things, like detecting the cases where normal ME fails, instead of always spending more time in search. QPel performs very well in scenes with much but very slow motion (src2,src18 = slow zoom, src10 = slow translation), maybe this could be a hint when to enable it. GMC sometimes helps a lot in fullpel mode, but this effect vanishes with halfpel, so I guess it's the GME that isn't good enough (as expected). I'll redo these tests when GME is better. Anyway, I really really need some volunteer to go through all the data and search for "patterns". Maybe do some plots, or statistical analysis. I have to hand in my Ph.D. thesis this week and do oral exams afterwards, otherwise I would do it myself. gruel From xvid-devel@xvid.org Sun Feb 2 12:33:06 2003 From: xvid-devel@xvid.org (Marco "elcabesa" Belli) Date: Sun, 2 Feb 2003 13:33:06 +0100 Subject: [XviD-devel] SKAL new gmc code BUG In-Reply-To: References: Message-ID: <200302021333.06328.elcabesa@inwind.it> Alle Saturday 01 February 2003 14:30, Christoph Lampert ha scritto: > Both. It's a better version of my "ISO" implementation, and it has limited > support for 3 warppoints (which mine didn't). In particular, there are a > few new entries in GMC_DATA struct. So if e.g encoder.c wasn't recompiled, > everything will crash. you are right!! after a make -f M akefile.linux clean make -f Makefile.linux all work=) From xvid-devel@xvid.org Sun Feb 2 20:37:56 2003 From: xvid-devel@xvid.org (Edouard Gomez) Date: Sun, 2 Feb 2003 21:37:56 +0100 Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile Message-ID: <20030202203756.GA592@leloo> --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, the unified makefile + configure seems to work fine on that: - Debian GNU/Linux x86, sparc64 - Red Hat 7.3 x86 - Solaris8 sparc32 - FreeBSD 4.7 x86 - BeOS R5 (gcc internal compiler error, but the makefile is fine) - Debian GNU/Linux alphaev64 the unified makefile fails on that platforms: - MacOSX 10.1 Server Edition the unified makefile has not been tested on: - Win32 + cygwin The binaries seem to work fine on all 32bit platforms, however the alpha target (the only one which is 64bit andis supported by gcc in 64bit mode) did crash when using the examples, the bitstream functions were reading out of bounds. So i need testers for 3 things: - Does the makefile works fine on Win32+cygwin ? - Does the ia64 version still works (because i fear 64bit targets are broken) and if someone has access to another alpha station, could he have a look at the source to find out why it segfaults ? - Test as much as possible all unix targets i had no access to: irix+mips, netbsd+all flavors of cpu I need the Win32 MSVC project files to be changed[1] so they use: -DARCH_IS_IA32 -DARCH_IS_32BIT -DARCH_IS_LITTLE_ENDIAN A working copy of my 0.9.x tree is at http://ed.gomez.free.fr/ MD5SUM -- f7ea0b035541e7e24da76674931bee62 xvid.tar.gz [1] well, the change will be needed if we decide to adopt these unix makefiles. But at the moment i need testers. --=20 Edouard Gomez --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+PYGkR5dTYz5sWMcRAnM5AKDB4IBE/haF0sd5nsUHkum5Vlts9wCdENVB W0hGzK9WpTNXCkxnARQ8Iig= =IuSQ -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From xvid-devel@xvid.org Sun Feb 2 20:58:23 2003 From: xvid-devel@xvid.org (Marco "elcabesa" Belli) Date: Sun, 2 Feb 2003 21:58:23 +0100 Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile In-Reply-To: <20030202203756.GA592@leloo> References: <20030202203756.GA592@leloo> Message-ID: <200302022158.23735.elcabesa@inwind.it> if you want i could test under linux slackware x86 =) i have nothhing else From xvid-devel@xvid.org Sun Feb 2 21:42:38 2003 From: xvid-devel@xvid.org (Christoph Lampert) Date: Sun, 2 Feb 2003 22:42:38 +0100 (CET) Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile In-Reply-To: <20030202203756.GA592@leloo> Message-ID: On Sun, 2 Feb 2003, Edouard Gomez wrote: > Hello, > > the unified makefile + configure seems to work fine on that: > - Debian GNU/Linux x86, sparc64 > - Red Hat 7.3 x86 > - Solaris8 sparc32 > - FreeBSD 4.7 x86 > - BeOS R5 (gcc internal compiler error, but the makefile is fine) > - Debian GNU/Linux alphaev64 > > the unified makefile fails on that platforms: > - MacOSX 10.1 Server Edition > > the unified makefile has not been tested on: > - Win32 + cygwin > > The binaries seem to work fine on all 32bit platforms, however the alpha > target (the only one which is 64bit andis supported by gcc in 64bit > mode) did crash when using the examples, the bitstream functions were > reading out of bounds. > > So i need testers for 3 things: > - Does the makefile works fine on Win32+cygwin ? > - Does the ia64 version still works (because i fear 64bit targets are > broken) and if someone has access to another alpha station, could he > have a look at the source to find out why it segfaults ? > - Test as much as possible all unix targets i had no access to: > irix+mips, netbsd+all flavors of cpu So, where is the makefile? Florin gave me access to Irix64. Currently, it encoding doesn't work with Makefile.irix64, but that doesn't mean a thing, I guess it's again unaligned access in bitstream.c or so. gruel From xvid-devel@xvid.org Sun Feb 2 22:12:40 2003 From: xvid-devel@xvid.org (Edouard Gomez) Date: Sun, 2 Feb 2003 23:12:40 +0100 Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile In-Reply-To: References: <20030202203756.GA592@leloo> Message-ID: <20030202221240.GB592@leloo> --f2QGlHpHGjS2mn6Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Christoph Lampert (chl@math.uni-bonn.de) wrote: > So, where is the makefile?=20 As i mentioned in my previous mail :-) it's there http://ed.gomez.free.fr/ --=20 Edouard Gomez --f2QGlHpHGjS2mn6Y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+PZfYR5dTYz5sWMcRAoKNAJ48BcjRMDHMhTnOj7G5XM7Ctru0EACdHY2e elixcPx8H03/bFjX06T5GfY= =i9Nq -----END PGP SIGNATURE----- --f2QGlHpHGjS2mn6Y-- From xvid-devel@xvid.org Sun Feb 2 22:18:51 2003 From: xvid-devel@xvid.org (Christoph Lampert) Date: Sun, 2 Feb 2003 23:18:51 +0100 (CET) Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile In-Reply-To: Message-ID: On Sun, 2 Feb 2003, Christoph Lampert wrote: > > So, where is the makefile? > Florin gave me access to Irix64. Currently, it encoding > doesn't work with Makefile.irix64, but that doesn't mean a > thing, I guess it's again unaligned access in bitstream.c or so. Sorry, bullsh*t... it does work, of course... it's just a little sloooooow. gruel From xvid-devel@xvid.org Sun Feb 2 22:31:05 2003 From: xvid-devel@xvid.org (Christoph Lampert) Date: Sun, 2 Feb 2003 23:31:05 +0100 (CET) Subject: [XviD-devel] int32_t etc. Message-ID: Hi, can one of the Windows users check if you have C99 header files with typedefs like uint_fast32_t instead of just uint32_t Those are by definition "the fastest unsigned type with at least 32bit" and since we almost never rely on "exactly 32 bits", but just on "more than 16", we could switch at many places. This would be better for upcoming 64bit machines, and also it's better style. gruel From xvid-devel@xvid.org Sun Feb 2 22:40:17 2003 From: xvid-devel@xvid.org (Christoph Lampert) Date: Sun, 2 Feb 2003 23:40:17 +0100 (CET) Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile In-Reply-To: <20030202221240.GB592@leloo> Message-ID: On Sun, 2 Feb 2003, Edouard Gomez wrote: > Christoph Lampert (chl@math.uni-bonn.de) wrote: > > So, where is the makefile? > > As i mentioned in my previous mail :-) it's there > > http://ed.gomez.free.fr/ Oh, I didn't notice I had to download half your harddisk to get the makefile ;-) Okay, got it... bash-2.05a$ ./configure checking build system type... mips-sgi-irix6.5 checking host system type... mips-sgi-irix6.5 checking target system type... mips-sgi-irix6.5 checking whether to use default CFLAGS... yes checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a BSD-compatible install... ./install-sh -c checking for processor type... mips checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking for int *... yes checking size of int *... 4 checking whether byte ordering is bigendian... yes checking for build extensions... .so .a .o checking for specific LDFLAGS... -shared -lc -lm checking stdio.h usability... yes checking stdio.h presence... yes checking for stdio.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes configure: creating ./config.status config.status: creating platform.inc So far so good... **** some Minutes of compiling later **** bash-2.05a$ bzcat cactus.pgm.bz2 | ./xvid_stat -m 1 xvid_stat - XviD core library test program written by Christoph Lampert 2002 Trying to retreive width and height from PGM header Frame 0: intra 1, enctime= 139.4 ms, size= 12470 bytes dectime = 79.1 ms PSNR 40.74 Frame 1: intra 0, enctime= 321.4 ms, size= 1067 bytes dectime = 23.0 ms PSNR 41.02 Frame 2: intra 0, enctime= 259.8 ms, size= 1212 bytes dectime = 24.3 ms PSNR 41.24 Avg. Q6 br 0900 ( 0.43 bpp) size 4916 ( 983 kbps / 0.47 bpp) enc: 4.2 fps, dec: 23.7 fps PSNR P(2): 41.13 ( 41.02 , 41.24 ; 0.0650 ) I(1): 40.74 ( 40.74 , 40.74 ; 0.0000 ) --------------------------------------- Well done, GomGom, seems to work fine, except for the speeeeed (4 fps...) gruel From xvid-devel@xvid.org Sun Feb 2 22:50:31 2003 From: xvid-devel@xvid.org (Edouard Gomez) Date: Sun, 2 Feb 2003 23:50:31 +0100 Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile In-Reply-To: References: <20030202221240.GB592@leloo> Message-ID: <20030202225031.GC592@leloo> --32u276st3Jlj2kUU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Christoph Lampert (chl@math.uni-bonn.de) wrote: > [...] > checking size of int *... 4 > checking whether byte ordering is bigendian... yes >=20 > Well done, GomGom, seems to work fine, except for the speeeeed (4 fps...) well, 32bit targets are all working, but i fear 64bit target (mips[lb]64, alpha or ia64) may experience problems with bitstream functions. On the alpha host on sourceforge compile farm, i got very strange results with the cactus test. And of course the resulting stream was simply badly decoded. --=20 Edouard Gomez --32u276st3Jlj2kUU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+PaC2R5dTYz5sWMcRAmViAKCCO7WLo8A2hMEmW1QyM8HDBQzbnQCg6rt9 4ctKgtKYaRwktrpbGBo5zgY= =jSYP -----END PGP SIGNATURE----- --32u276st3Jlj2kUU-- From xvid-devel@xvid.org Sun Feb 2 22:56:27 2003 From: xvid-devel@xvid.org (Michel LESPINASSE) Date: Sun, 2 Feb 2003 14:56:27 -0800 Subject: [XviD-devel] int32_t etc. In-Reply-To: References: Message-ID: <20030202225627.GA12578@zoy.org> On Sun, Feb 02, 2003 at 11:31:05PM +0100, Christoph Lampert wrote: > uint_fast32_t > instead of just > uint32_t > > Those are by definition "the fastest unsigned type with at least 32bit" > and since we almost never rely on "exactly 32 bits", but just on "more > than 16", we could switch at many places. This would be better for > upcoming 64bit machines, and also it's better style. hmmmm is it not OK to just use 'int' in these cases ? I'd expect most targets (except for 16-bit systems) to use an int that is both fast on their CPU, and at least 32 bits in size. Is this not always the case ??? Puzzled, -- Michel "Walken" LESPINASSE Is this the best that god can do ? Then I'm not impressed. From xvid-devel@xvid.org Sun Feb 2 23:05:33 2003 From: xvid-devel@xvid.org (Christoph Lampert) Date: Mon, 3 Feb 2003 00:05:33 +0100 (CET) Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile In-Reply-To: <20030202225031.GC592@leloo> Message-ID: On Sun, 2 Feb 2003, Edouard Gomez wrote: > Christoph Lampert (chl@math.uni-bonn.de) wrote: > > [...] > > checking size of int *... 4 > > checking whether byte ordering is bigendian... yes > > > > Well done, GomGom, seems to work fine, except for the speeeeed (4 fps...) > > well, 32bit targets are all working, but i fear 64bit target > (mips[lb]64, alpha or ia64) may experience problems with bitstream > functions. That was MIPS R5000 which has 64bit registers, but I guess since int-size is 32, it behaves just like ordinary 32bit. I tried again with -DARCH_IS_64BIT and it did compile and also didn't crash, but there were compiler warnings of the type ../../src/encoder.c:887: warning: cast from pointer to integer of different size for "DECLARE_ALIGNED_MATRIX" and what is strangest: cactus test was much smaller filesize at much higher PSNR! So maybe there's something wrong with image conversion already? bash-2.05a$ bzcat cactus.pgm.bz2 | ./xvid_stat -m 1 xvid_stat - XviD core library test program written by Christoph Lampert 2002 Trying to retreive width and height from PGM header Frame 0: intra 1, enctime= 126.9 ms, size= 3119 bytes dectime = 76.3 ms PSNR 40.74 Frame 1: intra 0, enctime= 295.7 ms, size= 344 bytes dectime = 26.2 ms PSNR 41.21 Frame 2: intra 0, enctime= 268.5 ms, size= 811 bytes dectime = 38.8 ms PSNR 42.47 Avg. Q6 br 0900 ( 0.43 bpp) size 1424 ( 284 kbps / 0.13 bpp) enc: 4.3 fps, dec: 21.2 fps PSNR P(2): 41.84 ( 41.21 , 42.47 ; 0.3650 ) I(1): 40.74 ( 40.74 , 40.74 ; 0.0000 ) From xvid-devel@xvid.org Sun Feb 2 23:50:39 2003 From: xvid-devel@xvid.org (John Cannon) Date: Sun, 2 Feb 2003 17:50:39 -0600 Subject: [XviD-devel] Greyscale option for credits is broken Message-ID: When using this option on non greyscale material, I get horrible mixes of colored and non-colored blocks. I think ithis could be the same reason that the black and white credits come out streaked. Maybe I am missing the actual point of greyscale credits but I thought it just dropped the luminance. Anyway, can someone please tell me what's up? Spyder From xvid-devel@xvid.org Mon Feb 3 00:08:53 2003 From: xvid-devel@xvid.org (Edouard Gomez) Date: Mon, 3 Feb 2003 01:08:53 +0100 Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile In-Reply-To: References: <20030202225031.GC592@leloo> Message-ID: <20030203000853.GA9999@leloo> --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Christoph Lampert (chl@math.uni-bonn.de) wrote: > On Sun, 2 Feb 2003, Edouard Gomez wrote: >=20 > > Christoph Lampert (chl@math.uni-bonn.de) wrote: > > > [...] > > > checking size of int *... 4 > > > checking whether byte ordering is bigendian... yes > > >=20 > > > Well done, GomGom, seems to work fine, except for the speeeeed (4 fps= =2E..) > >=20 > > well, 32bit targets are all working, but i fear 64bit target > > (mips[lb]64, alpha or ia64) may experience problems with bitstream > > functions. >=20 > That was MIPS R5000 which has 64bit registers, but I guess since int-size > is 32, it behaves just like ordinary 32bit.=20 The architecture size is for the address bus, so we make sure ptr_t is the right size for the platform. I get the same 32/64 bit ambiguity on sparc64 which is a 64bit processor (both data registers and address bus) but for some obvious reason, gcc generates only 32bit mode code. So gcc reports sizeof(int *) =3D=3D 4 the same way it did for your MIPS R5000. > I tried again with -DARCH_IS_64BIT and it did compile and also didn't > crash, but there were compiler warnings of the type=20 >=20 > ../../src/encoder.c:887: warning: cast from pointer to integer of > different size >=20 That is the ptr_t being wrong. You have just misunderstood what ARCH_IS_32/64BIT was meaning. > for "DECLARE_ALIGNED_MATRIX" and what is strangest: cactus test was=20 > much smaller filesize at much higher PSNR!=20 >=20 > So maybe there's something wrong with image conversion already?=20 >=20 >=20 >=20 >=20 > bash-2.05a$ bzcat cactus.pgm.bz2 | ./xvid_stat -m 1 > xvid_stat - XviD core library test program written by Christoph Lampert > 2002 >=20 > Trying to retreive width and height from PGM header > Frame 0: intra 1, enctime=3D 126.9 ms, size=3D 3119 bytes dectime = =3D 76.3 > ms PSNR 40.74 > Frame 1: intra 0, enctime=3D 295.7 ms, size=3D 344 bytes dectime = =3D 26.2 > ms PSNR 41.21 > Frame 2: intra 0, enctime=3D 268.5 ms, size=3D 811 bytes dectime = =3D 38.8 > ms PSNR 42.47 > Avg. Q6 br 0900 ( 0.43 bpp) size 1424 ( 284 kbps / 0.13 > bpp) enc: 4.3 fps, dec: 21.2 fps > PSNR P(2): 41.84 ( 41.21 , 42.47 ; 0.3650 ) I(1): 40.74 ( 40.74 , 40.74 > ; 0.0000 ) I got exactly the same results with the alpha target... so something is wrong when activating 64bit. Perhaps ptr_t is used where it should not be used. I'll have a look tomorrow. I'll also try to see if i find some new sparc machine in my shool (i know we have old sparcs, but i'm sure they bought some new SUN workstations last year) --=20 Edouard Gomez --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+PbMUR5dTYz5sWMcRArznAKC1L+tvNwiNxZHY0ZCK77wdljd3bwCcCt0T DH/tAmvzzuwlOU9Ibz1hA9Q= =UuMW -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From xvid-devel@xvid.org Mon Feb 3 00:18:03 2003 From: xvid-devel@xvid.org (suxen_drol) Date: Mon, 03 Feb 2003 11:18:03 +1100 Subject: [XviD-devel] int32_t etc. In-Reply-To: References: Message-ID: <20030203111802.D427.SUXEN_DROL@hotmail.com> On Sun, 2 Feb 2003 23:31:05 +0100 (CET) Christoph Lampert wrote: > > Hi, > > can one of the Windows users check if you have C99 header files > with typedefs like > > uint_fast32_t > > instead of just > > uint32_t microsoft visual studio v6 does not define uint32_t or uint_fast32_t. > Those are by definition "the fastest unsigned type with at least 32bit" > and since we almost never rely on "exactly 32 bits", but just on "more > than 16", we could switch at many places. This would be better for > upcoming 64bit machines, and also it's better style. we really only need to worry about uint8_t and uint16_t: - uint8_t is only used for pixel-space stuff - uint16_t is only used for dct-space stuff uint32_t should be replaced (almost) everywhere with plain int. -- pete; life is like a box of ammo From xvid-devel@xvid.org Mon Feb 3 01:54:36 2003 From: xvid-devel@xvid.org (suxen_drol) Date: Mon, 03 Feb 2003 12:54:36 +1100 Subject: [XviD-devel] DivX5.03 rounding? In-Reply-To: References: Message-ID: <20030203122908.804D.SUXEN_DROL@hotmail.com> On Sun, 26 Jan 2003 18:38:33 +0100 (CET) Christoph Lampert wrote: > Hi > > new DivX5.03 is there, and changelog says it corrected > some rounding issues, including QPel. > > http://www.divx.com/divx/divx_win_versions.php > http://www.divx.com/divx/divxpro_win_versions.php > > Can someone check if it's compatible with XVID decoder now? > > gruel yes it is now compatibile. by default divx503 uses the correct rounding, but if it detects the bitstream was encoded with < divx503, it will use the incorrect rounding (so older streams appear correct). this causes a problem for us, when using bframes>0 + packed + qpel. xvid inserts the divx version string "DivX501b481p" into the bitstream to inform divx and xvid that the bitstream is packed. (we do this *only* for packed mode). since divx503 assumes the stream was encoded with divx501, it uses the old incorect rounding. solutions: * modify xvid to insert a new version string ("DivX503b740p"). but what happens when bugs are found in divx503? * use something silly like "DivX000b000p" or "DivX999b999p", so we can identify packed streams, but not be affected by divx-versioing. * come up with a better way to identify packed streams. it'd be nice if the bitstream could indicate the desired level of post processing: use a user data string: "@id:n=xvid,v=090,b=20030201,f=3,p" n=%s : compressor name. ie. xvid,divx,3ivx,apple, whatever v=%d : version b=%d : build p[=%d] : packed f[=%d] : post filter leve where %i is in the range 0-9(inclusive) ? -- pete; life is like a box of ammo From xvid-devel@xvid.org Mon Feb 3 06:08:15 2003 From: xvid-devel@xvid.org (Cami) Date: Mon, 3 Feb 2003 08:08:15 +0200 Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile References: <20030202203756.GA592@leloo> Message-ID: <00d901c2cb4a$a4b578d0$803102c4@lonewolf> have you tried to login to the box yet? ----- Original Message ----- From: "Edouard Gomez" To: "xvid-devel ML" Sent: Sunday, February 02, 2003 10:37 PM Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile From xvid-devel@xvid.org Mon Feb 3 06:09:11 2003 From: xvid-devel@xvid.org (Cami) Date: Mon, 3 Feb 2003 08:09:11 +0200 Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile Message-ID: <00e701c2cb4a$c5e89e10$803102c4@lonewolf> | have you tried to login to the box yet? oops, please ignore that message. Thanks ;) ++C From xvid-devel@xvid.org Mon Feb 3 08:44:04 2003 From: xvid-devel@xvid.org (Edouard Gomez) Date: Mon, 3 Feb 2003 09:44:04 +0100 Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile In-Reply-To: <00d901c2cb4a$a4b578d0$803102c4@lonewolf> References: <20030202203756.GA592@leloo> <00d901c2cb4a$a4b578d0$803102c4@lonewolf> Message-ID: <20030203084404.GA499@leloo> --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cami (camis@mweb.co.za) wrote: > have you tried to login to the box yet? oops i forgot to inform you your box isn't accessible from cypher, ssh says "No route to host" --=20 Edouard Gomez --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+PivUR5dTYz5sWMcRAsASAJ4rikG3ro6lnkkHIpuxCFoAYy6r3ACgro6C TWBW/54CyuMx0/1kF0FcyPM= =Hkze -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From xvid-devel@xvid.org Mon Feb 3 13:49:14 2003 From: xvid-devel@xvid.org (Marco "elcabesa" Belli) Date: Mon, 3 Feb 2003 14:49:14 +0100 Subject: [XviD-devel] HVS, Adaptive Quant, "activity" In-Reply-To: References: Message-ID: <200302031449.14472.elcabesa@inwind.it> > For some reasons, it seems to disappears after '97 using google i found some docs in late 1999 that talk about it and some docs that talk about an imporvement of it NVFM normalized video fidelity metric From xvid-devel@xvid.org Mon Feb 3 13:54:38 2003 From: xvid-devel@xvid.org (Stephan Krause) Date: Mon, 3 Feb 2003 14:54:38 +0100 Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile In-Reply-To: <20030202203756.GA592@leloo> References: <20030202203756.GA592@leloo> Message-ID: Hi, > - Does the ia64 version still works (because i fear 64bit targets are > broken) ia64 Version does compile and run, but slightly slower (~15%) than with the original Makefile. I didn't try, but ia64/ecc should be broken because it needs an other idct-Version (dct/ia64_asm/idct_ia64_ecc.s instead of idct_ia64_gcc.s) Stephan -- Sig fault. (core dumped) From xvid-devel@xvid.org Mon Feb 3 17:25:16 2003 From: xvid-devel@xvid.org (Christoph Lampert) Date: Mon, 3 Feb 2003 18:25:16 +0100 (CET) Subject: [XviD-devel] Is your machine too fast? Message-ID: Hi, do you have a fast machine and fast internet access? Then please do me a favour and download some 720p and 1080p test-sequences from ftp://ftp.ldv.e-technik.tu-muenchen.de/pub/test_sequences/1080p/ ftp://ftp.ldv.e-technik.tu-muenchen.de/pub/test_sequences/720p/ Encode them using any software which reads raw YUV4:2:0 format (e.g. xvid_stat) and post the results. Please do one test with fixed quant 6 for _all_ frames types (including B-frames), because that way we can compare to the H26.L reference results. Remember: These are 1280x720@50fps or 1920x1080@25fps so I doubt anyone of you will reach real-time encoding. ;-) gruel From xvid-devel@xvid.org Mon Feb 3 19:06:13 2003 From: xvid-devel@xvid.org (John Cannon) Date: Mon, 3 Feb 2003 13:06:13 -0600 Subject: [XviD-devel] Re: Greyscale option for credits is broken References: Message-ID: "John Cannon" wrote in message news:b1kans$crv$1@main.gmane.org... > When using this option on non greyscale material, I get horrible mixes of > colored and non-colored blocks. I think ithis could be the same reason that > the black and white credits come out streaked. Maybe I am missing the > actual point of greyscale credits but I thought it just dropped the > luminance. Anyway, can someone please tell me what's up? > > Spyder Sorry that should have been dropped the chrominance From xvid-devel@xvid.org Mon Feb 3 23:57:20 2003 From: xvid-devel@xvid.org (Edouard Gomez) Date: Tue, 4 Feb 2003 00:57:20 +0100 Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile In-Reply-To: References: <20030202203756.GA592@leloo> Message-ID: <20030203235720.GA21538@leloo> --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Stephan Krause (s_kraste@ira.uka.de) wrote: > I didn't try, but ia64/ecc should be broken because it needs an other=20 > idct-Version (dct/ia64_asm/idct_ia64_ecc.s instead of idct_ia64_gcc.s) Yep that's something i dropped at the moment in order to obtain a working building system but it will be handled in a future version very soon. The aims of the new build system are: - no regressions (means all known working platforms will still build) - one makefile to rule them all - and in the darkness, the configure script forges its unique ring :-) One more success at school today: - Solaris with kernel 2.5.1 + solrais pmake + gcc 2.8.1 <-- try to find an older compiler ;-) on an UltraSparc I station Btw, does someone know why XviD refuses to link on MacOSX. The linker outputs lot of errors related to multiples symbol definitions. Any MacOSX tester ? --=20 Edouard Gomez --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+PwHgR5dTYz5sWMcRArdfAJ0VQ3oqndcWlnUgIERqzAD+12uhBgCgt1mG M+TSWlMMFFzIBjjnhoaRW+s= =2fWI -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From xvid-devel@xvid.org Tue Feb 4 00:10:51 2003 From: xvid-devel@xvid.org (suxen_drol) Date: Tue, 04 Feb 2003 11:10:51 +1100 Subject: [XviD-devel] DivX5.03 rounding? In-Reply-To: <20030203122908.804D.SUXEN_DROL@hotmail.com> References: <20030203122908.804D.SUXEN_DROL@hotmail.com> Message-ID: <20030204101225.CE8E.SUXEN_DROL@hotmail.com> On Mon, 03 Feb 2003 12:54:36 +1100 suxen_drol wrote: > yes it is now compatibile. by default divx503 uses the correct rounding, > but if it detects the bitstream was encoded with < divx503, it will use > the incorrect rounding (so older streams appear correct). wait: * divx503 rounds incorrectly when using qpel+bframes. * but, qpel by itself appears corect. would anyone else like to verify this; as testing divx503 is difficult here; it crashes my computer with a cmov. -- pete From xvid-devel@xvid.org Tue Feb 4 01:49:05 2003 From: xvid-devel@xvid.org (Marco Al) Date: Tue, 4 Feb 2003 02:49:05 +0100 Subject: [XviD-devel] adaptive quant improvement References: <200301311147.41323.elcabesa@inwind.it> Message-ID: <012d01c2cbef$99d91c00$bca45982@cal046201> From: "Marco "elcabesa" Belli" > thanks for this > if you have some free time can you explain how it activity work? The more common term is texture masking, texture masking is really just the result of local/spatial contrast masking over a larger area. Heavily textured/highly active parts of the image will have high contrasts between pixels, and as such will provide lots of contrast masking. A model incorporating both texture and luminance masking developed for JPEG which, with some adaption of the parameters, might work decently in the present (pre motion-compensation) adaptive quantization code is described in http://home.student.utwente.nl/m.f.al/00999032.pdf Marco From xvid-devel@xvid.org Tue Feb 4 06:35:28 2003 From: xvid-devel@xvid.org (ptk9417) Date: Tue, 04 Feb 2003 01:35:28 -0500 Subject: [XviD-devel] [Future PATCH] I need testers for unified Makefile In-Reply-To: <20030203235720.GA21538@leloo> Message-ID: > Btw, does someone know why XviD refuses to link on MacOSX. The linker > outputs lot of errors related to multiples symbol definitions. Any > MacOSX tester ? > > -- > Edouard Gomez Configuring with: ./configure --host=none Gives: ns2 ../../src/utils/ratecontrol.c -o ../../src/utils/ratecontrol.o gcc -c -DARCH_IS_GENERIC -DARCH_IS_32BIT -DARCH_IS_BIG_ENDIAN -Wall -O3 -fPIC -fomit-frame-pointer -ffast-math -funroll-loops -fschedule-insns -fschedule-insns2 ../../src/utils/timer.c -o ../../src/utils/timer.o ar rcs libxvidcore.a ../../src/decoder.o ../../src/divx4.o ../../src/encoder.o ../../src/xvid.o ../../src/bitstream/bitstream.o ../../src/bitstream/cbp.o ../../src/bitstream/mbcoding.o ../../src/dct/fdct.o ../../src/dct/idct.o ../../src/image/colorspace.o ../../src/image/image.o ../../src/image/interpolate8x8.o ../../src/motion/motion_comp.o ../../src/motion/motion_est.o ../../src/motion/sad.o ../../src/prediction/mbprediction.o ../../src/quant/adapt_quant.o ../../src/quant/quant_h263.o ../../src/quant/quant_matrix.o ../../src/quant/quant_mpeg4.o ../../src/utils/emms.o ../../src/utils/mbtransquant.o ../../src/utils/mem_align.o ../../src/utils/mem_transfer.o ../../src/utils/ratecontrol.o ../../src/utils/timer.o ranlib: file: libxvidcore.a(timer.o) has no symbols gcc ../../src/decoder.o ../../src/divx4.o ../../src/encoder.o ../../src/xvid.o ../../src/bitstream/bitstream.o ../../src/bitstream/cbp.o ../../src/bitstream/mbcoding.o ../../src/dct/fdct.o ../../src/dct/idct.o ../../src/image/colorspace.o ../../src/image/image.o ../../src/image/interpolate8x8.o ../../src/motion/motion_comp.o ../../src/motion/motion_est.o ../../src/motion/sad.o ../../src/prediction/mbprediction.o ../../src/quant/adapt_quant.o ../../src/quant/quant_h263.o ../../src/quant/quant_matrix.o ../../src/quant/quant_mpeg4.o ../../src/utils/emms.o ../../src/utils/mbtransquant.o ../../src/utils/mem_align.o ../../src/utils/mem_transfer.o ../../src/utils/ratecontrol.o ../../src/utils/timer.o -o libxvidcore.so /usr/bin/ld: Undefined symbols: _main make: *** [libxvidcore.so] Error 1 [dual:xvidcore.stable/build/generic] paul% ls -l total 1504 -rw-r--r-- 1 paul staff 4282 Feb 1 20:30 Makefile -rwxr-xr-x 1 paul staff 41134 Feb 1 12:32 config.guess -rw-r--r-- 1 paul staff 16025 Feb 4 00:22 config.log -rwxr-xr-x 1 paul staff 21478 Feb 4 00:22 config.status -rwxr-xr-x 1 paul staff 29763 Feb 1 12:32 config.sub -rwxr-xr-x 1 paul staff 138307 Feb 2 12:18 configure -rw-r--r-- 1 paul staff 8754 Feb 2 12:18 configure.in -rwxr-xr-x 1 paul staff 5599 Feb 1 12:31 install-sh -rw-r--r-- 1 paul staff 452728 Feb 4 00:23 libxvidcore.a -rw-r--r-- 1 paul staff 66 Feb 1 20:18 libxvidcore.def -rwxr-xr-x 1 paul staff 6480 Feb 1 12:31 missing -rwxr-xr-x 1 paul staff 722 Feb 1 12:31 mkinstalldirs -rw-r--r-- 1 paul staff 2105 Feb 4 00:22 platform.inc -rw-r--r-- 1 paul staff 2208 Feb 1 19:46 platform.inc.in -rw-r--r-- 1 paul staff 2336 Feb 1 12:31 sources.inc Kinda hard to see... sorry.. the static lib builds correctly. the shared lib borks.. i ran into this same problem a few months back.. The same results with gcc 2.95.2 and 3.1 included with OSX 10.2.3. I did get the shared lib workin back then.. but alas, forgot how i did it.. I would play with it again, but have a test in the mornin. There was a performance hit with the shared lib.. mostally because of PIC i believe. I have to build with --host=none, because the assembly format changed. I re-wrote a few of the altivec routines from assembly to C a few months back.. but i never really tested em. If there is intrest, i can look at the code again and try to get them into a submittable form. There has been some possibly useful altivec stuff happening on the ffmpeg side. Might be worth lookin into.. dust.. aka ptkme.. From elcabesa at inwind.it Tue Feb 4 19:08:12 2003 From: elcabesa at inwind.it (Marco "elcabesa" Belli) Date: Tue Feb 4 19:10:49 2003 Subject: [XviD-devel] adaptive quant improvement In-Reply-To: <012d01c2cbef$99d91c00$bca45982@cal046201> References: <200301311147.41323.elcabesa@inwind.it> <012d01c2cbef$99d91c00$bca45982@cal046201> Message-ID: <200302041908.12289.elcabesa@inwind.it> > The more common term is texture masking, texture masking is really just the > result of local/spatial contrast masking over a larger area. Heavily > textured/highly active parts of the image will have high contrasts between > pixels, and as such will provide lots of contrast masking. > > A model incorporating both texture and luminance masking developed for JPEG > which, with some adaption of the parameters, might work decently in the > present (pre motion-compensation) adaptive quantization code is described > in http://home.student.utwente.nl/m.f.al/00999032.pdf thank you=) to ed gomez have you tested my code? do you like it? does it work ? any idea about how to make it better? From ed.gomez at free.fr Tue Feb 4 21:35:37 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Tue Feb 4 21:35:29 2003 Subject: [XviD-devel] [BUG] Small LUT implementation Message-ID: <20030204203537.GF844@leloo> IA64 architecture spoted out a bug in the small LUT code, the (nasty imo) fix has been to use ptr_t for all variables type... which was just "stupid"[1] because ptr_t is supposed to cast a bus address into its int data format so we can do logical operations on it (mainly address alignment) So i had a look at the code, and it's simply buggy, because we can have an array index == -1 which is then causing a segfault. We(Marc and I) are just wondering how it worked fine on ia32... of course we are working at fixing that. @gruel i found why we were getting small bitstreams, it was a mistake of mine i introduced in my working tree. Use the code from the cvs for the src/bitstream/bitstream.h file and it will work fine. [1] a better word would be nosense :-) -- Edouard Gomez -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030204/1ceb31d4/attachment.bin From ed.gomez at free.fr Wed Feb 5 00:37:07 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Wed Feb 5 00:36:57 2003 Subject: [XviD-devel] [BUG] Small LUT implementation In-Reply-To: <20030204203537.GF844@leloo> References: <20030204203537.GF844@leloo> Message-ID: <20030204233707.GA16443@leloo> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030205/edcc13da/attachment.bin From ed.gomez at free.fr Wed Feb 5 00:47:27 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Wed Feb 5 00:47:18 2003 Subject: [XviD-devel] [BUG] Small LUT implementation - Previous patch was not the right one In-Reply-To: <20030204233707.GA16443@leloo> References: <20030204203537.GF844@leloo> <20030204233707.GA16443@leloo> Message-ID: <20030204234727.GB16443@leloo> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030205/5a50da86/attachment.bin From marco at simplex.nl Wed Feb 5 05:00:36 2003 From: marco at simplex.nl (Marco Al) Date: Wed Feb 5 05:00:25 2003 Subject: [XviD-devel] [BUG] Small LUT implementation - Previous patch wasnot the right one References: <20030204203537.GF844@leloo> <20030204233707.GA16443@leloo> <20030204234727.GB16443@leloo> Message-ID: <008001c2cccb$23bf9260$bca45982@cal046201> From: "Edouard Gomez" > This one should be ok, it does not change the cactus example. So I think > u really understand i would like you all to test it when possible. If you absolutely cannot abide the test relying on underflow and the sequence of evaluation just keep my code and add an extra "if (run > max_run[intra][last][level])" in front of the if statement for escape-2 coding, no need to make run_esc signed or to duplicate code. I still say the only patch that is needed is -if (level <= max_level[intra][last][run_esc] && run_esc <= max_run[intra][last][level]) +if (run_esc <= max_run[intra][last][level] && level <= max_level[intra][last][run_esc]) Marco From marco at simplex.nl Wed Feb 5 05:40:50 2003 From: marco at simplex.nl (Marco Al) Date: Wed Feb 5 05:40:54 2003 Subject: [XviD-devel] [BUG] Small LUT implementation - Previous patchwasnot the right one References: <20030204203537.GF844@leloo> <20030204233707.GA16443@leloo><20030204234727.GB16443@leloo> <008001c2cccb$23bf9260$bca45982@cal046201> Message-ID: <002301c2ccd0$c23740a0$bca45982@cal046201> From: "Marco Al" > If you absolutely cannot abide the test relying on underflow and the > sequence of evaluation just keep my code and add an extra Also level_esc has the same issue ... so you'd have more code to change. I propose the following patch. Marco-------------- next part -------------- 97c97 < ptr_t i, j, intra, last, run, run_esc, level, level_esc, escape, escape_len, offset; --- > uint32_t i, j, intra, last, run, run_esc, level, level_esc, escape, escape_len, offset; 132c132 < for (j = 0; j < 1 << (12 - coeff_tab[intra][i].vlc.len); j++) --- > for (j = 0; j < (uint32_t)(1 << (12 - coeff_tab[intra][i].vlc.len)); j++) 157c157 < for (level = 1; level < 32 << intra; level++) --- > for (level = 1; level < (uint32_t)(32 << intra); level++) 169,172d168 < /*use this test to use shorter esc2 codes when possible < if (level_esc <= max_level[intra][last][run] && run <= max_run[intra][last][level_esc] < && !(coeff_VLC[intra][last][level_esc + offset][run].len + 7 + 1 < > coeff_VLC[intra][last][level + offset][run_esc].code + 7 + 2))*/ 182c178 < if (level <= max_level[intra][last][run_esc] && run_esc <= max_run[intra][last][level]) --- > if (run_esc <= max_run[intra][last][level] && level <= max_level[intra][last][run_esc]) 223c219 < for (level = 32 << intra; level < 2048; level++) --- > for (level = (uint32_t)(32 << intra); level < 2048; level++) From xvid-devel at xvid.org Wed Feb 5 18:34:13 2003 From: xvid-devel at xvid.org (System Anti-Virus Administrator) Date: Wed Feb 5 19:42:24 2003 Subject: [XviD-devel] Illegal attachment type found in sent message "Re:skal,the Garden of Eden" Message-ID: <20030205183413.24830.qmail@planet-d.net> Attention: xvid-devel . A Illegal attachment type was found in an Email message you sent. This Email scanner intercepted it and stopped the entire message reaching it's destination. The Illegal attachment type was reported to be: ScreenSavers Disallowed (force by changing the extension) Please contact your I.T support personnel with any queries regarding this policy. Your message was sent with the following envelope: MAIL FROM: xvid-devel@xvid.org RCPT TO: skal@planet-d.net ... and with the following headers: From: xvid-devel To: skal@planet-d.net Subject: Re:skal,the Garden of Eden Message-ID: Date: Wed, 05 Feb 2003 18:41:44 +0000 The original message is kept in: ace:/var/spool/qmailscan/quarantine where the System Anti-Virus Administrator can further diagnose it. The Email scanner reported the following when it scanned that message: --- ---perlscanner results --- Illegal attachment type 'ScreenSavers Disallowed (force by changing the extension)' found in file /var/spool/qmailscan/ace104447005324823/will.scr --- From ed.gomez at free.fr Thu Feb 6 01:59:44 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Thu Feb 6 01:59:49 2003 Subject: [XviD-devel] [BUG] Small LUT implementation - Previous patchwasnot the right one In-Reply-To: <002301c2ccd0$c23740a0$bca45982@cal046201> References: <20030204203537.GF844@leloo> <008001c2cccb$23bf9260$bca45982@cal046201> <002301c2ccd0$c23740a0$bca45982@cal046201> Message-ID: <20030206005944.GA12674@leloo> Marco Al (marco@simplex.nl) wrote: > Also level_esc has the same issue ... so you'd have more code to change. > > I propose the following patch. Patch commited. Now we have a working XviD on lot of platforms :-) (at least my working tree) Here is a summary: - Debian GNU/Linux - StrongARM - Alphave67 (alpha 64bit) - ia32 - UltraSparcIII - Solaris - UltraSparcI - Sparc 32bit on old sun stations ( i don't remember the exact name) - FreeBSD 4.7 - ia32 - RedHat 7.3 - ia32 - Gentoo 1.4 - ia32 - the irix box according to christoph tests - working on ia64 - Unknown OS? The unix unified makefile supports: - gmake - pmake ToDo things to finish this new build system: - Manage the ecc/gcc source choice for ia64 - Someone to test the makefile on Cygwin and/or mingw+minsys - Update MSVC projects (replace 2 or 3 defines) - See why MacOSX is complaining about duplicated symbols, it seems the mach ABI does not alow namespace collisions even between C modules. And add altivec detection in configure.in I think we cannot make it more portable than i could do for now. The only thing i would like is to update the PowerPC support which seems to be updated (at least old gcc on macosx 10.1 does not understand the assembly files) - Perhaps stealing^Wtaking code from ffmpeg could help, though we have no known users of XviD on this list using PPC (/me summons iMacs, iBooks users :-). Once i fix most of these issues, 0.9.1 will be out, and i'll port all the fixes to dev-api-3, including the new build system. -- Edouard Gomez -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030206/138f07c0/attachment.bin From chl at math.uni-bonn.de Thu Feb 6 14:34:15 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Thu Feb 6 14:34:31 2003 Subject: [XviD-devel] DivX5.03 rounding? In-Reply-To: <20030204101225.CE8E.SUXEN_DROL@hotmail.com> Message-ID: On Tue, 4 Feb 2003, suxen_drol wrote: > > On Mon, 03 Feb 2003 12:54:36 +1100 suxen_drol wrote: > > yes it is now compatibile. by default divx503 uses the correct rounding, > > but if it detects the bitstream was encoded with < divx503, it will use > > the incorrect rounding (so older streams appear correct). > > wait: > * divx503 rounds incorrectly when using qpel+bframes. > * but, qpel by itself appears corect. Are we sure that XVID does correct direct mode Qpel? I may have asked earlier, but I remember something that direct mode always uses 8x8 blocks, not 16x16 as we do, even if collocated block is INTER, not INTER4V. For halfpel this doesn't matter, but for qpel it does. The same questions came up on mpeg4-technotes (without answer). gruel From radoslaw at syskin.cjb.net Fri Feb 7 00:13:54 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Thu Feb 6 14:43:20 2003 Subject: [XviD-devel] DivX5.03 rounding? In-Reply-To: References: Message-ID: <10316079210.20030207001354@syskin.cjb.net> Hello Christoph, > Are we sure that XVID does correct direct mode Qpel? I may have asked > earlier, but I remember something that direct mode always uses 8x8 blocks, > not 16x16 as we do, even if collocated block is INTER, not INTER4V. > For halfpel this doesn't matter, but for qpel it does. That's OK, we do it in 8x8 as well. MODE_DIRECT_NO4V is not set in qpel mode, so motion compensation to be performed on 8x8 blocks. [code] if (Data->qpel || b_mb->mode == MODE_INTER4V) pMB->mode = MODE_DIRECT; else pMB->mode = MODE_DIRECT_NO4V; //for faster compensation [/code] Radek From chl at math.uni-bonn.de Thu Feb 6 16:01:33 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Thu Feb 6 16:01:44 2003 Subject: [XviD-devel] DivX5.03 rounding? In-Reply-To: <10316079210.20030207001354@syskin.cjb.net> Message-ID: On Fri, 7 Feb 2003, Radek Czyz wrote: > Hello Christoph, > > > Are we sure that XVID does correct direct mode Qpel? I may have asked > > earlier, but I remember something that direct mode always uses 8x8 blocks, > > not 16x16 as we do, even if collocated block is INTER, not INTER4V. > > For halfpel this doesn't matter, but for qpel it does. > > That's OK, we do it in 8x8 as well. MODE_DIRECT_NO4V is not set in > qpel mode, so motion compensation to be performed on 8x8 blocks. Ahhh... that's tricky! Of course I just read the "switch" and thought DIRECT_NO4V was set. Is decoder doing this as well? There is a call in bf_interpolate_mbinter() if(dec->quarterpel) { if((pMB->mode == MODE_INTER || pMB->mode == MODE_INTER_Q)) interpolate16x16_quarterpel(dec->cur.y,forwar...) else { interpolate8x8_quarterpel(...) interpolate8x8_quarterpel(...) ... } gruel From zoltan at bendor.com.au Fri Feb 7 12:08:26 2003 From: zoltan at bendor.com.au (Zoltan Kocsi) Date: Fri Feb 7 01:55:41 2003 Subject: [XviD-devel] B frame help Message-ID: <15939.1186.740282.835568@tade.bendor.com.au> Dear All, I have to write a bitstream encoder. I use the XviD decoder for testing the bitstream. I and P frames are working nice but with B frames I have severe problems. The bitstream looks syntactically correct, at least XviD reads exactly as many bits for the frame as I write but what it generates as a decoded image is very strange. I created very simple test images to see what happens and the results are just weird. I would really appreciate if someone would be willing to help me to figure out what do I do wrong (possibly in private mail, so that the list doesn't get cluttered with this). My email is zoltan@bendor.com.au Thanks in advance, Zoltan From skal at planet-d.net Fri Feb 7 10:38:49 2003 From: skal at planet-d.net (skal) Date: Fri Feb 7 10:41:41 2003 Subject: [XviD-devel] Illegal attachment type found in sent message "Re:skal,the Garden of Eden" In-Reply-To: <20030205183413.24830.qmail@planet-d.net> References: <20030205183413.24830.qmail@planet-d.net> Message-ID: <1044610729.1467.5.camel@latitude344> On Wed, 2003-02-05 at 19:34, an unknown sender wrote: > Attention: xvid-devel . > > > A Illegal attachment type was found in an Email message you sent. > This Email scanner intercepted it and stopped the entire message > reaching it's destination. [...] wtf is this??? Skal, unaware he was bound for the Garden Of Eden :) (btw: Hi Walken!! Nice to have you lurking on this ML:)) From suxen_drol at hotmail.com Sat Feb 8 09:28:02 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Fri Feb 7 23:28:05 2003 Subject: [XviD-devel] B frame help In-Reply-To: <15939.1186.740282.835568@tade.bendor.com.au> References: <15939.1186.740282.835568@tade.bendor.com.au> Message-ID: <20030208092743.3DE7.SUXEN_DROL@hotmail.com> On Fri, 7 Feb 2003 12:08:26 +1100 (EST) Zoltan Kocsi wrote: hi > > I have to write a bitstream encoder. I use the XviD decoder for ____^^^^^^^ who is forcing you? and what do you mean by bitstream encoder? ie. are you implementing your own bistream routines (putbits,etc.), or writing a mpeg video encoder from scratch. > testing the bitstream. I and P frames are working nice but with > B frames I have severe problems. The bitstream looks syntactically > correct, at least XviD reads exactly as many bits for the frame > as I write but what it generates as a decoded image is very > strange. I created very simple test images to see what happens > and the results are just weird. b-vops are very similar to p-vops; the major differences: * macroblock mode/cbp vlcs * motion vectors stored differently (thus compensation performed differently) * co-located block skipping semantics > I would really appreciate if someone would be willing to help me > to figure out what do I do wrong (possibly in private mail, so that > the list doesn't get cluttered with this). the list wont mind getting cluttered. -- pete; life is like a box of ammo From zoltan at bendor.com.au Sat Feb 8 10:42:14 2003 From: zoltan at bendor.com.au (Zoltan Kocsi) Date: Sat Feb 8 00:29:33 2003 Subject: [XviD-devel] B frame help In-Reply-To: <20030208092743.3DE7.SUXEN_DROL@hotmail.com> References: <15939.1186.740282.835568@tade.bendor.com.au> <20030208092743.3DE7.SUXEN_DROL@hotmail.com> Message-ID: <15940.14160.440575.745663@tade.bendor.com.au> Hi, Thanks for the help! > > I have to write a bitstream encoder. I use the XviD decoder for > ____^^^^^^^ > > who is forcing you? > and what do you mean by bitstream encoder? ie. are you implementing your > own bistream routines (putbits,etc.), or writing a mpeg video encoder > from scratch. The force behind it is work, an MPEG4 encoder chip needs a C model before it is cut into silicon. At the end the whole code will be thrown away but the HW implementation will be designed by modeling what the SW does and it will be tested against the C code. The encoder gets the quantised DCT coefficients and the motion vectors as well as all the necessary information about frame and MB type. (These are working on silicon already.) From that it has to create a properly formed MPEG4 stream. Due to the limits of the HW not everything has to be implemented, no quarter pixel, vectors are all [-32,31], no quadrant motion, only forward/backward vectors and so on. Code efficiency is not a constraint, simplicity is. The code has to be written in a way that keeps the differences between HW and SW implementations in mind. > b-vops are very similar to p-vops; the major differences: > * macroblock mode/cbp vlcs It is OK and XviD decodes them properly. > * motion vectors stored differently (thus compensation performed > differently) This might be something I do wrong, actually I am sure that that's where the major problem is. My motion vectors are always in the [-32,31] range, fcode is always 1. Only forward or backward vector is used, none of the other methods available for B frames. Only one vector per macroblock, no quadrants. I use the exact same encoder (and predictor) what I use for the P frames and that might be the heart of the problem. I do not want to break the list ethics, but if it is OK, I can attach a (reasonably small) .tar.gz file with the 3 test frames and the result frames. Maybe someone who was working a lot with B frames looks at them and recognises the problem immediately and can tell me me what part of the standard I missed or misinterpreted. The images are small, 320x240 in PPM format, mostly black so they compress very well. Also, when I generate the bitstream I also create a bitstream debug file which looks like this: ... 116392 VOP header --------------------- 0000_0000_0000_0000_0000_0001_1011_0110 116424 B frame ------------------------ 10 116426 Modulo Time Base --------------- 0 116427 Marker ------------------------- 1 116428 Time increment B --------------- 0000_1 116433 Marker ------------------------- 1 116434 VOP coded ---------------------- 1 116435 Ftype DC VLC threshold --------- 000 116438 Scale -------------------------- 1000_0 116443 Motion pred. f_code_forward ---- 001 116446 Motion pred. f_code_backward --- 001 116449 Modb = mb_type + cbpb ---------- 00 116451 MB type backward --------------- 001 116454 CBPB --------------------------- 0001_00 116460 DBquant ------------------------ 0 116461 Motion vector ------------------ 1 116462 Motion vector ------------------ 1 116463 Escape ------------------------- 0000_011 116470 Esc-3 -------------------------- 11 116472 Last --------------------------- 1 116473 Run ---------------------------- 0000_00 116479 Marker ------------------------- 1 116480 Signed level ------------------- 0000_0011_1111 116492 Marker ------------------------- 1 116493 Skipping B for skipped P ------- 116493 Skipping B for skipped P ------- ... which I could supply. However, I think the problem is the formation and interpretation of the vectors. XviD remains in sync with the bitstream. Thus, I think, syntactically the bitstream is OK, it is the actual values that it encodes which are incorrect. > * co-located block skipping semantics Well, with that I have also some problems. According to the standard MB-s that were not encoded in the last P frame should be skipped in all B-s that have that P as backward reference. I have to apologise for the long ASCII art, but here is a testcase. My test image is a 16x16 square moving by 8,8 in every frame. In the ASCII a macroblock is 4x4 chars. The frame sequence is I1 b0 P3 B2 P5 B4 I7 B6 P9 B8 ... where b0 is thrown away. ####.... I1 ####.... ####.... ####.... ........ ........ ........ ........ ........ P3, the square moved 16 pixels ........ ........ ........ ....#### ....#### ....#### ....#### ........ The B between the two. The top right and bottom ........ left of the square are missing because those ..##.... macroblocks were not encoded in the P and hence ..##.... they are not encoded in the B either, even though ....##.. they changed. ....##.. ........ ........ In addition, the standard (and the XviD code as well), explicitly refers to the last P frame and not the last reference frame. Therefore, in this frame sequence I1 b0 P3 B2 P5 B4 I7 B6 P9 B8 when B4 (displayed between P3 and P5) is encoded, its skip map is derived from P5. However, when B6 (that in display order is between P5 and I7) is encoded its skip map is still derived from P5, that is, its forward reference frame instead of its backward one, because P5 was the last *P* frame received. I don't know if I misinterpreted the standard really badly or it is indeed the case. Thanks in advance, Zoltan From chl at math.uni-bonn.de Sat Feb 8 01:14:20 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sat Feb 8 01:14:22 2003 Subject: [XviD-devel] B frame help In-Reply-To: <15940.14160.440575.745663@tade.bendor.com.au> Message-ID: On Sat, 8 Feb 2003, Zoltan Kocsi wrote: > > * co-located block skipping semantics > > Well, with that I have also some problems. > According to the standard MB-s that were not encoded in the last P If "last"="last in encoding order", then yes. If "last"="last in viewing order", then no, then it has to be "next". > frame should be skipped in all B-s that have that P as backward > reference. > > I have to apologise for the long ASCII art, but here is a testcase. > My test image is a 16x16 square moving by 8,8 in every frame. In > the ASCII a macroblock is 4x4 chars. > > The frame sequence is I1 b0 P3 B2 P5 B4 I7 B6 P9 B8 ... where b0 is > thrown away. > > ####.... I1 > ####.... > ####.... > ####.... > ........ > ........ > ........ > ........ > > ........ P3, the square moved 16 pixels > ........ > ........ > ........ > ....#### > ....#### > ....#### > ....#### > > ........ The B between the two. The top right and bottom > ........ left of the square are missing because those > ..##.... macroblocks were not encoded in the P and hence > ..##.... they are not encoded in the B either, even though > ....##.. they changed. > ....##.. > ........ > ........ You're right on this one. MPEG-4 sucks, doesn't it? There are two known solutions: 1) Do not use not_coded blocks for co-located blocks if intermediate blocks should not be skipped (computationally expensive and also ugly). 2) Use S(GMC)-VOPs instead of P-VOPs, but most likely you don't support those. > In addition, the standard (and the XviD code as well), explicitly refers > to the last P frame and not the last reference frame. _That_ I believe is either a mistake in the standard or in your interpretation. B-frame encoding usually speaks about "co-located" block, and that is either in backwards P- or I-frame, but never in the past and never further in the future. gruel From ed.gomez at free.fr Sat Feb 8 01:14:39 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sat Feb 8 01:14:46 2003 Subject: [XviD-devel] MacOSX developers needed Message-ID: <20030208001439.GA593@leloo> Hello, my work on 0.9.1 tree is nearly finished now. However i would like the MacOSX part to be working for this release. So i need the help from people who know how to build dynlibs on this system. Basically, the ./configure script is configuring the sources with that (i added an option --disable-assembly in order to avoid gcc clash on ppc assembly): FEATURES= ARCHITECTURE=-DARCH_IS_GENERIC BUS=-DARCH_IS_32BIT ENDIANNESS=-DARCH_IS_BIG_ENDIAN CFLAGS=$(ARCHITECTURE) $(BUS) $(ENDIANNESS) $(FEATURES) -Wall -O2 -fPIC \ -fomit-\frame-pointer -ffast-math -funroll-loops -fschedule-insns \ -fschedule-insns2 SHARED_EXTENSION=dylib STATIC_EXTENSION=a OBJECT_EXTENSION=o OS_LDFLAGS=-dynamiclib And the final linking stage uses: $(STATIC_LIB): $(OBJECTS) ar rc $(STATIC_LIB) $(OBJECTS) $(SHARED_LIB): $(OBJECTS) $(CC) $(LDFLAGS) $(OBJECTS) -o $(SHARED_LIB) $(OS_LDFLAGS) But i obtain that errors: ld: common symbols not allowed with MH_DYLIB output format ../../src/quant/quant_mpeg4.o definition of common _dequant4_inter (size4) ../../src/quant/quant_mpeg4.o definition of common _dequant4_intra (size4) ../../src/quant/quant_h263.o definition of common _dequant_inter (size4) ../../src/quant/quant_h263.o definition of common _dequant_intra (size4) ../../src/utils/emms.o definition of common _emms (size 4) ../../src/dct/idct.o definition of common _idct (size 4) ../../src/image/interpolate8x8.o definition of common _interpolate8x8_halfpel_h (size 4) ../../src/image/interpolate8x8.o definition of common _interpolate8x8_halfpel_hv (size 4) ../../src/image/interpolate8x8.o definition of common _interpolate8x8_halfpel_v (size 4) ../../src/utils/mem_transfer.o definition of common _transfer8x8_copy (size 4) ../../src/utils/mem_transfer.o definition of common _transfer_16to8add (size 4) ../../src/utils/mem_transfer.o definition of common _transfer_16to8copy (size 4) ../../src/motion/motion_est.o definition of common _Halfpel8_Refine (size 4) ../../src/bitstream/cbp.o definition of common _calc_cbp (size 4) ../../src/motion/sad.o definition of common _dev16 (size 4) [...] /usr/bin/libtool: internal link edit command failed make: *** [libxvidcore.dylib] Error 1 I wonder why the linker is complaining about common definitions of these symbols. As we all (should) know, the code is error free (of this kind at least) for ages. So what i am supposed to do to avoid these errors. PS: the tested platform is the macosx server edition on sourceforge compile farm. bash-2.05a$ uname -a Darwin usf-cf-ppc-macosx-1 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 PDT 2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC Power Macintosh powerpc -- Edouard Gomez -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030208/e02ba701/attachment.bin From chl at math.uni-bonn.de Sat Feb 8 01:16:42 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sat Feb 8 01:16:44 2003 Subject: [XviD-devel] B frame help In-Reply-To: <15940.14160.440575.745663@tade.bendor.com.au> Message-ID: On Sat, 8 Feb 2003, Zoltan Kocsi wrote: > This might be something I do wrong, actually I am sure that that's > where the major problem is. My motion vectors are always in the > [-32,31] range, fcode is always 1. Only forward or backward vector > is used, none of the other methods available for B frames. Only one > vector per macroblock, no quadrants. > > I use the exact same encoder (and predictor) what I use for the > P frames and that might be the heart of the problem. I do not want > to break the list ethics, but if it is OK, I can attach a (reasonably > small) .tar.gz file with the 3 test frames and the result frames. > Maybe someone who was working a lot with B frames looks at them > and recognises the problem immediately and can tell me me what > part of the standard I missed or misinterpreted. The images > are small, 320x240 in PPM format, mostly black so they compress > very well. Also, when I generate the bitstream I also create a > bitstream debug file which looks like this: Maybe a predictor problem? Those happen easily, because MV prediction is slightly different than for P-frames. gruel From ed.gomez at free.fr Sat Feb 8 01:30:32 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sat Feb 8 01:30:39 2003 Subject: [XviD-devel] Latest source location In-Reply-To: <20030208001439.GA593@leloo> References: <20030208001439.GA593@leloo> Message-ID: <20030208003032.GB593@leloo> Hmmm, as i don't want to introduce regressions into CVS, I am maintaining my separated tree until i get all things fixed, you can find my latest sources there: http://ed.gomez.free.fr/ -- Edouard Gomez -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030208/e6975d9f/attachment.bin From walken at zoy.org Fri Feb 7 16:55:30 2003 From: walken at zoy.org (Michel LESPINASSE) Date: Sat Feb 8 01:56:24 2003 Subject: [XviD-devel] Illegal attachment type found in sent message "Re:skal,the Garden of Eden" In-Reply-To: <1044610729.1467.5.camel@latitude344> References: <20030205183413.24830.qmail@planet-d.net> <1044610729.1467.5.camel@latitude344> Message-ID: <20030208005530.GA12023@zoy.org> On Fri, Feb 07, 2003 at 10:38:49AM +0100, skal wrote: > (btw: Hi Walken!! Nice to have you lurking on this ML:)) Hi Skal :) How did you know I was here ? Heard from Tchi lately ? Cheers, -- Michel "Walken" LESPINASSE Is this the best that god can do ? Then I'm not impressed. From suxen_drol at hotmail.com Sat Feb 8 13:13:53 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Sat Feb 8 03:14:01 2003 Subject: [XviD-devel] Latest source location In-Reply-To: <20030208003032.GB593@leloo> References: <20030208001439.GA593@leloo> <20030208003032.GB593@leloo> Message-ID: <20030208130410.7B5E.SUXEN_DROL@hotmail.com> On Sat, 8 Feb 2003 01:30:32 +0100 Edouard Gomez wrote: > Hmmm, as i don't want to introduce regressions into CVS, I am > maintaining my separated tree until i get all things fixed, you can find > my latest sources there: > > http://ed.gomez.free.fr/ there is a typo in configure.in for cygwin/mingw32 targets: [[cC]][[yY]][[gG]][[wW]][[iI]][[nN]]|mingw32|mks) AC_MSG_RESULT([-shared -Wl,--dll,--out-implib,\$@.a]) OS_LDFLAGS="-shared -Wl,--dll,--out-implib,\$@.a libxvidcore.def" - CFLAGS="-mno-cygwin" + CFLAGS=CFLAGS" -mno-cygwin" ;; darwin*|raphsody*) i get the following warnings, but libxvidcore compiles & runs fine: configure:3802: WARNING: stdio.h: present but cannot be compiled configure:3804: WARNING: stdio.h: check for missing prerequisite headers? configure:3806: WARNING: stdio.h: proceeding with the preprocessor's result configure:3802: WARNING: signal.h: present but cannot be compiled configure:3804: WARNING: signal.h: check for missing prerequisite headers? configure:3806: WARNING: signal.h: proceeding with the preprocessor's result btw, are people happy typing in "cd build/generic", or should the ./configure stuff be placed in xvidcore/ root? (i opt for the later) -- pete; life is like a box of ammo From guillaume at morinfr.org Sat Feb 8 03:33:15 2003 From: guillaume at morinfr.org (Guillaume Morin) Date: Sat Feb 8 03:33:10 2003 Subject: [XviD-devel] Latest source location In-Reply-To: <20030208130410.7B5E.SUXEN_DROL@hotmail.com> References: <20030208001439.GA593@leloo> <20030208003032.GB593@leloo> <20030208130410.7B5E.SUXEN_DROL@hotmail.com> Message-ID: <20030208023315.GB538@siri> Dans un message du 08 Feb ? 13:13, suxen_drol ?crivait : > there is a typo in configure.in for cygwin/mingw32 targets: > > [[cC]][[yY]][[gG]][[wW]][[iI]][[nN]]|mingw32|mks) > AC_MSG_RESULT([-shared -Wl,--dll,--out-implib,\$@.a]) > OS_LDFLAGS="-shared -Wl,--dll,--out-implib,\$@.a libxvidcore.def" > - CFLAGS="-mno-cygwin" > + CFLAGS=CFLAGS" -mno-cygwin" > ;; > darwin*|raphsody*) It should be CFLAGS="$CFLAGS -mno-cygwin" > i get the following warnings, but libxvidcore compiles & runs fine: > configure:3802: WARNING: stdio.h: present but cannot be compiled > configure:3804: WARNING: stdio.h: check for missing prerequisite headers? > configure:3806: WARNING: stdio.h: proceeding with the preprocessor's result > configure:3802: WARNING: signal.h: present but cannot be compiled > configure:3804: WARNING: signal.h: check for missing prerequisite headers? > configure:3806: WARNING: signal.h: proceeding with the preprocessor's result Try the line above, it should fix that problem. -- Guillaume Morin I love you, I love you like a chocolate cake, like the trains, like the sea. See me loving you, please. (Dionysos) From radoslaw at syskin.cjb.net Sat Feb 8 19:54:52 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Sat Feb 8 10:23:37 2003 Subject: [XviD-devel] B frame help In-Reply-To: <15940.14160.440575.745663@tade.bendor.com.au> References: <15939.1186.740282.835568@tade.bendor.com.au> <20030208092743.3DE7.SUXEN_DROL@hotmail.com> <15940.14160.440575.745663@tade.bendor.com.au> Message-ID: <75689942.20030208195452@syskin.cjb.net> Hello Zoltan, > only forward/backward vectors You can skip B-frames if you don't intend to use direct mode... they will always be inferior compared to P-frames. B-frames are only better because of direct mode. > > * motion vectors stored differently (thus compensation performed > > differently) > I use the exact same encoder (and predictor) what I use for the > P frames and that might be the heart of the problem. It sure is :) Predictor is 'last encoded vector for this MB type' and it's set to zero at left boundary. It's very similar to p-frame predictor in mpeg1/2. Also remeber that if in future P-frame macroblock is not coded, it's completely ignored in b-frames for which it would be future reference. It is decoded as forward with 0,0 vector then. Best regards, Radek From radoslaw at syskin.cjb.net Sat Feb 8 20:15:09 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Sat Feb 8 10:44:02 2003 Subject: [XviD-devel] VHQ mode decision/ motion search - first results Message-ID: <1101907052.20030208201509@syskin.cjb.net> Hi everyone. I've been working on so-called 'VHQ mode decision" recently. You know what? It's beautiful. However, I not only do mode decision, but also a motion search. It's a second step search, after normal ME and currently consists of square and refinement. I compare vectors by computing exact number of bits needed for DCT data + vector. It doesn't include MODE nor CBP yet. My code doesn't support INTER4V mode yet, so it's far from being perfect. Some results. Compared at quant 2 against 'normal' search (with inter4v disabled to be fair) P-frames alone - filesize gain ~4%, PSNR loose ~0.1dB. with B-frames (@ q4) - filesize gain ~6%, PSNR... well unknown :P This is all with a single clip, quite a long one. It contains fades, but doesn't really contain any room for INTRA macroblocks. Again, 'real life' should work even better. The speed is decimated by 2 with qpel and by 3 without qpel... but it doesn't contain any optimizations yet, and actually does some things when it's not neccessary (such as SAD-based qpel refinement is followed by DCT-based qpel refinement... blah). Now, I have questions/favours to ask. 1. we need a name for it :P there should be 3 flags - one turns this thing on, second also makes subpel refinement in dct domain, third also does diamond-search in dct domain. 2. can anyone help me with _exact_ number of bits needed to code mode and cbp? I'm a bit confused about cbp, some strange things are done with it before putting into bitstream... same with mode. 3.. no there is no 3 yet. Some things are really needed to be asm optimized - but not yet. 4. does someone know how INTRA blocks are done in ffmpeg? The problem is AC/DC prediction. To make the prediction decision, neighbouring blocks's DCT needs to be known. Do they store it? Or maybe they code the macroblock right after it's motion estimated? We can't do the last thing because of GMC. I currently just use zigzag scan for intra check. From chl at math.uni-bonn.de Sat Feb 8 11:10:08 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sat Feb 8 11:10:11 2003 Subject: [XviD-devel] B frame help In-Reply-To: <75689942.20030208195452@syskin.cjb.net> Message-ID: On Sat, 8 Feb 2003, Radek Czyz wrote: > Hello Zoltan, > > > only forward/backward vectors > > You can skip B-frames if you don't intend to use direct mode... they > will always be inferior compared to P-frames. > B-frames are only better because of direct mode. Radek's right in this. Also, since you don't support QPel or GMC anyway, if you also drop B-frames the whole encoder and decoder will be easier and faster, and have at least a small chance to be MPEG-4 compliant (Simple Profile)... gruel From chl at math.uni-bonn.de Sat Feb 8 11:28:32 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sat Feb 8 11:28:35 2003 Subject: [XviD-devel] VHQ mode decision/ motion search - first results (fwd) Message-ID: On Sat, 8 Feb 2003, Radek Czyz wrote: > Now, I have questions/favours to ask. > 1. we need a name for it :P there should be 3 flags - one turns this > thing on, second also makes subpel refinement in dct domain, third > also does diamond-search in dct domain. DCT-Mode decision is a "general" flag, I guess... maybe XVID_MODEDECISION_DCT in contrast to other future (and maybe faster) heuristic XVID_MODEDECISION_XXX flags? For refinement, we currently have PMV_HALFPELREFINE[16/8] and PMV_QUARTERPELREFINE[16/8] so (if 16/8 is possible at all), then how about PMV_HALFPELREFINE_DCT[16/8] and PMV_QUARTERPELREFINE_DCT[16/8] ? For search? Hm, new flags SAD_MODE_DCT ? Which can be parallel to SAD_MODE_SAD, SAD_MODE_SSE, SAD_MODE_HADAMARD, or similar? ffmpeg has three numerical fields for this: precmp, cmp, subcmp for a presearch-step, the search itself and the subpel-refinement step. However, I believe we can restrict ourselves to do search itself with SAD (or maybe SSE for anime), but use "more intelligent" modes only for refinement... gruel From radoslaw at syskin.cjb.net Sat Feb 8 21:33:28 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Sat Feb 8 12:02:33 2003 Subject: [XviD-devel] VHQ mode decision/ motion search - first results In-Reply-To: <1101907052.20030208201509@syskin.cjb.net> References: <1101907052.20030208201509@syskin.cjb.net> Message-ID: <36605958.20030208213328@syskin.cjb.net> Lo, I knew I'll forget something 5. Who feels like writing quantization functions which not only return sum of coefficients, but also the sum of quantization errors? It could be useful here. Radek From chl at math.uni-bonn.de Sat Feb 8 12:11:27 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sat Feb 8 12:11:31 2003 Subject: [XviD-devel] VHQ mode decision/ motion search - first results In-Reply-To: <36605958.20030208213328@syskin.cjb.net> Message-ID: On Sat, 8 Feb 2003, Radek Czyz wrote: > Lo, > > I knew I'll forget something > > 5. Who feels like writing quantization functions which not only > return sum of coefficients, but also the sum of quantization errors? > It could be useful here. Hm, shouldn't that be another routine? You need to de-quantizae for this. Maybe there is a small speedup when one routine does both, but in general, I think it's better to simply create a wrapper Quant/Dequant/SSE of results until we are really in a need for speed... gruel From chl at math.uni-bonn.de Sat Feb 8 14:55:19 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sat Feb 8 14:55:24 2003 Subject: [XviD-devel] DivX5.03 rounding? In-Reply-To: Message-ID: On Thu, 6 Feb 2003, Christoph Lampert wrote: > > > > That's OK, we do it in 8x8 as well. MODE_DIRECT_NO4V is not set in > > qpel mode, so motion compensation to be performed on 8x8 blocks. > > Ahhh... that's tricky! Of course I just read the "switch" and thought > DIRECT_NO4V was set. > > Is decoder doing this as well? There is a call in bf_interpolate_mbinter() > > if(dec->quarterpel) { > if((pMB->mode == MODE_INTER || pMB->mode == MODE_INTER_Q)) > interpolate16x16_quarterpel(dec->cur.y,forwar...) > else { > interpolate8x8_quarterpel(...) > interpolate8x8_quarterpel(...) > ... > } Okay, I found it. For pMB->mode is never MODE_INTER, because it's hardcoded to MODE_INTER4V before calling of the routine. So once again, XVID does it right, and the other ones don't. gruel From chl at math.uni-bonn.de Sat Feb 8 14:59:45 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sat Feb 8 14:59:48 2003 Subject: [XviD-devel] VHQ mode decision/ motion search - first results In-Reply-To: <1101907052.20030208201509@syskin.cjb.net> Message-ID: On Sat, 8 Feb 2003, Radek Czyz wrote: > P-frames alone - filesize gain ~4%, PSNR loose ~0.1dB. > with B-frames (@ q4) - filesize gain ~6%, PSNR... well unknown :P xvid_bstat.c in examples dir does PSNR for bframes as well. It's plain ugly, but it works. gruel From suxen_drol at hotmail.com Sun Feb 9 04:06:09 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Sat Feb 8 18:06:12 2003 Subject: [XviD-devel] hq ac prediction mode Message-ID: <20030209034459.6837.SUXEN_DROL@hotmail.com> hi, i implemented a new ac prediction calculation method, which considers actual coefficient cost (bits), as ooposed to the present coeff sum method. it reduces file sizes a little, though nothing significant. 640x256, 500 consecutive i-frames | b y t e s quant | coeff bitstrema saving | sum sum --------+------------------------------------------------------ q=2 | 8,105,984 7,938,048 167,936 (2.07%) q=3 | 5,941,248 5,814,272 126,976 (2.14%) q=4 | 4,812,800 4,718,592 94,208 (1.96%) q=8 | 2,865,152 2,813,952 51,200 (1.79%) 640x256, 500 frames (~10 i-frames, 490 p-frames) | bytes quant | coeff bitstrema | sum sum --------+--------------------------------- q=2 | 2,187,264 2,183,168 q=3 | 1,519,616 1,515,520 q=4 | 1,105,920 1,103,872 q=8 | 561,152 559,104 should i clean it up with a XVID_HQACPRED flag, and commit? -- pete From chl at math.uni-bonn.de Sat Feb 8 18:54:16 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sat Feb 8 18:54:20 2003 Subject: [XviD-devel] hq ac prediction mode In-Reply-To: <20030209034459.6837.SUXEN_DROL@hotmail.com> Message-ID: On Sun, 9 Feb 2003, suxen_drol wrote: > > hi, > > i implemented a new ac prediction calculation method, which considers > actual coefficient cost (bits), as ooposed to the present coeff sum > method. it reduces file sizes a little, though nothing significant. > > 640x256, 500 consecutive i-frames > | b y t e s > quant | coeff bitstrema saving > | sum sum > --------+------------------------------------------------------ > q=2 | 8,105,984 7,938,048 167,936 (2.07%) > q=3 | 5,941,248 5,814,272 126,976 (2.14%) > q=4 | 4,812,800 4,718,592 94,208 (1.96%) > q=8 | 2,865,152 2,813,952 51,200 (1.79%) > > > 640x256, 500 frames (~10 i-frames, 490 p-frames) > | bytes > quant | coeff bitstrema > | sum sum > --------+--------------------------------- > q=2 | 2,187,264 2,183,168 > q=3 | 1,519,616 1,515,520 > q=4 | 1,105,920 1,103,872 > q=8 | 561,152 559,104 > > should i clean it up with a XVID_HQACPRED flag, and commit? Sure... how was speed? gruel From chl at math.uni-bonn.de Sat Feb 8 19:20:18 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sat Feb 8 19:20:22 2003 Subject: [XviD-devel] Watcom compiler Message-ID: Hi, does XVID compile with OpenWatcom? ftp://ftp.openwatcom.org/watcom/readme.txt gruel From ed.gomez at free.fr Sun Feb 9 02:05:12 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sun Feb 9 02:05:24 2003 Subject: [XviD-devel] XviD core 0.9.1 WIP Message-ID: <20030209010512.GA7837@leloo> Hello, I've been fixing lot of small details today, there are only 2 items on the ToDo list but they are affecting less than 0.01% of users' base (ia64 and powerpc). ia64 will be fixed tomorrow, and ppc support will probably be disabled (just plain C sources) because the assembly files need to be updated. I'm now happy with the new build system, so I think i'll start merging my work into CVS tomorrow. That's why I would like you to test my personnal tarballs so i could fix last things tomorrow afternoon (GMT+1 time). You can find my last working tarballs there: http://ed.gomez.free.fr/ -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030209/76a0d312/attachment.bin From ed.gomez at free.fr Sun Feb 9 02:11:04 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sun Feb 9 02:11:11 2003 Subject: [XviD-devel] Watcom compiler In-Reply-To: References: Message-ID: <20030209011104.GB7837@leloo> Christoph Lampert (chl@math.uni-bonn.de) wrote: > Hi, > > does XVID compile with OpenWatcom? > > ftp://ftp.openwatcom.org/watcom/readme.txt I'm pretty sure XviD 0.9.x tree will compile because it's pure ANSI C. Btw, this compiler will probably need another Makefile because watcom probably ships its own make implementation and so on. But with a bit of work, yes it should compile. -- Edouard Gomez -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030209/c4c2883d/attachment.bin From walawala5 at hotmail.com Sun Feb 9 14:48:30 2003 From: walawala5 at hotmail.com (wai sze) Date: Sun Feb 9 07:49:12 2003 Subject: [XviD-devel] Ask for help Message-ID: I have read the following site http://list.xvid.org/pipermail/xvid-devel/2002-September/000787.html which is written by you. I would like to ask about the header file that the page include. Where to get the atlimage.h so that I can implement the CImage class Thank you very much for your attention and looking forward to your kind reply. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030209/2d528121/attachment.htm From suxen_drol at hotmail.com Sun Feb 9 17:55:48 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Sun Feb 9 07:55:50 2003 Subject: [XviD-devel] hq ac prediction mode In-Reply-To: References: <20030209034459.6837.SUXEN_DROL@hotmail.com> Message-ID: <20030209175013.A9EA.SUXEN_DROL@hotmail.com> On Sat, 8 Feb 2003 18:54:16 +0100 (CET) Christoph Lampert wrote: > On Sun, 9 Feb 2003, suxen_drol wrote: > > > > > hi, > > > > i implemented a new ac prediction calculation method, which considers > > actual coefficient cost (bits), as ooposed to the present coeff sum > > method. it reduces file sizes a little, though nothing significant. > > > > 640x256, 500 consecutive i-frames > > | b y t e s > > quant | coeff bitstrema saving > > | sum sum > > --------+------------------------------------------------------ > > q=2 | 8,105,984 7,938,048 167,936 (2.07%) > > q=3 | 5,941,248 5,814,272 126,976 (2.14%) > > q=4 | 4,812,800 4,718,592 94,208 (1.96%) > > q=8 | 2,865,152 2,813,952 51,200 (1.79%) > > > > > > 640x256, 500 frames (~10 i-frames, 490 p-frames) > > | bytes > > quant | coeff bitstrema > > | sum sum > > --------+--------------------------------- > > q=2 | 2,187,264 2,183,168 > > q=3 | 1,519,616 1,515,520 > > q=4 | 1,105,920 1,103,872 > > q=8 | 561,152 559,104 > > > > should i clean it up with a XVID_HQACPRED flag, and commit? > commited. to enable hq acpred use: xframe.general |= XVID_HQACPRED; > Sure... how was speed? for short sequences (500-1000frames) its unnoticble. obviously that will depend on how many iframes are present in the sequence. i will perform some more extensive testing tonight. -- pete; life is like a box of ammo From suxen_drol at hotmail.com Sun Feb 9 18:03:59 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Sun Feb 9 08:04:03 2003 Subject: [XviD-devel] Ask for help In-Reply-To: References: Message-ID: <20030209175751.A9ED.SUXEN_DROL@hotmail.com> On Sun, 9 Feb 2003 14:48:30 +0800 "wai sze" wrote: > I have read the following site > http://list.xvid.org/pipermail/xvid-devel/2002-September/000787.html > which is written by you. > I would like to ask about the header file that the page include. > Where to get the atlimage.h so that I can implement the CImage class > > Thank you very much for your attention and looking forward to your kind reply. atl = advanced template library; atl*.h should come default with microsoft visual c/net the CImage class is only used to read the image pixel array from a file. you could get the same results by freading from a pgm/raw file. -- pete From chl at math.uni-bonn.de Sun Feb 9 13:53:18 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sun Feb 9 13:53:25 2003 Subject: [XviD-devel] DivX5 compatibe API Message-ID: Should XVID get an DivX5 compatible API (like divx4.h)? gruel From chl at math.uni-bonn.de Sun Feb 9 19:02:55 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sun Feb 9 19:03:02 2003 Subject: [XviD-devel] OpenMP parallelization Message-ID: Hi, what would you think of OpenMP parallelism instead of pthread-Multithreading? Does VisualC++ suport this (yeah, I know, of course not). There is something call Omni OpenMP for cygwin and other projects, I never heard of. icc for Linux does support openMP, so maybe Windows version does, too. And there might be some modification of gcc that does, but I didn't find it. For those who haven't met openMP: It's a "trick" to tell the compiler which parts of a program can be multithreaded by #pragma 's in the code. If the compiler doesn't know about openMP, it ignores the statements. If it does, it creates multithreaded code and does parts of the code in parallel: http://beowulf.lcs.mit.edu/18.337/beowulf.html#OMPE gruel From elcabesa at inwind.it Sun Feb 9 19:59:47 2003 From: elcabesa at inwind.it (Marco "elcabesa" Belli) Date: Sun Feb 9 20:02:33 2003 Subject: [XviD-devel] xvid 2 pass -mplayer bug Message-ID: <200302091959.47174.elcabesa@inwind.it> i have found a bug inside xvid or mplayer that make mplayer crash using 2 pass and lumi_mask. since ed gom read this forum and he makde the xvid_vbr.c file of mplayer i'm posting here the bug mplayer 2 pass ocde inside static int vbr_getquant_2pass2(void *sstate) make quant not able to change more than two form previous frame if(state->last_quant && capped_to_max_framesize == 0) { if (quant > state->last_quant + 2) { quant = state->last_quant + 2; } if (quant < state->last_quant - 2) { quant = state->last_quant - 2; } } } return(quant); but quant that mplayer give to xvid is changed by dapt_quant pEnc->current->quant = adaptive_quantization(pEnc->current->image.y, pEnc->mbParam.edged_width, temp_dquants, pEnc->current->quant, pEnc->current->quant, 2 * pEnc->current->quant, pEnc->mbParam.mb_width, pEnc->mbParam.mb_height); this is what happen mplayer set quant 4 xvid lumi_mask adapt quant change it to 10 mplayer get last_quant by xvid =10 then mplayer give a new quant ., it choose 5 but then it MUST CHANGE it to 8 xvid lumi mask adapt it to 15 mplayer try to lower it but it can laso do 13 ... etc etc if there are more than 80 -90 black frames.. mencoder simply crash byee please tell me how to fix it do you prefere limit lumi_mask power or xvid_vbr module? From ed.gomez at free.fr Sun Feb 9 20:04:18 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sun Feb 9 20:04:26 2003 Subject: [XviD-devel] hq ac prediction mode In-Reply-To: <20030209034459.6837.SUXEN_DROL@hotmail.com> References: <20030209034459.6837.SUXEN_DROL@hotmail.com> Message-ID: <20030209190418.GA920@leloo> Very basic test with "Le fabuleux destin d'Amelie Poulain" First 10000 frames sequence (frames resized to 640x272) Quantizer | Size | Options ----------+----------+--------------------------------------------------------------- q3 81223900 base options q3 80142222 base options + PMV_CHROMA16 + PMV_CHROMA8 q3 81110018 base options + HQ acdc prediction q3 79989286 base options + PMV_CHROMA16 + PMV_CHROMA8 + HQ acdc prediction It saves 0.15% for non chromaME and 0.19% for chromaME while just using chromaME can save 1.3% base options are: [export_xvidcvs.so] Constant Quantizer: 3 [export_xvidcvs.so] Max keyframe Interval: 250 [export_xvidcvs.so] Max BFrame Sequence: 1 [export_xvidcvs.so] BFrame Quant Ratio: 150 [export_xvidcvs.so] BFrame Quant Offset: 100 [export_xvidcvs.so] Motion Flags: PMV_ADVANCEDDIAMOND8 PMV_ADVANCEDDIAMOND16 PMV_HALFPELREFINE16 PMV_EXTSEARCH16 PMV_HALFPELREFINE8 [export_xvidcvs.so] Global Flags: [export_xvidcvs.so] General Flags: XVID_H263QUANT XVID_HALFPEL XVID_INTER4V -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030209/9d49f3c5/attachment.bin From chl at math.uni-bonn.de Sun Feb 9 20:25:51 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sun Feb 9 20:25:53 2003 Subject: [XviD-devel] hq ac prediction mode In-Reply-To: <20030209190418.GA920@leloo> Message-ID: On Sun, 9 Feb 2003, Edouard Gomez wrote: > Very basic test with "Le fabuleux destin d'Amelie Poulain" > > First 10000 frames sequence (frames resized to 640x272) > > Quantizer | Size | Options > ----------+----------+--------------------------------------------------------------- > q3 81223900 base options > q3 80142222 base options + PMV_CHROMA16 + PMV_CHROMA8 > q3 81110018 base options + HQ acdc prediction > q3 79989286 base options + PMV_CHROMA16 + PMV_CHROMA8 + HQ acdc prediction > > It saves 0.15% for non chromaME and 0.19% for chromaME while > just using chromaME can save 1.3% Oh well, better than nothing, isn't it? 0.19% on a full CD is 1.4 MB, sometimes that's just what's missing to fit on a CD-R ;-) gruel P.S. Btw. Chroma_ME. Does anyone know _why_ chroma ME has such a positive effect? Is it really the chromanance bits, or is it rather that search doesn't terminate as early? Or is the result closer to "real motion" , so motion field get smoother? From ed.gomez at free.fr Sun Feb 9 20:39:36 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sun Feb 9 20:39:43 2003 Subject: [XviD-devel] XviD core 0.9.1 WIP In-Reply-To: <20030209010512.GA7837@leloo> References: <20030209010512.GA7837@leloo> Message-ID: <20030209193936.GB920@leloo> Edouard Gomez (ed.gomez@free.fr) wrote: > I'm now happy with the new build system, so I think i'll start merging > my work into CVS tomorrow. Ok, the files and changes have been merged. Now you can't build from CVS anymore, you need at least these tools to generate the build stuff (usually done by the maintainer when it releases a new version) - autoconf >= 2.50 - automake (provides install-sh ...) - libtoolize (provides config.sub config.guess ...) -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030209/37f6b8a4/attachment.bin From chl at math.uni-bonn.de Sun Feb 9 21:00:58 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sun Feb 9 21:01:01 2003 Subject: [XviD-devel] XviD core 0.9.1 WIP In-Reply-To: <20030209193936.GB920@leloo> Message-ID: Hi Gom, compiles well on IRIX 6.3, but another thing: Did you or did I create xvid_encraw.c ? Because it outputs the text messages from xvid_stat with wrong command line options... instead of its own. gruel On Sun, 9 Feb 2003, Edouard Gomez wrote: > Edouard Gomez (ed.gomez@free.fr) wrote: > > I'm now happy with the new build system, so I think i'll start merging > > my work into CVS tomorrow. > > Ok, the files and changes have been merged. Now you can't build from CVS > anymore, you need at least these tools to generate the build stuff > (usually done by the maintainer when it releases a new version) > > - autoconf >= 2.50 > - automake (provides install-sh ...) > - libtoolize (provides config.sub config.guess ...) > > -- > Edouard Gomez From ed.gomez at free.fr Sun Feb 9 21:10:08 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sun Feb 9 21:10:15 2003 Subject: [XviD-devel] XviD core 0.9.1 WIP In-Reply-To: References: <20030209193936.GB920@leloo> Message-ID: <20030209201008.GA13818@leloo> Christoph Lampert (chl@math.uni-bonn.de) wrote: > Did you or did I create xvid_encraw.c ? > Because it outputs the text messages from xvid_stat with > wrong command line options... instead of its own. You created it as you did for other examples, but i think i updated it after xvid_stat and copy/pasted some chunks into xvid_encraw and xvid_decraw. I'll have a look at this. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030209/f913ed64/attachment.bin From chl at math.uni-bonn.de Sun Feb 9 21:21:24 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sun Feb 9 21:21:27 2003 Subject: [XviD-devel] XviD core 0.9.1 WIP In-Reply-To: <20030209201008.GA13818@leloo> Message-ID: On Sun, 9 Feb 2003, Edouard Gomez wrote: > Christoph Lampert (chl@math.uni-bonn.de) wrote: > > Did you or did I create xvid_encraw.c ? > > Because it outputs the text messages from xvid_stat with > > wrong command line options... instead of its own. > > You created it as you did for other examples, but i think i updated it > after xvid_stat and copy/pasted some chunks into xvid_encraw and > xvid_decraw. I'll have a look at this. I just saw, it may only be the name which is outputed. What I thought was a but was that I specified -m0 but it should have been -m 0 gruel From chl at math.uni-bonn.de Sun Feb 9 21:25:42 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sun Feb 9 21:25:45 2003 Subject: [XviD-devel] Watcom compiler In-Reply-To: <20030209011104.GB7837@leloo> Message-ID: On Sun, 9 Feb 2003, Edouard Gomez wrote: > Christoph Lampert (chl@math.uni-bonn.de) wrote: > > Hi, > > > > does XVID compile with OpenWatcom? > > > > ftp://ftp.openwatcom.org/watcom/readme.txt > > I'm pretty sure XviD 0.9.x tree will compile because it's pure ANSI > C. Btw, this compiler will probably need another Makefile because watcom > probably ships its own make implementation and so on. XVID is ANSI C, but I guess only after the compiler passed through portab.h in which it fails e.g. for IRIX cc because the compiler is unknown. It only checks for #if defined(_MSC_VER) #elif defined(__GNUC__) || defined(__ICC) #else # error Do not know how to define (u)int(size)_t types. #endif Although they simply are part of C99 as inttypes.h ! gruel From ptk9417 at ritvax.rit.edu Sun Feb 9 16:33:36 2003 From: ptk9417 at ritvax.rit.edu (ptk9417) Date: Sun Feb 9 22:34:06 2003 Subject: [XviD-devel] MacOSX developers needed In-Reply-To: <20030208001439.GA593@leloo> Message-ID: <2580AF13-3C76-11D7-897C-000393B8DC8A@rit.edu> On Friday, February 7, 2003, at 07:14 PM, Edouard Gomez wrote: > [...] > /usr/bin/libtool: internal link edit command failed > make: *** [libxvidcore.dylib] Error 1 > > I wonder why the linker is complaining about common definitions of > these > symbols. As we all (should) know, the code is error free (of this kind > at least) for ages. So what i am supposed to do to avoid these errors Hello Edouard, Build process looks good on OSX 10.2.3. I had to run ranlib on the static lib befor it can be linked in with something else. But thats normal. Oh.. btw, i follow the bad habit of installing libs into /usr/lib.. I did run into an intresting occurance with the dynamic lib and xvid_bench.. the crc check fails... but only on the quant4* routines. The crc is correct in the output of the static lib. {Dynamic lib build settings} gcc -Wall -I../src/ -DARCH_IS_32BIT -DARCH_IS_BIG_ENDIAN -DARCH_IS_GENERIC xvid_bench.c -o xvid_bench_dyn -lxvidcore ===== test quant ===== PLAINC - quant4_intra 71.314 usec crc=25180 *** CRC ERROR! *** PLAINC - quant4_inter 71.803 usec crc=23407 *** CRC ERROR! *** PLAINC - dequant4_intra 36.953 usec crc=51702 *** CRC ERROR! *** PLAINC - dequant4_inter 46.318 usec crc=59009 *** CRC ERROR! *** PLAINC - quant_intra 28.257 usec crc=25662 PLAINC - quant_inter 28.998 usec crc=23972 PLAINC - dequant_intra 28.794 usec crc=49900 PLAINC - dequant_inter 27.955 usec crc=48899 {Static lib build settings} gcc -Wall -I../src/ -DARCH_IS_32BIT -DARCH_IS_BIG_ENDIAN -DARCH_IS_GENERIC xvid_bench.c -o xvid_bench_stat /usr/lib/libxvidcore.a ===== test quant ===== PLAINC - quant4_intra 71.599 usec crc=29809 PLAINC - quant4_inter 71.075 usec crc=12574 PLAINC - dequant4_intra 35.268 usec crc=24052 PLAINC - dequant4_inter 45.114 usec crc=63847 PLAINC - quant_intra 28.880 usec crc=25662 PLAINC - quant_inter 29.355 usec crc=23972 PLAINC - dequant_intra 28.410 usec crc=49900 PLAINC - dequant_inter 26.987 usec crc=48899 Something to note, When i compile the dynamic xvid_bench i do get a bunch of multiple symbol defenitions warnings.. see below. No warnings appear when compiling against the static lib. [dual:Download/xvidcore/examples] paul% gcc -Wall -I../src/ -DARCH_IS_32BIT -DARCH_IS_BIG_ENDIAN -DARCH_IS_GENERIC xvid_bench_mod.c -o xvid_bench_mod_dyn -lxvidcore ld: warning multiple definitions of symbol _get_intra_matrix_status /var/tmp//cctn8miN.o definition of _get_intra_matrix_status in section (__TEXT,__text) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _get_intra_matrix_status ld: warning multiple definitions of symbol _get_default_inter_matrix /var/tmp//cctn8miN.o definition of _get_default_inter_matrix in section (__TEXT,__text) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _get_default_inter_matrix ld: warning multiple definitions of symbol _get_default_intra_matrix /var/tmp//cctn8miN.o definition of _get_default_intra_matrix in section (__TEXT,__text) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _get_default_intra_matrix ld: warning multiple definitions of symbol _set_inter_matrix /var/tmp//cctn8miN.o definition of _set_inter_matrix in section (__TEXT,__text) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _set_inter_matrix ld: warning multiple definitions of symbol _set_intra_matrix /var/tmp//cctn8miN.o definition of _set_intra_matrix in section (__TEXT,__text) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _set_intra_matrix ld: warning multiple definitions of symbol _get_inter_matrix /var/tmp//cctn8miN.o definition of _get_inter_matrix in section (__TEXT,__text) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _get_inter_matrix ld: warning multiple definitions of symbol _get_inter_matrix_status /var/tmp//cctn8miN.o definition of _get_inter_matrix_status in section (__TEXT,__text) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _get_inter_matrix_status ld: warning multiple definitions of symbol _get_intra_matrix /var/tmp//cctn8miN.o definition of _get_intra_matrix in section (__TEXT,__text) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _get_intra_matrix ld: warning multiple definitions of symbol _custom_inter_matrix /var/tmp//cctn8miN.o definition of _custom_inter_matrix in section (__DATA,__data) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _custom_inter_matrix ld: warning multiple definitions of symbol _custom_intra_matrix /var/tmp//cctn8miN.o definition of _custom_intra_matrix in section (__DATA,__data) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _custom_intra_matrix ld: warning multiple definitions of symbol _default_inter_matrix /var/tmp//cctn8miN.o definition of _default_inter_matrix in section (__DATA,__data) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _default_inter_matrix ld: warning multiple definitions of symbol _default_intra_matrix /var/tmp//cctn8miN.o definition of _default_intra_matrix in section (__DATA,__data) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _default_intra_matrix ld: warning multiple definitions of symbol _inter_matrix /var/tmp//cctn8miN.o definition of _inter_matrix in section (__DATA,__data) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _inter_matrix ld: warning multiple definitions of symbol _inter_matrix_fix /var/tmp//cctn8miN.o definition of _inter_matrix_fix in section (__DATA,__data) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _inter_matrix_fix ld: warning multiple definitions of symbol _intra_matrix /var/tmp//cctn8miN.o definition of _intra_matrix in section (__DATA,__data) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _intra_matrix ld: warning multiple definitions of symbol _intra_matrix_fix /var/tmp//cctn8miN.o definition of _intra_matrix_fix in section (__DATA,__data) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _intra_matrix_fix ld: warning multiple definitions of symbol _set_inter_matrix_status /var/tmp//cctn8miN.o definition of _set_inter_matrix_status in section (__TEXT,__text) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _set_inter_matrix_status ld: warning multiple definitions of symbol _set_intra_matrix_status /var/tmp//cctn8miN.o definition of _set_intra_matrix_status in section (__TEXT,__text) /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of _set_intra_matrix_status Compiling xvid_stat with the same settings, the files outputed are identical for both the raw decoded frames and the m4v when testing with the cactus input images. So this doesn't seem to effect the actual core.. I added some quick print statements to xvid_bench to dump the tables. Below is the output: {Dynamic lib build settings} ===== test quant ===== VVVV quant4_intra - Src VVVV 0: 1 1 -59 -57 -111 -107 -155 -149 1: 1 1 -43 -41 -79 -75 -107 -101 2: 1 1 -27 -25 -47 -43 -59 -53 3: 1 1 -11 -9 -15 -11 -11 -5 4: 1 1 5 7 17 21 37 43 5: 1 1 21 23 49 53 85 91 6: 1 1 37 39 81 85 133 139 7: 1 1 53 55 113 117 181 187 VVVV quant4_intra - Dst VVVV 0: 0 0 -1 -1 -1 -1 -1 -1 1: 0 0 0 0 -1 -1 -1 -1 2: 0 0 0 0 0 0 0 0 3: 0 0 0 0 0 0 0 0 4: 0 0 0 0 0 0 0 0 5: 0 0 0 0 0 0 1 0 6: 0 0 0 0 1 1 1 1 7: 0 0 0 0 1 1 1 1 PLAINC - quant4_intra 70.893 usec crc=25180 *** CRC ERROR! *** VVVV quant4_inter - Src VVVV 0: 1 1 -59 -57 -111 -107 -155 -149 1: 1 1 -43 -41 -79 -75 -107 -101 2: 1 1 -27 -25 -47 -43 -59 -53 3: 1 1 -11 -9 -15 -11 -11 -5 4: 1 1 5 7 17 21 37 43 5: 1 1 21 23 49 53 85 91 6: 1 1 37 39 81 85 133 139 7: 1 1 53 55 113 117 181 187 VVVV quant4_inter - Dst VVVV 0: 0 0 0 0 -1 -1 -1 -1 1: 0 0 0 0 0 0 -1 -1 2: 0 0 0 0 0 0 0 0 3: 0 0 0 0 0 0 0 0 4: 0 0 0 0 0 0 0 0 5: 0 0 0 0 0 0 0 0 6: 0 0 0 0 0 0 1 1 7: 0 0 0 0 1 1 1 1 PLAINC - quant4_inter 71.221 usec crc=23407 *** CRC ERROR! *** VVVV dequant4_intra - Src VVVV 0: 1 1 -59 -57 -111 -107 -155 -149 1: 1 1 -43 -41 -79 -75 -107 -101 2: 1 1 -27 -25 -47 -43 -59 -53 3: 1 1 -11 -9 -15 -11 -11 -5 4: 1 1 5 7 17 21 37 43 5: 1 1 21 23 49 53 85 91 6: 1 1 37 39 81 85 133 139 7: 1 1 53 55 113 117 181 187 VVVV dequant4_intra - Dst VVVV 0: 31 65 -2048 -2048 -2048 -2048 -2048 -2048 1: 65 69 -2048 -2048 -2048 -2048 -2048 -2048 2: 77 81 -2048 -2048 -2048 -2048 -2048 -2048 3: 81 85 -980 -837 -1511 -1193 -1278 -620 4: 85 89 465 705 1844 2047 2047 2047 5: 89 93 2047 2047 2047 2047 2047 2047 6: 96 100 2047 2047 2047 2047 2047 2047 7: 104 108 2047 2047 2047 2047 2047 2047 PLAINC - dequant4_intra 36.623 usec crc=51702 *** CRC ERROR! *** VVVV dequant4_inter - Src VVVV 0: 1 1 -59 -57 -111 -107 -155 -149 1: 1 1 -43 -41 -79 -75 -107 -101 2: 1 1 -27 -25 -47 -43 -59 -53 3: 1 1 -11 -9 -15 -11 -11 -5 4: 1 1 5 7 17 21 37 43 5: 1 1 21 23 49 53 85 91 6: 1 1 37 39 81 85 133 139 7: 1 1 53 55 113 117 181 187 VVVV dequant4_inter - Dst VVVV 0: 93 98 -2048 -2048 -2048 -2048 -2048 -2048 1: 98 104 -2048 -2048 -2048 -2048 -2048 -2048 2: 104 110 -2048 -2048 -2048 -2048 -2048 -2048 3: 110 116 -935 -809 -1381 -1069 -1158 -575 4: 116 122 468 668 1695 2047 2047 2047 5: 122 127 1916 2047 2047 2047 2047 2047 6: 127 133 2047 2047 2047 2047 2047 2047 7: 133 139 2047 2047 2047 2047 2047 2046 PLAINC - dequant4_inter 45.586 usec crc=59009 *** CRC ERROR! *** PLAINC - quant_intra 28.073 usec crc=25662 PLAINC - quant_inter 28.730 usec crc=23972 PLAINC - dequant_intra 28.272 usec crc=49900 PLAINC - dequant_inter 27.530 usec crc=48899 --- MMX - skipped... IA64 - skipped... {Static lib build settings} ===== test quant ===== VVVV quant4_intra - Src VVVV 0: 1 1 -59 -57 -111 -107 -155 -149 1: 1 1 -43 -41 -79 -75 -107 -101 2: 1 1 -27 -25 -47 -43 -59 -53 3: 1 1 -11 -9 -15 -11 -11 -5 4: 1 1 5 7 17 21 37 43 5: 1 1 21 23 49 53 85 91 6: 1 1 37 39 81 85 133 139 7: 1 1 53 55 113 117 181 187 VVVV quant4_intra - Dst VVVV 0: 0 0 0 0 0 0 0 0 1: 0 0 0 0 0 0 0 0 2: 0 0 0 0 0 0 0 0 3: 0 0 0 0 0 0 0 0 4: 0 0 0 0 0 0 0 0 5: 0 0 0 0 0 0 0 0 6: 0 0 0 0 0 0 0 0 7: 0 0 0 0 0 0 0 0 PLAINC - quant4_intra 70.637 usec crc=29809 VVVV quant4_inter - Src VVVV 0: 1 1 -59 -57 -111 -107 -155 -149 1: 1 1 -43 -41 -79 -75 -107 -101 2: 1 1 -27 -25 -47 -43 -59 -53 3: 1 1 -11 -9 -15 -11 -11 -5 4: 1 1 5 7 17 21 37 43 5: 1 1 21 23 49 53 85 91 6: 1 1 37 39 81 85 133 139 7: 1 1 53 55 113 117 181 187 VVVV quant4_inter - Dst VVVV 0: 0 0 0 0 0 0 0 0 1: 0 0 0 0 0 0 0 0 2: 0 0 0 0 0 0 0 0 3: 0 0 0 0 0 0 0 0 4: 0 0 0 0 0 0 0 0 5: 0 0 0 0 0 0 0 0 6: 0 0 0 0 0 0 0 0 7: 0 0 0 0 0 0 0 0 PLAINC - quant4_inter 70.819 usec crc=12574 VVVV dequant4_intra - Src VVVV 0: 1 1 -59 -57 -111 -107 -155 -149 1: 1 1 -43 -41 -79 -75 -107 -101 2: 1 1 -27 -25 -47 -43 -59 -53 3: 1 1 -11 -9 -15 -11 -11 -5 4: 1 1 5 7 17 21 37 43 5: 1 1 21 23 49 53 85 91 6: 1 1 37 39 81 85 133 139 7: 1 1 53 55 113 117 181 187 VVVV dequant4_intra - Dst VVVV 0: 31 988 -2048 -2048 -2048 -2048 -2048 -2048 1: 988 988 -2048 -2048 -2048 -2048 -2048 -2048 2: 988 988 -2048 -2048 -2048 -2048 -2048 -2048 3: 988 988 -2048 -2048 -2048 -2048 -2048 -2048 4: 988 988 2047 2047 2047 2047 2047 2047 5: 988 988 2047 2047 2047 2047 2047 2047 6: 988 988 2047 2047 2047 2047 2047 2047 7: 988 988 2047 2047 2047 2047 2047 2047 PLAINC - dequant4_intra 35.706 usec crc=24052 VVVV dequant4_inter - Src VVVV 0: 1 1 -59 -57 -111 -107 -155 -149 1: 1 1 -43 -41 -79 -75 -107 -101 2: 1 1 -27 -25 -47 -43 -59 -53 3: 1 1 -11 -9 -15 -11 -11 -5 4: 1 1 5 7 17 21 37 43 5: 1 1 21 23 49 53 85 91 6: 1 1 37 39 81 85 133 139 7: 1 1 53 55 113 117 181 187 VVVV dequant4_inter - Dst VVVV 0: 1482 1482 -2048 -2048 -2048 -2048 -2048 -2048 1: 1482 1482 -2048 -2048 -2048 -2048 -2048 -2048 2: 1482 1482 -2048 -2048 -2048 -2048 -2048 -2048 3: 1482 1482 -2048 -2048 -2048 -2048 -2048 -2048 4: 1482 1482 2047 2047 2047 2047 2047 2047 5: 1482 1482 2047 2047 2047 2047 2047 2047 6: 1482 1482 2047 2047 2047 2047 2047 2047 7: 1482 1482 2047 2047 2047 2047 2047 2046 PLAINC - dequant4_inter 45.094 usec crc=63847 PLAINC - quant_intra 28.702 usec crc=25662 PLAINC - quant_inter 29.201 usec crc=23972 PLAINC - dequant_intra 27.992 usec crc=49900 PLAINC - dequant_inter 26.975 usec crc=48899 --- MMX - skipped... IA64 - skipped... The output values do definately differ at points.. Sorry.. don't have time to track down the cause. 2 weeks till finals. and lots of work to do. have fun, dust From felix-xvid at fefe.de Sun Feb 9 22:38:41 2003 From: felix-xvid at fefe.de (Felix von Leitner) Date: Sun Feb 9 22:38:55 2003 Subject: [XviD-devel] Re: OpenMP parallelization In-Reply-To: References: Message-ID: <20030209213841.GA8757@fefe.de> Thus spake Christoph Lampert (chl@math.uni-bonn.de): > what would you think of OpenMP parallelism instead of > pthread-Multithreading? Why "instead of"? Is there reason to believe that openmp could scale better than the pthread stuff? > Does VisualC++ suport this (yeah, I know, of course not). > There is something call Omni OpenMP for cygwin and other projects, I never > heard of. > icc for Linux does support openMP, so maybe Windows version does, too. > And there might be some modification of gcc that does, but I didn't find > it. Just a few days ago, a gcc cvs branch was created for openmp, but AFAIK no actual code is in it yet. I'm not involved, I just saw it on the mailing list. > For those who haven't met openMP: It's a "trick" to tell the compiler > which parts of a program can be multithreaded by #pragma 's in the code. > If the compiler doesn't know about openMP, it ignores the statements. I wonder how this can me more efficient than pthread on any CPU you can buy today. I haven't actually see it used yet, but I understand it is mainly important to scientists on NUMA architectures. Does anyone here have a NUMA box at his disposal? Felix From chl at math.uni-bonn.de Sun Feb 9 22:48:52 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sun Feb 9 22:48:54 2003 Subject: [XviD-devel] Re: OpenMP parallelization In-Reply-To: <20030209213841.GA8757@fefe.de> Message-ID: On Sun, 9 Feb 2003, Felix von Leitner wrote: > Thus spake Christoph Lampert (chl@math.uni-bonn.de): > > what would you think of OpenMP parallelism instead of > > pthread-Multithreading? > > Why "instead of"? Is there reason to believe that openmp could scale > better than the pthread stuff? No, but pthread stuff requires big modifications and make the source either completely unreadable code or needs a double code basis for SMP and non-SMP. OpenMP would only be a few pragmas at crucial positions. I don't expect linear speedup, but on SMP it might help in heavy calculation routines which are still C-only, like GMC. > > Does VisualC++ suport this (yeah, I know, of course not). > > There is something call Omni OpenMP for cygwin and other projects, I never > > heard of. > > > icc for Linux does support openMP, so maybe Windows version does, too. > > And there might be some modification of gcc that does, but I didn't find > > it. > > Just a few days ago, a gcc cvs branch was created for openmp, but AFAIK > no actual code is in it yet. > > I'm not involved, I just saw it on the mailing list. > > > For those who haven't met openMP: It's a "trick" to tell the compiler > > which parts of a program can be multithreaded by #pragma 's in the code. > > If the compiler doesn't know about openMP, it ignores the statements. > > I wonder how this can me more efficient than pthread on any CPU you can > buy today. I'm pretty sure that it isn't more efficient. But it's simpler to do, because you don't have to deal with all the semaphores and mutex stuff. gruel From christian at matroska.org Sun Feb 9 22:59:27 2003 From: christian at matroska.org (ChristianHJW) Date: Sun Feb 9 23:02:29 2003 Subject: [XviD-devel] Re: DivX5 compatibe API References: Message-ID: "Christoph Lampert" schrieb im Newsbeitrag news:Pine.LNX.4.21.0302091351200.21879-100000@lieb.math.uni-bonn.de... > Should XVID get an DivX5 compatible API (like divx4.h)? > gruel Well, what do we know about this API ?? I was trying to contact DivX N some time ago, basically to find out if it was possible to make an UCI wrapper for DivX5 ( yes, i know, UCI is not here yet ... dont remind me :P ), but they didnt bother to answer. I honestly had no idea DivX N made it open ? ChristianHJW http://matroska.org P.S. libmatroska will be released this week From ed.gomez at free.fr Sun Feb 9 23:56:30 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sun Feb 9 23:56:38 2003 Subject: [XviD-devel] Watcom compiler In-Reply-To: References: <20030209011104.GB7837@leloo> Message-ID: <20030209225630.GC920@leloo> Christoph Lampert (chl@math.uni-bonn.de) wrote: > > XVID is ANSI C, but I guess only after the compiler passed through > portab.h in which it fails e.g. for IRIX cc because the compiler is > unknown. Ironic ? ok ok ok christoph, try now, i commited a patch that should be a lot more "unknown compiler" friendly. Of course if you go through the unknown compiler #ifdef paths, then all stuff is generic... so it's probably wrong for your architecture but i can't do better as alignment and others macros depends on the inline assembler and so on... > Although they simply are part of C99 as inttypes.h ! ANSI C is ISO C89, so relying on this, is not very ANSI C compliant ... anyway, i commited with the same patch an #include instead of the previous definitions. If you know better solutions to these problems just tell me, i'm open to foreign ideas ;-) -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030209/cb41c6dc/attachment.bin From chl at math.uni-bonn.de Mon Feb 10 00:20:45 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Mon Feb 10 00:20:51 2003 Subject: [XviD-devel] Re: DivX5 compatibe API In-Reply-To: Message-ID: On Sun, 9 Feb 2003, ChristianHJW wrote: > > "Christoph Lampert" schrieb im Newsbeitrag > news:Pine.LNX.4.21.0302091351200.21879-100000@lieb.math.uni-bonn.de... > > Should XVID get an DivX5 compatible API (like divx4.h)? > > gruel > > Well, what do we know about this API ?? I was trying to contact DivX N some > time ago, basically to find out if it was possible to make an UCI wrapper > for DivX5 ( yes, i know, UCI is not here yet ... dont remind me :P ), but > they didnt bother to answer. > > I honestly had no idea DivX N made it open ? I was referring to divx4linux501-20020418.tgz (DivX5.01 "basic version"). It contains decore.h and encore2.h which are more or less documented. There is an EXTENSIONS structure with fields for MPEG-quant, QPel, GMC, interlace, etc.. Of course, they have no effect in the "basic" version, so they are useless for DivX5, but they would not be for XVID. Current xvid has "divx4.h" which is compatible to old DivX4Linux (or at least used to be). gruel From chl at math.uni-bonn.de Mon Feb 10 00:26:27 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Mon Feb 10 00:26:29 2003 Subject: [XviD-devel] Watcom compiler In-Reply-To: <20030209225630.GC920@leloo> Message-ID: On Sun, 9 Feb 2003, Edouard Gomez wrote: > Christoph Lampert (chl@math.uni-bonn.de) wrote: > > > > XVID is ANSI C, but I guess only after the compiler passed through > > portab.h in which it fails e.g. for IRIX cc because the compiler is > > unknown. > > Ironic ? No, simply a little tired, sorry. > ok ok ok christoph, try now, i commited a patch that should be > a lot more "unknown compiler" friendly. Of course if you go through the > unknown compiler #ifdef paths, then all stuff is generic... so it's > probably wrong for your architecture but i can't do better as alignment > and others macros depends on the inline assembler and so on... I was just a little puzzled because on MIPS there is no inline-assembler anyway and you have this nice "ARCH_IS_GENERIC" define etc, but then in portab.h everything except gcc, MSVC++ and icc is simply kicked out. I search a little at google and found that __sgi is the Define I had to check for. Adding this in the GCC/ICC section worked as well, but I really prefer a "generic compiler" section. > > Although they simply are part of C99 as inttypes.h ! > > ANSI C is ISO C89, so relying on this, is not very ANSI C compliant > ... anyway, i commited with the same patch an #include > instead of the previous definitions. If we don't want to rely on C99, I'll have to change a few lines in new GMC. Good to know... :-) gruel From chl at math.uni-bonn.de Mon Feb 10 00:27:09 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Mon Feb 10 00:27:10 2003 Subject: [XviD-devel] SGI MIPS Message-ID: Hi, me again, last time for today... After more than a year, I returned to ProjectMayo a few minutes ago, because I read that the only real project there, the PocketPC DivX player has MIPS optimzation, and it seems that it really does. http://home.adelphia.net/~mdukette/kits/PocketMVP_source.zip The license is indeed GPL, not the crappy OpenDivX License, so the routines could be reused for XVID on SGI. Of course I don't know if this is interesting, or if the architecture is too different, betwen MIPS on Handheld and MIPS on SGI, but maybe someone is interested? gruel From ed.gomez at free.fr Mon Feb 10 00:43:18 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Mon Feb 10 00:43:29 2003 Subject: [XviD-devel] Re: DivX5 compatibe API In-Reply-To: References: Message-ID: <20030209234318.GD920@leloo> Christoph Lampert (chl@math.uni-bonn.de) wrote: > I was referring to divx4linux501-20020418.tgz (DivX5.01 "basic version"). > > It contains decore.h and encore2.h which are more or less documented. > There is an EXTENSIONS structure with fields for MPEG-quant, QPel, GMC, > interlace, etc.. > > Of course, they have no effect in the "basic" version, so they are useless > for DivX5, but they would not be for XVID. > > Current xvid has "divx4.h" which is compatible to old DivX4Linux (or at > least used to be). > Is it worth doing that ? I'm not sure whether a program or not supports DivX pro features as it has never been released for linux ia32. DivX5 pro compatible programs support only the basic part of the API afaik. In other words, why trying to be compatible with something that is not used ? -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030210/079035f0/attachment.bin From anaf at prism.uvsq.fr Mon Feb 10 11:13:36 2003 From: anaf at prism.uvsq.fr (Abdelhamid Nafaa) Date: Mon Feb 10 11:08:40 2003 Subject: [XviD-devel] None Message-ID: <000201c2d0ed$1474ca20$0301a8c0@jourdan> Good Morning, Are ther any public XVID library for transcoding form MPEG-2 to XVID MPEG-4? Thank's for your answer. ---------------- Abdelhamid NAFAA | Tel: +33 1 39 25 40 76 University of Versailles, PRiSM Lab. | Fax: +33 1 39 25 40 57 45, Av. Des Etats Unis, 78035 - Versailles, France. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030210/34bcd6ed/attachment.htm From suxen_drol at hotmail.com Mon Feb 10 22:50:01 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Mon Feb 10 12:50:01 2003 Subject: [XviD-devel] Re: DivX5 compatibe API In-Reply-To: <20030209234318.GD920@leloo> References: <20030209234318.GD920@leloo> Message-ID: <20030210224958.5245.SUXEN_DROL@hotmail.com> On Mon, 10 Feb 2003 00:43:18 +0100 Edouard Gomez wrote: > Christoph Lampert (chl@math.uni-bonn.de) wrote: > > I was referring to divx4linux501-20020418.tgz (DivX5.01 "basic version"). > > > > It contains decore.h and encore2.h which are more or less documented. > > There is an EXTENSIONS structure with fields for MPEG-quant, QPel, GMC, > > interlace, etc.. > > > > Of course, they have no effect in the "basic" version, so they are useless > > for DivX5, but they would not be for XVID. > > > > Current xvid has "divx4.h" which is compatible to old DivX4Linux (or at > > least used to be). > > > > Is it worth doing that ? I'm not sure whether a program or not supports > DivX pro features as it has never been released for linux ia32. DivX5 > pro compatible programs support only the basic part of the API afaik. > > In other words, why trying to be compatible with something that is not > used ? i agree; and also think we should dump the divx4/opendivx api wrapper with 1.0.0 ("whenever"). -- pete; life is like a box of ammo From guillaume at morinfr.org Mon Feb 10 14:28:04 2003 From: guillaume at morinfr.org (Guillaume Morin) Date: Mon Feb 10 14:27:46 2003 Subject: [XviD-devel] MacOSX developers needed In-Reply-To: <2580AF13-3C76-11D7-897C-000393B8DC8A@rit.edu> References: <20030208001439.GA593@leloo> <2580AF13-3C76-11D7-897C-000393B8DC8A@rit.edu> Message-ID: <20030210132804.GC2804@morinfr.org> Dans un message du 09 Feb ? 16:33, ptk9417 ?crivait : > {Dynamic lib build settings} > gcc -Wall -I../src/ -DARCH_IS_32BIT -DARCH_IS_BIG_ENDIAN > -DARCH_IS_GENERIC xvid_bench.c -o xvid_bench_dyn -lxvidcore > > ===== test quant ===== > PLAINC - quant4_intra 71.314 usec crc=25180 > *** CRC ERROR! *** Very weird. Is that reproducible ? It works fine here. > [dual:Download/xvidcore/examples] paul% gcc -Wall -I../src/ > -DARCH_IS_32BIT -DARCH_IS_BIG_ENDIAN -DARCH_IS_GENERIC xvid_bench_mod.c > -o xvid_bench_mod_dyn -lxvidcore > ld: warning multiple definitions of symbol _get_intra_matrix_status > /var/tmp//cctn8miN.o definition of _get_intra_matrix_status in > section (__TEXT,__text) > /usr/lib/libxvidcore.dylib(quant_matrix.o) definition of > _get_intra_matrix_status This patch fixes that problem (Edouard, please apply it to your tree) : --- configure.in.old Mon Feb 10 13:36:19 2003 +++ configure.in Mon Feb 10 14:18:09 2003 @@ -247,7 +247,7 @@ ;; darwin*|raphsody*) AC_MSG_RESULT([-dynamiclib]) - OS_LDFLAGS="-dynamiclib" + OS_LDFLAGS="-dynamiclib -flat_namespace" CFLAGS="$CFLAGS -fno-common" ;; beos) -- Guillaume Morin 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5 (Andy Tanenbaum, 30 Jan 1992) From ed.gomez at free.fr Mon Feb 10 15:10:04 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Mon Feb 10 15:10:20 2003 Subject: [XviD-devel] None In-Reply-To: <000201c2d0ed$1474ca20$0301a8c0@jourdan> References: <000201c2d0ed$1474ca20$0301a8c0@jourdan> Message-ID: <20030210141004.GA766@leloo> Abdelhamid Nafaa (anaf@prism.uvsq.fr) wrote: > Good Morning, Salut > Are ther any public XVID library for transcoding form MPEG-2 to XVID > MPEG-4? XviD is only a MPEG4 codec, thus you have to combine XviD with a MPEG2 library (e.g. libmpeg2) to obtain what you're looking for. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030210/3f156be2/attachment.bin From ed.gomez at free.fr Mon Feb 10 15:13:50 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Mon Feb 10 15:13:58 2003 Subject: [XviD-devel] MacOSX developers needed In-Reply-To: <20030210132804.GC2804@morinfr.org> References: <20030208001439.GA593@leloo> <2580AF13-3C76-11D7-897C-000393B8DC8A@rit.edu> <20030210132804.GC2804@morinfr.org> Message-ID: <20030210141350.GB766@leloo> Guillaume Morin (guillaume@morinfr.org) wrote: > This patch fixes that problem (Edouard, please apply it to your tree) : > > --- configure.in.old Mon Feb 10 13:36:19 2003 > +++ configure.in Mon Feb 10 14:18:09 2003 Applied bot local tree and CVS. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030210/f34683ca/attachment.bin From michaelnottebrock at gmx.net Mon Feb 10 15:26:05 2003 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Feb 10 15:26:14 2003 Subject: [XviD-devel] gratuitious linkage? Message-ID: <3E47B67D.6030900@gmx.net> I recently discovered that libxvidcore is linked against libc, is there any specific reason for this? -- Regards, Michael Nottebrock From ed.gomez at free.fr Mon Feb 10 15:46:12 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Mon Feb 10 15:46:20 2003 Subject: [XviD-devel] gratuitious linkage? In-Reply-To: <3E47B67D.6030900@gmx.net> References: <3E47B67D.6030900@gmx.net> Message-ID: <20030210144612.GC766@leloo> Michael Nottebrock (michaelnottebrock@gmx.net) wrote: > I recently discovered that libxvidcore is linked against libc, is there > any specific reason for this? Of course... we use malloc :-) and for debug versions we use fprintf. We use other functions but i don't remeber them all. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030210/b341d0fc/attachment.bin From michaelnottebrock at gmx.net Mon Feb 10 19:24:34 2003 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Mon Feb 10 19:24:47 2003 Subject: [XviD-devel] gratuitious linkage? References: <3E47B67D.6030900@gmx.net> <20030210144612.GC766@leloo> Message-ID: <3E47EE62.7050009@gmx.net> Edouard Gomez wrote: > Of course... we use malloc :-) and for debug versions we use fprintf. > > We use other functions but i don't remeber them all. Doh, first I grepped the wrong sources for libc functions, and then the compiler doesn't complain about unresolved symbols because the line is only -shared without -symbolic. Some nice footshooting I did there *puts the pointy hat on*. -- Regards, Michael Nottebrock From ed.gomez at free.fr Tue Feb 11 00:27:39 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Tue Feb 11 00:27:49 2003 Subject: [XviD-devel] [PRE RELEASE] v0.9.1 is ready -- last chance to report bugs Message-ID: <20030210232739.GD766@leloo> Ok the 0.9.1 release is ready (except release details like version numbering and so on). I would like that you all test the building process for both unix and windows with msvc/cygwin/mingw. And in particular, IA64 *must* be tested as i have no access to that kind of box (at least no ia64 box with the possibility to download things on it). If you nothing wrong then i'll change version number, commit my last changes and release the last 0.9.x realease. As always, tarballs are ready and uploaded there: http://ed.gomez.free.fr/ PS: i forgot to fix xvid_encraw -help message, will be done later. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030211/e3bdbc03/attachment.bin From s_kraste at ira.uka.de Tue Feb 11 00:49:45 2003 From: s_kraste at ira.uka.de (Stephan Krause) Date: Tue Feb 11 00:49:51 2003 Subject: [XviD-devel] [PRE RELEASE] v0.9.1 is ready -- last chance to report bugs In-Reply-To: <20030210232739.GD766@leloo> References: <20030210232739.GD766@leloo> Message-ID: Hi, > I would like that you all test the building process for both unix and > windows with msvc/cygwin/mingw. And in particular, IA64 *must* be tested > as i have no access to that kind of box (at least no ia64 box with the > possibility to download things on it). It compiles, and xvid_stats runs, so it should work ;-) No time to do more testing today, but i'll do the next days. Stephan -- Sig fault. (core dumped) From ed.gomez at free.fr Tue Feb 11 01:03:27 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Tue Feb 11 01:03:37 2003 Subject: [XviD-devel] [PRE RELEASE] v0.9.1 is ready -- last chance to report bugs In-Reply-To: References: <20030210232739.GD766@leloo> Message-ID: <20030211000327.GF766@leloo> Stephan Krause (s_kraste@ira.uka.de) wrote: > It compiles, and xvid_stats runs, so it should work ;-) > > No time to do more testing today, but i'll do the next days. Good to hear that, I'm just curious to know what you do with XviD on such a highend type of architecture ;-) Son: "I want to watch my mpeg4 videos now !" Mom: "son, daddy and I will go to the PC retailer this afternoon and we will give you the IA64 box tonight. Be patient" Son: "i love you so much mom" ... -- Edouard Gomez -- No drugs were used during the writing of this email-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030211/0f0ac3e9/attachment.bin From s_kraste at ira.uka.de Tue Feb 11 01:23:31 2003 From: s_kraste at ira.uka.de (Stephan Krause) Date: Tue Feb 11 01:23:37 2003 Subject: [XviD-devel] [PRE RELEASE] v0.9.1 is ready -- last chance to report bugs In-Reply-To: <20030211000327.GF766@leloo> References: <20030210232739.GD766@leloo> <20030211000327.GF766@leloo> Message-ID: Hi, > Good to hear that, I'm just curious to know what you do with XviD on > such a highend type of architecture ;-) [...] The iA64-Code is the result of a "Praktical Work" at the University of Karlsruhe (with the goal to find possibilities to optimize assembler code for this architecture which *could* be used to build a good[1] compiler for iA64). (And I remained as "maintainer", because we didn't want all the work to be wasted) But at last, the Itanium (1) is not really highend, but only a damm expansive way of heating. In fact, my Athlon 900 is *MUCH* faster encoding Videos than that piece of hardware. The Itanium 2 is said to be much better, but 'till now, I did never see one.. But since the Architecture is mostly the same, XviD should run there, too, and should be able to use our assembler- optimizations. Stephan [1] ther is no really good compile for iA64 i know of, most of the pretty features of the architecture can only be used coding assembler, and the is no real solution finding the optimal order of instructions to reach a maximum level of parallelism, as the cpu does not reorder the instructions like the x86. -- Sig fault. (core dumped) From michaelnottebrock at gmx.net Tue Feb 11 02:27:30 2003 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Tue Feb 11 02:27:47 2003 Subject: [XviD-devel] [PRE RELEASE] v0.9.1 is ready -- last chance to report bugs In-Reply-To: <20030210232739.GD766@leloo> References: <20030210232739.GD766@leloo> Message-ID: <200302110227.31286.michaelnottebrock@gmx.net> On Tuesday 11 February 2003 00:27, Edouard Gomez wrote: > Ok the 0.9.1 release is ready (except release details like version > numbering and so on). > > I would like that you all test the building process for both unix and > windows with msvc/cygwin/mingw. Libxvidcore should install as libxvidcore.so.revision and symlink libxvidcore.so to that. Atm it just installs libxvidcore.so, which FreeBSD's ld(config) won't find. -- Regards, Michael Nottebrock From michaelnottebrock at gmx.net Tue Feb 11 02:46:46 2003 From: michaelnottebrock at gmx.net (Michael Nottebrock) Date: Tue Feb 11 02:46:53 2003 Subject: [XviD-devel] [PRE RELEASE] v0.9.1 is ready -- last chance to report bugs In-Reply-To: <200302110227.31286.michaelnottebrock@gmx.net> References: <20030210232739.GD766@leloo> <200302110227.31286.michaelnottebrock@gmx.net> Message-ID: <200302110246.47388.michaelnottebrock@gmx.net> On Tuesday 11 February 2003 02:27, I wrote: > Libxvidcore should install as libxvidcore.so.revision and symlink > libxvidcore.so to that. Atm it just installs libxvidcore.so, which > FreeBSD's ld(config) won't find. ... Apparently I still have the pointy hat on, it's only ldconfig which is confused, linking works fine. Still, someday the need for having distinct revisions might arise anyway. -- Regards, Michael Nottebrock From chl at math.uni-bonn.de Tue Feb 11 12:29:56 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Tue Feb 11 12:30:01 2003 Subject: [XviD-devel] Cacheline, portab.h Message-ID: Hi, I'm still not finished complaining about portab.h. Sorry for that ;-) What do we do with CACHE_LINE argument from portab.h ? Just alignment of matrices? I didn't find any prefetch-code based on this (would be a good idea, too, btw.) I was just asking because if it's were really important, we should not use a fixed definition based on architecture #if defined(ARCH_IS_32BIT) # define CACHE_LINE 16 #elif defined(ARCH_IS_64BIT) # define CACHE_LINE 32 #endif (if this is bytes, it's rather wrong, btw, since imho most 32bit CPUs have 32 (PII/PIII/PowerPC) or even 64 bytes (P4,Athlon) cachelines ) On x86 we could get this using configure directly from CPUID, as "cpuid" does: http://freshmeat.net/projects/cpuid/?topic_id=146 For crosscompiling or on other plattforms, it could also be predefined, but adjustable during configure. gruel --------- typical output of cpuid.c (which claims to be GPLed) --------- eax in eax ebx ecx edx 00000000 00000002 756e6547 6c65746e 49656e69 00000001 00000683 00000002 00000000 0383f9ff 00000002 03020101 00000000 00000000 0c040882 Vendor ID: "GenuineIntel"; CPUID level 2 Intel-specific functions: Version 00000683: Type 0 - Original OEM Family 6 - Pentium Pro Model 8 - Pentium III/Pentium III Xeon - internal L2 cache Stepping 3 Reserved 0 Brand index: 2 [Pentium III processor] Feature flags 0383f9ff: FPU Floating Point Unit VME Virtual 8086 Mode Enhancements DE Debugging Extensions PSE Page Size Extensions TSC Time Stamp Counter MSR Model Specific Registers PAE Physical Address Extension MCE Machine Check Exception CX8 COMPXCHG8B Instruction SEP Fast System Call MTRR Memory Type Range Registers PGE PTE Global Flag MCA Machine Check Architecture CMOV Conditional Move and Compare Instructions FGPAT Page Attribute Table PSE-36 36-bit Page Size Extension MMX MMX instruction set FXSR Fast FP/MMX Streaming SIMD Extensions save/restore SSE Streaming SIMD Extensions instruction set TLB and cache info: 01: Instruction TLB: 4KB pages, 4-way set assoc, 32 entries 02: Instruction TLB: 4MB pages, 4-way set assoc, 2 entries 03: Data TLB: 4KB pages, 4-way set assoc, 64 entries 82: 2nd-level cache: 256KB, 8-way set assoc, 32 byte line size 08: 1st-level instruction cache: 16KB, 4-way set assoc, 32 byte line size 04: Data TLB: 4MB pages, 4-way set assoc, 8 entries 0c: 1st-level data cache: 16KB, 4-way set assoc, 32 byte line size From suxen_drol at hotmail.com Tue Feb 11 22:55:52 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Tue Feb 11 12:55:54 2003 Subject: [XviD-devel] [PRE RELEASE] v0.9.1 is ready -- last chance to report bugs In-Reply-To: <20030210232739.GD766@leloo> References: <20030210232739.GD766@leloo> Message-ID: <20030211224402.EF5D.SUXEN_DROL@hotmail.com> On Tue, 11 Feb 2003 00:27:39 +0100 Edouard Gomez wrote: > Ok the 0.9.1 release is ready (except release details like version > numbering and so on). > > I would like that you all test the building process for both unix and > windows with msvc/cygwin/mingw. And in particular, IA64 *must* be tested > as i have no access to that kind of box (at least no ia64 box with the > possibility to download things on it). > > If you nothing wrong then i'll change version number, commit my last > changes and release the last 0.9.x realease. > > As always, tarballs are ready and uploaded there: > http://ed.gomez.free.fr/ > > PS: i forgot to fix xvid_encraw -help message, will be done later. two things: * some systems dont have ranlib, rather they perform reindexing automatically within ar. i dont have autoconf250 here to make u a diff, but the following changes are necessary: configure.in: add "AC_PROG_RANLIB" platform.inc.in: add "RANLIB=@RANLIB@" Makefile: replace "ranlib $(STATIC_LIB)" with "$(RANLIB) $(STATIC_LIB)" * on line 58 of sources.inc, there is a line containing only a tab. this causes problems with an older version of sgi make. please remove this line! it works well with mingw/msys, but my cygwin has stuff upped (and unable to test it). otherwise its good to go. -- pete; life is like a box of ammo From suxen_drol at hotmail.com Tue Feb 11 23:30:12 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Tue Feb 11 13:30:12 2003 Subject: [XviD-devel] [PRE RELEASE] v0.9.1 is ready -- last chance to report bugs In-Reply-To: <20030211224402.EF5D.SUXEN_DROL@hotmail.com> References: <20030210232739.GD766@leloo> <20030211224402.EF5D.SUXEN_DROL@hotmail.com> Message-ID: <20030211230228.EF60.SUXEN_DROL@hotmail.com> On Tue, 11 Feb 2003 22:55:52 +1100 suxen_drol wrote: > > it works well with mingw/msys, but my cygwin has stuff upped (and unable > to test it). otherwise its good to go. retract that: * mingw/msys linker fails when compiling without the divx4 functions. the reason: libxvidcore.def specifies the divx4 decore,encore fuctions. one way arround this, would be to specify decore,encore on the ld command line. or just remove decore&encore from the .def. * -fPIC is not neccessary for win32 pe (dll) target, and results in: "warning: -fPIC ignored for target (all code is position independent)" > -- pete; life is like a box of ammo From suxen_drol at hotmail.com Tue Feb 11 23:45:17 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Tue Feb 11 13:45:27 2003 Subject: [XviD-devel] Watcom compiler In-Reply-To: References: <20030209225630.GC920@leloo> Message-ID: <20030211234226.EF63.SUXEN_DROL@hotmail.com> hi, other than some minor portab.h changes, watcomc works fine with the dev-api-3 libxvidcore. note: i was unable to get nasm code working with it. -- pete From chl at math.uni-bonn.de Tue Feb 11 14:55:36 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Tue Feb 11 14:55:40 2003 Subject: [XviD-devel] Someone has a virus Message-ID: Hi, somebody connected to XVID seems to have a W32/Klez.h virus, maybe he recognizes himself from this description. My first assumption is: T-Online user, IP at Tuesday, 11th, 14:50 is 217.81.4.170, Maybe some connection to maxhost.de ? Must have the XVID file changelog.txt on his disk (22591 bytes). I just got an e-mail from him with header: Received: from [62.67.195.155] (helo=max1.maxhost.de) by mx09.web.de with esmtp (WEB.DE(Exim) 4.95 #31) id 18iaYY-0005Vc-00 for gruel@web.de; Tue, 11 Feb 2003 14:34:38 +0100 Received: from Zplzbkib (pD95104AA.dip.t-dialin.net [217.81.4.170]) by max1.maxhost.de (Postfix) with SMTP id 69C2F443063 for ; Tue, 11 Feb 2003 14:32:16 +0100 (CET) Information on Klez.h (in german) is available at http://www.tu-berlin.de/www/software/virus/aktuell.shtml (see "April 2002") You can detect it from existence of files Wqk.exe und Wink????.exe in \Windows\System[32]\ Antivirus e.g. at http://www.symantec.com/avcenter/venc/data/w32.klez.removal.tool.html Home that stops it. gruel From ed.gomez at free.fr Tue Feb 11 18:20:35 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Tue Feb 11 18:20:52 2003 Subject: [XviD-devel] [PRE RELEASE] v0.9.1 is ready -- last chance to report bugs In-Reply-To: <20030211230228.EF60.SUXEN_DROL@hotmail.com> References: <20030210232739.GD766@leloo> <20030211224402.EF5D.SUXEN_DROL@hotmail.com> <20030211230228.EF60.SUXEN_DROL@hotmail.com> Message-ID: <20030211172035.GA2161@leloo> suxen_drol (suxen_drol@hotmail.com) wrote: > retract that: > * mingw/msys linker fails when compiling without the divx4 functions. > the reason: libxvidcore.def specifies the divx4 decore,encore fuctions. Already reported by a previous report. > one way arround this, would be to specify decore,encore on the ld > command line. or just remove decore&encore from the .def. I'll generate libxvidcore.def at configure time > * -fPIC is not neccessary for win32 pe (dll) target, and results in: > "warning: -fPIC ignored for target (all code is position independent)" I'll put that to the SPECIFIC_CFLAGS and all should be fine. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030211/8d5fa8eb/attachment.bin From michael at xvid.org Tue Feb 11 20:55:31 2003 From: michael at xvid.org (Michael Militzer) Date: Tue Feb 11 20:55:33 2003 Subject: [XviD-devel] [PRE RELEASE] v0.9.1 is ready -- last chance to report bugs In-Reply-To: <20030210232739.GD766@leloo> References: <20030210232739.GD766@leloo> Message-ID: <1044993331.3e495533694ac@www.xvid.org> Hi, Quoting Edouard Gomez : > Ok the 0.9.1 release is ready (except release details like version > numbering and so on). > > I would like that you all test the building process for both unix and > windows with msvc/cygwin/mingw. And in particular, IA64 *must* be tested > as i have no access to that kind of box (at least no ia64 box with the > possibility to download things on it). > > If you nothing wrong then i'll change version number, commit my last > changes and release the last 0.9.x realease. > > As always, tarballs are ready and uploaded there: > http://ed.gomez.free.fr/ ok, I just grabbed your latest tarball and I noticed that there's still decoding support for b-frames and quarterpel included in the source code. Basically that's no problem, however b-frame decoding might be broken (I haven't tried but a lot has been changed in the dev-tree since we branched off) and qpel support is definitively wrong and buggy. Many people are not aware that the stable branch also includes outdated and buggy code while at the same time the correct (or at least more correct) code equivalents are somehow "hidden" in the dev-tree. So I suggest to either remove b-frame + qpel support from stable or sync the code between dev-api3 and stable... bye, Michael From ed.gomez at free.fr Tue Feb 11 22:13:59 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Tue Feb 11 22:14:11 2003 Subject: [XviD-devel] [RELEASE CANDIDATE] v0.9.1 In-Reply-To: <1044993331.3e495533694ac@www.xvid.org> References: <20030210232739.GD766@leloo> <1044993331.3e495533694ac@www.xvid.org> Message-ID: <20030211211359.GB2161@leloo> Michael Militzer (michael@xvid.org) wrote: > Many people are not aware that the stable branch also includes outdated and > buggy code while at the same time the correct (or at least more correct) code > equivalents are somehow "hidden" in the dev-tree. So I suggest to either remove > b-frame + qpel support from stable or sync the code between dev-api3 and > stable... I felt too lazy, i dropped support for these supports as nobody was using them. At least public builds of the lib were not defining BFRAME decoding. I think dev-api-3 is stable enough to be used for "every day" use if someone wants bframes and qpel. I am preparing this release mainly because we need CVS_HEAD soon (for dev-api-3 stabilization) and that stable version had some fixes and the VLC memory footprint improvement. A new version will be uploaded in a few minutes. This one is supposed to be a Release Candidate. http://ed.gomez.free.fr/ -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030211/d7ccccf4/attachment.bin From hello_the_haxor at hotmail.com Wed Feb 12 08:35:00 2003 From: hello_the_haxor at hotmail.com (Joel) Date: Tue Feb 11 23:05:11 2003 Subject: [XviD-devel] [RELEASE CANDIDATE] v0.9.1 References: <20030210232739.GD766@leloo><1044993331.3e495533694ac@www.xvid.org> <20030211211359.GB2161@leloo> Message-ID: xvidcore-0.9.1-rc1 configures, complies and runs xvid_stat fine under cygwin a question: when doing a 'make all' in the exampes dir, the file /build/generic/libxvidcore.a will be looked for. however, after building xvild, only a libxvidcore.dll.a will be made. so could there either be a symbolic link to libxvidcore.dll.a, or could the makefile for the 'examples' programs be told to look also for a libxvidcore.dll.a? joel From ed.gomez at free.fr Tue Feb 11 23:17:34 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Tue Feb 11 23:17:46 2003 Subject: [XviD-devel] [RELEASE CANDIDATE] v0.9.1 In-Reply-To: References: <20030211211359.GB2161@leloo> Message-ID: <20030211221734.GC2161@leloo> Joel (hello_the_haxor@hotmail.com) wrote: > xvidcore-0.9.1-rc1 configures, complies and runs xvid_stat fine under cygwin > > a question: when doing a 'make all' in the exampes dir, the file > /build/generic/libxvidcore.a will be looked for. however, after building > xvild, only a libxvidcore.dll.a will be made. so could there either be a > symbolic link to libxvidcore.dll.a, or could the makefile for the 'examples' > programs be told to look also for a libxvidcore.dll.a? No, cygwin is very nasty on that .dll.a files, if it finds a .dll.a and a .a file then it'll choose the .dll.a one. It is a big big mistake from cygwin guys because this is something we find nowhere on *nix world and i cannot handle that in examples as they are not "configured" for the running target. Perhaps a -static could help at linking stage. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030211/3a788203/attachment.bin From ed.gomez at free.fr Tue Feb 11 23:29:34 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Tue Feb 11 23:29:44 2003 Subject: [XviD-devel] Cacheline, portab.h In-Reply-To: References: Message-ID: <20030211222934.GD2161@leloo> Christoph Lampert (chl@math.uni-bonn.de) wrote: > I'm still not finished complaining about portab.h. Sorry for that ;-) What about waiting for dev-api-3 stabilization work :-) i'm really bored at fixing portab.h for the next month :-) -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030211/4f97bc0f/attachment.bin From andrelsr13 at yahoo.com.br Tue Feb 11 20:45:27 2003 From: andrelsr13 at yahoo.com.br (=?iso-8859-1?B?QW5kcukgTHXtcw==?=) Date: Tue Feb 11 23:47:46 2003 Subject: [XviD-devel] Please help me with XviD Message-ID: <001201c2d227$aa1733c0$0301a8c0@Andre> Hi, How I can install Xvid Codec on my PC?? I didn't understand the readme, please help me!!!! Please answer this e-mail, Andr? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030211/5b54ea27/attachment.htm From ptk9417 at ritvax.rit.edu Wed Feb 12 00:21:25 2003 From: ptk9417 at ritvax.rit.edu (ptk9417) Date: Wed Feb 12 06:21:36 2003 Subject: [XviD-devel] MacOSX developers needed In-Reply-To: <20030210132804.GC2804@morinfr.org> Message-ID: On Monday, February 10, 2003, at 08:28 AM, Guillaume Morin wrote: > Dans un message du 09 Feb ? 16:33, ptk9417 ?crivait : >> {Dynamic lib build settings} >> gcc -Wall -I../src/ -DARCH_IS_32BIT -DARCH_IS_BIG_ENDIAN >> -DARCH_IS_GENERIC xvid_bench.c -o xvid_bench_dyn -lxvidcore >> >> ===== test quant ===== >> PLAINC - quant4_intra 71.314 usec crc=25180 >> *** CRC ERROR! *** > > Very weird. Is that reproducible ? It works fine here. > Hello Guillaume, I forgot to check /usr/local/lib/ for previous development cruft. i had an old copy of the libxvidcore quietly sleeping in there. /me smacks himself.. I'm very sorry for the false alarm. But on a different note.. building on linux ppc, without debugging (the -g flag) causes a segfault on encoding. It occurs in a call to idct_int32. When debugging is turned on with -g, everything seems to work fine.. the same occurs with both a static lib and a dyn lib. {system info} external@cube examples $ uname -a Linux cube 2.4.20-ppc-r2 #1 SMP Mon Jan 13 19:49:57 EST 2003 ppc 0 7400, altivec supported GNU/Linux external@cube examples $ gcc -v Reading specs from /usr/lib/gcc-lib/powerpc-unknown-linux-gnu/3.2.1/specs Configured with: /var/tmp/portage/gcc-3.2.1/work/gcc-3.2.1/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu --target=powerpc-unknown-linux-gnu --with-system-zlib --enable-languages=c,c++,ada,f77,objc,java --enable- threads=posix --enable-long-long --disable-checking --enable-cstdio=stdio --enable-clocale=generic --enable- __cxa_atexit --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/include/g++-v32 --with- local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext Thread model: posix gcc version 3.2.1 {the run -- No debugging enabled} external@cube examples $ gdb ./xvid_stat GNU gdb 5.3 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-unknown-linux-gnu"... (gdb) set args -i cactus.pgm -d 1 (gdb) run Starting program: /home/external/xvidcore-0.9.1-rc1/examples/xvid_stat -i cactus.pgm -d 1 xvid_stat - XviD core library test program written by Christoph Lampert 2002 Trying to retreive width and height from PGM header Program received signal SIGSEGV, Segmentation fault. 0x10007210 in idct_int32 () (gdb) I'll look into this more over the weekend. dust From guillaume at morinfr.org Wed Feb 12 10:39:10 2003 From: guillaume at morinfr.org (Guillaume Morin) Date: Wed Feb 12 10:38:51 2003 Subject: [XviD-devel] MacOSX developers needed In-Reply-To: References: <20030210132804.GC2804@morinfr.org> Message-ID: <20030212093910.GA2776@morinfr.org> Dans un message du 12 f?v ? 0:21, ptk9417 ?crivait : > But on a different note.. building on linux ppc, without debugging > (the -g flag) causes a segfault on encoding. It occurs in a call to > idct_int32. When debugging is turned on with -g, everything seems to > work fine.. the same occurs with both a static lib and a dyn lib. I've found a regression in gcc 3.2.x when you compile idct.c with optimizations on powerpc. The bug has been reported and should be fixed soon. When you compile with -g, does your command line contain -O2 ? Regards, -- Guillaume Morin Pastis servi, pastis bu (Patrice) From radoslaw at syskin.cjb.net Wed Feb 12 21:50:56 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Wed Feb 12 12:20:19 2003 Subject: [XviD-devel] VHQ Message-ID: <1624239796.20030212215056@syskin.cjb.net> Heya everybody, I have good news - I fixed all known VHQ bugs and I'm preparing to commit the code. Anyone would like to comment? What I mean is if someone would like to stop me for whatever reason, please do it now. The code doesn't work with GMC yet (mcsel comparsion would not work) but I'm going to fix this soon. The result will be a perfect, brute force S_VOP/P_VOP selection and mcsel selection. A bit about the flags which will appear in xvid.h: global flag XVID_MODEDECISION_DCT will activate the code and use it for mode decision. motion flags: QUARTERPELREFINE16_DCT - quarterpel refinement for 16x16 mode will be performed using DCT (well in fact not dct, but BITS) comparsion. It doesn't mean it will not be performed using SAD, so do not deactivate PMV_QUARTERPELREFINE16 or suffer some PSNR degradation. I'll write why this happens if someone asks me. HALFPELREFINE16_DCT - just as the above, but for halfpel refinement. In qpel mode it will automatically activate the above flag. QUARTERPELREFINE8_DCT - just like the _16 flag, but one thing is different - 8x8 qpel refinement will _never_ be performed using SAD, so PMV_QUARTERPELREFINE8 is ignored. HALFPELREFINE8_DCT - no surprises here. will replace SAD-based hpel refinement of 8x8 candidates and will activate QUARTERPELREFINE8_DCT if in qpel mode. EXTSEARCH_DCT - will use square-based search pattern on our 16x16 candidate. Will automatically activate hpel16_dct and qpel16_dct (if qpel). If you also want square to be used for 8x8 search, combine it with PMV_EXTSEARCH8. CHECKPREDICTION_DCT - with this flag, the code will automatically make one additional check - of the vector equal to prediction. The check is reasonably fast but at the other hand doesn't give that much. It's independant of all other motion flags. And that's it. If you disable the global flag, you can safely activate the motion flags - they will be ignored. Any questions? It will take me at least on hour to prepare the commit (I have to be careful, many files have changed), so you can still stop me if something's wrong. Radek From chl at math.uni-bonn.de Wed Feb 12 12:35:49 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Wed Feb 12 12:35:53 2003 Subject: [XviD-devel] VHQ In-Reply-To: <1624239796.20030212215056@syskin.cjb.net> Message-ID: Hi Radek, that's great news! On Wed, 12 Feb 2003, Radek Czyz wrote: > Heya everybody, > > I have good news - I fixed all known VHQ bugs and I'm preparing to > commit the code. Anyone would like to comment? What I mean is if > someone would like to stop me for whatever reason, please do it now. > > The code doesn't work with GMC yet (mcsel comparsion would not work) > but I'm going to fix this soon. The result will be a perfect, > brute force S_VOP/P_VOP selection and mcsel selection. > > A bit about the flags which will appear in xvid.h: > > global flag XVID_MODEDECISION_DCT will activate the code and use it > for mode decision. > > motion flags: > QUARTERPELREFINE16_DCT - quarterpel refinement for 16x16 mode will be > performed using DCT (well in fact not dct, but BITS) comparsion. It > doesn't mean it will not be performed using SAD, so do not deactivate > PMV_QUARTERPELREFINE16 or suffer some PSNR degradation. I'll write why > this happens if someone asks me. I didn't get that. Qpel refine is done how exactly? SAD _and_ BITS ? > [...] If you really implemented BITS instead of DCT, the "DCT"-names I proposed are of course misleading. Why not call all the flags "XXX_BITS" instead of "XXX_DCT"? Btw., I didn't even know there were that many bits left in our flags vector... Maybe we have to switch to 64-bit because of too many features. ;-) gruel From michael at xvid.org Wed Feb 12 12:38:02 2003 From: michael at xvid.org (Michael Militzer) Date: Wed Feb 12 12:38:05 2003 Subject: [XviD-devel] [RELEASE CANDIDATE] v0.9.1 In-Reply-To: <20030211211359.GB2161@leloo> References: <20030210232739.GD766@leloo> <1044993331.3e495533694ac@www.xvid.org> <20030211211359.GB2161@leloo> Message-ID: <1045049882.3e4a321aab63e@www.xvid.org> Hi, Quoting Edouard Gomez : > Michael Militzer (michael@xvid.org) wrote: > > Many people are not aware that the stable branch also includes outdated and > > > buggy code while at the same time the correct (or at least more correct) > code > > equivalents are somehow "hidden" in the dev-tree. So I suggest to either > remove > > b-frame + qpel support from stable or sync the code between dev-api3 and > > stable... > > I felt too lazy, i dropped support for these supports as nobody was > using them. At least public builds of the lib were not defining BFRAME > decoding. I know > I think dev-api-3 is stable enough to be used for "every day" use if > someone wants bframes and qpel. I am preparing this release mainly > because we need CVS_HEAD soon (for dev-api-3 stabilization) and that > stable version had some fixes and the VLC memory footprint improvement. yes sure b-frames + qpel on CVS_HEAD are not for usage and maybe it's also true that these features are never used - however that's not the point. The core problem is that other developers might have a look at the code and suppose - because they've downloaded the stable-tree code - that the bframe + qpel code here is stable and bug-free. I have received a message in private mail recently where someone used the XVID "stable" decoder as reference for his own encoder and was then of course very confused about XVID's qpel behaviour... So that was my point: if we call the thing "stable", there shouldn't be any known bugs or incorrect code included. Apart from this: nice work Ed! bye, Michael From elcabesa at inwind.it Wed Feb 12 12:40:54 2003 From: elcabesa at inwind.it (marco belli) Date: Wed Feb 12 12:44:42 2003 Subject: [XviD-devel] question about xvid api Message-ID: <200302121240.54480.elcabesa@inwind.it> is right that when i set a quantizer value from an externally source , eg fixed_quant or 2nd pass , luminance mask simply change it? From chl at math.uni-bonn.de Wed Feb 12 12:46:46 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Wed Feb 12 12:46:49 2003 Subject: [XviD-devel] [RELEASE CANDIDATE] v0.9.1 In-Reply-To: <1045049882.3e4a321aab63e@www.xvid.org> Message-ID: On Wed, 12 Feb 2003, Michael Militzer wrote: > So that was my point: if we call the thing "stable", there shouldn't be any > known bugs or incorrect code included. Hm, would it really be worth to throw out code which is deactivated anyway just for a small group of developers who are supposed to read the docs before starting to work with the code? We could add a README which tells just what you discussed: ACTIVATED code is (hopefully) bugfree. DEACTIVATED code isn't, that's why it's deactivated, but it's not worth debugging it, because there is a corrected version is in CVS already and will be released soon anyway. gruel From michael at xvid.org Wed Feb 12 13:09:32 2003 From: michael at xvid.org (Michael Militzer) Date: Wed Feb 12 13:00:16 2003 Subject: [XviD-devel] [RELEASE CANDIDATE] v0.9.1 References: Message-ID: <004e01c2d28f$9a9cf890$ba0407d5@mmpc> ----- Original Message ----- From: "Christoph Lampert" To: Sent: Wednesday, February 12, 2003 12:46 PM Subject: Re: [XviD-devel] [RELEASE CANDIDATE] v0.9.1 > On Wed, 12 Feb 2003, Michael Militzer wrote: > > So that was my point: if we call the thing "stable", there shouldn't be any > > known bugs or incorrect code included. > > Hm, would it really be worth to throw out code which is deactivated > anyway just for a small group of developers who are supposed to read > the docs before starting to work with the code? > We could add a README which tells just what you discussed: > ACTIVATED code is (hopefully) bugfree. DEACTIVATED code isn't, that's why > it's deactivated, but it's not worth debugging it, because there is a > corrected version is in CVS already and will be released soon anyway. qpel is activated by default on CVS HEAD and there's no notice that the code is outdated. Michael From suxen_drol at hotmail.com Wed Feb 12 23:16:18 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Wed Feb 12 13:16:19 2003 Subject: [XviD-devel] [RELEASE CANDIDATE] v0.9.1 In-Reply-To: References: <1045049882.3e4a321aab63e@www.xvid.org> Message-ID: <20030212225024.EEBB.SUXEN_DROL@hotmail.com> On Wed, 12 Feb 2003 12:46:46 +0100 (CET) Christoph Lampert wrote: > On Wed, 12 Feb 2003, Michael Militzer wrote: > > So that was my point: if we call the thing "stable", there shouldn't be any > > known bugs or incorrect code included. > > Hm, would it really be worth to throw out code which is deactivated > anyway just for a small group of developers who are supposed to read > the docs before starting to work with the code? > We could add a README which tells just what you discussed: > ACTIVATED code is (hopefully) bugfree. DEACTIVATED code isn't, that's why > it's deactivated, but it's not worth debugging it, because there is a > corrected version is in CVS already and will be released soon anyway. > > gruel dev-api-3 is growing too much i think. it appears to be stable as many people are using it, but obviously not release worthy. the major todo for xvid-1.0 are Ratecontrol, API and the VFW gui. RC and API are kinda ready, but need intergration testing. to do that, we really need another branch. i suggest the following development plan: 1. stable should be taged and branched as 'release_0_9_1' 2. merge dev-api-3 back into CVS_HEAD. non-major development stuff now gets commited here. 3. tag & branch CVS_HEAD as dev-api-4. 4. commit current api and rc patches (thats me and gom) into dev-api-4 *only*. get it working, and merge back into head another minor annoyance is the cvs/directory layout. maintaing cvs branches between xvidcore,dshow and vfw is painful! how do people feel about incorporating vfw & dshow into the xvidcore tree? -- pete From chl at math.uni-bonn.de Wed Feb 12 13:37:32 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Wed Feb 12 13:37:53 2003 Subject: [XviD-devel] [RELEASE CANDIDATE] v0.9.1 In-Reply-To: <004e01c2d28f$9a9cf890$ba0407d5@mmpc> Message-ID: On Wed, 12 Feb 2003, Michael Militzer wrote: > qpel is activated by default on CVS HEAD and there's no notice that the code > is outdated. Okay, that I didn't notice. outdated qpel cann off course not be part of stable. gruel From radoslaw at syskin.cjb.net Wed Feb 12 23:17:24 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Wed Feb 12 13:46:41 2003 Subject: [XviD-devel] VHQ In-Reply-To: References: Message-ID: <189427906.20030212231724@syskin.cjb.net> Hi, > I didn't get that. Qpel refine is done how exactly? SAD _and_ BITS ? OK, I'll explain this in more details. This is actually still a result of some experiments and in the end might not be true. Imagine that after sad-based ME we're doing our first check in BITS domain. We discover that cbp == 0, which means that all blocks will not be coded (and at this moment I mean 4 luma blocks). When this happens, we can still do square/refinement steps and minimize bits needed for motion vectors. What I discovered: when we do that PSNR drops. This is because when we're minimizing MV bits, we move away from 'best match' in the understanding of SAD. We can save some bits, but SAD of the match - which means SAD of the MB in new picture [no dct to correct] - will get worse. This is not big deal for quantizer 2, and this doesn't happen often at quantizer 2 anyway. But for q6 that makes a _big_ difference. Now, back to refinement. If we are supposed to stop after we discover that cbp of sad-found vector is 0, we should check sad-refined vector for that. Also, if we're supposed to stop, we have to make sure that this vector is actually refined. The best way to do all this is to sad-refine the vector, then check. A speedup can be obtained if we estimate, using SAD, if the match actually has any chances of being cbp==0. The outcome is - if refine16_bits is active: - do sad-based fullpexel search - if SAD is low enough, refine it - check if cbp == 0. if yes, stop (see? it's refined after all) - if it's not, just do all the search and refinement using _BITS functions And that's the explanation. This is all subject of further tests and corrections, and I'm open on ideas as well. Radek PS you're right gruel, I changed the names to _BITS From ptk9417 at ritvax.rit.edu Wed Feb 12 08:49:43 2003 From: ptk9417 at ritvax.rit.edu (ptk9417) Date: Wed Feb 12 14:50:33 2003 Subject: [XviD-devel] MacOSX developers needed In-Reply-To: <20030212093910.GA2776@morinfr.org> Message-ID: On Wednesday, February 12, 2003, at 04:39 AM, Guillaume Morin wrote: > Dans un message du 12 f?v ? 0:21, ptk9417 ?crivait : >> But on a different note.. building on linux ppc, without debugging >> (the -g flag) causes a segfault on encoding. It occurs in a call to >> idct_int32. When debugging is turned on with -g, everything seems to >> work fine.. the same occurs with both a static lib and a dyn lib. > > I've found a regression in gcc 3.2.x when you compile idct.c with > optimizations on powerpc. The bug has been reported and should be fixed > soon. > > When you compile with -g, does your command line contain -O2 ? > When compilng with -g, i didn't use -O2. turning on -O2 with -g causes the error to come back.. Coolness. Thanks for the help! dust From chl at math.uni-bonn.de Wed Feb 12 14:58:02 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Wed Feb 12 14:58:07 2003 Subject: [XviD-devel] VHQ In-Reply-To: <189427906.20030212231724@syskin.cjb.net> Message-ID: On Wed, 12 Feb 2003, Radek Czyz wrote: > What I discovered: when we do that PSNR drops. This is because when > we're minimizing MV bits, we move away from 'best match' in the > understanding of SAD. We can save some bits, but SAD of the match - > which means SAD of the MB in new picture [no dct to correct] - will > get worse. > > This is not big deal for quantizer 2, and this doesn't happen often at > quantizer 2 anyway. But for q6 that makes a _big_ difference. You mean that even between all possible positions with cbp==0 there can be big differences in how "good" the positions actually are? For quant==2 there aren't many positions with cbp==0 (because that's a statement about quantized DCTed differences), but for quant==6 there are many positions, and simply optimizing vector bits within those (which means going closer towards the prediction vector) is bad, because cbp==0 just means the residue is below some level, but not "how much". I guess it would be logical then not to use "bits", but differences between _unquantized_ DCT data, and since DCT in theory is an orthogonal operation, that should be equal to SSE with SAD acting as an approximation of this. So what we would need is a criterion _when_ the bits saved actually outweight the residual error, and it seems "needed bits" alone is not enough for this :-( Current implementation of search uses some kind of langrangian with fixed lambda-value (depending on quantizer), but this doesn't seem to be perfect, either, of course. Now what? Maybe we can use a method not to optmize total number of bits, but bits needed for residue coding? So we start from the best position after ME. If possible, position with best SSE, not with best SAD, but whatever... Then, we ignore vector bits and use gradient decent of needed bits for texture. That way, if we started with cbp==0 (so bits==0) we wouldn't move at all, but if we started with bits==N, we would at least lower this number by 1 in every succesful step of refinement. At the same time, the vector can get longer at most by 1 per step (if we use a small diamond pattern), so it shouldn't need more than 1 extra bit per step to encode. When we end up in a local minimum of residue-bits, we would at least not have _raised_ the total number of bits. But maybe this leads to no effect at all, or the motion field gets garbled, I have no idea, just thinking aloud... gruel From radoslaw at syskin.cjb.net Thu Feb 13 00:32:48 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Wed Feb 12 15:02:09 2003 Subject: [XviD-devel] VHQ In-Reply-To: <189427906.20030212231724@syskin.cjb.net> References: <189427906.20030212231724@syskin.cjb.net> Message-ID: <14113951812.20030213003248@syskin.cjb.net> Yahoo, code commited. According to my tests it works. Please check :) I have some other things I'd like to propose/ask/do/. 1. How about I'd commit this new (not new anymore) lumimasking code? Koepi's been including it in he's builds for a long time and it seems to be stable. It's also much better than the current one. I see no reason not to do that... 2. How about we moved to simple IDCT? The code is already there, but disabled. It's not included in VS's project, and I bet it's not included in all the makefiles, so I won't activate it myself. It _does_ give much better quality when the video is played with ffmpeg/ffdshow. 3. OK I'll fix that in a sec - when bframes are disabled, first frame is not forced to be intra - the second frame is. Just a small change... Please check if VHQ stuff works Radek From radoslaw at syskin.cjb.net Thu Feb 13 00:47:16 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Wed Feb 12 15:16:35 2003 Subject: [XviD-devel] VHQ In-Reply-To: References: Message-ID: <5314820250.20030213004716@syskin.cjb.net> > I guess it would be logical then not to use "bits", but differences > between _unquantized_ DCT data, and since DCT in theory is an orthogonal > operation, that should be equal to SSE with SAD acting as an approximation > of this. I also thought about checking total quantization error. In this case, this would do what we need. However, my tests with dequant->count error were horribly slow, and in fact it didn't help a thing. Also, we would have to create some relations between total error and bits (how much of an error should equal one bit?) and the whole search would not be so pure, nice and clean. I think I like the way it is now - if cbp = 0, we count on SAD. If not, we count bits. Radek From chl at math.uni-bonn.de Wed Feb 12 15:33:11 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Wed Feb 12 15:33:13 2003 Subject: [XviD-devel] VHQ In-Reply-To: <5314820250.20030213004716@syskin.cjb.net> Message-ID: On Thu, 13 Feb 2003, Radek Czyz wrote: > I think I like the way it is now - if cbp = 0, we count on SAD. If > not, we count bits. hm, but where is there difference between minimizing vector bits with fixed dct-bits between cbp!=0 and cbp==0 ? In the second case, there is no chance to lower number of dct-bits, okay, but still if we have several possibilites with same number of DCT-bits, vector bits don't give a clue which to choose, and minimizing them would be bad. I guess your method works, because due to the nature of video signal, it's less likely that DCT bits stay constants and vector bits done, unless everything is 0 from the beginning already, but still I have the impression that a method * "Optimize DCT bits under the condition of total bits not getting larger than what ME had found", instead of * "optimize total number of bits" would be worth looking at. I'll check a few samples how "# of bits" evolves during this search and see if it would make difference. gruel From ed.gomez at free.fr Wed Feb 12 16:16:45 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Wed Feb 12 16:16:58 2003 Subject: [XviD-devel] [RELEASE CANDIDATE] v0.9.1 In-Reply-To: References: <004e01c2d28f$9a9cf890$ba0407d5@mmpc> Message-ID: <20030212151645.GA816@leloo> Christoph Lampert (chl@math.uni-bonn.de) wrote: > Okay, that I didn't notice. outdated qpel cann off course not be part of > stable. The code has been disabled in my patch-20 revision, i did not modify bitstream.c as it is a very minor change (a dprintf error turned into a dprintf debug) -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030212/e5ac9dbe/attachment.bin From chl at math.uni-bonn.de Wed Feb 12 16:31:51 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Wed Feb 12 16:31:54 2003 Subject: [XviD-devel] VHQ In-Reply-To: <1624239796.20030212215056@syskin.cjb.net> Message-ID: On Wed, 12 Feb 2003, Radek Czyz wrote: > Heya everybody, > > I have good news - I fixed all known VHQ bugs and I'm preparing to > commit the code. Anyone would like to comment? What I mean is if > someone would like to stop me for whatever reason, please do it now. Nice indeed... even if I couldn't check anything else, yet, I got for foreman QCIF at different quality levels, fixed quant 6: without _BITS options Avg: enctime(ms) = 20.91, fps = 47.82, length(bytes) = 1430 <- FP Avg: enctime(ms) = 18.26, fps = 54.76, length(bytes) = 1461 FP+ext Avg: enctime(ms) = 26.41, fps = 37.87, length(bytes) = 1046 <- HP Avg: enctime(ms) = 27.45, fps = 36.43, length(bytes) = 1030 HP+ext Avg: enctime(ms) = 31.62, fps = 31.63, length(bytes) = 1018 <- HP+4MV Avg: enctime(ms) = 43.47, fps = 23.00, length(bytes) = 1004 HP+4+ext Avg: enctime(ms) = 74.31, fps = 13.46, length(bytes) = 814 <- QP+4+ext with many _BITS options Avg: enctime(ms) = 34.05, fps = 29.37, length(bytes) = 1425 -5 -0.3% Avg: enctime(ms) = 28.84, fps = 34.68, length(bytes) = 1455 -6 -0.3% Avg: enctime(ms) = 78.26, fps = 12.78, length(bytes) = 1017 -29 -2.6% Avg: enctime(ms) = 81.15, fps = 12.32, length(bytes) = 963 -65 -6.5% Avg: enctime(ms) = 115.36, fps = 8.67, length(bytes) = 947 -71 -6.9% Avg: enctime(ms) = 126.70, fps = 7.89, length(bytes) = 930 -74 -7.3% Avg: enctime(ms) = 222.01, fps = 4.50, length(bytes) = 763 -51 -6.2% Of course this is only 1 clip, I didn't check PSNR and speed dropped severely, etc, but it's quite a good start! gruel From chl at math.uni-bonn.de Wed Feb 12 18:27:16 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Wed Feb 12 18:27:26 2003 Subject: [XviD-devel] VHQ In-Reply-To: Message-ID: Hi, I did one more test, now with xvid_bstat, so PSNR is available: QCIF "Miss America" (very easy), maxb=2, bquant_ratio=2.00 without BITS, fixed quant 4 Q0 size 291 enc: 87.4 fps, dec: 371.1 fps PSNR P: 40.70 B: 40.86 Q1 size 239 enc: 72.6 fps, dec: 336.7 fps PSNR P: 41.93 B: 41.23 Q2 size 239 enc: 70.0 fps, dec: 320.9 fps PSNR P: 41.93 B: 41.23 Q3 size 234 enc: 66.1 fps, dec: 312.1 fps PSNR P: 41.94 B: 41.24 Q4 size 234 enc: 62.7 fps, dec: 341.2 fps PSNR P: 41.93 B: 41.24 Q5 size 206 enc: 40.5 fps, dec: 204.7 fps PSNR P: 41.89 B: 41.52 Q6 size 206 enc: 35.5 fps, dec: 190.4 fps PSNR P: 41.87 B: 41.50 with BITS , fixed quant 4 Q0 size 290 enc: 82.3 fps, dec: 389.6 fps PSNR P: 40.69 B: 40.84 Q1 size 230 enc: 71.1 fps, dec: 392.3 fps PSNR P: 41.79 B: 41.15 Q2 size 230 enc: 70.4 fps, dec: 394.1 fps PSNR P: 41.79 B: 41.15 Q3 size 220 enc: 60.6 fps, dec: 388.4 fps PSNR P: 41.74 B: 41.09 Q4 size 221 enc: 54.3 fps, dec: 389.9 fps PSNR P: 41.73 B: 41.08 Q5 size 196 enc: 31.1 fps, dec: 205.6 fps PSNR P: 41.66 B: 41.33 Q6 size 196 enc: 29.3 fps, dec: 208.0 fps PSNR P: 41.68 B: 41.34 >From this you can see that PSNR _drops_ for BITS, but size drops, too, without BITS, bitrate 128 (effective only 40-49) Q0 size 248 enc: 88.5 fps, dec: 393.4 fps PSNR P: 39.84 B: 40.17 Q1 size 235 enc: 86.5 fps, dec: 392.1 fps PSNR P: 41.81 B: 41.13 Q2 size 235 enc: 86.4 fps, dec: 394.2 fps PSNR P: 41.81 B: 41.13 Q3 size 235 enc: 84.0 fps, dec: 393.6 fps PSNR P: 41.89 B: 41.21 Q4 size 236 enc: 74.7 fps, dec: 392.0 fps PSNR P: 41.96 B: 41.24 Q5 size 232 enc: 40.7 fps, dec: 207.7 fps PSNR P: 42.20 B: 41.80 Q6 size 232 enc: 37.9 fps, dec: 208.2 fps PSNR P: 42.20 B: 41.79 with BITS, bitrate 128 (effective only 40-49) Q0 size 248 enc: 82.4 fps, dec: 392.2 fps PSNR P: 39.84 B: 40.16 Q1 size 237 enc: 69.9 fps, dec: 390.1 fps PSNR P: 41.85 B: 41.22 Q2 size 237 enc: 69.9 fps, dec: 390.4 fps PSNR P: 41.85 B: 41.22 Q3 size 237 enc: 59.7 fps, dec: 386.9 fps PSNR P: 41.98 B: 41.28 Q4 size 236 enc: 53.8 fps, dec: 385.0 fps PSNR P: 41.98 B: 41.27 Q5 size 235 enc: 30.3 fps, dec: 200.0 fps PSNR P: 42.28 B: 41.88 Q6 size 234 enc: 28.6 fps, dec: 201.4 fps PSNR P: 42.24 B: 41.84 Like in my other tests, BITS led to _better overall PSNR_, but its not 100% sure, because filesize also is about 1% higher as well. At home I'll test with more "intelligent" clips... Still, it should be possible to create a BITS variant where fixed quant PSNR does not drop, but bitrate is nevertheless reduced... gruel From chl at math.uni-bonn.de Wed Feb 12 18:49:09 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Wed Feb 12 18:49:12 2003 Subject: [XviD-devel] VHQ In-Reply-To: Message-ID: Hi, same here: PSNR&size drop for BITS, but in total it's a win. 400frames Foreman QCIF, maxb=2, bquant-ratio=2.00 no BITS, fixed quant 4 Q0 s 1799 e: 104.3 , d: 334.9 P(240): 36.20 B(154): 36.22 Q1 s 1309 e: 88.2 , d: 336.7 P(216): 36.71 B(178): 36.48 Q2 s 1309 e: 88.2 , d: 335.8 P(216): 36.71 B(178): 36.48 Q3 s 1264 e: 80.3 , d: 335.2 P(218): 36.75 B(176): 36.54 Q4 s 1219 e: 65.0 , d: 338.1 P(216): 36.75 B(178): 36.53 Q5 s 1050 e: 38.6 , d: 154.9 P(221): 36.98 B(173): 36.79 Q6 s 1038 e: 34.7 , d: 153.9 P(222): 36.92 B(172): 36.86 BITS, fixed quant 4 Q0 s 1779 e: 80.4 , d: 335.8 P(240): 36.27 B(154): 36.24 Q1 s 1281 e: 47.9 , d: 337.8 P(220): 36.67 B(174): 36.48 Q2 s 1281 e: 48.0 , d: 337.4 P(220): 36.67 B(174): 36.48 Q3 s 1180 e: 33.3 , d: 333.3 P(220): 36.61 B(174): 36.41 Q4 s 1147 e: 30.3 , d: 336.5 P(219): 36.62 B(175): 36.42 Q5 s 989 e: 17.5 , d: 152.9 P(221): 36.80 B(173): 36.67 Q6 s 970 e: 16.7 , d: 151.9 P(220): 36.76 B(174): 36.71 no BITS, bitrate 128kbps (effective: 89-96 kbps) Q0 s 630 e: 206.6, d: 503.5 P(384): 29.62 B( 10): 32.15 Q1 s 481 e: 108.8, d: 424.6 P(287): 32.03 B(107): 32.53 Q2 s 481 e: 109.0, d: 427.6 P(287): 32.03 B(107): 32.53 Q3 s 483 e: 94.6, d: 423.9 P(288): 32.17 B(106): 32.42 Q4 s 476 e: 72.6, d: 421.7 P(283): 32.18 B(111): 32.73 Q5 s 450 e: 43.5, d: 176.6 P(269): 32.74 B(125): 33.15 Q6 s 446 e: 38.4, d: 174.8 P(266): 32.82 B(128): 33.19 BITS, bitrate 128kbps (effective 89-96 kbps) Q0 s 630 e: 130.2 , d: 510.7 P(384): 29.52 B( 10): 32.19 Q1 s 484 e: 55.7 , d: 424.4 P(289): 32.14 B(105): 32.32 Q2 s 484 e: 55.7 , d: 426.1 P(289): 32.14 B(105): 32.32 Q3 s 479 e: 37.8 , d: 414.9 P(285): 32.19 B(109): 32.78 Q4 s 477 e: 33.2 , d: 412.8 P(283): 32.33 B(111): 32.92 Q5 s 448 e: 20.5 , d: 174.4 P(267): 32.85 B(127): 33.25 Q6 s 446 e: 19.3 , d: 173.5 P(266): 32.95 B(128): 33.41 We gain 0.1 to 0.2dB (except for fullpel, which hopefully nobody uses anyway) in exchange for losing half the speed. gruel P.S. Yes, I did notice that Q1 == Q2, I just forgot to remove it. ------------------------------------------------------------------- On Wed, 12 Feb 2003, Christoph Lampert wrote: > I did one more test, now with xvid_bstat, so PSNR is available: > QCIF "Miss America" (very easy), maxb=2, bquant_ratio=2.00 > > without BITS, fixed quant 4 > Q0 size 291 enc: 87.4 fps, dec: 371.1 fps PSNR P: 40.70 B: 40.86 > Q1 size 239 enc: 72.6 fps, dec: 336.7 fps PSNR P: 41.93 B: 41.23 > Q2 size 239 enc: 70.0 fps, dec: 320.9 fps PSNR P: 41.93 B: 41.23 > Q3 size 234 enc: 66.1 fps, dec: 312.1 fps PSNR P: 41.94 B: 41.24 > Q4 size 234 enc: 62.7 fps, dec: 341.2 fps PSNR P: 41.93 B: 41.24 > Q5 size 206 enc: 40.5 fps, dec: 204.7 fps PSNR P: 41.89 B: 41.52 > Q6 size 206 enc: 35.5 fps, dec: 190.4 fps PSNR P: 41.87 B: 41.50 > > with BITS , fixed quant 4 > Q0 size 290 enc: 82.3 fps, dec: 389.6 fps PSNR P: 40.69 B: 40.84 > Q1 size 230 enc: 71.1 fps, dec: 392.3 fps PSNR P: 41.79 B: 41.15 > Q2 size 230 enc: 70.4 fps, dec: 394.1 fps PSNR P: 41.79 B: 41.15 > Q3 size 220 enc: 60.6 fps, dec: 388.4 fps PSNR P: 41.74 B: 41.09 > Q4 size 221 enc: 54.3 fps, dec: 389.9 fps PSNR P: 41.73 B: 41.08 > Q5 size 196 enc: 31.1 fps, dec: 205.6 fps PSNR P: 41.66 B: 41.33 > Q6 size 196 enc: 29.3 fps, dec: 208.0 fps PSNR P: 41.68 B: 41.34 > > > >From this you can see that PSNR _drops_ for BITS, but size drops, too, > > without BITS, bitrate 128 (effective only 40-49) > Q0 size 248 enc: 88.5 fps, dec: 393.4 fps PSNR P: 39.84 B: 40.17 > Q1 size 235 enc: 86.5 fps, dec: 392.1 fps PSNR P: 41.81 B: 41.13 > Q2 size 235 enc: 86.4 fps, dec: 394.2 fps PSNR P: 41.81 B: 41.13 > Q3 size 235 enc: 84.0 fps, dec: 393.6 fps PSNR P: 41.89 B: 41.21 > Q4 size 236 enc: 74.7 fps, dec: 392.0 fps PSNR P: 41.96 B: 41.24 > Q5 size 232 enc: 40.7 fps, dec: 207.7 fps PSNR P: 42.20 B: 41.80 > Q6 size 232 enc: 37.9 fps, dec: 208.2 fps PSNR P: 42.20 B: 41.79 > > with BITS, bitrate 128 (effective only 40-49) > Q0 size 248 enc: 82.4 fps, dec: 392.2 fps PSNR P: 39.84 B: 40.16 > Q1 size 237 enc: 69.9 fps, dec: 390.1 fps PSNR P: 41.85 B: 41.22 > Q2 size 237 enc: 69.9 fps, dec: 390.4 fps PSNR P: 41.85 B: 41.22 > Q3 size 237 enc: 59.7 fps, dec: 386.9 fps PSNR P: 41.98 B: 41.28 > Q4 size 236 enc: 53.8 fps, dec: 385.0 fps PSNR P: 41.98 B: 41.27 > Q5 size 235 enc: 30.3 fps, dec: 200.0 fps PSNR P: 42.28 B: 41.88 > Q6 size 234 enc: 28.6 fps, dec: 201.4 fps PSNR P: 42.24 B: 41.84 > > > Like in my other tests, BITS led to _better overall PSNR_, but > its not 100% sure, because filesize also is about 1% higher as well. > At home I'll test with more "intelligent" clips... > > > Still, it should be possible to create a BITS variant where fixed quant > PSNR does not drop, but bitrate is nevertheless reduced... > > gruel > > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel > From elcabesa at inwind.it Wed Feb 12 18:48:15 2003 From: elcabesa at inwind.it (elcabesa) Date: Wed Feb 12 18:51:12 2003 Subject: [XviD-devel] VHQ In-Reply-To: <1624239796.20030212215056@syskin.cjb.net> References: <1624239796.20030212215056@syskin.cjb.net> Message-ID: <200302121848.15771.elcabesa@inwind.it> when enabling your new code sohuld i disable other morion search? or this is an addon? i'm doing some test and i get small filesize , but moving object leave behind them a "scia" i don't know how to translate this word..... it is the whie tline behind a airplane or a boat =) soory for my puoi english From chl at math.uni-bonn.de Wed Feb 12 19:27:18 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Wed Feb 12 19:27:22 2003 Subject: [XviD-devel] VHQ In-Reply-To: Message-ID: Hi, me again, for the last time, promised: I forgot to do the most important check: just mode decision, no DCT-refinement (inspired by vhq mode in ffmpeg): foreman, maxb=2, bquant_ratio=2.00, etc. BITS-mode-decision, Fixed Quant 4 Q0 s 1779 e: 79.3 , d: 334.5 P(240): 36.27 B(154): 36.24 Q1 s 1306 e: 70.9 , d: 328.5 P(215): 36.72 B(179): 36.51 Q2 s 1306 e: 63.3 , d: 291.9 P(215): 36.72 B(179): 36.51 Q3 s 1217 e: 56.5 , d: 315.4 P(220): 36.77 B(174): 36.53 Q4 s 1175 e: 48.6 , d: 315.6 P(217): 36.80 B(177): 36.48 Q5 s 1012 e: 31.5 , d: 147.5 P(220): 36.94 B(174): 36.84 Q6 s 1004 e: 29.3 , d: 147.4 P(223): 36.97 B(171): 36.82 BITS-mode-decision, bitrate 128 Q0 s 630 e: 129.2 , d: 510.1 P(384): 29.52 B( 10): 32.19 Q1 s 477 e: 87.9 , d: 421.5 P(284): 32.00 B(110): 32.52 Q2 s 477 e: 87.5 , d: 427.6 P(284): 32.00 B(110): 32.52 Q3 s 474 e: 70.8 , d: 416.0 P(282): 32.28 B(112): 32.81 Q4 s 469 e: 56.6 , d: 416.6 P(279): 32.40 B(115): 32.82 Q5 s 446 e: 37.0 , d: 175.3 P(266): 32.94 B(128): 33.34 Q6 s 440 e: 32.8 , d: 173.0 P(262): 33.03 B(132): 33.43 If you compare these two to the previous mail, you see the real thing: For fixed quant, PSNR gets slightly _higher_ while bitrate drops (not as much as for BITS-refinement, but significant). For bitrate mode, PSNR is clearly higher than no-BITS or BITS-refine, while speed drops much less (not by 50% less fps, but only 10-20%) gruel From radoslaw at syskin.cjb.net Thu Feb 13 19:52:42 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Thu Feb 13 10:21:32 2003 Subject: [XviD-devel] VHQ In-Reply-To: References: Message-ID: <1883576687.20030213195242@syskin.cjb.net> Thanks for the results, Christoph. First of all, I'm happy it works. The tests you've conducted have the same results as mine. There are 3 things on my VHQ-related todo list now: - do something about the speed. in particular, when we compute cbp, we can remember it (put it in MACROBLOCK struct <-- this doesn't sound so good). In motion compensation we could use transfer8x8_copy instead if transfer_8to16sub for blocks which will not be coded. We would also skip fdct + quantization for these blocks. - experiment more and discover if we could do something about this PSNR drop. Perhaps we should skip _BITS refinement/search (leave only decision) for macroblocks where _any_ luma dct block is zero? or two? or three? just an idea. - use it for mcsel in GMC. should work good. The problem I would _really_ like to fix is this B-frames flickering I hate so much. Stupid bug, it's even difficult to prove it exists. But it does exist. Best regards, Radek From chl at math.uni-bonn.de Thu Feb 13 10:50:34 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Thu Feb 13 10:50:37 2003 Subject: [XviD-devel] VHQ In-Reply-To: <1883576687.20030213195242@syskin.cjb.net> Message-ID: On Thu, 13 Feb 2003, Radek Czyz wrote: > Thanks for the results, Christoph. > > First of all, I'm happy it works. The tests you've conducted have the > same results as mine. > > There are 3 things on my VHQ-related todo list now: > > - do something about the speed. in particular, when we compute > cbp, we can remember it (put it in MACROBLOCK struct <-- this doesn't > sound so good). In motion compensation we could use > transfer8x8_copy instead if transfer_8to16sub for blocks which > will not be coded. We would also skip fdct + quantization for these > blocks. My first idea would be to not always use _BITS for mode decision but only in "difficult cases". For this we should first a huge data file, maybe of the data we could use for mode decision: 1) SAD after ME 2) variance of current block Maybe we could add 3) length of pmv , but I don't know if this helps. Those are the "training samples". Then we need "teaching data" which won't be available to the final algorithm. 4) bits for INTRA 5) bits for INTER And we should be able to find regions of classification: A) Surely to be INTERed (e.g. if SAD is below some threshhold) B) Surely to be INTRAed (e.g. if variance is above some threshhold?) C) doubtfull (blocks with this 1)-3) are not clearly INTER or INTRA) >From this we could implement a general rule and call _BITS mode decision only if we detect a C) case. I doubt that this is going to be more than 5%. Radek, since you know best what is calculated when, could you add a #ifdef or some dprintf which simply print 1)-5) (or at least 1,2,4,5) to stderr or a file when running in _BITS mode? Doesn't have to be in CVS, but just as a quick hack for developers/testers? > - experiment more and discover if we could do something about this > PSNR drop. Perhaps we should skip _BITS refinement/search (leave only > decision) for macroblocks where _any_ luma dct block is zero? or two? > or three? just an idea. When I have time, I'll try my "minimize TEXTURE bits" idea. > The problem I would _really_ like to fix is this B-frames flickering I > hate so much. Stupid bug, it's even difficult to prove it exists. But > it does exist. Can it be reproduced on "artificial" images? Are you sure that it's really a bug and not due to some quantization rounding or something? gruel From elcabesa at inwind.it Thu Feb 13 10:55:59 2003 From: elcabesa at inwind.it (elcabesa) Date: Thu Feb 13 10:58:57 2003 Subject: [XviD-devel] VHQ In-Reply-To: <200302121848.15771.elcabesa@inwind.it> References: <1624239796.20030212215056@syskin.cjb.net> <200302121848.15771.elcabesa@inwind.it> Message-ID: <200302131055.59684.elcabesa@inwind.it> On Wednesday 12 February 2003 18:48, elcabesa wrote: > when enabling your new code sohuld i disable other morion search? or this > is an addon? > > i'm doing some test and i get small filesize , but moving object leave > behind them a "scia" i don't know how to translate this word..... it is the > whie tline behind a airplane or a boat =) soory for my puoi english sorry i was totally wrong From chl at math.uni-bonn.de Thu Feb 13 14:18:17 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Thu Feb 13 14:18:21 2003 Subject: [XviD-devel] VHQ In-Reply-To: <1883576687.20030213195242@syskin.cjb.net> Message-ID: Hi, in new ModeDecision you call dev16() for deviation of current block four times, I guess its supposed to sum up the subblocks, but dev16 acts on 16x16 blocks! We don't have a dev8() routine... deviation = dev16(Data->Cur, Data->iEdgedWidth) + dev16(Data->Cur+8, Data->iEdgedWidth) + dev16(Data->Cur + 8*Data->iEdgedWidth,Data->iEdgedWidth) + dev16(Data->Cur+8+8*Data->iEdgedWidth,Data->iEdgedWidth); It that a typo? gruel From radoslaw at syskin.cjb.net Fri Feb 14 00:04:23 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Thu Feb 13 14:34:02 2003 Subject: [XviD-devel] VHQ In-Reply-To: References: Message-ID: <15818678296.20030214000423@syskin.cjb.net> Hello Christoph, > deviation = dev16(Data->Cur, Data->iEdgedWidth) + > dev16(Data->Cur+8, Data->iEdgedWidth) + > dev16(Data->Cur + 8*Data->iEdgedWidth,Data->iEdgedWidth) + > dev16(Data->Cur+8+8*Data->iEdgedWidth,Data->iEdgedWidth); > It that a typo? well, the line before is: if (!Data->rrv) deviation = dev16(Data->Cur, Data->iEdgedWidth); else [and the code you quote] Data->rrv says that we're encoding at reduced resolution.... Radek PS .... so it IS a typo. not 8 but 16! Damn.... lol From radoslaw at syskin.cjb.net Fri Feb 14 00:21:00 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Thu Feb 13 14:49:56 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: References: Message-ID: <16219674906.20030214002100@syskin.cjb.net> I said >> The problem I would _really_ like to fix is this B-frames flickering I >> hate so much. Stupid bug, it's even difficult to prove it exists. But >> it does exist. Gruel said > Can it be reproduced on "artificial" images? Are you sure that it's really > a bug and not due to some quantization rounding or something? I just created a clip where it's really visible. It took some experiments but here it is. http://noa.sm.pl/~syskin/makurukurushike.avi People who understand the filename... don't have to wonder about the filename. I don't really understand why I suceeded so much about the blocks in this particular clip. Code has not been changed, even BITS have not been used. Just qpel + bframes. Still, this is the first clip which I can show as a definite proof. Now, I'll buy a pack of beer for a person who will tell me what macroblock mode is used in the macroblocks with dark blocks. ^ we have to meet first for the beer. First tests show that this is not asm problem - plain C creates the same clip. Please help me with this one... Radek From marco at simplex.nl Thu Feb 13 14:50:54 2003 From: marco at simplex.nl (Marco Al) Date: Thu Feb 13 14:50:47 2003 Subject: [XviD-devel] VHQ References: Message-ID: <004001c2d366$edd9e400$bca45982@cal046201> From: "Christoph Lampert" > So what we would need is a criterion _when_ the bits saved actually > outweight the residual error, and it seems "needed bits" alone is not > enough for this :-( Current implementation of search uses some kind of > langrangian with fixed lambda-value (depending on quantizer), but this > doesn't seem to be perfect, either, of course. > > Now what? I havent taken a look at ffmpeg's code, but it says its dct based ME is R-D optimized ... maybe take a look? A lagrangian multiplier technique where you update the multiplier based on history and the rate targets from rate control (not easy) might work, and shouldnt be noticably slower than the pure rate based search (apart from the fact that there is no early out from the SAD based search). Marco From chl at math.uni-bonn.de Thu Feb 13 14:52:10 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Thu Feb 13 14:52:12 2003 Subject: [XviD-devel] Mode decision Message-ID: Hi, from the logfile which a modified version of syskins mode decision generates, it seems clear to me, that the decision INTER/INTER4V is the crucial part. In foreman and miss_america, INTRA blocks are hardly present, but still BITS-decision manages to significanty lower bitrate. I plotted the "sad16 / sad8"-values of those blocks who were classified INTER using bitcount (green) and those who classified INTER4V (red). The blue line is approximately our current decision method: sad16INTER4V or vice versa would cost in extra bits. And you also cannot see that there are hardly any real INTER4V blocks with sad16 below 600. So maybe this would be a way to speed things up, simply not doing inter4v for those. But of course I only tested one clip so far. gruel -------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦xƒSì ÔÄG…ižò¥è¦j¿¦x‹7µë¯wo+^°7¬qJå†Ûiÿ÷¹¹á¡÷^þ˜©z¹šŠ_ñ¾']z÷¥ý«miÈfz{lÿm4ßMµß÷7wg÷×oÈ51¾Â LDxV™à From chl at math.uni-bonn.de Thu Feb 13 15:13:05 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Thu Feb 13 15:13:10 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: <16219674906.20030214002100@syskin.cjb.net> Message-ID: On Fri, 14 Feb 2003, Radek Czyz wrote: > I just created a clip where it's really visible. It took some > experiments but here it is. > http://noa.sm.pl/~syskin/makurukurushike.avi > > I don't really understand why I suceeded so much about the blocks in > this particular clip. Code has not been changed, even BITS have not > been used. Just qpel + bframes. Still, this is the first clip which I > can show as a definite proof. > > Now, I'll buy a pack of beer for a person who will tell me what > macroblock mode is used in the macroblocks with dark blocks. > ^ we have to meet first for the beer. Decoding with ffmpeg in macroblock-debug mode (change PRINT_MB_TYPE(a) in h263.c) should be helpful here :-) gruel From ed.gomez at free.fr Thu Feb 13 21:57:51 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Thu Feb 13 21:58:06 2003 Subject: [XviD-devel] [RELEASE] XviD 0.9.1 taged on CVS Message-ID: <20030213205751.GB6131@leloo> Hello, as nobody complained for the RC1, I tagged the CVS for this release. The tag is release-0_9_1. I'll prepare tarballs tonight and they will be available on my public web space at: http://ed.gomez.free.fr/ Well, now the bad news related to CVS branches and all fun around CVS... :-) Merging is clearly impossible, there are conflict for all the files. So nice merging will not be possible. I propose a nasty solution that is based on a method that proves to be efficient :-): - cvs checkout -r dev-api-3 - cvs checkout - copy files from dev to stable - add new files from dev to stable - commit all changes at once - tag the tree - repeat until all is working - All done -- every one is happy :) Drawbacks: I can break all the stuff, to avoid that i'll process on an atomic approach, commiting all at once until it works and using temporrary tags to be able to delete things easily (cvs admin -o merging-tmp). If nobody is against that, i would like that nobody commit a change to CVS tomorrow starting from 6pm GMT to avoid clashes and forgoten patches in dev-api-3. Thanks -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030213/4083c1b2/attachment.bin From ed.gomez at free.fr Thu Feb 13 23:13:43 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Thu Feb 13 23:13:54 2003 Subject: [XviD-devel] [RELEASE] XviD 0.9.1 taged on CVS In-Reply-To: <20030213205751.GB6131@leloo> References: <20030213205751.GB6131@leloo> Message-ID: <20030213221343.GC6131@leloo> Edouard Gomez (ed.gomez@free.fr) wrote: > The tag is release-0_9_1. I'll prepare tarballs tonight and they will be > available on my public web space at: http://ed.gomez.free.fr/ Michael, could you upload that files to the xvid files server and copy paste the announce on the website ? Thanks -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030213/b135539a/attachment.bin From chenm001 at 163.com Fri Feb 14 14:38:25 2003 From: chenm001 at 163.com (CM) Date: Fri Feb 14 07:39:54 2003 Subject: [XviD-devel] DCT for Philips Trimedia Message-ID: <200302140638.h1E6cNrA031646@edu.bnhof.de> Hi: I will portab the Xvid to Trimedia CPU. That is a DCT module. and I will send other module soon. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡CM ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡chenm001@163.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-02-14 -------------- next part -------------- A non-text attachment was scrubbed... Name: dct_trimedia.c Type: application/octet-stream Size: 7745 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030214/2eece3bb/dct_trimedia.obj From chenm001 at 163.com Fri Feb 14 14:39:48 2003 From: chenm001 at 163.com (CM) Date: Fri Feb 14 07:39:57 2003 Subject: [XviD-devel] DCT for Philips Trimedia Message-ID: <200302140639.h1E6dmtg024189@s3.lansco.de> Hi: I will portab the Xvid to Trimedia CPU. That is a DCT module. and I will send other module soon. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡CM ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡chenm001@163.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-02-14 -------------- next part -------------- A non-text attachment was scrubbed... Name: dct_trimedia.c Type: application/octet-stream Size: 7745 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030214/b28c4263/dct_trimedia.obj From suxen_drol at hotmail.com Fri Feb 14 18:12:59 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Fri Feb 14 08:13:05 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: <16219674906.20030214002100@syskin.cjb.net> References: <16219674906.20030214002100@syskin.cjb.net> Message-ID: <20030214180918.F1D0.SUXEN_DROL@hotmail.com> On Fri, 14 Feb 2003 00:21:00 +1030 Radek Czyz wrote: > First tests show that this is not asm problem - plain C creates the > same clip. > > Please help me with this one... radek: can u dump the original/uncompressed frames on your website? (use huffyuv or sth). -- pete; life is like a box of ammo From chenm001 at 163.com Fri Feb 14 17:18:37 2003 From: chenm001 at 163.com (CM) Date: Fri Feb 14 10:18:48 2003 Subject: [XviD-devel] DCT for Philips Trimedia Message-ID: <200302140918.h1E9IZrA010156@edu.bnhof.de> Hi: I rewrite some code, then I set the const_bits to 14, it may be to have a good precision. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡CM ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡chenm001@163.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-02-14 -------------- next part -------------- A non-text attachment was scrubbed... Name: dct1_trimedia.c Type: application/octet-stream Size: 8661 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030214/3240c301/dct1_trimedia.obj From radoslaw at syskin.cjb.net Fri Feb 14 21:03:08 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Fri Feb 14 11:32:21 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: <16219674906.20030214002100@syskin.cjb.net> References: <16219674906.20030214002100@syskin.cjb.net> Message-ID: <12330307875.20030214210308@syskin.cjb.net> Hello, > Now, I'll buy a pack of beer for a person who will tell me what > macroblock mode is used in the macroblocks with dark blocks. I guess that would be me :)) The dark blocks appear in direct mode macroblocks. I've created a horrible debug-output system, and this is what I've found: Everything works correctly. Except that I don't know why it works this way. Strange? The dark blocks appear because after motion compensation (in encoder), transquant functions notice that motion compensated image is too bright. To counter this, DC value of luma blocks in all macroblocks (or maybe only direct macroblocks?) is negative. This value is not very big, and it's usually quatized to zero. However, it's sometimes bigger and quantized to 1. This creates a dark block. fDCT function is right - the average of all 64 16-bit data from transfer8to16sub2 is indeed negative. transfer8to16sub2 also seems to be working correctly, I checked (and used) c-version several times. So the question is - WHY COMPENSATED IMAGE IS TOO BRIGHT _or_ WHY "current" image is too dark. And also, why motion estimation doesn't do anything about it - we all know that sad-based ME is very sensitive to mean luminance. This shift only applies to luma blocks, mean error of compensated chroma blocks is zero+gaussian distribution, as it should be. Also, this doesn't happen to forward or backward mode. I also failed to find any problems with interpolate mode, but then again it's not very common and I might have not noticed. At the very end of my tests I've also conducted this experiment: After fDCT, if macroblock's mode is direct, set DC value of all four luma blocks to zero. Guess what. Even though it was completely wrong, the image was looking perfect - no flickering, no artifacts, nothing... This is all very strange. Please notice that DC value is usually zero. All 'bad' blocks I found had quantized DC = -1 and all other coefficients = 0 (coeff[0] == -1 ; sum == 1;). This does not happen. Any comments? Am I missing something? Are we all missing something?... Best Regards, Radek From chl at math.uni-bonn.de Fri Feb 14 14:26:33 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Fri Feb 14 14:26:36 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: <12330307875.20030214210308@syskin.cjb.net> Message-ID: On Fri, 14 Feb 2003, Radek Czyz wrote: > > So the question is - WHY COMPENSATED IMAGE IS TOO BRIGHT _or_ WHY > "current" image is too dark. And also, why motion estimation doesn't > do anything about it - we all know that sad-based ME is very sensitive > to mean luminance. Okay, I never had problems with blinking blocks, so maybe its compiler dependent, too, and my first idea isn't too ridiculous. Maybe by checking several routines, we'll find the right one in the end. First candidate for a check is the transfer-function which is only called for direct and interpolated mode. Is it possible that the calculation of r in transfer_8to16sub2_c is done wrong, depending on the compiler? int r = (ref1[j * stride + i] + ref2[j * stride +i] + 1) / 2; ref1[N] and ref2[N] are both uint8_t. Is it possible that the compiler decides to calculate the sum in 8bits unsigned before dividing by 2, thus overflowing if the sum is larger than 255? Then of course r would be too small, and since r is subtracted from c, the values would end up being too large = bright. My gcc doesn't do this, it always seems to calculate with ints. But who knows... gruel ------------------------------------ void transfer_8to16sub2_c(int16_t * const dct, uint8_t * const cur, const uint8_t * ref1, const uint8_t * ref2, const uint32_t stride) { uint32_t i, j; for (j = 0; j < 8; j++) { for (i = 0; i < 8; i++) { uint8_t c = cur[j * stride + i]; int r = (ref1[j * stride + i] + ref2[j * stride +i] + 1) / 2; //fprintf(stderr,"%d %d\n",((int16_t)ref1[j*stride+i] +(int16_t)ref2[j*stride+i]+1)/2,r); if (r > 255) { r = 255; } //cur[j * stride + i] = r; dct[j * 8 + i] = (int16_t) c - (int16_t) r; } } } Btw. there does the check for (r>255) come from??? Since 0 <= [0,255]+[0,255]+1 <= 511 and 511/2 = 255 (/2 rounds to 0), the path is never taken... gruel From chl at math.uni-bonn.de Fri Feb 14 14:54:51 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Fri Feb 14 14:54:54 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: Message-ID: No, wait, this was only in QPel mode, right? Then forget it... gruel On Fri, 14 Feb 2003, Christoph Lampert wrote: > On Fri, 14 Feb 2003, Radek Czyz wrote: > > > > So the question is - WHY COMPENSATED IMAGE IS TOO BRIGHT _or_ WHY > > "current" image is too dark. And also, why motion estimation doesn't > > do anything about it - we all know that sad-based ME is very sensitive > > to mean luminance. > > Okay, I never had problems with blinking blocks, so maybe its compiler > dependent, too, and my first idea isn't too ridiculous. Maybe by checking > several routines, we'll find the right one in the end. > > First candidate for a check is the transfer-function which is only called > for direct and interpolated mode. > > Is it possible that the calculation of r in transfer_8to16sub2_c > is done wrong, depending on the compiler? > > int r = (ref1[j * stride + i] + ref2[j * stride +i] + 1) / 2; > > ref1[N] and ref2[N] are both uint8_t. Is it possible that the compiler > decides to calculate the sum in 8bits unsigned before dividing by 2, thus > overflowing if the sum is larger than 255? Then of course r would be too > small, and since r is subtracted from c, the values would end up being too > large = bright. > > My gcc doesn't do this, it always seems to calculate with ints. But who > knows... > > gruel > ------------------------------------ > void > transfer_8to16sub2_c(int16_t * const dct, > uint8_t * const cur, > const uint8_t * ref1, > const uint8_t * ref2, > const uint32_t stride) > { > uint32_t i, j; > > for (j = 0; j < 8; j++) { > for (i = 0; i < 8; i++) { > uint8_t c = cur[j * stride + i]; > int r = (ref1[j * stride + i] + ref2[j * stride +i] + 1) / 2; > //fprintf(stderr,"%d %d\n",((int16_t)ref1[j*stride+i] +(int16_t)ref2[j*stride+i]+1)/2,r); > if (r > 255) { > r = 255; > } > //cur[j * stride + i] = r; > dct[j * 8 + i] = (int16_t) c - (int16_t) r; > } > } > } > > Btw. there does the check for (r>255) come from??? > Since 0 <= [0,255]+[0,255]+1 <= 511 and 511/2 = 255 (/2 rounds to 0), > the path is never taken... > > gruel > > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel > From radoslaw at syskin.cjb.net Sat Feb 15 00:25:30 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Fri Feb 14 14:55:07 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: References: Message-ID: <14742449906.20030215002530@syskin.cjb.net> Hi, >ref1[N] and ref2[N] are both uint8_t. Is it possible that the compiler >decides to calculate the sum in 8bits unsigned before dividing by 2, thus >overflowing if the sum is larger than 255? Then of course r would be too >small, and since r is subtracted from c, the values would end up being too >large = bright. I had the same idea, and I changed the code to int r = ((int)ref1[j * stride + i] + (int)ref2[j * stride +i] + 1) / 2; And it didn't help. Please remember that we're talking about the values being too big by 2..5 ... About the compiler, I can only say that Intel Compiler gives the same result. From dknop at gwdg.de Fri Feb 14 15:00:06 2003 From: dknop at gwdg.de (Dirk Knop) Date: Fri Feb 14 15:00:18 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: References: Message-ID: <3E4CF666.1050509@gwdg.de> Hi, no, this happens in bframes - qpel just amplifies the effect a little IMO. regards Koepi Christoph Lampert wrote: >No, wait, this was only in QPel mode, right? >Then forget it... > >gruel > > From radoslaw at syskin.cjb.net Sat Feb 15 00:35:40 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Fri Feb 14 15:05:15 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: References: Message-ID: <3143059921.20030215003540@syskin.cjb.net> > No, wait, this was only in QPel mode, right? > Then forget it... No! Unfortunetly, abolutely not :( For some reason it's usually easier to notice it in qpel, but I just encoded the same clip with hpel and there is one frame where two blocks are just horribly wrong (I wonder if that's -1 only - might be -2) From chl at math.uni-bonn.de Fri Feb 14 17:00:16 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Fri Feb 14 17:00:19 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: <14742449906.20030215002530@syskin.cjb.net> Message-ID: On Sat, 15 Feb 2003, Radek Czyz wrote: > Hi, > > >ref1[N] and ref2[N] are both uint8_t. Is it possible that the compiler > >decides to calculate the sum in 8bits unsigned before dividing by 2, thus > >overflowing if the sum is larger than 255? Then of course r would be too > >small, and since r is subtracted from c, the values would end up being too > >large = bright. > > I had the same idea, and I changed the code to > > int r = ((int)ref1[j * stride + i] + (int)ref2[j * stride +i] + 1) / 2; > > And it didn't help. Please remember that we're talking about the > values being too big by 2..5 ... Okay, a lot of questions, because I still coulnd't produce any blocks. Just some ideas what I would check, if I could: Does it happen without INTER4V? If yes, always switch that off, it makes analysis of direct mode much easier. How did you notice the image was too bright? Did you output the compensated pic (maybe mean value of blocks after compensation)? Or did you get that impression from the DCTed data? Is it really reproducable now, so can you "measure" it at some point in the processing queue? If yes: Does the bias depend on quantizer? If I'm not mistaken, the "too bright" effect is there also without "too dark" blocks, but not always visible due to quantization. So it would be a possible to check if it is only there for DIRECT mode, or for the complete picture. Is it present if all DIRECT blocks are forced to be INTERPOLATE? gruel From chl at math.uni-bonn.de Fri Feb 14 17:03:40 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Fri Feb 14 17:03:43 2003 Subject: [XviD-devel] VHQ In-Reply-To: <15818678296.20030214000423@syskin.cjb.net> Message-ID: Hey Radek, for mode decision, I need the SAD8-values of an MB after INTER search but before INTER4V search. I believe sad16v writes them to iMinSAD[1]-[4], right? Are these values stored somewhere, so I can access them in mode decision, or do I have to put the code before INTER4V search is started. gruel From radoslaw at syskin.cjb.net Sat Feb 15 02:52:01 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Fri Feb 14 17:21:10 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: References: Message-ID: <351241203.20030215025201@syskin.cjb.net> > Does it happen without INTER4V? If yes, always switch that off, it makes > analysis of direct mode much easier. Yes, I actually had a debug version which printed both current mode and future mode - it was happening in both. > How did you notice the image was too bright? Did you output the > compensated pic (maybe mean value of blocks after compensation)? Or did > you get that impression from the DCTed data? Is it really reproducable > now, so can you "measure" it at some point in the processing queue? First, I just used DC value after fdct. When I saw what's happening I also checked the values before fdct, to see if it's not fdct problem. Take a look at this dark block: block number 2 before fdct: -2 -4 -1 -1 0 -4 -3 -3 -2 -2 -1 1 0 -2 -3 -2 1 -1 -2 -2 1 -3 -2 -2 -2 -1 -3 1 1 -2 -4 -2 -2 -1 -3 -3 -1 -3 -2 -4 -3 -3 -3 -3 -2 -2 -3 -3 -1 0 -1 -3 -1 0 1 -2 -3 -1 -1 -3 -3 0 0 -3 DC value is -14, quantized to -1. AC values are 0. Mode direct, compensated with "MODE_DIRCT" as this is quarterpel and _NO4V is not available. > If yes: Does the bias depend on quantizer? I'm pretty sure that very high quantizer would produce more zeroes - quantization looks correct here. > If I'm not mistaken, the "too bright" effect is there also > without "too dark" blocks, but not always visible due to > quantization. No, the 8-bit compensated image is never too bright in the decoder. If it was, this DC value of fdct would make it correct. But it isn't too bright and this DC makes it visibly darker compared to all spatial and temporal neighbours. I adimit I'll have to check MC in encoder somehow... > Is it present if all DIRECT > blocks are forced to be INTERPOLATE? It's a very very good idea. I'll check that tommorow. I'll also make sure if simply interpolate has the problem. Radek From radoslaw at syskin.cjb.net Sat Feb 15 02:55:14 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Fri Feb 14 17:24:15 2003 Subject: [XviD-devel] VHQ In-Reply-To: References: Message-ID: <13951434406.20030215025514@syskin.cjb.net> > for mode decision, I need the SAD8-values of an MB after INTER search but > before INTER4V search. I believe sad16v writes them to iMinSAD[1]-[4], > right? Are these values stored somewhere, so I can access them in mode > decision, or do I have to put the code before INTER4V search is started. Yes, iMinSAD[1..4] will have the best 8x8 SADs found during 16x16 search. However, first block ( iMinSAD[1] ) will have it's motion vector added (predicion was known during 16x16 search), but all other blocks will not have this added. It's fixed at the very beginning of search8() function. Radek From elcabesa at inwind.it Fri Feb 14 18:43:56 2003 From: elcabesa at inwind.it (elcabesa) Date: Fri Feb 14 18:46:59 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: <351241203.20030215025201@syskin.cjb.net> References: <351241203.20030215025201@syskin.cjb.net> Message-ID: <200302141843.57084.elcabesa@inwind.it> i'm testing xvid on linux using mplayer on an athlon machine i downloaded you LORD of the ring small avi and decode it.. i have tried to set luminance of screen higer and higer but it seems that i get no black block.. can you explain me how is the problem.. maybe i didn't see it..( and where is in your small avi =) ) becouse if it'sn ot present here maybe it's a WINDOWS compiler bug or a intel problem , and if you know what it really is you can combat it better =) From chl at math.uni-bonn.de Fri Feb 14 19:04:45 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Fri Feb 14 19:04:47 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: <351241203.20030215025201@syskin.cjb.net> Message-ID: On Sat, 15 Feb 2003, Radek Czyz wrote: > First, I just used DC value after fdct. When I saw what's happening I > also checked the values before fdct, to see if it's not fdct problem. > > Take a look at this dark block: > > block number 2 before fdct: > > -2 -4 -1 -1 0 -4 -3 -3 > -2 -2 -1 1 0 -2 -3 -2 > 1 -1 -2 -2 1 -3 -2 -2 > -2 -1 -3 1 1 -2 -4 -2 > -2 -1 -3 -3 -1 -3 -2 -4 > -3 -3 -3 -3 -2 -2 -3 -3 > -1 0 -1 -3 -1 0 1 -2 > -3 -1 -1 -3 -3 0 0 -3 > > DC value is -14, quantized to -1. AC values are 0. Mode direct, > compensated with "MODE_DIRCT" as this is quarterpel and _NO4V is not > available. And there are no such blocks with potive values? DC==+14 quantized to +1 ? > > If I'm not mistaken, the "too bright" effect is there also > > without "too dark" blocks, but not always visible due to > > quantization. > > No, the 8-bit compensated image is never too bright in the decoder. I didn't mean that. I meant do _all_ blocks have this slightly negative values (-3, -3, 0, -2, 1), but most of the time this is quantized to 0. Only in rare cases it's quantized to 1 and the block become "dark flickering". Or are the blocks with negative value exceptions? gruel From chl at math.uni-bonn.de Fri Feb 14 19:39:02 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Fri Feb 14 19:39:05 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: <3E4CF666.1050509@gwdg.de> Message-ID: On Fri, 14 Feb 2003, Dirk Knop wrote: > Hi, > > no, this happens in bframes - qpel just amplifies the effect a little IMO. Crucial question, since I'm still not sure it's a bug: Are flickering dark blocks also there with bquant_ratio == 100 ? Couldn't it simply be a quantization problem which happens in Bframes because quantizer is higher there, so a difference of 1 in the quantized values is really visible? This doesn't happen in P-frames with high quants, because there overall quality is worse, so you don't notice the "bad" block. On in the mixture between high quality reference pictures and highly quantized differential image it's more visible? gruel From ed.gomez at free.fr Sat Feb 15 00:47:33 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sat Feb 15 00:47:55 2003 Subject: [XviD-devel] [RELEASE] XviD 0.9.1 taged on CVS In-Reply-To: <20030213205751.GB6131@leloo> References: <20030213205751.GB6131@leloo> Message-ID: <20030214234733.GI1013@leloo> Edouard Gomez (ed.gomez@free.fr) wrote: > Merging is clearly impossible, there are conflict for all the files. So > nice merging will not be possible. I propose a nasty solution that is > based on a method that proves to be efficient :-): > - cvs checkout -r dev-api-3 > - cvs checkout > - copy files from dev to stable > - add new files from dev to stable > - commit all changes at once - tag the tree > - repeat until all is working > - All done -- every one is happy :) > > Drawbacks: I can break all the stuff, to avoid that i'll process on an > atomic approach, commiting all at once until it works and using > temporrary tags to be able to delete things easily (cvs admin -o > merging-tmp). > > If nobody is against that, i would like that nobody commit a change to > CVS tomorrow starting from 6pm GMT to avoid clashes and forgoten patches > in dev-api-3. Hmmm, I've been busy with other stuff, doing lot of personal backup, sorry. Btw I'll use arch to help me doing things on my own tree (because it handles rename/moving operations an so on) so you can coninue commiting. I'll do like the build process patch, i'll commit only when i have my own tree completely merged. Will be ready befaore the end of the week end. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030215/99aba382/attachment.bin From suxen_drol at hotmail.com Sat Feb 15 13:42:22 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Sat Feb 15 03:42:28 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: <351241203.20030215025201@syskin.cjb.net> References: <351241203.20030215025201@syskin.cjb.net> Message-ID: <20030215131004.34C8.SUXEN_DROL@hotmail.com> On Sat, 15 Feb 2003 02:52:01 +1030 Radek Czyz wrote: > First, I just used DC value after fdct. When I saw what's happening I > also checked the values before fdct, to see if it's not fdct problem. > > Take a look at this dark block: > > block number 2 before fdct: > > -2 -4 -1 -1 0 -4 -3 -3 > -2 -2 -1 1 0 -2 -3 -2 > 1 -1 -2 -2 1 -3 -2 -2 > -2 -1 -3 1 1 -2 -4 -2 > -2 -1 -3 -3 -1 -3 -2 -4 > -3 -3 -3 -3 -2 -2 -3 -3 > -1 0 -1 -3 -1 0 1 -2 > -3 -1 -1 -3 -3 0 0 -3 looking through 'makurukurushike.avi,' it appears all the bframes use quant=7, whilst i/pframes use quant=4. if we take the above "input" matix, and pipe it through fdct we get: -14, 1, -3, 2, 1, -1, -1, 1, 0, 2, -3, -2, 5, 0, 0, 1, 1, -1, 0, -1, -2, 2, 1, 1, -3, -1, 0, 0, 0, 0, 0, 1, -2, 0, -1, -1, 0, 0, 0, 0, 2, 0, 0, 0, 1, 0, 0, 1, -2, 0, 1, 0, 1, 0, 1, 1, 1, 1, 2, 1, -1, 0, -1, 2, h263 inter quantization causes all coefficients to be divide by twice the quantization paramet. so everything is divided by 14. the matrix after quantiztion becomes: -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, now at dequantization, we multiply all the non-zero coefficients by 14 _and_ the add 13 (quant-1). the dequantized matrix then becomes: -27, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, after inverse dct the matrix is a uniform -3: -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, -3, as gruel has said, this probably isnt a bug, rather the effect of using a mix or high quantizers for bframes. though iam curious why this only happens for direct mode. -- pete; life is like a box of ammo From radoslaw at syskin.cjb.net Sat Feb 15 20:32:54 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Sat Feb 15 11:01:36 2003 Subject: [XviD-devel] dark blocks in b-frames. some resonable answers, finally In-Reply-To: References: Message-ID: <111532859.20030215203254@syskin.cjb.net> Hello everyne,, Christoph wrote > And there are no such blocks with potive values? DC==+14 quantized to +1 ? and I follwed the idea of statistical approach versus 'what's wrong with this particular macroblock' approach. Finally, I have some useful results. I my experiment, I was counting the blocks which look suspicious. In particular, I was counting: - DC == -1 ; sum == 1 ('dark block' maybe) - DC == 1 ; sum == 1 ('white block', unspotted as a bug) Test was reasonably long, halfpel + motion precision 4. Again Pframe's quant 4 and Bframe's quant 7. First, forward mode results: Total number of _coded_ forward-mode luma blocks: 115088 DC = -1, sum = 1 : 11307 DC = 1, sum = 1 : 8508 before I comment, backward mode: total blocks : 124632 DC = -1, sum = 1 : 12081 DC = 1, sum = 1 : 9945 There is a slight bias towards negative DC. My hypotesis was: halfpel interpolation uses rounding_control = 0, so the total compensated image might indeed be a bit brighter - the formula is r1 + r2 + 1 - rounding; . Further experiments confirm this - the values get swapped if I use rounding control of 1. So far, so good. Let's check interpolate mode: total coded blocks : 83683 DC = -1, sum = 1 : 9954 DC = 1, sum = 1 : 4897 The bias got bigger. Why? Because we interpolate two pictures and _again_ round away from zero, towards white. MPEG4 sucks, how can we round in the same direction twice? Now, direct mode, the one which causes trouble: total : 616349 DC -1 : 115687 DC +1 : 31955 Can you see the problem? Once again, we're rounding towards white twice. This time however, motion compensation can't do nothing about it - it's very limited, both reference pictures are interpolated with the probability of 75% each, so there is 56% that they are both interpolated and only 6% that none. And in the end, they are interpolated together, again with rounding towards infinity. And this is the problem. I tried rounding of 1 for the interpolation - the picture was looking better already, there both white blocks and dark blocks, both almost invisible. And the filesize was smaller. However, this is not a solution. Please comment. Radek From radoslaw at syskin.cjb.net Sat Feb 15 20:44:16 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Sat Feb 15 11:12:59 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: <20030215131004.34C8.SUXEN_DROL@hotmail.com> References: <351241203.20030215025201@syskin.cjb.net> <20030215131004.34C8.SUXEN_DROL@hotmail.com> Message-ID: <1822214937.20030215204416@syskin.cjb.net> lo, > now at dequantization, we multiply all the non-zero coefficients by 14 > _and_ the add 13 (quant-1). the dequantized matrix then becomes: You substract 13 here ;). I really hope you mean "+/- (quant-1), away from zero" > -27, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, Ok, so quantization rounds towards zero, and then dequantization assumes that the rounding was as bad as possible? That's weird. I don't get it. Why 13, when the average error is 6? MPEG4's weird. Anyways, in light of my previous mail - I think we'll have to detect this kind of blocks and 'fix' them, simply because they look horrible. > as gruel has said, this probably isnt a bug, rather the effect of using > a mix or high quantizers for bframes. I wonder why noone noticed this in DivX5. They should also have the problem, especially because they use even higher quantizers for bframes. Radek From chl at math.uni-bonn.de Sat Feb 15 13:33:17 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sat Feb 15 13:33:23 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: <1822214937.20030215204416@syskin.cjb.net> Message-ID: On Sat, 15 Feb 2003, Radek Czyz wrote: > Anyways, in light of my previous mail - I think we'll have to detect > this kind of blocks and 'fix' them, simply because they look horrible. > > > as gruel has said, this probably isnt a bug, rather the effect of using > > a mix or high quantizers for bframes. I see two possibilities for this: a) Quick and dirty: Don't allow sum==1 blocks in B-VOPs (just as in P/I). Make them 0. This might give even bigger artefacts, if 1 was right! So better only don't allow those sum==1 blocks where rounding is done "in the wrong direction". This is simple to do, but not simple to do well. b) Better: Add a flag "FLICKERING_BLOCKS_WORKAROUND". Detect blocks with sum==1 and encode them with lower quant. Every non-direct B-block has a "dbquant" field which codes a quant difference of +2,0,-2 (Table 6-28). A "flicker candidate" MB would have to be coded FORWARD/BACKWARD or INTERPOLATE with dbquant==-2. The next block in line would have to FORWARD/BACKWARD/INTERPOLATE coded with dbquant==+2. Both blocks could not be MODE_DIRECT. So this might cost a few bits (2 extra for quant change in 2 blocks, 2 extra for INTERPOL instead of DIRECT in 2 blocks, some bits because 4 instead of 2 or 0 MVs are encoded). Only if collocated block is INTER4V or in QPel mode this will not give exactly the same result as DIRECT, but I doubt the difference will be noticable (except for less flickering). > I wonder why noone noticed this in DivX5. They should also have the > problem, especially because they use even higher quantizers for > bframes. Simple: Decode DivX5 and search for DCT==-1 sum==1 / DCT==1, sum==1 blocks. Maybe they do some filtering, too. gruel From radoslaw at syskin.cjb.net Sat Feb 15 23:59:03 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Sat Feb 15 14:28:11 2003 Subject: [XviD-devel] dark blocks in b-frames In-Reply-To: <1822214937.20030215204416@syskin.cjb.net> References: <351241203.20030215025201@syskin.cjb.net> <20030215131004.34C8.SUXEN_DROL@hotmail.com> <1822214937.20030215204416@syskin.cjb.net> Message-ID: <13913902078.20030215235903@syskin.cjb.net> > Ok, so quantization rounds towards zero, and then dequantization > assumes that the rounding was as bad as possible? That's weird. I > don't get it. Why 13, when the average error is 6? MPEG4's weird. Ok wait.. 13 is not quant-1, it's 2*quant-1. So maybe it's really 6? BTW I do get it now - the idea was to make bigger values still quntize to 0. So the smallest possible DC change is 4*quant-1. OK, whatever. Can you tell me the way DC is quantized in mpeg quant type? I'll try to write a code which prevents the black blocks. Radek From ed.gomez at free.fr Sat Feb 15 16:33:01 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sat Feb 15 16:33:10 2003 Subject: [XviD-devel] [INFO] dev-api-3 merged into CVS_HEAD Message-ID: <20030215153301.GA662@leloo> That's done. Please see if something is wrong in CVS_HEAD. For me all is working great. Changes from 0.9.1: - merged code from dev-api-3 - merged examples from dev-api-3 - updated sources.inc to dev-api-3 source files - kept the stable portab.h + merged watcom part of dev-api-3 version - merged ARCH_IS_... changes in dev-api-3 files Unix changes: - the target lib is now postfixed with the API version 3.0 Windows changes: - none Please don't commit things to CVS_HEAD yet. We must make sure nothing has been messed up during the merge. Thanks -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030215/b34fd453/attachment.bin From ed.gomez at free.fr Sat Feb 15 17:12:40 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sat Feb 15 17:12:48 2003 Subject: [XviD-devel] [INFO] First problems In-Reply-To: <20030215153301.GA662@leloo> References: <20030215153301.GA662@leloo> Message-ID: <20030215161240.GA12148@leloo> Edouard Gomez (ed.gomez@free.fr) wrote: > Please see if something is wrong in CVS_HEAD. For me all is working > great. Cyrius (an IRC user) tested it for me on his Win32 platform with MSVC, it seems that examples are broken. If a win32/msvc developer could fix that stupid bugs (mainly project file related, perhaps missing #define ...) Please don't commit the change, i prefer you send me the patch. [16:40] --------------------Configuration: xvid_encraw - Win32 Release-------------------- [16:40] Linking... [16:40] libxvidcore.lib(xvid.obj) : error LNK2001: unresolved external symbol _read_counter [16:40] libxvidcore.lib(encoder.obj) : error LNK2001: unresolved external symbol _snprintf [16:40] bin/xvid_encraw.exe : fatal error LNK1120: 2 unresolved externals [16:40] Error executing link.exe. Thanks. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030215/e45cdb84/attachment.bin From elcabesa at inwind.it Sat Feb 15 17:57:06 2003 From: elcabesa at inwind.it (elcabesa) Date: Sat Feb 15 18:01:19 2003 Subject: [XviD-devel] [INFO] First problems In-Reply-To: <20030215161240.GA12148@leloo> References: <20030215153301.GA662@leloo> <20030215161240.GA12148@leloo> Message-ID: <200302151757.06694.elcabesa@inwind.it> small bug, merging has removed some files from xvidcore/build/generic now there is not ./configure script From ed.gomez at free.fr Sat Feb 15 18:11:06 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sat Feb 15 18:11:16 2003 Subject: [XviD-devel] [INFO] First problems In-Reply-To: <200302151757.06694.elcabesa@inwind.it> References: <20030215153301.GA662@leloo> <20030215161240.GA12148@leloo> <200302151757.06694.elcabesa@inwind.it> Message-ID: <20030215171106.GC12148@leloo> elcabesa (elcabesa@inwind.it) wrote: > small bug, merging has removed some files from xvidcore/build/generic > now there is not ./configure script This is expected behavior. The CVS does not contain generated files. Install autoconf, automake and libtool and then run ./bootstrap.sh Perhaps you have to modify program names in the bootstrap.sh script PS: autoconf >= 2.50 -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030215/48f97147/attachment.bin From elcabesa at inwind.it Sat Feb 15 21:02:03 2003 From: elcabesa at inwind.it (elcabesa) Date: Sat Feb 15 21:06:32 2003 Subject: [XviD-devel] new Chroma_opt option review Message-ID: <200302152102.03683.elcabesa@inwind.it> hi i'm testing chroma opt opt adn found that it help not compression, i always get file big than the one made without the option enable. i think this problem is due to you try flat very dark area and very light ones in image. i think that this souhld be done only if there are more than x % of chroma pixel inside a macroblock that are dark or light. this is what i mean the code is now in cvs take image and flat chroma in dark area (y<16) and light area( y>235). this make some dark area inside a macroblock flat, and couse you have a non flat MB with a smal flat area when you do FDCT , this give more coefficent. i think that filtering in dark area or light area shgould be done only if a MB has 70% of pixe dark or light. this way most of the MB is made flat nad you reduce high freq coefficents after FTCT nowaday , the result is only a bigger filesize (0.1% i think =) ) couse very dark and verly light area are very few bye From elcabesa at inwind.it Sat Feb 15 21:03:31 2003 From: elcabesa at inwind.it (elcabesa) Date: Sat Feb 15 21:06:35 2003 Subject: [XviD-devel] [INFO] First problems In-Reply-To: <20030215171106.GC12148@leloo> References: <20030215153301.GA662@leloo> <200302151757.06694.elcabesa@inwind.it> <20030215171106.GC12148@leloo> Message-ID: <200302152103.31460.elcabesa@inwind.it> On Saturday 15 February 2003 18:11, Edouard Gomez wrote: > elcabesa (elcabesa@inwind.it) wrote: > > small bug, merging has removed some files from xvidcore/build/generic > > now there is not ./configure script > > This is expected behavior. The CVS does not contain generated > files. Install autoconf, automake and libtool and then run > ./bootstrap.sh > > Perhaps you have to modify program names in the bootstrap.sh script > > PS: autoconf >= 2.50 you are right. i tried bootstrap.sh.. but have not noticed that it asked me to install autoconf >=2.50.. adn it bother also me about my old nasm =( From elcabesa at inwind.it Sat Feb 15 21:16:01 2003 From: elcabesa at inwind.it (elcabesa) Date: Sat Feb 15 21:19:02 2003 Subject: [XviD-devel] gmc-quantizer Message-ID: <200302152116.01515.elcabesa@inwind.it> when using gmc you know where image is moving or zooming. this can be used to lower quantizer in some area, this could enance visula quality. le me explain, a camera moving to right make motion compensate move the image to left , so right MB suffer couse they have not an old image that compensate them.. you can lower quantizer to them. zooming out make this problem at all border of image. if you see the avi that redek has upload to show problem in dark area you can see that left area of river is not prefect. but if you globally lower quant the problem is gone away. maybe that lowering quant at left border would enanche image bye From suxen_drol at hotmail.com Sun Feb 16 09:50:49 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Sat Feb 15 23:51:03 2003 Subject: [XviD-devel] new Chroma_opt option review In-Reply-To: <200302152102.03683.elcabesa@inwind.it> References: <200302152102.03683.elcabesa@inwind.it> Message-ID: <20030216085325.A5E5.SUXEN_DROL@hotmail.com> On Sat, 15 Feb 2003 21:02:03 +0100 elcabesa wrote: > i'm testing chroma opt opt adn found that it help not compression, i always > get file big than the one made without the option enable. > i think this problem is due to you try flat very dark area and very light ones > in image. > i think that this souhld be done only if there are more than x % of chroma > pixel inside a macroblock that are dark or light. > this is what i mean > the code is now in cvs take image and flat chroma in dark area (y<16) and > light area( y>235). this make some dark area inside a macroblock flat, and > couse you have a non flat MB with a smal flat area when you do FDCT , this > give more coefficent. yep, further tweaking is neccessary. the 16,235 range can be changed to increase the chance of chroma flatterning (at the loss of some visual quality). > i think that filtering in dark area or light area shgould be done only if a MB > has 70% of pixe dark or light. this way most of the MB is made flat nad you > reduce high freq coefficents after FTCT > nowaday , the result is only a bigger filesize (0.1% i think =) ) couse very > dark and verly light area are very few it's experimental. the idea was invented by mf some time ago, and has been sitting unused in image.c for months. at the request of some users, i added a general flag, so that ppl can experiment it without delving into xvidcore. hopefully some types of video compress significantly better with chroma optimation. if not, then we'll surely remove it. -- pete; life is like a box of ammo From suxen_drol at hotmail.com Sun Feb 16 11:35:34 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Sun Feb 16 01:35:52 2003 Subject: [XviD-devel] [INFO] dev-api-3 merged into CVS_HEAD In-Reply-To: <20030215153301.GA662@leloo> References: <20030215153301.GA662@leloo> Message-ID: <20030216113530.7FDA.SUXEN_DROL@hotmail.com> On Sat, 15 Feb 2003 16:33:01 +0100 Edouard Gomez wrote: > That's done. excellent! > Unix changes: > - the target lib is now postfixed with the API version 3.0 we're going from 0.9.1 to 1.0.0? +> Windows changes: > - none > > Please don't commit things to CVS_HEAD yet. We must make sure nothing > has been messed up during the merge. i have performed my own comparison, and CVS_HEAD is identical to the dev-branch, except for some minor portab.h issues: * we nolonger need the EMMS() macro * there are snprintf macros for MSVC * the linux DPRINTF has been macro. though it is wrapped in a while(0) loop, which is rather odd. anyone know why? i have attched a diff for the above issues. --- another related issue, is the vfw and dshow project. we need to merge the dev-api-3 versions of these, back into their individual CVS_HEAD's. this is painfull; i'd rather have vfw and dshow inside the xvidcore project, such that everything is in sync. prime example: people who checkout CVS_HEAD of xvidcore,vfw,dshow TODAY will find they're incompatible. dshow is rarely modified, and consists of a few files. vfw is only modified to reflect api changes, and will reduce in size greatly once ratecontrol is perform inside xvidcore. -- pete; life is like a box of ammo -------------- next part -------------- A non-text attachment was scrubbed... Name: cvshead-portab-h.diff Type: application/octet-stream Size: 6769 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030216/e42826dd/cvshead-portab-h.obj From ed.gomez at free.fr Sun Feb 16 02:17:17 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sun Feb 16 02:17:28 2003 Subject: [XviD-devel] [INFO] dev-api-3 merged into CVS_HEAD In-Reply-To: <20030216113530.7FDA.SUXEN_DROL@hotmail.com> References: <20030215153301.GA662@leloo> <20030216113530.7FDA.SUXEN_DROL@hotmail.com> Message-ID: <20030216011717.GE12148@leloo> suxen_drol (suxen_drol@hotmail.com) wrote: > we're going from 0.9.1 to 1.0.0? Changes made in dev-api-3 are rather important and if we only change the patch version (third number) then it will not show how much XviD features changed. I think 1.0.0 is good even if we have not reached all our desired features. Sometimes it's important to get things released even if it's not what we expected. There's still time to improve things. > i have performed my own comparison, and CVS_HEAD is identical to the > dev-branch, except for some minor portab.h issues: > > * we nolonger need the EMMS() macro Yep, i forgot that dev-api-3 change. Will be merged > * there are snprintf macros for MSVC I trust you because i don't know how win32 stuff works :) Will be merged. > * the linux DPRINTF has been macro. though it is wrapped in a while(0) > loop, which is rather odd. anyone know why? I refuse that one because the MacOSX port needs this DPRINTF to be a function for variable parameters passing. However I've read a document this afternoon (MacOSX porting guidelines). And it seems that i can come back to the macro version for all *nix platforms. the while(0) thingy is very simple. You can't use {} because the ; after the macro call will be misinterpreted by some compilers, so the better solution is to enclose the code in a do { } while(0) so the ";" after the macro is right for ANSI C compilers. The while(0) is then removed by the compiler because it knows the condition is always false. At least the compiler should perform that supression during optimization. If it does not, that shows that the compiler sucks -> change the compiler :-) > another related issue, is the vfw and dshow project. we need to merge > the dev-api-3 versions of these, back into their individual CVS_HEAD's. > this is painfull; i'd rather have vfw and dshow inside the xvidcore > project, such that everything is in sync. > > prime example: people who checkout CVS_HEAD of xvidcore,vfw,dshow TODAY > will find they're incompatible. As i explained you on IRC, this is a pure maintainer task to keep things in sync. Moreover as you see, I communicate important changes to CVS before applying them so every coder can ask for a delay. All we need is good communication among developers. As an example, just look at the way i manage having transcode modules in sync with both 0.9.x series and dev-api-3. I'm not superman, I just have good organization(well this is the visible part of the iceberg). Including vfw and dshow will just break that nice OS independency of the core. I think xvid_core_ should stay an independent module. Now i won't force my point of view. We already discussed that on IRC so you know I'm against that. I just want to hear other developers' opinion. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030216/4382765a/attachment.bin From ed.gomez at free.fr Sun Feb 16 02:49:10 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sun Feb 16 02:49:21 2003 Subject: [XviD-devel] [INFO] dev-api-3 merged into CVS_HEAD In-Reply-To: <20030216011717.GE12148@leloo> References: <20030215153301.GA662@leloo> <20030216113530.7FDA.SUXEN_DROL@hotmail.com> <20030216011717.GE12148@leloo> Message-ID: <20030216014910.GF12148@leloo> Edouard Gomez (ed.gomez@free.fr) wrote: > > * we nolonger need the EMMS() macro > > Yep, i forgot that dev-api-3 change. Will be merged > > > * there are snprintf macros for MSVC > > I trust you because i don't know how win32 stuff works :) Will be > merged. Commited. Had you the same problem cyrius reported to me on IRC with examples ? PS: I know examples are missing some fixes done in (ex) stable branch. PPS: now time to sleep a bit. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030216/a7e132fd/attachment.bin From suxen_drol at hotmail.com Sun Feb 16 13:50:17 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Sun Feb 16 03:50:28 2003 Subject: [XviD-devel] [INFO] dev-api-3 merged into CVS_HEAD In-Reply-To: <20030216011717.GE12148@leloo> References: <20030216113530.7FDA.SUXEN_DROL@hotmail.com> <20030216011717.GE12148@leloo> Message-ID: <20030216133148.B821.SUXEN_DROL@hotmail.com> hi, On Sun, 16 Feb 2003 02:17:17 +0100 Edouard Gomez wrote: > Changes made in dev-api-3 are rather important and if we only change the > patch version (third number) then it will not show how much XviD > features changed. I think 1.0.0 is good even if we have not reached all > our desired features. Sometimes it's important to get things released > even if it's not what we expected. There's still time to improve things. agree. but what i meant to say: "we're going from 0.9.1 to 1.0.0, so why not call it libxvidcore.so.1.0.0?" > the while(0) thingy is very simple. You can't use {} because the ; after > the macro call will be misinterpreted by some compilers, so the better > solution is to enclose the code in a do { } while(0) so the ";" after > the macro is right for ANSI C compilers. > > The while(0) is then removed by the compiler because it knows the > condition is always false. At least the compiler should perform that > supression during optimization. If it does not, that shows that the > compiler sucks -> change the compiler :-) ok. i understand now. > As i explained you on IRC, this is a pure maintainer task to keep things > in sync. Moreover as you see, I communicate important changes to CVS > before applying them so every coder can ask for a delay. All we need is > good communication among developers. > > As an example, just look at the way i manage having transcode modules in > sync with both 0.9.x series and dev-api-3. I'm not superman, I just have > good organization(well this is the visible part of the iceberg). > > Including vfw and dshow will just break that nice OS independency of the > core. I think xvid_core_ should stay an independent module. that is a good point. > Now i won't force my point of view. We already discussed that on IRC so > you know I'm against that. I just want to hear other developers' > opinion. since the new api intends to be forwards/backwards compatible -- future project-synch issues should become non-existant. actually, i would prefer xvid to house it's own mirror of the transcode & player xvid modules, within the xvidcore project. while this _is_ redudant, it would make updating them easier in the event of api change. -- pete; life is like a box of ammo From suxen_drol at hotmail.com Sun Feb 16 16:27:30 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Sun Feb 16 06:27:42 2003 Subject: [XviD-devel] [INFO] dev-api-3 merged into CVS_HEAD In-Reply-To: <20030216014910.GF12148@leloo> References: <20030216011717.GE12148@leloo> <20030216014910.GF12148@leloo> Message-ID: <20030216162302.0D5A.SUXEN_DROL@hotmail.com> On Sun, 16 Feb 2003 02:49:10 +0100 Edouard Gomez wrote: > Edouard Gomez (ed.gomez@free.fr) wrote: > > > * we nolonger need the EMMS() macro > > > > Yep, i forgot that dev-api-3 change. Will be merged > > > > > * there are snprintf macros for MSVC > > > > I trust you because i don't know how win32 stuff works :) Will be > > merged. > > Commited. Had you the same problem cyrius reported to me on IRC with > examples ? its working now. [i removed the #ifdef _PROFILING_ from portab.h.] > > PS: I know examples are missing some fixes done in (ex) stable branch. > PPS: now time to sleep a bit. -- pete; life is like a box of ammo From ed.gomez at free.fr Sun Feb 16 10:47:33 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sun Feb 16 10:47:47 2003 Subject: [XviD-devel] [INFO] dev-api-3 merged into CVS_HEAD In-Reply-To: <20030216133148.B821.SUXEN_DROL@hotmail.com> References: <20030216113530.7FDA.SUXEN_DROL@hotmail.com> <20030216011717.GE12148@leloo> <20030216133148.B821.SUXEN_DROL@hotmail.com> Message-ID: <20030216094733.GA706@leloo> suxen_drol (suxen_drol@hotmail.com) wrote: > agree. but what i meant to say: > "we're going from 0.9.1 to 1.0.0, so why not call it libxvidcore.so.1.0.0?" The library version is not that important from user programs, the only thing that counts is the API version we are offering. Btw i was wrong it's still 2.1 in the .h, is this a mistake ? -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030216/c7d8295e/attachment.bin From chl at math.uni-bonn.de Sun Feb 16 10:59:46 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sun Feb 16 10:59:48 2003 Subject: [XviD-devel] [INFO] dev-api-3 merged into CVS_HEAD In-Reply-To: <20030216011717.GE12148@leloo> Message-ID: On Sun, 16 Feb 2003, Edouard Gomez wrote: > Including vfw and dshow will just break that nice OS independency of the > core. I think xvid_core_ should stay an independent module. I see both, the advantages and the disadvantages in a merge of those. But we already have much code that isn't "OS independent" in the core, e.g. the assembler stuff. portab.h and the Makefiles deal with this. I don't think it would hurt if we added vfw and dshow to the core tree, but of course in separate files (subdirectories), and then the Un*X Makefiles would simply not compile them (so missing Windows headers stay unnoticed) but MSC "workspace" would include them. Just as ia64 stuff isn't compiled on ia32, because it isn't supported by the compiler anyway. gruel From ed.gomez at free.fr Sun Feb 16 11:13:09 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sun Feb 16 11:13:18 2003 Subject: [XviD-devel] [INFO] Merge summary Message-ID: <20030216101309.GA744@leloo> Hello, The merge is now complete and ready to be used. I tagged the first step of the merge as "merged-dev-api-3" so if we need to remove the merge for an obscure reason this would still be possible. Before I branch dev-api-4 for changing API and RC, I would like to add the headers and restore proper copyrights so we would not need to do this once more. I'll also do some very quick "warnings" squashing. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030216/559abcbd/attachment.bin From radoslaw at syskin.cjb.net Sun Feb 16 22:44:57 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Sun Feb 16 13:13:49 2003 Subject: [XviD-devel] vlc_codes.h Message-ID: <16738678281.20030216224457@syskin.cjb.net> Lo everyone, I have a new subject for you ;) Maybe you have noticed that after the _BITS stuff, our library got serveral tens of kilobytes larger. VfW dll was larger by at least 60kb. You might ask me what kind of code I write. I promise you this is not the size of _BITS functions. The problem is that I had to #include vlc_codes.h to motion estimation. This file contains all our hard-coded VLC tables, all declared static. As a result, every table which is used in motion estimation is incuded in motion estimation object file. All tables needed for MB coding are included in mbcoding object. All tables needed for intra block coding are included in mbprediction object. They are all static - invisible to other modules. I wanted to do something about it and came up with an idea which works. I created a new object, vlc_codes.c . Here, all tables are defined, not as static. The old vlc_codes.h, which is #included in other modules, contains 'prototypes' (I don't know the correct word...) of the tables - just all the tables again, without the actual data and with 'extern' keyword. This way, everything works correctly, but the VfW dll is smaller by 120kb ! Even if it doesn't have the real effect on performance (but what about mem bandwith and cpu cache), it still looks much better. There probably are better ways - we could include the actual tables to some existing object - but I hope you agree that we should do _something_ like this. Best regards, Radek From ed.gomez at free.fr Sun Feb 16 13:26:58 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sun Feb 16 13:27:20 2003 Subject: [XviD-devel] vlc_codes.h In-Reply-To: <16738678281.20030216224457@syskin.cjb.net> References: <16738678281.20030216224457@syskin.cjb.net> Message-ID: <20030216122658.GB744@leloo> Radek Czyz (radoslaw@syskin.cjb.net) wrote: > I wanted to do something about it and came up with an idea which > works. I created a new object, vlc_codes.c . Oh good,i was doing the same stuff in order to shut the mouth of the gcc compiler, because it was complaining about unused static arrays all around the sources. Come on IRC channel, we'll discuss about that. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030216/89a4502a/attachment.bin From chl at math.uni-bonn.de Sun Feb 16 14:21:20 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sun Feb 16 14:21:31 2003 Subject: [XviD-devel] dark blocks in b-frames. some resonable answers, finally In-Reply-To: <111532859.20030215203254@syskin.cjb.net> Message-ID: Hi, somehow the topic is solved, but here is my final idea for a quick "solution": >From what Radek checked we know that bframes have a bias towards "overcompansation" due to rounding. I'm not sure about forward and backward mode: I thought there we use the (possibly halfpel interpolate) reference picture which is does with ordinary rounding==0 or rounding==1. I don't know where extra rounding come into play. Let forget about those for the moment. For interpolated and direct mode, B-frames routine surely has to interpolate. This is always done with rounding==0, because the standard demands it (that's faster for hardware implementation, I guess). So we know, that every stop of interpolation will round up in 2 of 4 cases, and never round down. r1&1 r2&1 "real" rounded (r1+r2+1)/2 0 0 0 0 0 1 0.5 1 1 0 0.5 1 1 1 1 1 The expectation value of error is 0.25 instead of 0.00 in a perfect world, so we know that in the mean, block luminance will be too high by 0.25. This cannot be expressed in the image domain, of course. But it _can_ in the DCT domain, because DC coefficient has higher resolution than [0,255]. So let's simply subtract the (constant) value of DCT(0.25) from the DC coefficient before quantization and see what happens. In theory, there should then be as many "too dark" blocks as there are "too light" blocks, but fewer than there are now. If the light blocks are less visisble, we can change the bias to more than DCT(0.25). Remember: We can do anything we want with B-frames, it doesn't change coding efficiency, since they are not used for prediction. I'm not completely familiar with rounding in bframes. Radek wrote that for forward and backward mode we are rounding as well, and for interpolated and direct mode even twice. Then of course, we would have to change the value, and use it for forward mode, too. We could also take into account, that we _know_ if a vector has even or odd components, so we know if it acts on an interpolate image or not. This could play a role as well. Maybe somebody can check, if rounding in QPel is somewhat the same, or even more biased. gruel P.S. Another way would be to not do rounding in image domain at all: Simply let DCT act on both reference blocks and add them together, then devide afterwards in DCT domain (everything's linear...). Again remember: motion compensation of encoder and decoder doesn't have to be exactly the same, since errors don't propagate. It just has to _look_ good when decoded (actually, there is not compensation in encoder at all). > There is a slight bias towards negative DC. My hypotesis was: halfpel > interpolation uses rounding_control = 0, so the total compensated > image might indeed be a bit brighter - the formula is > r1 + r2 + 1 - rounding; . > > Further experiments confirm this - the values get swapped if I use > rounding control of 1. > > The bias got bigger. Why? Because we interpolate two pictures and > _again_ round away from zero, towards white. MPEG4 sucks, how can we > round in the same direction twice? > > Now, direct mode, the one which causes trouble: > total : 616349 > DC -1 : 115687 > DC +1 : 31955 > > Can you see the problem? Once again, we're rounding towards white > twice. This time however, motion compensation can't do nothing about > it - it's very limited, both reference pictures are interpolated with > the probability of 75% each, so there is 56% that they are both > interpolated and only 6% that none. And in the end, they are > interpolated together, again with rounding towards infinity. From chenm001 at 163.com Mon Feb 17 17:58:21 2003 From: chenm001 at 163.com (CM) Date: Mon Feb 17 10:58:32 2003 Subject: [XviD-devel] portab.h for Philips Trimedia Message-ID: <200302170958.h1H9wJrA016845@edu.bnhof.de> Hi: 1. I change the portab.h to support Philips Trimedia please help me to add in cvs. 2. Please remove my dir mesh, because I'm not finish that. 3. Plaease add my DCT for trimedia to cvs. Thanks ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡CM ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡chenm001@163.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-02-17 -------------- next part -------------- A non-text attachment was scrubbed... Name: portab.zip Type: application/octet-stream Size: 4572 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030217/3bc6299b/portab.obj From felix-xvid at fefe.de Mon Feb 17 11:59:44 2003 From: felix-xvid at fefe.de (Felix von Leitner) Date: Mon Feb 17 11:59:53 2003 Subject: [XviD-devel] Re: VHQ In-Reply-To: References: <1883576687.20030213195242@syskin.cjb.net> Message-ID: <20030217105943.GA8933@fefe.de> Thus spake Christoph Lampert (chl@math.uni-bonn.de): > > The problem I would _really_ like to fix is this B-frames flickering I > > hate so much. Stupid bug, it's even difficult to prove it exists. But > > it does exist. > Can it be reproduced on "artificial" images? Are you sure that it's really > a bug and not due to some quantization rounding or something? For what it's worth, I get bad visual quality with mplayer when I encode something with xvid with b-frames but play it back with ffmpeg. qpel, gmc, all help next to nothing. Playing back with -vc xvid looks much better. Is there any way we could get b-frames and two pass mode to cooperate? So far I am not using b-frames at all because they always look much worse than a decent two pass mode without all the advanced features. Felix From chl at math.uni-bonn.de Mon Feb 17 12:17:26 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Mon Feb 17 12:17:29 2003 Subject: [XviD-devel] Re: VHQ In-Reply-To: <20030217105943.GA8933@fefe.de> Message-ID: On Mon, 17 Feb 2003, Felix von Leitner wrote: > Thus spake Christoph Lampert (chl@math.uni-bonn.de): > > > The problem I would _really_ like to fix is this B-frames flickering I > > > hate so much. Stupid bug, it's even difficult to prove it exists. But > > > it does exist. > > Can it be reproduced on "artificial" images? Are you sure that it's really > > a bug and not due to some quantization rounding or something? > > For what it's worth, I get bad visual quality with mplayer when I > encode something with xvid with b-frames but play it back with ffmpeg. > qpel, gmc, all help next to nothing. Playing back with -vc xvid looks > much better. What exactly is the difference? Can you make a snapshot of both (e.g. with -vo jpeg or -vo png ) ? gruel From felix-xvid at fefe.de Mon Feb 17 12:17:36 2003 From: felix-xvid at fefe.de (Felix von Leitner) Date: Mon Feb 17 12:17:43 2003 Subject: [XviD-devel] Re: [INFO] dev-api-3 merged into CVS_HEAD In-Reply-To: <20030216113530.7FDA.SUXEN_DROL@hotmail.com> References: <20030215153301.GA662@leloo> <20030216113530.7FDA.SUXEN_DROL@hotmail.com> Message-ID: <20030217111736.GC8933@fefe.de> Thus spake suxen_drol (suxen_drol@hotmail.com): > * the linux DPRINTF has been macro. though it is wrapped in a while(0) > loop, which is rather odd. anyone know why? Well, we have to put it in { } to remove else ambiguities outside the macro. Now consider this macro: #define foo(x) { bar(x) } and this code: foo(3); /* works */ if (predicate()) foo(17); /* does not work, because the ; terminates the whole if */ else foo(23); That's why it has to be wrapped with the "do { ... } while (0);" From suxen_drol at hotmail.com Mon Feb 17 23:25:10 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Mon Feb 17 13:25:18 2003 Subject: [XviD-devel] new Chroma_opt option review In-Reply-To: <20030216085325.A5E5.SUXEN_DROL@hotmail.com> References: <200302152102.03683.elcabesa@inwind.it> <20030216085325.A5E5.SUXEN_DROL@hotmail.com> Message-ID: <20030217232110.18DB.SUXEN_DROL@hotmail.com> On Sun, 16 Feb 2003 09:50:49 +1100 suxen_drol wrote: > hopefully some types of video compress significantly better with > chroma optimation. if not, then we'll surely remove it. after speaking to mf on irc, it appears chromaopt is intended to increase chroma image quality arround pure white/black edges, rather than increasing compression (hence reducing filesize). > > -- pete; life is like a box of ammo From ravage at gmx.de Mon Feb 17 17:44:22 2003 From: ravage at gmx.de (Ravage) Date: Mon Feb 17 16:41:29 2003 Subject: [XviD-devel] B-Frame Questions Message-ID: <1045500262.29782.0.camel@linux.daR.av> Hi, while playing around and developing with XviD I have to question to the developers: 1) B-Frames: Without B-Frames the codec works straight forward: give them a frame - it decodes - know you can display it. If I'm not wrong, this is how it works with I- and P-Frames. But with B-Frames are enabled the problem is that I'll need the corresponding frames for decoding the B-Frame. So I need to give the codec the frame(s) before and after first - then it will be decoding it. Right ? But in which order ? A player must know which frame is displayed next and has to reorder these frame after decoding ?! 2) How is the detection of the frame type done and where ? Are there some routines checking if the frame delivert to the codec is a I-/P-/B-Frame or is it done "deep" within while decoding itself ? Thanks in advance, Bernd -- Ravage From chl at math.uni-bonn.de Mon Feb 17 17:12:25 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Mon Feb 17 17:12:29 2003 Subject: [XviD-devel] B-Frame Questions In-Reply-To: <1045500262.29782.0.camel@linux.daR.av> Message-ID: On 17 Feb 2003, Ravage wrote: > 1) B-Frames: > Without B-Frames the codec works straight forward: give them a frame - > it decodes - know you can display > it. If I'm not wrong, this is how it works with I- and P-Frames. > But with B-Frames are enabled the problem is that I'll need the > corresponding frames for decoding the > B-Frame. So I need to give the codec the frame(s) before and after first > - then it will be decoding it. > Right ? For encoding, you give the frames in viewing order, (so first the frame that is supposed to become a B-VOP, later the second reference VOP). If your GOP is IBBP input for the decoder is IBBP. Output of the encoder will be (after some delay): IPBB For decoding, you have to give the frames in decoding order, so if the GOP is IBBP you have to give them as IPBB which is just the order the encoder had as output. Output of the decoder will be IBBP, in viewing order. > But in which order ? > A player must know which frame is displayed next and has to reorder > these frame after decoding ?! > > 2) How is the detection of the frame type done and where ? > Are there some routines checking if the frame delivert to the codec is a > I-/P-/B-Frame or is it done > "deep" within while decoding itself ? The encoder decides on frame type rather early in encoder.c, because handling of B-VOPs is very different from others. The decoder simply reads a few byte from the beginning of the encoded VOP. There the VOP-type is specified by some value in some data field of MPEG header. gruel From chl at math.uni-bonn.de Mon Feb 17 18:50:31 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Mon Feb 17 18:50:35 2003 Subject: [XviD-devel] CheckCandidate Message-ID: Hi, in CheckCandidate16/16no4v/8 the current SAD is _multiplicated_ with the number of motion bits in the way sad += (data->lambda16 * t * sad)>>10; Where does this come from? Syskin, was that you? I don't remember it from my earlier versions, in particular since it leaves the usual lagrangian method. Is there any special reason why it was chosen in this way? gruel From m_sikkema at hotmail.com Mon Feb 17 18:54:06 2003 From: m_sikkema at hotmail.com (Marloes) Date: Mon Feb 17 18:54:39 2003 Subject: [XviD-devel] xvid-codec Message-ID: hello, i'm sorry to bother you, but i downloaded a movie which tells me it needs an XVID-codec. so i searched on the internet for such a codec and downloaded the xvidcore-0.9.0 zip-package. i opened it, but now i can't find any installation- or setupfile. what am i supposed to do? can you help me, or do you know anyone who can? I should probably tell you that i am a codec-dummie (i do not have any experience whatsoever). many thanx in advance, Marloes Sikkema The Netherlands-------------- next part -------------- An HTML attachment was scrubbed... URL: http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030217/ab11f045/attachment.htm From chl at math.uni-bonn.de Mon Feb 17 19:08:35 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Mon Feb 17 19:08:40 2003 Subject: [XviD-devel] xvid-codec In-Reply-To: Message-ID: The xvidcore-ZIP package is only the SOURCE-files, not an executable. You would have to compile it first before you can install it. If you search at google for "XVID binaries" you might be more succesful. gruel P.S. To the rest of the list: We should add a BIG comment into README.txt of xvidcore-0.9.1 about this! I guess we have to ask Michael to do so, or does anybody else know how to upload files to xvid.org? On Mon, 17 Feb 2003, Marloes wrote: > hello, i'm sorry to bother you, but i downloaded a movie which tells > me it needs an XVID-codec. so i searched on the internet for such a > codec and downloaded the xvidcore-0.9.0 zip-package. i opened it, but > now i can't find any installation- or setupfile. what am i supposed to > do? can you help me, or do you know anyone who can? I should probably > tell you that i am a codec-dummie (i do not have any experience > whatsoever). many thanx in advance, Marloes Sikkema The Netherlands From ed.gomez at free.fr Tue Feb 18 00:08:30 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Tue Feb 18 00:09:10 2003 Subject: [XviD-devel] portab.h for Philips Trimedia In-Reply-To: <200302170958.h1H9wJrA016845@edu.bnhof.de> References: <200302170958.h1H9wJrA016845@edu.bnhof.de> Message-ID: <20030217230830.GA4238@leloo> CM (chenm001@163.com) wrote: > 1. I change the portab.h to support Philips Trimedia please > help me to add in cvs. > 2. Please remove my dir mesh, because I'm not finish that. > 3. Plaease add my DCT for trimedia to cvs. Before commiting this to the CVS, i just want to ask you what toolchain you're using, so if you want i can try to integrate the toolchain in the generic Unix build process. However if it's a completly different toolchain than the classic (make, CC, ar), then i'll just commit those files without dealing with it building. thanks. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030218/c78e385b/attachment.bin From radoslaw at syskin.cjb.net Tue Feb 18 21:11:21 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Tue Feb 18 11:40:59 2003 Subject: [XviD-devel] CheckCandidate In-Reply-To: References: Message-ID: <1363400421.20030218211121@syskin.cjb.net> Hello, > in CheckCandidate16/16no4v/8 the current SAD is _multiplicated_ with > the number of motion bits in the way sad += (data->>lambda16 * t * sad)>>10; > Where does this come from? Syskin, was that you? I don't remember it from > my earlier versions, in particular since it leaves the usual lagrangian > method. Is there any special reason why it was chosen in this way? Yes that was me. I explained it (more or less), here's the archive: http://edu.bnhof.de/pipermail/xvid-devel/2002-November/001228.html In short: It was always better. Radek P.S. This is another mail which I only recieved on my backup account. Does anyone else have this problem? Or maybe this cjb.net of mine simply drops some mails... From chl at math.uni-bonn.de Tue Feb 18 12:23:24 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Tue Feb 18 12:23:29 2003 Subject: [XviD-devel] CheckCandidate In-Reply-To: Message-ID: Hi, nobody seems responsible, but I was just asking because am no friend of methods which are implemented only because they seem to work in practice. Often, one just thinks they do but in fact they don't. My tests showed that current INTER/INTER4V method choses many more INTER4V blocks than the previous pure lagrangian. This is good at low quantizers of 2 to 4, there the current method often reaches an error of 2-3% and sometimes less (I mean bitrate is only 2% larger than with optimal decision. In fact, 20-30% percent of block are classified wrong, but for the vast majority of them the effect is very small). An error of 2% is very good, btw. But for medium quantizers, the method is much worse, usually the error peaks at a quantizer 8 to 12 with a bitrate often more than 10% higher than necessary! That's because still INTER4V is choosen too often... The bitrate error then drops again until it's somewhat stable below 5% for very high quants (almost all blocks are INTER then, but still more INTER4V than optimal). You can see this very well from the plot I attached: Possible saves in bitrate versus quantizer for several (rather static) QCIF sequences. Especially the "miss america" sequence is _horrible_ with more than 20% too high bitrate, just due to mode decision... Without the sad += ... line there are much fewer INTER4V blocks, and the error rate of about constant 4-5% for most quantizers. Still, this cannot simply be compared, since of course ME uses different tracks and other blocks are encoded ... Is there any voluteer around to check what's wrong with medium quants at the moment? I guess from the practical point it would be better to have high errors at very high quantizers, and as good as possible decision in the area of quant 3 to 8 where most of the encoding takes place. gruel On Mon, 17 Feb 2003, Christoph Lampert wrote: > in CheckCandidate16/16no4v/8 the current SAD is _multiplicated_ with > the number of motion bits in the way > > sad += (data->lambda16 * t * sad)>>10; > > Where does this come from? Syskin, was that you? I don't remember it from > my earlier versions, in particular since it leaves the usual lagrangian > method. Is there any special reason why it was chosen in this way? > > gruel > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: saved-bitrate.png Type: image/png Size: 9019 bytes Desc: Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030218/1a61b6f3/saved-bitrate.png From chl at math.uni-bonn.de Tue Feb 18 12:28:10 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Tue Feb 18 12:28:13 2003 Subject: [XviD-devel] CheckCandidate In-Reply-To: <1363400421.20030218211121@syskin.cjb.net> Message-ID: Hi Radek, good timinig, I just sent my results on ModeDecision to the list a few seconds ago... Anyway, I don't really like the argument "It was better", even though it has a certain logic. I read your xvid-devel explaining it, but I would still prefer a somewhat "theoretical" reason for this, something like a model with parameters which we can then optimize. gruel On Tue, 18 Feb 2003, Radek Czyz wrote: > Hello, > > > in CheckCandidate16/16no4v/8 the current SAD is _multiplicated_ with > > the number of motion bits in the way > > sad += (data->>lambda16 * t * sad)>>10; > > > Where does this come from? Syskin, was that you? I don't remember it from > > my earlier versions, in particular since it leaves the usual lagrangian > > method. Is there any special reason why it was chosen in this way? > > Yes that was me. I explained it (more or less), here's the archive: > http://edu.bnhof.de/pipermail/xvid-devel/2002-November/001228.html > > In short: It was always better. > > Radek > > P.S. This is another mail which I only recieved on my backup account. > Does anyone else have this problem? Or maybe this cjb.net of mine > simply drops some mails... > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel > From radoslaw at syskin.cjb.net Tue Feb 18 23:46:57 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Tue Feb 18 14:15:43 2003 Subject: [XviD-devel] CheckCandidate In-Reply-To: References: Message-ID: <9412735796.20030218234657@syskin.cjb.net> Heya, > good timinig, I just sent my results on ModeDecision to the list a few > seconds ago... Anyway, I don't really like the argument "It was better", > even though it has a certain logic. > I read your xvid-devel explaining it, but I would still prefer a somewhat > "theoretical" reason for this, something like a model with parameters > which we can then optimize. I also prefer a scientific approach. However, probably the only way to prove it would be to show that if SAD is high, it is no longer accurate (or rather: even more inaccurate) as a prediction of bits used (actually, I could prove it now using this bits thingy) As it is inaccurate, but d_mv_bits() is not inaccurate, relaying on d_mv_bits more in such case is statistically better... Anyway, I got this idea and my initial test gave me 0.1 dB just like that - so you see why I liked it. > Is there any voluteer around to check what's wrong with medium quants at > the moment? I guess from the practical point it would be better to have > high errors at very high quantizers, and as good as possible decision in > the area of quant 3 to 8 where most of the encoding takes place. The inter/inter4v decision was difficult, I admit. Three factors play part - how we add mv bits to SAD (lambda_vec8[] table, with expotential scaling(quant) * (SAD + BIAS) ; where bias is constant) and the bias in the decision itself (IMV16X16 , linear scaling(quant)). First thing that comes to my head - if lambda_vec8[] was linear, equal to current at q2 and q31, it would be higher in middle range. Exactly what we need. It doesn't mean it would be better, though. I'll check this, and other possibilities as well. Radek From chl at math.uni-bonn.de Tue Feb 18 16:42:36 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Tue Feb 18 16:42:39 2003 Subject: [XviD-devel] Change 2 bits <-> 2 percent speedup Message-ID: Hi, please try thing on your machine: When I changed in portab.h #define CACHE_LINE 16 to #define CACHE_LINE 32 XVID got faster by 2 percent. This was on Pentium3 where cacheline actually _is_ 32 byte. On Athlon or P4 you might want to try 64 (changing even 4 bits). gruel From hecata_nosferatu at hotmail.com Tue Feb 18 17:22:19 2003 From: hecata_nosferatu at hotmail.com (Yoeri Bouwman) Date: Tue Feb 18 17:22:30 2003 Subject: [XviD-devel] How do you use Xvid codec? Message-ID: An HTML attachment was scrubbed... URL: http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030218/426a36c1/attachment.htm From elcabesa at inwind.it Tue Feb 18 20:28:38 2003 From: elcabesa at inwind.it (elcabesa) Date: Tue Feb 18 20:31:44 2003 Subject: [XviD-devel] How do you use Xvid codec? In-Reply-To: References: Message-ID: <200302182028.38660.elcabesa@inwind.it> On Tuesday 18 February 2003 17:22, Yoeri Bouwman wrote: >
Where must I extract the zip file > xvidcore-0.9.1 and make it work with DivX? I have and avi file that doens't > work in DivX, but the user says that you must use divX to play > the file. So I downloaded xvidcore-0.9.1.zip and extracted it in the > DivX folder. Still it doesn't work. What must I do? I spent 5 days > downloading this file and is it in vain? I hope not. Please help me. (don't > redirect me to FAQ please...)
 
>
Yoeri Bouwman.


Eindelijk leveren je > vrienden wat op! Nieuwsgierig? > Klik hier. simply downloading codec from one of these site http://xvid.hopto.org/ http://nic.dnsalias.com/ or http://roeder.goe.net/~koepi/ the file you have downloaded has only src ifle not executable files=) From chl at math.uni-bonn.de Tue Feb 18 21:07:31 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Tue Feb 18 21:07:34 2003 Subject: [XviD-devel] Bootstrap Message-ID: Hi, why is exactly "autoconf2.50" called in xvidcore/build/generic/bootstrap.sh ? It may be called like this in Debian, but shouldn't we rather use the generic name "autoconf" instead of some special versioning? gruel From chl at math.uni-bonn.de Tue Feb 18 21:24:56 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Tue Feb 18 21:24:58 2003 Subject: [XviD-devel] Change 2 bits <-> 2 percent speedup In-Reply-To: Message-ID: Okay, forget the 2%. They disappeared in my re-check a few hours later. Still, higher CACHE_LINE won't hurt. gruel On Tue, 18 Feb 2003, Christoph Lampert wrote: > Hi, > > please try thing on your machine: > > When I changed in portab.h > > #define CACHE_LINE 16 > > to > > #define CACHE_LINE 32 > > XVID got faster by 2 percent. This was on Pentium3 where cacheline > actually _is_ 32 byte. On Athlon or P4 you might want to try 64 > (changing even 4 bits). > > gruel > > > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel > From ed.gomez at free.fr Wed Feb 19 01:04:06 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Wed Feb 19 01:04:49 2003 Subject: [XviD-devel] Bootstrap In-Reply-To: References: Message-ID: <20030219000406.GA30684@leloo> Christoph Lampert (chl@math.uni-bonn.de) wrote: > why is exactly "autoconf2.50" called in > xvidcore/build/generic/bootstrap.sh ? > > It may be called like this in Debian, but shouldn't we > rather use the generic name "autoconf" instead of some > special versioning? It's distro specific, and no, we can't use autoconf because many distros use symbolic links between real autoconf2.13 and /usr/bin/autoconf. The configure.in is really for autoconf 2.50 and higher. I may insert a minimum requirement in the configure.in (don't remember the exact macro name for that) but anyway, this does not solve the autoconf version problem. That's why i added to the script header this sentence: # NB: This script is adapted to Debian GNU/Linux SID program names # Perhaps you could have to modify program names to match your distro -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030219/2ff41cdc/attachment.bin From chenm001 at 163.com Wed Feb 19 09:30:15 2003 From: chenm001 at 163.com (CM) Date: Wed Feb 19 02:30:26 2003 Subject: [XviD-devel] portab.h for Philips Trimedia Message-ID: <200302190130.h1J1UDrA013756@edu.bnhof.de> Hi: I'm use the Philips's Trimedia SDE 2.1 to compile Xvid, the make I use the cygwin's MAKE. I use follow command line(in cygwin's bash shell): CC=tmcc ./configure make btw: only static lib can be make, dynamic not. >Before commiting this to the CVS, i just want to ask you what toolchain >you're using, so if you want i can try to integrate the toolchain in the >generic Unix build process. However if it's a completly different >toolchain than the classic (make, CC, ar), then i'll just commit those >files without dealing with it building. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡CM ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡chenm001@163.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-02-19 From chl at math.uni-bonn.de Wed Feb 19 09:51:30 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Wed Feb 19 09:51:36 2003 Subject: [XviD-devel] Bootstrap In-Reply-To: <20030219000406.GA30684@leloo> Message-ID: On Wed, 19 Feb 2003, Edouard Gomez wrote: > Christoph Lampert (chl@math.uni-bonn.de) wrote: > > why is exactly "autoconf2.50" called in > > xvidcore/build/generic/bootstrap.sh ? > > > > It may be called like this in Debian, but shouldn't we > > rather use the generic name "autoconf" instead of some > > special versioning? > > It's distro specific, and no, we can't use autoconf because many distros > use symbolic links between real autoconf2.13 and /usr/bin/autoconf. The > configure.in is really for autoconf 2.50 and higher. > > I may insert a minimum requirement in the configure.in (don't remember > the exact macro name for that) but anyway, this does not solve the > autoconf version problem. That's why i added to the script header this > sentence: > > # NB: This script is adapted to Debian GNU/Linux SID program names > # Perhaps you could have to modify program names to match your distro > Yes, of course I read that, but I find it rather strange to remove all the makefiles by an advanced automatic "autoconf/automake" system, and then every user except for Debian Linux (which I doubt is the majority of non-windows users) has to edit the file by hand before even bootstrap runs. How about a wrapper (as -like google told me- e.g. Quakeforge does) that checks for both and uses whichever is better? #!/bin/sh # detect autoconf # Quakeforge showed how to do it. # AUTOCONF=`which autoconf2.50 2> /dev/null` if [ -x "$AUTOCONF" ]; then rm -f configure.in else AUTOCONF=`which autoconf 2> /dev/null` if [ -x "$AUTOCONF" ]; then AC_VER=`autoconf --version | head -1 | sed 's/^[^0-9]*//i'` AC_MAJORVER=`echo $AC_VER | cut -f1 -d'.'` AC_MINORVER=`echo $AC_VER | cut -f2 -d'.'` if [ "$AC_MAJORVER" -lt "2" ]; then echo bootstrap.sh needs autoconf 2.50 or greater. exit 1 fi if [ "$AC_MINORVER" -lt "50" ]; then echo bootstrap.sh needs autoconf 2.50 or greater. exit 1 fi else echo "autoconf wasn't found at all." echo "bootstrap.sh needs autoconf 2.50 or greater." exit 1 fi fi # ----------------- the rest -------------------- # # echo $AUTOCONF $AC_VER # # gruel From chl at math.uni-bonn.de Wed Feb 19 10:01:20 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Wed Feb 19 10:01:23 2003 Subject: [XviD-devel] Re: Xvid Developement (Hardware) In-Reply-To: Message-ID: Hello Ahmad, before you start implementing any part of XVID in hardware, please take the time to read our software license (GPL) which can be found in any distribution of XVID or at http://www.fsf.org/licenses I general, hardware implementations are _not_ compatible with the GPL, since it makes it impossible for users to modify and redistribute the program. However, I don't know how FPGAs fits into this picture. Please check this at http://www.fsf.org or in the corresponding newsgroups/mailing-list . If it turns out that FPGA are not compatible with GPL, you may create an implementation and use it at your will, but you may _not distribute_ it in any way, neither commercially, nor for free. When these general questions are settled, I'm sure many people at our mailing list xvid-devel@xvid.org to which you can subscribe at our homepage www.xvid.org will be willing to help you. Best regards Christoph Lampert On Wed, 19 Feb 2003, Ahmad Al-kilani wrote: > Dear Xvid Developer: > My Name is Ahmad M. Alkilani, I am a graduate student in the Jordan University of > Science > and Technology. Being interested in your work, we have decided to go one step further. > This > step involves the hardware implementation of a part of your Xvid codec as part of a > reconfigurable Processing graduation project. This means that we are tending to make a > reconfigurable processor using FPGA technology and have one of its configurations > handle the > processing power bottle neck of Xvid (encoding/Decoding). > Thus far everything sounds nice, but we don't know how ur codec really functions! I > mean > where the need of all the processing power really is within your code. What techniques > Xvid > uses, and what exactly is in need to be implemented using hardware and thus getting > much > much higher speeds. > Well this is where you come in "hopefully". We are asking of your help to guide us > through. > We really need answers to those questions, that is if you are willing to help. > We considerably thank you for your help, and hope you good luck. > Best Regards, > Ahmad Al-kilani, > amk_com@hotmail.com > amkilani@just.edu.jo From chl at math.uni-bonn.de Wed Feb 19 11:18:45 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Wed Feb 19 11:18:50 2003 Subject: [XviD-devel] VOP_TYPE defined twice Message-ID: Hi, we define VOP_TYPEs twice, once as #define in bitstream/bitstream.h #define I_VOP 0 #define P_VOP 1 #define B_VOP 2 #define S_VOP 3 #define N_VOP 4 and once as enum in encoder.h typedef enum { I_VOP = 0, P_VOP = 1, B_VOP = 2, S_VOP = 3 } VOP_TYPE; encoder.c includes both, so enum is overwritten with #defines, but at least the value seem to agree ;-) Anyway, which one should we use? gruel From suxen_drol at hotmail.com Wed Feb 19 23:01:32 2003 From: suxen_drol at hotmail.com (peter ross) Date: Wed Feb 19 13:01:37 2003 Subject: [XviD-devel] VOP_TYPE defined twice Message-ID: >From: Christoph Lampert >encoder.c includes both, so enum is overwritten with #defines, >but at least the value seem to agree ;-) > >Anyway, which one should we use? enums. i think we should enumerate as much as possible (api,bitstream stuff), because they make the code more readable and maybe prevent silly type'd mistakes. note: the new ap will define XVID_TYPE_xxx for to permit forcing frame vop type (0=auto,1=ivop,2=pvop..). however, internally xvid will use the above bitstream-indexed defines. -- pete _________________________________________________________________ Hotmail now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/hotmail_mobile.asp From chl at math.uni-bonn.de Wed Feb 19 13:04:57 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Wed Feb 19 13:05:10 2003 Subject: [XviD-devel] Re: XviD Mpeg4 Iso Interoperability bug! In-Reply-To: <27404F1E37381C428F26763DF89BDCBC8EE6F6@excsrv01.eidoslan.net> Message-ID: On Wed, 19 Feb 2003, Daniele Buffa wrote: > Sorry if I contact you directly, I posted this problem on doom9 forum > but I've received no response yet but I think it's anyway important... > > I report what I wrote on doom9 > > << > Latest cvs sources and strange iso compatibility problems... > > Hi, > > Yesterday (16-02-03) I checked out last source of development three > and compiled my "personal" version of XviD. > > I have to compress some material....:/ If it's important material, don't use the development tree since that may change from time to time (as you might have noticed). Normally, that is when bugs are _removed_, no introduced, but who knows... > First, the new feature, VHQ, cause my system to crash. However isn't > this the problem, 'cause VHQ is very beta and unstable feature and at > the moment I don't want to use it. Can you be more specific? I didn't have a single crash since I started testing it. > The problem is on b-frame coding and mpeg4 iso interoperability. With > previous version I had no problem, so I think the b-frame coding has > been modified since the last time I checked out cvs. That depends on _when_ you checked out the last time. Please check which bitstream version of XVID that was. (it's in xvid.h) As far as I know only padding has been changed lately (a few weeks ago), and that was because is was broken _before_ (MPEG-4 padding is rather strange business...), and now isn't anymore. > Here you can find a small test movie. I used quant 8 in order to gain > bytes (I've a normal slow analogic modem, no adsl) but also using > quant 2 the situation is the same. > > The avi movie (no visible problem if played with Xvid or Divx filter) > http://www.neowebsite.it/xvid/test.avi > > The iso mp4 movie obtained from the above avi (with the problem, played with Envivio TV, www.envivio.com ) > http://www.neowebsite.it/xvid/test.mp4 Hm, there is no problem with ffmpeg decoder, so maybe it's not encoder related but rather the decoder. Can you describe _what_ you see with Envivio? Can you maybe check with real MS FDAM and provide output of that? Apart from the decoder, if it's really a bug, we need your encoding settings and hardware/software plattform. > I think that should be better for XviD to test also mpeg4 iso > interoperability on corrections/new implementations... obviously not > on aplha implementation, but isn't this the case. Envivio is not perfect mpeg4 iso, it's Envivio. I'm pretty sure it has as many bugs as other decoders. And even MPEG-4 ISO Specs are changed (called "clarified") from time to time. gruel > The mine would be just an advice, I use XviD only for mp4 iso streams, > I would continue to use it if possible .... > > Sorry for my english that is far to be perfect, > Thanks in advance, > > FunMan > > >> > > Hoping in your answer, > > Greeting > > Daniele. > > From radoslaw at airnet.com.au Wed Feb 19 22:46:24 2003 From: radoslaw at airnet.com.au (Radoslaw) Date: Wed Feb 19 13:14:59 2003 Subject: [XviD-devel] Re: XviD Mpeg4 Iso Interoperability bug! In-Reply-To: References: Message-ID: <19531121718.20030219224624@airnet.com.au> > First, the new feature, VHQ, cause my system to crash. However isn't > this the problem, 'cause VHQ is very beta and unstable feature and at > the moment I don't want to use it. It crashes with sse2 optimizations, disable them. It's probably that coefficients table is not declared with DECLARE_ALIGNED_MATRIX while idct_sse2 needs it. I've been wondering - are our sse2 functions any faster than sse? If they aren't we should disable them. Radek From D.Buffa at eidosis.com Wed Feb 19 17:03:40 2003 From: D.Buffa at eidosis.com (Daniele Buffa) Date: Wed Feb 19 17:04:07 2003 Subject: [XviD-devel] RIF: XviD Mpeg4 Iso Interoperability bug! Message-ID: <27404F1E37381C428F26763DF89BDCBC8EE6F8@excsrv01.eidoslan.net> First of all thank for your reply, I'm using a very hostile webmail, so I'll use the tags to quote your message If it's important material, don't use the development tree since that may change from time to time (as you might have noticed). Normally, that is when bugs are _removed_, no introduced, but who knows... It's not important material, but I have to compress some DVD and I want to use bframe and croma motion, so I must to use development tree. And bframe and croma motion seem to be quite stable, with previous version I had no problem. Unluckly when I compiled the new version I overwritten the "old" one... :( > First, the new feature, VHQ, cause my system to crash. However isn't > this the problem, 'cause VHQ is very beta and unstable feature and at > the moment I don't want to use it. Can you be more specific? I didn't have a single crash since I started testing it. Simply when I try to use it VirtualDub or VirtualDubMod crashes! I'll write my system configuration if this can help you. However my problem, as I said, isn't VHQ... That depends on _when_ you checked out the last time. Please check which bitstream version of XVID that was. (it's in xvid.h) At the moment I'm not at home. I checked out the source in 16-02. Yeasterday I tried to check out but there's no modified code. Hm, there is no problem with ffmpeg decoder, so maybe it's not encoder related but rather the decoder. Can you describe _what_ you see with Envivio? Mmmm, it's hard to describe, my advice if you can is to install Envivio tv and try yourself. However the problem is that the title "Queen Productions presents" is color altered and distorted, with yellow in the red (but the original title is *only* red!) Can you maybe check with real MS FDAM and provide output of that? I don't know where looking for it. If you can tell me where it could be downloaded I'll check it Apart from the decoder, if it's really a bug, we need your encoding settings and hardware/software plattform. Encoding settings: I used AviSynth 2.5 (YV12), the script is very simple, however I used UnDot, Luma -2 and UnFilter(-5,-5) in order to reducing the blockiness problem in dark areas. A correct crop and a 512x288 lanczos resize. My system: Pentium IV 2.4 GHz, 512 Mb RIMM @ 1066 MHz, mainboard Asus P4T533 (i850), Raid Array in stripe mode (Promise FastTrack 133 lite controller onboard), Acard 6712UW (cd burner and dvd player on scsi chain), sound card Audigy2 Platinum, OS Windows XP sp1, XviD self compiled (but also using Koepi build the result is the same) with VC7 (.Net) sp2, the last version of Envivio TV player. I posted the problem also on Envivio support board. You can find it here http://ubb.envivio.com/6/ubb.x?a=tpc&s=31860025&f=494606401&m=3326042832&r=3326042832#3326042832 This message is sent also to Boris of Envivio, in Cc, hoping he could check the Envivio player. Waiting for an answer Thanks Daniele From sms at 2BSD.COM Wed Feb 19 10:56:24 2003 From: sms at 2BSD.COM (Steven M. Schultz) Date: Wed Feb 19 19:56:37 2003 Subject: [XviD-devel] libxvidcore.so not found + suggested fix Message-ID: <200302191856.h1JIuOU23173@moe.2bsd.com> Hi! I'm using one of the *BSD* variants (BSD/OS 4.3.1 to be precise) and was surprised to get a "libxvidcore.so not found" error when running 'mencoder' (MPlayer's encoder which uses libxvidcore): moe.18-> mencoder mencoder: can't load library 'libxvidcore.so' moe.20-> objdump -p /usr/local/lib/libxvidcore.so /usr/local/lib/libxvidcore.so: file format elf32-i386 Program Header: LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12 filesz 0x00086684 memsz 0x00086684 flags r-x LOAD off 0x000866c0 vaddr 0x000876c0 paddr 0x000876c0 align 2**12 filesz 0x00003de8 memsz 0x0006dda0 flags rw- DYNAMIC off 0x0008a410 vaddr 0x0008b410 paddr 0x0008b410 align 2**2 filesz 0x00000098 memsz 0x00000098 flags rw- Dynamic Section: NEEDED libc.so.2 NEEDED libm.so NEEDED libgcc.so.1 INIT 0x9cbc FINI 0x8013c HASH 0x94 STRTAB 0x2bc8 SYMTAB 0xc88 STRSZ 0x1e4b SYMENT 0x10 PLTGOT 0x8acfc PLTRELSZ 0x478 PLTREL 0x11 JMPREL 0x9844 REL 0x4a14 RELSZ 0x4e30 RELENT 0x8 TEXTREL 0x0 The problem is that the shared library does not have a "soname" for the dynamic linker to find. When creating a shared library it seems to be necessary to add use "-soname libxvidcore.so -shared" This small patch does rely on using 'gcc' to pass thru to the linker the appropriate flags: --- configure.in.dist Sun Feb 16 21:17:45 2003 +++ configure.in Wed Feb 19 10:43:15 2003 @@ -247,7 +247,7 @@ case "$target_os" in *bsd*|linux*|irix*|solaris*) AC_MSG_RESULT([-shared -lc -lm]) - SPECIFIC_LDFLAGS="-shared -lc -lm" + SPECIFIC_LDFLAGS="-Wl,-soname -Wl,libxvidcore.so -shared -lc -lm" SPECIFIC_CFLAGS="-fPIC" ;; [[cC]][[yY]][[gG]][[wW]][[iI]][[nN]]|mingw32|mks) After building the shared library with that change: /usr/local/lib/libxvidcore.so: file format elf32-i386 Program Header: LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12 filesz 0x0008691c memsz 0x0008691c flags r-x LOAD off 0x00086940 vaddr 0x00087940 paddr 0x00087940 align 2**12 filesz 0x00003df0 memsz 0x0006ddb8 flags rw- DYNAMIC off 0x0008a690 vaddr 0x0008b690 paddr 0x0008b690 align 2**2 filesz 0x000000a0 memsz 0x000000a0 flags rw- NOTE off 0x00086904 vaddr 0x00086904 paddr 0x00086904 align 2**2 filesz 0x00000018 memsz 0x00000018 flags r-- Dynamic Section: NEEDED libc.so.2 NEEDED libm.so NEEDED libgcc.so.1 SONAME libxvidcore.so INIT 0x9ee0 FINI 0x803bc HASH 0xb4 STRTAB 0x2cb0 SYMTAB 0xcd0 STRSZ 0x1ea0 SYMENT 0x10 PLTGOT 0x8af7c PLTRELSZ 0x488 PLTREL 0x11 JMPREL 0x9a58 REL 0x4b50 RELSZ 0x4f08 RELENT 0x8 TEXTREL 0x0 Cheers, Steven Schultz From camis at mweb.co.za Thu Feb 20 08:00:27 2003 From: camis at mweb.co.za (Cami) Date: Thu Feb 20 07:00:26 2003 Subject: [XviD-devel] RIF: XviD Mpeg4 Iso Interoperability bug! References: <27404F1E37381C428F26763DF89BDCBC8EE6F8@excsrv01.eidoslan.net> Message-ID: <007001c2d8a5$5e7f7510$803102c4@mweb.com> | | > First, the new feature, VHQ, cause my system to crash. However isn't | > this the problem, 'cause VHQ is very beta and unstable feature and at | > the moment I don't want to use it. | | Can you be more specific? I didn't have a single crash since I started | testing it. | | | Simply when I try to use it VirtualDub or VirtualDubMod crashes! | I'll write my system configuration if this can help you. However my problem, as I said, isn't VHQ... Disable SSE2 when using VHQ, the bug was found yesterday.. Once disabled, the "crashes" stop.. ++C From D.Buffa at eidosis.com Thu Feb 20 11:02:17 2003 From: D.Buffa at eidosis.com (Daniele Buffa) Date: Thu Feb 20 11:02:29 2003 Subject: [XviD-devel] RIF: XviD Mpeg4 Iso Interoperability bug! Message-ID: <27404F1E37381C428F26763DF89BDCBC8EE6F9@excsrv01.eidoslan.net> Always on the known problem I notice that with the new version of XviD enabling bframe and using it in mp4, I've video/audio sync problem and also little freeze on fast action scenes. Turning off bframe I cannot notice the problem. This evening I'll try to compile the codec with previous version of code (I've XviD sources under VSS at home, synchronized with CVS) in order to try to understand where the problem is. I think the problem (if really it's a problem) is in bframe and/or bitstream coding (because if I disable bframe I've no problem at all). Which module regarding bframe and bistream has been modified since 01-02-03? Thanks, Daniele. From suxen_drol at hotmail.com Thu Feb 20 23:20:08 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Thu Feb 20 13:20:25 2003 Subject: [XviD-devel] RIF: XviD Mpeg4 Iso Interoperability bug! In-Reply-To: <27404F1E37381C428F26763DF89BDCBC8EE6F9@excsrv01.eidoslan.net> References: <27404F1E37381C428F26763DF89BDCBC8EE6F9@excsrv01.eidoslan.net> Message-ID: <20030220231246.BE5A.SUXEN_DROL@hotmail.com> On Thu, 20 Feb 2003 11:02:17 +0100 "Daniele Buffa" wrote: [...] i downloaded your test.avi/mp4 files. * it decodes correctly in xvid and fdam and divx503. * evivio (ETV-1-2-46-i1-Q1.exe) displays color artifacts when decoding the first ~100 frames. is this same problem u have? if so, then it's most likely an envivio decoder fault. -- pete; life is like a box of ammo From suxen_drol at hotmail.com Thu Feb 20 23:43:17 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Thu Feb 20 13:43:28 2003 Subject: [XviD-devel] dev-api-4 this weekend Message-ID: <20030220232906.254A.SUXEN_DROL@hotmail.com> hi. now that dev-api-3 is back into the CVS_HEAD, i plan to fork dev-api-4 this weekend, and commit some major changes. here's my plan: 1. tag&branch xvidcore into "dev-api-4" 2. commit my new api to dev-api-4 3. add&commit three subdirectories (vfw, dshow and rawdec) into the xvidcore "dev-api-4". these will be similar to the existing vfw & dshow project, but will support the new api. rawdec is one of my personal debug tools, and is not unlike the examples/xvid_decraw. 4. perform extensive testing 5. intergrate ed's rate control framework. 6. perform futher testing dev-api-4 is intended for api/ratecontrol stuff only. i hope to stablize the branch quickly (two months max) and merged back into CVS_HEAD. -- pete; life is like a box of ammo From chl at math.uni-bonn.de Thu Feb 20 15:02:58 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Thu Feb 20 15:03:20 2003 Subject: [XviD-devel] dev-api-4 this weekend In-Reply-To: <20030220232906.254A.SUXEN_DROL@hotmail.com> Message-ID: On Thu, 20 Feb 2003, suxen_drol wrote: > now that dev-api-3 is back into the CVS_HEAD, i plan to fork dev-api-4 > this weekend, and commit some major changes. > > here's my plan: > 1. tag&branch xvidcore into "dev-api-4" > > 2. commit my new api to dev-api-4 > > 3. add&commit three subdirectories (vfw, dshow and rawdec) into the > xvidcore "dev-api-4". these will be similar to the existing vfw & dshow > project, but will support the new api. rawdec is one of my personal > debug tools, and is not unlike the examples/xvid_decraw. Is it able to read video dimensions from raw data stream? That's something I would love to see in xvid-examples (and of course it's not too difficult to do, but I'm to lazy to do so). > 4. perform extensive testing > > 5. intergrate ed's rate control framework. > > 6. perform futher testing > > dev-api-4 is intended for api/ratecontrol stuff only. i hope to stablize > the branch quickly (two months max) and merged back into CVS_HEAD. Great! Thanks Pete! gruel From ed.gomez at free.fr Thu Feb 20 15:33:34 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Thu Feb 20 15:33:39 2003 Subject: [XviD-devel] dev-api-4 this weekend In-Reply-To: References: <20030220232906.254A.SUXEN_DROL@hotmail.com> Message-ID: <20030220143334.GB13515@leloo> Christoph Lampert (chl@math.uni-bonn.de) wrote: > Is it able to read video dimensions from raw data stream? That's something > I would love to see in xvid-examples (and of course it's not too difficult > to do, but I'm to lazy to do so). Yes, step through a debug session of xvid_decraw, as it uses the flag DEC_STAT, it is able to retrieve the dimensions when the parser reads the first header in the stream. This has been hidden in xvid_decraw but i can modify it to make it search for dimansions first and then start again decompression ? @pete: why commiting your test bed, what have they more than xvid_decraw/xvid_encraw/(future) xvid_stat have not yet ? I remeber you sent me these files long ago, and iirc they do the same job. Correct me if i'm wrong. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030220/49a64b73/attachment.bin From elcabesa at inwind.it Thu Feb 20 16:03:01 2003 From: elcabesa at inwind.it (elcabesa) Date: Thu Feb 20 16:06:14 2003 Subject: [XviD-devel] dev-api-4 this weekend In-Reply-To: <20030220232906.254A.SUXEN_DROL@hotmail.com> References: <20030220232906.254A.SUXEN_DROL@hotmail.com> Message-ID: <200302201603.01360.elcabesa@inwind.it> On Thursday 20 February 2003 13:43, suxen_drol wrote: > hi. > > now that dev-api-3 is back into the CVS_HEAD, i plan to fork dev-api-4 > this weekend, and commit some major changes. > > here's my plan: > 1. tag&branch xvidcore into "dev-api-4" > > 2. commit my new api to dev-api-4 > > 3. add&commit three subdirectories (vfw, dshow and rawdec) into the > xvidcore "dev-api-4". these will be similar to the existing vfw & dshow > project, but will support the new api. rawdec is one of my personal > debug tools, and is not unlike the examples/xvid_decraw. > > 4. perform extensive testing > > 5. intergrate ed's rate control framework. > > 6. perform futher testing > > dev-api-4 is intended for api/ratecontrol stuff only. i hope to stablize > the branch quickly (two months max) and merged back into CVS_HEAD. > > -- pete; life is like a box of ammo wow=) i like to see new code and try to mae it work with mplayer=) now a suggestion: since dev-3-api is declered stable why not remove from xvid.h #define XVID_API_UNSTABLE and i'll try to remove it also form mplayer and hope that they will include these fix=) byee From chl at math.uni-bonn.de Thu Feb 20 16:17:31 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Thu Feb 20 16:17:33 2003 Subject: [XviD-devel] dev-api-4 this weekend In-Reply-To: <200302201603.01360.elcabesa@inwind.it> Message-ID: On Thu, 20 Feb 2003, elcabesa wrote: > now a suggestion: > since dev-3-api is declered stable why not remove from xvid.h > #define XVID_API_UNSTABLE Btw. is dev-api-3 really "stable" now??? Considering how much bugfixing I did for GMC (not much) etc., I doubt that it's ready for that. Of course, it is "main line of development", but apart from that... gruel From ed.gomez at free.fr Thu Feb 20 16:32:56 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Thu Feb 20 16:33:07 2003 Subject: [XviD-devel] dev-api-4 this weekend In-Reply-To: References: <200302201603.01360.elcabesa@inwind.it> Message-ID: <20030220153256.GC13515@leloo> Christoph Lampert (chl@math.uni-bonn.de) wrote: > Of course, it is "main line of development", but apart from that... I agree, it's mainline, but this i do not consider it as stable nor from the developer point of view (new features are still added from time to time modifying the API -- even if it's just a flag, it's an API change) nor from the user point of view (features are rather new and untested -- bits, gmc among others). -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030220/7f295cbe/attachment.bin From elcabesa at inwind.it Thu Feb 20 17:11:08 2003 From: elcabesa at inwind.it (elcabesa) Date: Thu Feb 20 17:14:19 2003 Subject: [XviD-devel] dev-api-4 this weekend In-Reply-To: <20030220153256.GC13515@leloo> References: <200302201603.01360.elcabesa@inwind.it> <20030220153256.GC13515@leloo> Message-ID: <200302201711.08745.elcabesa@inwind.it> On Thursday 20 February 2003 16:32, Edouard Gomez wrote: > Christoph Lampert (chl@math.uni-bonn.de) wrote: > > Of course, it is "main line of development", but apart from that... > > I agree, it's mainline, but this i do not consider it as stable nor from > the developer point of view (new features are still added from time to > time modifying the API -- even if it's just a flag, it's an API change) > nor from the user point of view (features are rather new and untested -- > bits, gmc among others). ok so another question how a coder can know which xvid library is using? will api number change? From chl at math.uni-bonn.de Thu Feb 20 17:39:27 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Thu Feb 20 17:39:35 2003 Subject: [XviD-devel] dev-api-4 this weekend In-Reply-To: <200302201711.08745.elcabesa@inwind.it> Message-ID: On Thu, 20 Feb 2003, elcabesa wrote: > On Thursday 20 February 2003 16:32, Edouard Gomez wrote: > > Christoph Lampert (chl@math.uni-bonn.de) wrote: > > > Of course, it is "main line of development", but apart from that... > > > > I agree, it's mainline, but this i do not consider it as stable nor from > > the developer point of view (new features are still added from time to > > time modifying the API -- even if it's just a flag, it's an API change) > > nor from the user point of view (features are rather new and untested -- > > bits, gmc among others). > > ok so another question > how a coder can know which xvid library is using? > will api number change? I very much hope so! Somehow we forgot(?) to update API_VERSION from 2.1 to 3.0, but the first commit of the new one should definitely have API_VERSION 4.0 in xvid.h gruel From ed.gomez at free.fr Thu Feb 20 19:07:52 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Thu Feb 20 19:08:12 2003 Subject: [XviD-devel] Bootstrap In-Reply-To: References: <20030219000406.GA30684@leloo> Message-ID: <20030220180752.GD13515@leloo> Christoph Lampert (chl@math.uni-bonn.de) wrote: > Yes, of course I read that, but I find it rather strange to remove all the > makefiles by an advanced automatic "autoconf/automake" system, and then > every user except for Debian Linux (which I doubt is the majority of > non-windows users) has to edit the file by hand before even bootstrap > runs. I'm sure you know CVS is meant for development :-) so CVS versions are not for "users" but rather for developers that want to test the CVS version. These users know what to do, "joe" user will not, but "joe" user should use releases and not CVS. Btw your patch is welcome to make bootstrap.sh more "all distro" friendly. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030220/8bd30450/attachment.bin From chl at math.uni-bonn.de Thu Feb 20 19:16:18 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Thu Feb 20 19:16:23 2003 Subject: [XviD-devel] Bootstrap In-Reply-To: <20030220180752.GD13515@leloo> Message-ID: On Thu, 20 Feb 2003, Edouard Gomez wrote: > Christoph Lampert (chl@math.uni-bonn.de) wrote: > > Yes, of course I read that, but I find it rather strange to remove all the > > makefiles by an advanced automatic "autoconf/automake" system, and then > > every user except for Debian Linux (which I doubt is the majority of > > non-windows users) has to edit the file by hand before even bootstrap > > runs. > > I'm sure you know CVS is meant for development :-) so CVS versions are > not for "users" but rather for developers that want to test the CVS > version. These users know what to do, "joe" user will not, but "joe" > user should use releases and not CVS. Can we agree that _I'm_ just too lazy to edit bootstrap.sh every time I do a fresh checkout? > Btw your patch is welcome to make bootstrap.sh more "all distro" > friendly. Hooray! ;-) gruel From ed.gomez at free.fr Thu Feb 20 19:39:59 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Thu Feb 20 19:40:15 2003 Subject: [XviD-devel] Bootstrap In-Reply-To: References: <20030220180752.GD13515@leloo> Message-ID: <20030220183959.GE13515@leloo> Christoph Lampert (chl@math.uni-bonn.de) wrote: > Can we agree that _I'm_ just too lazy to edit bootstrap.sh every time I do > a fresh checkout? Yep i agree :-P > > Btw your patch is welcome to make bootstrap.sh more "all distro" > > friendly. > > Hooray! ;-) Now commited, but it's a reworked patch because yours was a bit buggy :-) if [ -x $AUTOCONF ] rm -f configure.in else ... Would have removed the configure.in file on all Debian boxes.... you are evil gruel :-) trying to impose me what i imposed you ? ;-)) -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030220/48b72491/attachment.bin From chl at math.uni-bonn.de Thu Feb 20 20:16:19 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Thu Feb 20 20:16:24 2003 Subject: [XviD-devel] Bootstrap In-Reply-To: <20030220183959.GE13515@leloo> Message-ID: On Thu, 20 Feb 2003, Edouard Gomez wrote: > Would have removed the configure.in file on all Debian boxes.... you are > evil gruel :-) trying to impose me what i imposed you ? ;-)) That wasn't me, that was Quakeforge... I thought there might be a reason, so I didn't touch it. gruel From sms at 2BSD.COM Thu Feb 20 14:12:06 2003 From: sms at 2BSD.COM (Steven M. Schultz) Date: Thu Feb 20 23:12:27 2003 Subject: [XviD-devel] ./bootstrap.sh errors Message-ID: <200302202212.h1KMC6x18641@moe.2bsd.com> Hi ! Ran into a bit of trouble with the new ./bootstrap.sh script... $ testing=`which autoconf2.50` $ echo $testing no autoconf2.50 in /bin /usr/bin /usr/sbin /sbin /usr/contrib/bin /usr/X11/bin /usr/local/bin /usr/local/sbin /usr/contrib/teTeX/bin /mysql/bin /usr/java/bin /usr/wp8/wpbin /usr/local/pccts/bin /usr/contrib/kde/bin /usr/contrib/gnome/bin /usr/contrib/gnome/enlightenment/bin The test for autoconf2.50 does not work as expected since that test uses `which autoconf2.50` awds59.643-> ./bootstrap.sh sed: 1: "s/^[^0-9]*//i": bad flag in substitute command: 'i' test: null string where integer was expected test: null string where integer was expected Creating ./configure Copying files provided by automake Copying files provided by libtool Removing files that are not needed 'i' isn't a valid flag for 'sed' it seems. The "test" errors are because strings are empty and that causes argument mismatches in '[' ']' processing. Below is an alternate approach to testing for the correct version of autoconf. Also, there needs to be a "-soname" in the shared library that is built - else the ld.so loader can't find the shared object at run time (that's what the patch I submitted yesterday was for). Cheers, Steven Schultz --------------------cut here--------------------- --- bootstrap.sh.dist Thu Feb 20 13:36:57 2003 +++ bootstrap.sh Thu Feb 20 14:06:54 2003 @@ -11,21 +11,23 @@ ############################################################################## # we first test Debian GNU/Linux autoconf for 2.50 series -AUTOCONF=`which autoconf2.50` +AUTOCONF=autoconf2.50 -if [ ! -x "$AUTOCONF" ] ; then +$AUTOCONF >/dev/null 2>/dev/null +if [ $? != 0 ] ; then # Test failed, testing generic name -- many distros are shipping 2.13 with # that name, that's why we have to perform an additional test for version. - AUTOCONF=`which autoconf` + AUTOCONF=autoconf - if [ ! -x "$AUTOCONF" ] ; then + $AUTOCONF + if [ $? != 0 ] ; then echo "No autoconf binary found in PATH" exit -1 fi # Tests the autoconf version - AC_VER=`$AUTOCONF --version | head -1 | sed 's/^[^0-9]*//i'` + AC_VER=`$AUTOCONF --version | head -1 | sed 's/^[^0-9]*//'` AC_MAJORVER=`echo $AC_VER | cut -f1 -d'.'` AC_MINORVER=`echo $AC_VER | cut -f2 -d'.'` From ed.gomez at free.fr Thu Feb 20 23:23:29 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Thu Feb 20 23:23:42 2003 Subject: [XviD-devel] XVID_INIT_TEST question & request Message-ID: <20030220222329.GF13515@leloo> I'm going into a rush before pete branches dev-api-4 because i want some simple portability fixes to be done once for all branches. I'm wondering why we have a test function that takes the param1 as a "what tests do we perform" flag but there are no documented flags in xvid.h. Could the one who commited tests do proper flags documentation and move them to xvid.h as required ? Thanks -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030220/cca4f7fe/attachment.bin From ed.gomez at free.fr Thu Feb 20 23:51:57 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Thu Feb 20 23:52:12 2003 Subject: [XviD-devel] ./bootstrap.sh errors In-Reply-To: <200302202212.h1KMC6x18641@moe.2bsd.com> References: <200302202212.h1KMC6x18641@moe.2bsd.com> Message-ID: <20030220225157.GG13515@leloo> Steven M. Schultz (sms@2bsd.com) wrote: > ... ran into trouble ... > > $ testing=`which autoconf2.50` > $ echo $testing > no autoconf2.50 in /bin /usr/bin /usr/sbin ... oh... a different "which" output, GNU/Linux whish does output nothing when it does not find it. Fixing that with your proposed patch > Also, there needs to be a "-soname" in the shared library that > is built - else the ld.so loader can't find the shared object at > run time (that's what the patch I submitted yesterday was for). I am working on that too, and have something ready, but it needs some more work as it will definitively break the possibility to install old versions and new versions alongside. Moreover i'm fixing win32 build and macosx build because their versionning system is quite different. I'll probably don't do versionning on win32 and respect MacOSX tradition libname$(version).dylib -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030220/0fc5e5b9/attachment.bin From ed.gomez at free.fr Fri Feb 21 01:37:21 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Fri Feb 21 01:37:35 2003 Subject: [XviD-devel] [BUGS] failure on alpha processor and memory leakings Message-ID: <20030221003721.GJ13515@leloo> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030221/9d9a3653/attachment.bin From s_kazim_raza at yahoo.com Thu Feb 20 21:13:07 2003 From: s_kazim_raza at yahoo.com (Kazim Raza) Date: Fri Feb 21 06:13:13 2003 Subject: [XviD-devel] imp DiectX Message-ID: <20030221051307.16325.qmail@web12808.mail.yahoo.com> While using Directx I am using the program StillCap program in directx Well trying to get the real time incoming buffer I am usin the function GetCurrentBuffer and it is giving me the following Errorcode VFW_E_WRONG_STATEThe filter did not buffer a sample yet. To buffer a sample, run or pause the graph. how to cope withthis sort of error Kazim Raza --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more-------------- next part -------------- An HTML attachment was scrubbed... URL: http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030220/8ed972bd/attachment.htm From suxen_drol at hotmail.com Fri Feb 21 18:00:11 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Fri Feb 21 08:00:19 2003 Subject: [XviD-devel] dev-api-4 this weekend In-Reply-To: <20030220143334.GB13515@leloo> References: <20030220143334.GB13515@leloo> Message-ID: <20030221174150.4173.SUXEN_DROL@hotmail.com> On Thu, 20 Feb 2003 15:33:34 +0100 Edouard Gomez wrote: > > @pete: why commiting your test bed, what have they more than > xvid_decraw/xvid_encraw/(future) xvid_stat have not yet ? I remeber you > sent me these files long ago, and iirc they do the same job. Correct me > if i'm wrong. yep they perform the same thing. i like rawenc, because its very simple. someday i would like see a single "xvid" command line tool. ie. % xvid [command] [options...] input [output] % xvid enc pgm%03i.pgm stream.m4v ; basic encoding % xvid enc --psnr pgm%03i.pgm ; xvid_stat % xvid dec stream.m4v pgm%03i.pgm ; decode % xvid test ; xvid test/bench On Thu, 20 Feb 2003 17:11:08 +0100 elcabesa wrote: > ok so another question > how a coder can know which xvid library is using? > will api number change? the new api will use slightly different public symbols to the existing api. i plan to call them: xvid_global, xvid_encoder, xvid_decoder. OR, should we respect our encore,decore heritage? the new api will have a well documented version system, to enable forward/backwards compatibility. if you dredge up some mails from october-thru-decemember, you will see our discussion about versioning. i consider libxvidcore and the api version to be the same thing. when the new api is stabilzed, i intend to call it "v1.0.0". On Thu, 20 Feb 2003 23:23:29 +0100 Edouard Gomez wrote: > I'm wondering why we have a test function that takes the param1 as a > "what tests do we perform" flag but there are no documented flags in > xvid.h. Could the one who commited tests do proper flags documentation > and move them to xvid.h as required ? this code is from my "new-api" tree. ~two months back, we were experiencing problems with dcts and quant's above>14, so i commited this test code. the my intention was to have something like xvid_bench inside xvidcore, which can be compiled with a ./configure flag. however i never decided on a proper xvid_test_t struct, or a console output mechanism (for example: printf-like callback?) since the XVID_TEST_xxx stuff is api related, this can be fixed as part of the api upgrade. -- pete; life is like a box of ammo From suxen_drol at hotmail.com Fri Feb 21 18:27:25 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Fri Feb 21 08:27:34 2003 Subject: [XviD-devel] cvs structure Message-ID: <20030221182724.CEC2.SUXEN_DROL@hotmail.com> hi everyone, --- to uManiac: last week we merged the dev-api-3 tree back into the CVS_HEAD. people are complaining that your auto-compiled 'stable' builds are no longer stable and in-fact developer builds. oouch! --- here's is how i envisage future use of the xvidcore project: we use three tiers of development. "stable": where the code appears to be stable enough for public release. we tag the cvs in the form "release_$major_$minor_$patch". important: i think we should have a "release" tag, which always points to the latest release. "unstable": CVS_HEAD us used for current development, where we add new code and commit patches. its developmental, which means it should always compile, but the output bitstream can't be fully trusted. naturally, we encourage people to test unstable, so eventually it can be made stable. "experimental": this is where we branch off (ie. dev-api-3), and work on something. we do this, so that we can experiment with radical ideas and/or apply major-changes without affecting the normal development team. when the autors are satisifed, they can merge their changes back into CVS_HEAD. dev-api-3 was a bit awkward, because we tried to stablize the bframes, qpel and gmc, but it proved to be too big to manage. ideally, experimental stuff should be strictly focused, such that they dont get out of control! --- to uManiac: i suggest you provide a stable release by using "cvs co -r release" and a unstable release by using "cvs co". experimental builds, with the exception of dev-api-3, shouldn't be made downloadable to the public. --- -- pete; life is like a box of ammo From chl at math.uni-bonn.de Fri Feb 21 11:36:12 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Fri Feb 21 11:36:21 2003 Subject: [XviD-devel] [BUGS] failure on alpha processor and memory leakings In-Reply-To: <20030221003721.GJ13515@leloo> Message-ID: On Fri, 21 Feb 2003, Edouard Gomez wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x120031f28 in sad16_c (cur=0x2000037d690 "...", > ref=0x201003a94b0
, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > stride=480, best_sad=1048576) at ../../src/motion/sad.c:68 Most likely again a "pointer are 64bit but offset calculation is done in 32bit" problem. E.g. I guess "stride" values should always be of type ptr_t instead of int32_t and especially they should not be of type uint32_t. > Is the code 64bit ready ? Could you have a look at your code and try to > find code areas where 64bit could lead to problems ? Is it better for 64bit to use &cur[x*stride+y] notation instead of cur+x*stride+y ? Does (cur + x) work when x ist signed int32_t with negative value and cur is a pointer? Then we could go through the code once and for all and remove all unnecessary "int32_t/uint32_t" and also make everything signed that is needed. Actually make everything signed which is used for calculations and where extra bit is not needed (e.g. macroblock x-dim etc, too). > @all > > When i saw the alpha regression, I decided to see if this error was > present in the ia32 arch but for some obscure reason did not trigger > SIGSEGV signal (it's common that libc on ia32 allocates a bit more space > than needed, thus allows implicitly out of bounds operations) In sad16_c as well? That's strange... > And we have two memory leaks in core. Not sure whether the leak is in > core or xvid_encraw. I'll have a look tomorrow but if you have time then > "many eyes" are always better than mine(+glasses) only. > > You have the valgrind report in attachement. I don't think it's xvid_encraw. That allocated only two buffers, but both are freed in the end unless the program terminates early. The buffers are of the size XDIM*YDIM*3/2 resp. XDIM*YDIM*3 so one is twice the size of the other and the valgrind output seems to have different sizes. Is seems one is 5 times the other two, and the rest might be due to ALIGNMENT. @all: Just as a general information: Calling free(NULL) is completely legal ANSI C, it does exactly nothing. So checking for ptr!=NULL is never needed before free'ing. Often code gets a little more readable by not checking. gruel From s_kraste at ira.uka.de Fri Feb 21 11:54:02 2003 From: s_kraste at ira.uka.de (Stephan Krause) Date: Fri Feb 21 11:54:11 2003 Subject: [XviD-devel] [BUGS] failure on alpha processor and memory leakings In-Reply-To: References: Message-ID: Hi, > > Is the code 64bit ready ? Could you have a look at your code and try to > > find code areas where 64bit could lead to problems ? As the ia64-guy, I thougth it was 64bit-ready... May it be that the alph-portab.h does not define ptr_t? > Is it better for 64bit to use > &cur[x*stride+y] notation instead of cur+x*stride+y ? It compiles to exactly the same assembler code (at least on ia64). > Does (cur + x) work when x ist signed int32_t with negative value > and cur is a pointer? Should do. > Then we could go through the code once and for all and remove all > unnecessary "int32_t/uint32_t" and also make everything signed that is > needed. Actually make everything signed which is used for calculations > and where extra bit is not needed (e.g. macroblock x-dim etc, too). Good idea (but much work...) > > When i saw the alpha regression, I decided to see if this error was > > present in the ia32 arch but for some obscure reason did not trigger > > SIGSEGV signal (it's common that libc on ia32 allocates a bit more space > > than needed, thus allows implicitly out of bounds operations) > > In sad16_c as well? That's strange... Long ago ;-) we had the same problem on ia64. In halfpel-refine ref was computed using a array[negative value], we changed the variable to be a ptr_t and all was good. So i think the problem will go away if you define ptr_t for alphas Stephan -- Sig fault. (core dumped) From ed.gomez at free.fr Fri Feb 21 13:54:21 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Fri Feb 21 13:54:40 2003 Subject: [XviD-devel] [BUGS] failure on alpha processor and memory leakings In-Reply-To: References: Message-ID: <20030221125421.GA735@leloo> Stephan Krause (s_kraste@ira.uka.de) wrote: > As the ia64-guy, I thougth it was 64bit-ready... May it be that the > alph-portab.h does not define ptr_t? > [...] > So i think the problem will go away if you define ptr_t for alphas The new build system that i take care not to throw away during merge does not define things according to their arch but it uses general description of the target. ARCH_IS_32/64BIT: tells us how big the bus address is. It is tested by the configure script. ARCH_IS_IA32/IA64/PPC/PPC_ALTIVEC/GENERIC: all defined by configure script. They activate per architecture code in sources. The last one (GENERIC) is used to trigger users that try to compile the sources without taking care of defining these defines. I mean GENERIC is plain C version, but you have to define it to show that you know how to compile XviD on your box. ARCH_IS_BIG/LITTLE_ENDIAN: I hope you guess what it means As I did lot of testing for 0.9.1, i know this new portab.h is quite solid and i'm sure it defines ptr_t he right way. Any other suggestion ? PS: the bug you solved changing an uint32_t into a ptr_t variable was not only for 64bit. This bug was here for all architectures but for an obscure reason, only the ia64 CPU was affected. Btw, changing things to ptr_t is not the solution in most cases. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030221/90aca413/attachment.bin From chl at math.uni-bonn.de Fri Feb 21 22:06:10 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Fri Feb 21 22:06:21 2003 Subject: [XviD-devel] vlc_codes.h In-Reply-To: <16738678281.20030216224457@syskin.cjb.net> Message-ID: Hi, Radeks patch created some problems with ffmpeg/mplayer because now some tables are exported that haven't been before and create naming conflicts (e.g. cbpy_tab[] which is only needed in mbcoding.h ) Somehow we should find a real solution, by giving a unique name like xvid_XXX to everything that is exported, and apart from that try not to export anything that isn't really needed from outside! gruel On Sun, 16 Feb 2003, Radek Czyz wrote: > Lo everyone, > > I have a new subject for you ;) > > Maybe you have noticed that after the _BITS stuff, our library got > serveral tens of kilobytes larger. VfW dll was larger by at least > 60kb. > You might ask me what kind of code I write. I promise you this is not > the size of _BITS functions. > The problem is that I had to #include vlc_codes.h to motion > estimation. This file contains all our hard-coded VLC tables, all > declared static. As a result, every table which is used in motion > estimation is incuded in motion estimation object file. All tables > needed for MB coding are included in mbcoding object. All tables > needed for intra block coding are included in mbprediction object. > They are all static - invisible to other modules. > > I wanted to do something about it and came up with an idea which > works. I created a new object, vlc_codes.c . Here, all tables are > defined, not as static. The old vlc_codes.h, which is #included in > other modules, contains 'prototypes' (I don't know the correct > word...) of the tables - just all the tables again, without the actual > data and with 'extern' keyword. > > This way, everything works correctly, but the VfW dll is smaller by > 120kb ! Even if it doesn't have the real effect on performance (but > what about mem bandwith and cpu cache), it still looks much better. > > There probably are better ways - we could include the actual tables to > some existing object - but I hope you agree that we should do > _something_ like this. > > Best regards, > Radek > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel > From ed.gomez at free.fr Fri Feb 21 22:24:09 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Fri Feb 21 22:24:38 2003 Subject: [XviD-devel] vlc_codes.h In-Reply-To: References: <16738678281.20030216224457@syskin.cjb.net> Message-ID: <20030221212409.GA6221@leloo> Christoph Lampert (chl@math.uni-bonn.de) wrote: > Radeks patch created some problems with ffmpeg/mplayer because now > some tables are exported that haven't been before and create naming > conflicts (e.g. cbpy_tab[] which is only needed in mbcoding.h ) > > Somehow we should find a real solution, by giving a unique name > like xvid_XXX to everything that is exported, and apart from that try not > to export anything that isn't really needed from outside! Not that simple, because his BITS features need mostly all tables of Xvid. Before we had separated things in module, but the BITS feature are completly breaking this nice separation. And if you know how to export only some function/variables on Unix systems... i would realy appreciate you to teach me :) The xvid_* prefixing rule seems reasonable. -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030221/2a642a98/attachment.bin From suxen_drol at hotmail.com Sat Feb 22 20:00:27 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Sat Feb 22 10:00:37 2003 Subject: [XviD-devel] dev-api-4 this weekend In-Reply-To: <20030221174150.4173.SUXEN_DROL@hotmail.com> References: <20030220143334.GB13515@leloo> <20030221174150.4173.SUXEN_DROL@hotmail.com> Message-ID: <20030222194720.E2EB.SUXEN_DROL@hotmail.com> hi everybody, i have forked core, calling it "dev-api-4" and commuted the new api with supporting vfw,dshow and rawdec application. while it compiles and functions "okay", i havent had time to do an exhaustive api test against the old CVS_HEAD api. this is roughly how i want the final api to look, though the ratecontrol is not finished nor committed. we also should further discuss gruels plugin concept. i've defined XVID_VERSION as "v1.-127.0" (major=1,minor=-127,minor=0). -127 is used, as minor is incremented at each api change. this gives us sufficient room to upgrade the api before we hit v1.0.0. -- pete; life is like a box of ammo From chl at math.uni-bonn.de Sat Feb 22 10:20:21 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sat Feb 22 10:20:24 2003 Subject: [XviD-devel] dev-api-4 this weekend In-Reply-To: <20030222194720.E2EB.SUXEN_DROL@hotmail.com> Message-ID: On Sat, 22 Feb 2003, suxen_drol wrote: > i've defined XVID_VERSION as "v1.-127.0" (major=1,minor=-127,minor=0). > -127 is used, as minor is incremented at each api change. this gives us > sufficient room to upgrade the api before we hit v1.0.0. Yes! Finally somebody noticed the wonderful efficiency of negative versioning ;-) gruel From chl at math.uni-bonn.de Sat Feb 22 10:46:57 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sat Feb 22 10:46:59 2003 Subject: [XviD-devel] vlc_codes.h In-Reply-To: <20030221212409.GA6221@leloo> Message-ID: On Fri, 21 Feb 2003, Edouard Gomez wrote: > > And if you know how to export only some function/variables on Unix > systems... i would realy appreciate you to teach me :) We can strip whatever we don't need. But for the static lib (which is the problem) I guess this would only work for symbols that really are not needed over sourcefile boundaries... > The xvid_* prefixing rule seems reasonable. Maybe we could do that automatically when creating the library? I found that recent version of "GNU objcopy" have an --redefine-sym option. Thus one could make a copy of libxvidcore.a and rename all exported symbols to the same symbol with a xvid_ in front (except for xvid_encore/decore/init of course). Apart from that we should really find a solution which doesn't export so many internal variables. Isn't there a way to create a static lib where sourcefiles are somehow linked to form a new independent object, each knowing the other ones symbols, but the outside world doesn't? Or is that for shared libs only? gruel From elcabesa at inwind.it Sat Feb 22 11:27:13 2003 From: elcabesa at inwind.it (elcabesa) Date: Sat Feb 22 11:30:58 2003 Subject: [XviD-devel] dev-api-4 this weekend In-Reply-To: <20030222194720.E2EB.SUXEN_DROL@hotmail.com> References: <20030220143334.GB13515@leloo> <20030221174150.4173.SUXEN_DROL@hotmail.com> <20030222194720.E2EB.SUXEN_DROL@hotmail.com> Message-ID: <200302221127.13378.elcabesa@inwind.it> On Saturday 22 February 2003 10:00, suxen_drol wrote: > hi everybody, > > i have forked core, calling it "dev-api-4" and commuted the new api with > supporting vfw,dshow and rawdec application. while it compiles and > functions "okay", i havent had time to do an exhaustive api test against > the old CVS_HEAD api. > > this is roughly how i want the final api to look, though the ratecontrol > is not finished nor committed. we also should further discuss gruels > plugin concept. > > i've defined XVID_VERSION as "v1.-127.0" (major=1,minor=-127,minor=0). > -127 is used, as minor is incremented at each api change. this gives us > sufficient room to upgrade the api before we hit v1.0.0. hi everybody how many ofrk are inside cvs and what are used or still alive? cvs-head dev-3-api and dev-4-api? From elcabesa at inwind.it Sat Feb 22 12:49:45 2003 From: elcabesa at inwind.it (elcabesa) Date: Sat Feb 22 13:21:26 2003 Subject: [XviD-devel] dev-api-4 this weekend In-Reply-To: <20030222194720.E2EB.SUXEN_DROL@hotmail.com> References: <20030220143334.GB13515@leloo> <20030221174150.4173.SUXEN_DROL@hotmail.com> <20030222194720.E2EB.SUXEN_DROL@hotmail.com> Message-ID: <200302221249.45721.elcabesa@inwind.it> On Saturday 22 February 2003 10:00, suxen_drol wrote: > hi everybody, > this is roughly how i want the final api to look, though the ratecontrol > is not finished nor committed. we also should further discuss gruels > plugin concept. hi since you want to move ratecontrol inside core why not move inside core fuction to set motion estimation preset? static int const motion_presets[7] = { 0, 0, 0, 0, PMV_HALFPELREFINE16 | PMV_HALFPELDIAMOND8 , PMV_HALFPELREFINE16 | PMV_HALFPELDIAMOND8 | PMV_ADVANCEDDIAMOND16 | , PMV_HALFPELREFINE16 | PMV_EXTSEARCH16 | PMV_HALFPELREFINE8 | PMV_HALFPELDIAMOND8 | PMV_USESQUARES16 } this may be done during init , using xvid_global and you can also leave abilty to user to change it as they do now=) p.s. looking new api i see that every struct has inside VERSION and you tell that when starting a function we should make a memset and then set version is this xvid-coder related or MUST be done also by external program that want to use xvid codec? byee From elcabesa at inwind.it Sat Feb 22 18:03:55 2003 From: elcabesa at inwind.it (elcabesa) Date: Sat Feb 22 18:07:50 2003 Subject: [XviD-devel] dev-api-4 this weekend In-Reply-To: <20030222194720.E2EB.SUXEN_DROL@hotmail.com> References: <20030220143334.GB13515@leloo> <20030221174150.4173.SUXEN_DROL@hotmail.com> <20030222194720.E2EB.SUXEN_DROL@hotmail.com> Message-ID: <200302221329.24091.elcabesa@inwind.it> On Saturday 22 February 2003 10:00, suxen_drol wrote: > hi everybody, > i've defined XVID_VERSION as "v1.-127.0" (major=1,minor=-127,minor=0). hi i'm looking new code nad found lot's of idea.. and post them here =) please don't kill me=) can you define ADD this version system in stable and dev-api-3 too? it would make coders life easy have a common system versioning p.s. i wrote ADD not replace=) From chl at math.uni-bonn.de Sat Feb 22 19:26:53 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sat Feb 22 19:26:56 2003 Subject: [XviD-devel] Homedefined types Message-ID: Hi, what would you think of introducing new types with more "obvious" names: sad_t for any SAD values in the widest sense of meaning stride_t for typical "stride" types like "edgedwidth" It seems that those two are the most frequent sources of signed/unsigned 32/64bit errors. Others will surely be logical, too. Maybe quant_t dct_t What do you think? gruel From chl at math.uni-bonn.de Sat Feb 22 21:06:14 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sat Feb 22 21:06:18 2003 Subject: [XviD-devel] Macros ? Message-ID: Hi, in ME we define ABS as a macro #define ABS(X) (((X)>0)?(X):-(X)) which is translated into jumps, not conditional moves (on gcc) or bit-arithmetics whereas libc abs() functions should be optimized for the corresponding plattform and should always be inline in any reasonable compiler. Should we change that? Or is macro faster on Windows? Then we could move it to portab.h Similar question for "SIGN(X)" but not urgend, because that isn't used at all... gruel From chl at math.uni-bonn.de Sat Feb 22 21:37:20 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sat Feb 22 21:37:31 2003 Subject: [XviD-devel] 16bit structures Message-ID: Hi, there are some data structure with 16bit values, e.g. static const uint16_t scan_tables[3][64]= {...} in src/bitstream.h and int16_t predictors[8] in src/prediction/mbprediction.h. Is there any specfic reason for that? Just saving memory or something else? Some ratecontrol and quantmatrix stuff is 16bit, too, but I don't know anything about those... gruel From suxen_drol at hotmail.com Sun Feb 23 09:30:03 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Sat Feb 22 23:30:17 2003 Subject: [XviD-devel] dev-api-4 this weekend In-Reply-To: <200302221127.13378.elcabesa@inwind.it> References: <20030222194720.E2EB.SUXEN_DROL@hotmail.com> <200302221127.13378.elcabesa@inwind.it> Message-ID: <20030223085006.E1BD.SUXEN_DROL@hotmail.com> hi, On Sat, 22 Feb 2003 11:27:13 +0100 elcabesa wrote: > how many ofrk are inside cvs and what are used or still alive? > > cvs-head > dev-3-api and > dev-4-api? i posted 'cvs structure' to xvid-devel >1 day ago, which describes the cvs layout. cvs-head is very much alive. it is the primarly place for ~unstable development. dev-api-3 was recently merged back into the head, and now inactive. dev-api-4 is currently active. On Sat, 22 Feb 2003 12:49:45 +0100 elcabesa wrote: > since you want to move ratecontrol inside core why not move inside core > fuction to set motion estimation preset? > > static int const motion_presets[7] = { [...]> > > this may be done during init , using xvid_global and you can also leave abilty > to user to change it as they do now=) we could do it via XVID_GBL_INFO, or a XVID_ENC_INFO command, where xvid returns the array and number of elements. my only concern is that the api becomes over-compliciated by structures. /* motion descriptor */ struct { int flags; motion flag preset char * desc; short flag description ("Low","Medium", "High","Ultra","Monster Kill") } xvid_motion_preset_t; /* encoder info */ struct { int version; [in] int preset_num; [out] num of presets xvid_motion_desc_t * preset; [out] motion preset descriptor array } xvid_enc_info_t; > p.s. looking new api i see that every struct has inside VERSION and you tell > that when starting a function we should make a memset and then set version > is this xvid-coder related or MUST be done also by external program that want > to use xvid codec? the application must zero the struct and set the version field. this ensures backwards/forwards compatibility. > i'm looking new code nad found lot's of idea.. and post them here =) > please don't kill me=) ideas are welcome code/patches are very welcome. > can you define ADD this version system in stable and dev-api-3 too? > it would make coders life easy have a common system versioning > p.s. i wrote ADD not replace=) the new versioning system was designed to make life easier. its been on my todo list since september. however, upgrading the api is a lot of work, which is why i've forked off to commit changes. when we're satisified with the new api (and ratecontrol/plugins issues are resolved), it will merged into the head. there's still much to be done, so please dont upgrade libmpcodecs\ve_xvid.c just yet. the stable releases (release_0_9_0 and release_0_9_1) shouldn't be changed. they are release versions, which are only maintained in the event of bugs. -- pete; life is like a box of ammo From suxen_drol at hotmail.com Sun Feb 23 09:42:00 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Sat Feb 22 23:42:06 2003 Subject: [XviD-devel] Homedefined types In-Reply-To: References: Message-ID: <20030223093200.E1C6.SUXEN_DROL@hotmail.com> On Sat, 22 Feb 2003 19:26:53 +0100 (CET) Christoph Lampert wrote: > > Hi, > > what would you think of introducing new types with more > "obvious" names: > > sad_t for any SAD values in the widest sense of meaning > stride_t for typical "stride" types like "edgedwidth" > > It seems that those two are the most frequent sources of > signed/unsigned 32/64bit errors. > > Others will surely be logical, too. Maybe > > quant_t > dct_t > > What do you think? i think the better solution, which you described, is to replace all the unneccessary portab types with plain ints. for the asm stuff we should retain portab types so we dont break the ppc&ia64 code. dct_t is interesting. i wonder if we could support, through the use of macros (or templates-style hacks), the use of different coefficient sizes. x86-mmx works best with 16-bit coefficients, whereas plain ints are faster on non-simd platforms. keep in mind: it'd be nice to get the new api into head before any major cvs-wide changes are applied... it makes merging a royal pain. -- pete; life is like a box of ammo From suxen_drol at hotmail.com Sun Feb 23 10:19:04 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Sun Feb 23 00:19:11 2003 Subject: [XviD-devel] Macros ? In-Reply-To: References: Message-ID: <20030223094240.E1C9.SUXEN_DROL@hotmail.com> On Sat, 22 Feb 2003 21:06:14 +0100 (CET) Christoph Lampert wrote: > > Hi, > > in ME we define ABS as a macro > > #define ABS(X) (((X)>0)?(X):-(X)) > > which is translated into jumps, not conditional moves (on gcc) or > bit-arithmetics whereas libc abs() functions should be optimized for the > corresponding plattform and should always be inline in any reasonable > compiler. > > Should we change that? Or is macro faster on Windows? > Then we could move it to portab.h stdlib.h::abs() is faster than ABS() with microsoft vc and gcc, even though my box doesnt have cmov's i think we should shift to abs() > -- pete; life is like a box of ammo From elcabesa at inwind.it Sun Feb 23 10:04:00 2003 From: elcabesa at inwind.it (elcabesa) Date: Sun Feb 23 10:07:55 2003 Subject: [XviD-devel] dev-api-4 this weekend In-Reply-To: <20030223085006.E1BD.SUXEN_DROL@hotmail.com> References: <20030222194720.E2EB.SUXEN_DROL@hotmail.com> <200302221127.13378.elcabesa@inwind.it> <20030223085006.E1BD.SUXEN_DROL@hotmail.com> Message-ID: <200302231004.00369.elcabesa@inwind.it> On Saturday 22 February 2003 23:30, suxen_drol wrote: > > can you define ADD this version system in stable and dev-api-3 too? > > it would make coders life easy have a common system versioning > > p.s. i wrote ADD not replace=) > > the new versioning system was designed to make life easier. its been on > my todo list since september. however, upgrading the api is a lot of > work, which is why i've forked off to commit changes. > > when we're satisified with the new api (and ratecontrol/plugins issues > are resolved), it will merged into the head. there's still much to be > done, so please dont upgrade libmpcodecs\ve_xvid.c just yet. > > the stable releases (release_0_9_0 and release_0_9_1) shouldn't be > changed. they are release versions, which are only maintained in the > event of bugs. > > -- pete; life is like a box of ammo > hi i mean can something like this added to all cvs tag. #define XVID_MAKE_VERSION(a,b,c) ( (((a)&0xff)<<16) | (((b)&0xff)<<8) | ((c)&0xff) ) #define XVID_MAJOR(a) ( ((a)>>16) & 0xff ) #define XVID_MINOR(b) ((char)( ((b)>>8) & 0xff )) #define XVID_PATCH(c) ( (c) & 0xff ) #define XVID_VERSION XVID_MAKE_VERSION(1,-127,0) From elcabesa at inwind.it Sun Feb 23 10:55:21 2003 From: elcabesa at inwind.it (elcabesa) Date: Sun Feb 23 10:59:11 2003 Subject: [XviD-devel] last request Message-ID: <200302231055.21498.elcabesa@inwind.it> hi i'm trying to compile xvid head_cvs with mplayer and get this strange error /usr/local/lib/libxvidcore.a(mbcoding.o)(.rodata+0xe00): multiple definition of `cbpy_tab' libavcodec/libavcodec.a(h263.o):/home/elcabesa/MPLAY/main/libavcodec/common.h:21 : first defined here /usr/i386-slackware-linux/bin/ld: Warning: size of symbol `cbpy_tab' changed fro m 32 to 128 in /usr/local/lib/libxvidcore.a(mbcoding.o) collect2: ld returned 1 exit status make: *** [mplayer] Error 1 i think that both you and libavcodec coders define a cpby_tab inside your own code i don't know why it happens, maybe couse you define it "extern" inside a include file =) any idea ? how can i hack it nad maybe givve you a diff that make it work with mplayer? From chl at math.uni-bonn.de Sun Feb 23 11:17:37 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sun Feb 23 11:17:41 2003 Subject: [XviD-devel] last request In-Reply-To: <200302231055.21498.elcabesa@inwind.it> Message-ID: Yes, that was reported on the Mplayer (or ffmpeg?)-list already. Since Syskin's changes, cbpy_tab is exported, which conflicts with ffmpeg. You can either replace all occurances of cbpy_tab to xvid_cbpy_tab in the sources or use objcopy --redefine-sym cbpy_tab=xvid_cbpy_tab libxvidcore.a to change name in binary until we come up with a general solution (cbpy_tab isn't the only unnecessary export). gruel On Sun, 23 Feb 2003, elcabesa wrote: > hi > i'm trying to compile xvid head_cvs with mplayer and get this strange error > > /usr/local/lib/libxvidcore.a(mbcoding.o)(.rodata+0xe00): multiple definition > of `cbpy_tab' > libavcodec/libavcodec.a(h263.o):/home/elcabesa/MPLAY/main/libavcodec/common.h:21 > : first defined here > /usr/i386-slackware-linux/bin/ld: Warning: size of symbol `cbpy_tab' changed > fro m 32 to 128 in /usr/local/lib/libxvidcore.a(mbcoding.o) > collect2: ld returned 1 exit status > make: *** [mplayer] Error 1 > > > i think that both you and libavcodec coders define a cpby_tab inside your own > code > i don't know why it happens, maybe couse you define it "extern" inside a > include file =) > > any idea ? how can i hack it nad maybe givve you a diff that make it work with > mplayer? > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel > From radoslaw at syskin.cjb.net Sun Feb 23 21:03:57 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Sun Feb 23 11:32:43 2003 Subject: [XviD-devel] last request In-Reply-To: References: Message-ID: <153917140.20030223210357@syskin.cjb.net> Hello, > Yes, that was reported on the Mplayer (or ffmpeg?)-list already. > Since Syskin's changes, cbpy_tab is exported, which conflicts with > ffmpeg. Actually, I never commited these changes, I just proposed them. However, let me please tell you one thing: the idea to link coding libraries directly to encoding/decoding applictions, without any kind of standard interface, just asks for conflicts like this. I would really like to understand why mplayer developers disgust any standard codec interface. Just because such interface is "a brain damaged microsoft's idea" is no argument. They have enough power to make UCI, or anything else, a *nix standard within months... Oh well, not my problem (except for this) Regards, Radek From elcabesa at inwind.it Sun Feb 23 11:30:56 2003 From: elcabesa at inwind.it (elcabesa) Date: Sun Feb 23 11:34:51 2003 Subject: [XviD-devel] last request In-Reply-To: References: Message-ID: <200302231130.56690.elcabesa@inwind.it> On Sunday 23 February 2003 11:17, Christoph Lampert wrote: > Yes, that was reported on the Mplayer (or ffmpeg?)-list already. > Since Syskin's changes, cbpy_tab is exported, which conflicts with > ffmpeg. > > You can either replace all occurances of cbpy_tab to xvid_cbpy_tab > in the sources or use > > objcopy --redefine-sym cbpy_tab=xvid_cbpy_tab libxvidcore.a > > to change name in binary until we come up with a general solution > (cbpy_tab isn't the only unnecessary export). > > gruel > > On Sun, 23 Feb 2003, elcabesa wrote: > > hi > > i'm trying to compile xvid head_cvs with mplayer and get this strange > > error > > > > /usr/local/lib/libxvidcore.a(mbcoding.o)(.rodata+0xe00): multiple > > definition of `cbpy_tab' > > libavcodec/libavcodec.a(h263.o):/home/elcabesa/MPLAY/main/libavcodec/comm > >on.h:21 > > > > : first defined here > > > > /usr/i386-slackware-linux/bin/ld: Warning: size of symbol `cbpy_tab' > > changed fro m 32 to 128 in /usr/local/lib/libxvidcore.a(mbcoding.o) > > collect2: ld returned 1 exit status > > make: *** [mplayer] Error 1 > > > > > > i think that both you and libavcodec coders define a cpby_tab inside your > > own code > > i don't know why it happens, maybe couse you define it "extern" inside a > > include file =) > > > > any idea ? how can i hack it nad maybe givve you a diff that make it work > > with mplayer? > > _______________________________________________ > > XviD-devel mailing list > > XviD-devel@xvid.org > > http://list.xvid.org/mailman/listinfo/xvid-devel > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel ops so sorry for this doulbe report=) From ed.gomez at free.fr Sun Feb 23 12:08:44 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Sun Feb 23 12:09:31 2003 Subject: [XviD-devel] last request In-Reply-To: <153917140.20030223210357@syskin.cjb.net> References: <153917140.20030223210357@syskin.cjb.net> Message-ID: <20030223110844.GA720@leloo> Radek Czyz (radoslaw@syskin.cjb.net) wrote: > I would really like to understand why mplayer developers disgust > any standard codec interface. Just because such interface is "a brain > damaged microsoft's idea" is no argument. > > They have enough power to make UCI, or anything else, a *nix standard > within months... > > Oh well, not my problem (except for this) The problem is not having a common interface, the problem is directly related to the fact that all shared library have a common name space and we can't easily decide what to export and what to keep internal. gcc 3.3 or 3.4 (read the gcc development documentation) has new attribtes that would allow us to avoid that in shared code (__attribute__(visibility(hidden))) Now, the problem with mplayer is also related to the fact they like to do static linking, and in this case, you can't avoid name clashes. MPlayer devs are very picky at that, they like their monolithic architecture and don't try to convince them to do a dlopen()... this choice has advantages and drawbacks... -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030223/baa88830/attachment.bin From chl at math.uni-bonn.de Sun Feb 23 12:16:31 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Sun Feb 23 12:16:33 2003 Subject: [XviD-devel] last request In-Reply-To: <153917140.20030223210357@syskin.cjb.net> Message-ID: On Sun, 23 Feb 2003, Radek Czyz wrote: > Hello, > > > Yes, that was reported on the Mplayer (or ffmpeg?)-list already. > > Since Syskin's changes, cbpy_tab is exported, which conflicts with > > ffmpeg. > > Actually, I never commited these changes, I just proposed them. I meant the wonderful introduction of "MODEDECISION_BITS" which unfortunately needs to access some structures which were only static before. > However, let me please tell you one thing: the idea to link coding > libraries directly to encoding/decoding applictions, without any kind > of standard interface, just asks for conflicts like this. That's what static linking is about. Linking the library to the code. An "interface" is needed for calling the routines, how should there be an interface for "linnkig"? > I would really like to understand why mplayer developers disgust > any standard codec interface. Just because such interface is "a brain > damaged microsoft's idea" is no argument. Let's stay constructive, okay? The problem appears in the moment where you try to link both xvidcore and ffmpeg statically to any software, e.g. mplayer. It has nothing to do with not using standard interfaces. Mplayer uses native XVID API just as any other (reasonable) program on UN*X. Btw. ffmpeg developers added a "ff_" prefix to may of their structure/routines to make the names unique. We should do the same. I see no reason why statical linking shouldn't be allowed, I like to link statically very much, because then my programs continue running even when I recompile and install xvid. gruel From Jens.Arm at gmx.de Mon Feb 24 11:55:36 2003 From: Jens.Arm at gmx.de (Jens Arm) Date: Mon Feb 24 11:52:29 2003 Subject: [XviD-devel] xvid (cvs-head) problem (ffmpeg+mplayer) Message-ID: <20030224115536.68c19a4c.Jens.Arm@gmx.de> Hi Since I think last week there is a problem linking xvid with mplayer: gcc -O4 -march=pentium3 -mcpu=pentium3 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ilibmpdemux -Iloader -Ilibvo -I/usr/include/freetype2 -o mplayer mplayer.o mp_msg.o cpudetect.o codec-cfg.o cfgparser.o my_profile.o spudec.o playtree.o playtreeparser.o asxparser.o vobsub.o subreader.o sub_cc.o find_sub.o m_config.o m_option.o parser-cfg.o m_struct.o unrarlib.o mixer.o parser-mpcmd.o libvo/libvo.a libao2/libao2.a vidix/libvidix.a libmpcodecs/libmpcodecs.a mp3lib/libMP3.a liba52/liba52.a libmpeg2/libmpeg2.a loader/libloader.a loader/dshow/libDS_Filter.a loader/dmo/libDMO_Filter.a libaf/libaf.a libmpdemux/libmpdemux.a input/libinput.a postproc/libswscale.a osdep/libosdep.a -Llibmpdvdkit2 -lmpdvdkit libavcodec/libavcodec.a -lmad -lvorbis -logg -ldv -lxvidcore -lpng -lz -lz -ljpeg -lfreetype -ltermcap -lnsl -lungif -laa -lGL -lXxf86dga -lXv -lXxf86vm -lXinerama -L/usr/X11R6/lib -lXext -lX11 -lnsl -lmad -lnsl -lpthread -ldl -lm /usr/local/lib/libxvidcore.a(mbcoding.o)(.rodata+0xd40): multiple definition of `cbpy_tab' libavcodec/libavcodec.a(h263.o):/home/tux/tmp/comp/mplayer/libavcodec/common.h:300: first defined here /usr/bin/ld: Warning: size of symbol `cbpy_tab' changed from 32 to 128 in /usr/local/lib/libxvidcore.a(mbcoding.o) collect2: ld returned 1 exit status make: *** [mplayer] Error 1 If you link dynamically you doesn't get an error and can decode without problems, but encoding results in only pretty color block noise :( I have tried to rename the table-name and then everything IS WORKING fine. Perhaps you can do this in the CVS ??? Jens From radoslaw at syskin.cjb.net Mon Feb 24 21:36:13 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Mon Feb 24 12:05:28 2003 Subject: [XviD-devel] xvid (cvs-head) problem (ffmpeg+mplayer) In-Reply-To: <20030224115536.68c19a4c.Jens.Arm@gmx.de> References: <20030224115536.68c19a4c.Jens.Arm@gmx.de> Message-ID: <305667359.20030224213613@syskin.cjb.net> Lo, > I have tried to rename the table-name and then everything IS WORKING fine. > Perhaps you can do this in the CVS ??? I need a quick answer - do you play with gcc to hide the symbols, or you want to chage them in the code? Just tell me and I'll change them today. Find&replace is fast. Radek From JArm at pixip.net Mon Feb 24 12:16:10 2003 From: JArm at pixip.net (Jens Arm) Date: Mon Feb 24 12:13:19 2003 Subject: [XviD-devel] xvid (cvs-head) problem (ffmpeg+mplayer) In-Reply-To: <305667359.20030224213613@syskin.cjb.net> References: <20030224115536.68c19a4c.Jens.Arm@gmx.de> <305667359.20030224213613@syskin.cjb.net> Message-ID: <20030224121610.4c825998.JArm@pixip.net> > > I have tried to rename the table-name and then everything IS WORKING fine. > > Perhaps you can do this in the CVS ??? > > I need a quick answer - do you play with gcc to hide the symbols, or > you want to chage them in the code? Just tell me and I'll change them > today. Find&replace is fast. I have done a Find&replace. I am new to this list and I have now found that this problem is already known ! There is a solution that you can rename in the binary, too: objcopy --redefine-sym cbpy_tab=xvid_cbpy_tab libxvidcore.a http://list.xvid.org/pipermail/xvid-devel/2003-February/002332.html Jens From chl at math.uni-bonn.de Mon Feb 24 12:14:34 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Mon Feb 24 12:14:41 2003 Subject: [XviD-devel] xvid (cvs-head) problem (ffmpeg+mplayer) In-Reply-To: <305667359.20030224213613@syskin.cjb.net> Message-ID: On Mon, 24 Feb 2003, Radek Czyz wrote: > Lo, > > > I have tried to rename the table-name and then everything IS WORKING fine. > > Perhaps you can do this in the CVS ??? > > I need a quick answer - do you play with gcc to hide the symbols, or > you want to chage them in the code? Just tell me and I'll change them > today. Find&replace is fast. Done already. gruel From chl at math.uni-bonn.de Mon Feb 24 12:14:49 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Mon Feb 24 12:14:54 2003 Subject: [XviD-devel] xvid (cvs-head) problem (ffmpeg+mplayer) In-Reply-To: <20030224115536.68c19a4c.Jens.Arm@gmx.de> Message-ID: Okay, we had this reported several times and since we'll have to do about exported symbols anyway: I replaced all occurance of cbpy_tab (not cbpy_table) with xvid_cbpy_tab in CVS. It's just in mbcoding.c, motion_est.c and vlc_codes.h Yes, it's not beautiful to fix just this table, but before I change everything, we have to come up with a strategy. My suggestion is to either split up vlc_codes.h or move BITS-related functions from motion_est.c to bitstream.c, etc... What cannot be handled this way should get a unique header, e.g. xvid_XXX like ffmpeg (often) using ff_XXX for global symbols. gruel On Mon, 24 Feb 2003, Jens Arm wrote: > Since I think last week there is a problem linking xvid with mplayer: > > gcc -O4 -march=pentium3 -mcpu=pentium3 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ilibmpdemux -Iloader -Ilibvo -I/usr/include/freetype2 -o mplayer mplayer.o mp_msg.o cpudetect.o codec-cfg.o cfgparser.o my_profile.o spudec.o playtree.o playtreeparser.o asxparser.o vobsub.o subreader.o sub_cc.o find_sub.o m_config.o m_option.o parser-cfg.o m_struct.o unrarlib.o mixer.o parser-mpcmd.o libvo/libvo.a libao2/libao2.a vidix/libvidix.a libmpcodecs/libmpcodecs.a mp3lib/libMP3.a liba52/liba52.a libmpeg2/libmpeg2.a loader/libloader.a loader/dshow/libDS_Filter.a loader/dmo/libDMO_Filter.a libaf/libaf.a libmpdemux/libmpdemux.a input/libinput.a postproc/libswscale.a osdep/libosdep.a -Llibmpdvdkit2 -lmpdvdkit libavcodec/libavcodec.a -lmad -lvorbis -logg -ldv -lxvidcore -lpng -lz -lz -ljpeg -lfreetype -ltermcap -lnsl -lungif -laa -lGL -lXxf86dga -lXv -lXxf86vm -lXinerama -L/usr/X11R6/lib -lXext -lX11 -lnsl -lmad -lnsl ! ! > -lpthread -ldl -lm > /usr/local/lib/libxvidcore.a(mbcoding.o)(.rodata+0xd40): multiple definition of `cbpy_tab' > libavcodec/libavcodec.a(h263.o):/home/tux/tmp/comp/mplayer/libavcodec/common.h:300: first defined here > /usr/bin/ld: Warning: size of symbol `cbpy_tab' changed from 32 to 128 in /usr/local/lib/libxvidcore.a(mbcoding.o) > collect2: ld returned 1 exit status > make: *** [mplayer] Error 1 > > > If you link dynamically you doesn't get an error and can decode without problems, but encoding results in > only pretty color block noise :( > > I have tried to rename the table-name and then everything IS WORKING fine. > Perhaps you can do this in the CVS ??? > > > Jens > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel > From ed.gomez at free.fr Mon Feb 24 20:53:07 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Mon Feb 24 20:53:38 2003 Subject: [XviD-devel] xvid (cvs-head) problem (ffmpeg+mplayer) In-Reply-To: References: <20030224115536.68c19a4c.Jens.Arm@gmx.de> Message-ID: <20030224195306.GA819@leloo> Christoph Lampert (chl@math.uni-bonn.de) wrote: > My suggestion is to either split up vlc_codes.h or move BITS-related > functions from motion_est.c to bitstream.c, etc... > What cannot be handled this way should get a unique header, e.g. xvid_XXX > like ffmpeg (often) using ff_XXX for global symbols. I have a third way :) Let's group all tables in a common structure and then we export only the structured element. Then in code we can do a bunch of defines to access tables directly without the need for -> or . operators. Example: /* table.h */ typedef struct { int *firsttable; int *secondtable; }xvid_tables_t; /* table.c */ static int local_firsttable[64]; static int local_secondtable[64]; xvid_tables_t xvid_tables = { local_firsttable, local_secondtable, }; /* Then e.g. in motion_est.c */ #define cbpy_tab xvid_tables.cbpy_tab This way we export only one symbol: xvid_tables, but we still have access to all tables. This is a trick i use to build RC modules that export only one structure that gives access to local functions. What do you think about that ? -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030224/96c33e57/attachment.bin From chl at math.uni-bonn.de Mon Feb 24 21:48:43 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Mon Feb 24 21:48:48 2003 Subject: [XviD-devel] xvid (cvs-head) problem (ffmpeg+mplayer) In-Reply-To: <20030224195306.GA819@leloo> Message-ID: On Mon, 24 Feb 2003, Edouard Gomez wrote: > Christoph Lampert (chl@math.uni-bonn.de) wrote: > > My suggestion is to either split up vlc_codes.h or move BITS-related > > functions from motion_est.c to bitstream.c, etc... > > What cannot be handled this way should get a unique header, e.g. xvid_XXX > > like ffmpeg (often) using ff_XXX for global symbols. > > I have a third way :) > > Let's group all tables in a common structure and then we export only the > structured element. Then in code we can do a bunch of defines to access > tables directly without the need for -> or . operators. If that's as fast as without the additional level, then sure, why not. > Example: > > /* table.h */ > > typedef struct > { > int *firsttable; > int *secondtable; > }xvid_tables_t; > > /* table.c */ > static int local_firsttable[64]; > static int local_secondtable[64]; > > xvid_tables_t xvid_tables = { > local_firsttable, > local_secondtable, > }; > > /* Then e.g. in motion_est.c */ > #define cbpy_tab xvid_tables.cbpy_tab That I don't like. I mean, I don't like #defines which contain fixed variable names as prefix or suffix or modify them or anything. And where is the advantage of #defining cpby_tab as xvid_tabls.cbpy_tab over simply calling the table xvid_cbpy_tab and defining #define cbpy_tab xvid_cbpy_tab if we really want to keep the code shorter? > This way we export only one symbol: xvid_tables, but we still have > access to all tables. This is a trick i use to build RC modules that > export only one structure that gives access to local functions. > > What do you think about that ? I like the idea, but I don't know if it's really simpler or better than using unique names. I have nothing against exporting many symbols if the names are unique... gruel From chl at math.uni-bonn.de Mon Feb 24 21:51:46 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Mon Feb 24 21:51:50 2003 Subject: [XviD-devel] CFLAGS for automake/configure Message-ID: Hi, sorry for asking stupid ./configure related questions: How can I add additional CFLAGS options at configure stage (without editing plattform.inc afterwards)? If I define CFLAGS to something noempty, default flags are not set (which is okay for heavy testing), but I just wanted to add "-march=athlon-xp" because CPU type is not autodetected. gruel From chl at math.uni-bonn.de Mon Feb 24 23:00:30 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Mon Feb 24 23:00:36 2003 Subject: [XviD-devel] "restrict" keyword Message-ID: Hi, does MSVC++ know about "restrict"? That's a new qualifier for pointer types in C99 which tells the compiler that the data referenced by two pointers do not overlap. This can be interesting for optimization, because you know e.g. that write to an address does not change the value of where the other pointer points to, so you don't have to read that value again. It's also important for memcpy() stuff. void fcpy(float *restrict a, float *restrict b, float *restrict aa, float *restrict bb, int n) { int i; for(i = 0; i < n; i++) { aa[i]=a[i]; bb[i]=b[i]; } } means these copy loops can be done "in parallel", because e.g. aa != b gcc accepts it when --std=c99 is active. gruel From ed.gomez at free.fr Mon Feb 24 23:01:21 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Mon Feb 24 23:01:59 2003 Subject: [XviD-devel] xvid (cvs-head) problem (ffmpeg+mplayer) In-Reply-To: References: <20030224195306.GA819@leloo> Message-ID: <20030224220121.GB819@leloo> Christoph Lampert (chl@math.uni-bonn.de) wrote: > And where is the advantage of #defining cpby_tab > as xvid_tabls.cbpy_tab over simply calling the > table xvid_cbpy_tab and defining > #define cbpy_tab xvid_cbpy_tab > > if we really want to keep the code shorter? The defines are not meant to keep things shorter, they are meant to not modify existing code. And the benefit of my method is that you won't polute namespace at all, you only export xvid_tables and that's all you need to access all tables you would ever want to access. -- Edouard Gomez From ed.gomez at free.fr Mon Feb 24 23:09:14 2003 From: ed.gomez at free.fr (Edouard Gomez) Date: Mon Feb 24 23:09:43 2003 Subject: [XviD-devel] CFLAGS for automake/configure In-Reply-To: References: Message-ID: <20030224220914.GC819@leloo> Christoph Lampert (chl@math.uni-bonn.de) wrote: > sorry for asking stupid ./configure related questions: > How can I add additional CFLAGS options at configure stage > (without editing plattform.inc afterwards)? > If I define CFLAGS to something noempty, default flags are not > set (which is okay for heavy testing), but I just wanted to add > "-march=athlon-xp" because CPU type is not autodetected. Ok it's not trivial but i thought about that case ;-) even if it's not evident for everyone: Run the configure script once with defaults then: CFLAGS="`make list-cflags | grep "CFLAGS=" | sed 's/CFLAGS=//'` -march=athlon-xp" ./configure Let's explain it a bit: I've put a rule for Makefile debugging that lists lot of things: # make info Part of this info rule is: # make list-cflags So we retrieve this only part of the info, and pipe it to get only the CFLAGS definition, then we remove the "CFLAGS=", add -march=xxx to the defiunition and finally we redefine CFLAGS with that new string. Simple, isn't it ? -- Edouard Gomez-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030224/4bd19f46/attachment.bin From chl at math.uni-bonn.de Mon Feb 24 23:24:59 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Mon Feb 24 23:25:07 2003 Subject: [XviD-devel] CFLAGS for automake/configure In-Reply-To: <20030224220914.GC819@leloo> Message-ID: On Mon, 24 Feb 2003, Edouard Gomez wrote: > Christoph Lampert (chl@math.uni-bonn.de) wrote: > > sorry for asking stupid ./configure related questions: > > How can I add additional CFLAGS options at configure stage > > (without editing plattform.inc afterwards)? > > If I define CFLAGS to something noempty, default flags are not > > set (which is okay for heavy testing), but I just wanted to add > > "-march=athlon-xp" because CPU type is not autodetected. > > Ok it's not trivial but i thought about that case ;-) even if it's not > evident for everyone: > > Run the configure script once with defaults then: > > CFLAGS="`make list-cflags | grep "CFLAGS=" | sed 's/CFLAGS=//'` -march=athlon-xp" ./configure > > Let's explain it a bit: > > I've put a rule for Makefile debugging that lists lot of things: > # make info > > Part of this info rule is: > # make list-cflags > > So we retrieve this only part of the info, and pipe it to get only the > CFLAGS definition, then we remove the "CFLAGS=", add -march=xxx to the > defiunition and finally we redefine CFLAGS with that new string. > > Simple, isn't it ? Nah, it's not simple. But it's tricky, I like it ;-) gruel From james at dattrax.co.uk Tue Feb 25 07:00:39 2003 From: james at dattrax.co.uk (Jim Hauxwell) Date: Tue Feb 25 08:00:44 2003 Subject: [XviD-devel] "restrict" keyword In-Reply-To: Message-ID: Hi, MSVC doesnt, however Intel Compiler 7 does This being the case I still think it would be of benefit for Windows builds Jim > -----Original Message----- > From: xvid-devel-bounces@xvid.org [mailto:xvid-devel-bounces@xvid.org]On > Behalf Of Christoph Lampert > Sent: 24 February 2003 22:01 > To: xvid-devel@xvid.org > Subject: [XviD-devel] "restrict" keyword > > > > Hi, > > does MSVC++ know about "restrict"? > > That's a new qualifier for pointer types in C99 which > tells the compiler that the data referenced by two pointers > do not overlap. This can be interesting for optimization, > because you know e.g. that write to an address does not change > the value of where the other pointer points to, so you don't have to read > that value again. It's also important for memcpy() stuff. > > void > fcpy(float *restrict a, float *restrict b, > float *restrict aa, float *restrict bb, int n) > { > int i; > for(i = 0; i < n; i++) { > aa[i]=a[i]; > bb[i]=b[i]; > } > } > > means these copy loops can be done "in parallel", because e.g. aa != b > > gcc accepts it when --std=c99 is active. > > gruel > > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel From radoslaw at syskin.cjb.net Tue Feb 25 22:52:49 2003 From: radoslaw at syskin.cjb.net (Radek Czyz) Date: Tue Feb 25 13:22:00 2003 Subject: [XviD-devel] b-frames api question Message-ID: <19414253046.20030225225249@syskin.cjb.net> Hey, I think I'll try to re-design b-frames decision again. The idea came to me because of many b-frames reports at forums (doom9 and more) and because I myself encoded some (well, two) movies recently - I haven't done that before. Experience is good, I guess. However, nothing is obvious here - in particular, there are two groups of users - some people like bframes and are unable to see any artifacts related to it (such as infamous dark blocks). At the other hand, there are people who say that bframes look very bad and they are not using them at all. My current idea is that we could need a possibility to control the number of bframes not only in terms of maximum, but simply in terms of 'sensitivity'. This would affect the possibility that the _first_ bframe is inserted - something we can't do yet. Now, there are two options. 1. Add new integer value to the API. The bad side is that I don't feel like adding new integer to api, especially because b-frames are controled by 3 (!) integers already. The good thing is that it would be possible to set this integer to very high/very low value, disabling the dynamic decision at all. 2. Use current MAX setting to alter not only maximum, but also sensitivity. This wouldn't give huge control (I'm not saying that's bad). It wouldn't allow users to disable the dynamic decision. It wouldn't change the API. What do you think? I'm in favour of the second solution, but maybe the first has better future... From chl at math.uni-bonn.de Tue Feb 25 15:03:04 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Tue Feb 25 15:03:09 2003 Subject: [XviD-devel] b-frames api question In-Reply-To: <19414253046.20030225225249@syskin.cjb.net> Message-ID: On Tue, 25 Feb 2003, Radek Czyz wrote: > Hey, > > I think I'll try to re-design b-frames decision again. The idea came > to me because of many b-frames reports at forums (doom9 and more) and > because I myself encoded some (well, two) movies recently - I haven't > done that before. Experience is good, I guess. > > However, nothing is obvious here - in particular, there are two groups > of users - some people like bframes and are unable to see any > artifacts related to it (such as infamous dark blocks). At the other > hand, there are people who say that bframes look very bad and they > are not using them at all. > > My current idea is that we could need a possibility to control the > number of bframes not only in terms of maximum, but simply in terms of > 'sensitivity'. This would affect the possibility that the _first_ > bframe is inserted - something we can't do yet. > > Now, there are two options. > > 1. Add new integer value to the API. The bad side is that I don't feel > like adding new integer to api, especially because b-frames are > controled by 3 (!) integers already. The good thing is that it would > be possible to set this integer to very high/very low value, disabling > the dynamic decision at all. Since Pete just commited structure for the new API, _now_ would be the best time to restructure b-frames and add "sensitivity" or something else. IMHO the API can have as many parameters as possible. As long as they are not all accessible through the API, this doesn't hurt. > 2. Use current MAX setting to alter not only maximum, but also > sensitivity. This wouldn't give huge control (I'm not saying that's > bad). It wouldn't allow users to disable the dynamic decision. It > wouldn't change the API. Hm, that sounds like a foul compromise to me. Combining two parameters that have not really much to do with each other, just to save 1 int. I think it should be possible to a) use a certain fixed number of bframes without "dynamic setting" This would also be better for testing, because you could benchmark dynamic bframes vs. ordinary bframes. b) change sensitivity of dynamic bframes setting (if this feature really turn out to be useful) I don't see how both could be combined into one parameter. > What do you think? I'm in favour of the second solution, but maybe the > first has better future... I vote for the first. gruel From skal at planet-d.net Tue Feb 25 18:20:44 2003 From: skal at planet-d.net (skal) Date: Tue Feb 25 18:21:12 2003 Subject: [XviD-devel] Quality optimization In-Reply-To: <004c01c2c248$ba532440$bca45982@student.utwente.nl> References: <004c01c2c248$ba532440$bca45982@student.utwente.nl> Message-ID: <1046193644.1444.48.camel@latitude344> Hi, almost forgot this one too: On Wed, 2003-01-22 at 20:01, Marco Al wrote: > Christoph Lampert wrote: > > >> Do we have some timings for a 8 bit Hadamard transform yet? > > > > I did some a while ago of skal's MMXEXT(?) version and posted them to > > the list. I don't remember, but might have been twice the speed of DCT, > > but half the speed of SAD. > > The non attributed asm code only managed 173 cycles with 8 bits accourding to > the source, that is not twice as fast as DCT AFAIK. > here's a C/MMX/SSE version of the Hadamard transform (16bits). Without the 'pshufw' re-ordering, output columns are re-ordered according to: [03127465]. C-version spits the correct order... Note: Output is also scaled by 8. bye! Skal -------------- next part -------------- ; void xvid_Hadamard_SSE(int16_t Matrix[8*8]); cglobal xvid_Hadamard_SSE ;////////////////////////////////////////////////////////////////////// %macro BUTF2 4 ; a, b, c, d paddsw %2, %1 ; a+b paddsw %4, %3 ; c+d paddsw %1, %1 ; 2a paddsw %3, %3 ; 2c psubsw %1, %2 ; a-b psubsw %3, %4 ; c-d %endmacro ;////////////////////////////////////////////////////////////////////// %macro HADAMARD_HPASS 2 ; %1: offset %2:REORDERING movq mm0, [eax+%1] ; [0123] movq mm7, mm0 movq mm1, [eax+%1+8] ; [4567] paddsw mm0, mm1 ; [abcd] psubsw mm7, mm1 ; [efgh] movq mm1,mm0 punpcklwd mm0,mm7 ; [aebf] punpckhwd mm1,mm7 ; [cgdh] movq mm7,mm0 paddsw mm0,mm1 ; [ABCD] psubsw mm7,mm1 ; [EFGH] movq mm1,mm0 punpcklwd mm0,mm7 ; [ABEF] punpckhwd mm1,mm7 ; [CDGH] movq mm7,mm0 paddsw mm0,mm1 ; [0312] psubsw mm7,mm1 ; [7465] %if (%2!=0) ; SSE only pshufw mm0,mm0, 01111000b ; [0123] movq [eax+%1 ], mm0 pshufw mm7,mm7, 00101101b ; [4567] %else movq [eax+%1 ], mm0 %endif movq [eax+%1+8], mm7 %endmacro %macro HADAMARD_VPASS 1 ; src/dst ; 27c movq mm0, [%1+0*16] movq mm1, [%1+1*16] movq mm2, [%1+2*16] movq mm3, [%1+3*16] movq mm4, [%1+4*16] movq mm5, [%1+5*16] movq mm6, [%1+6*16] movq mm7, [%1+7*16] BUTF2 mm0, mm1, mm2, mm3 BUTF2 mm1, mm3, mm0, mm2 BUTF2 mm4, mm5, mm6, mm7 BUTF2 mm4, mm6, mm5, mm7 BUTF2 mm3, mm7, mm0, mm4 BUTF2 mm2, mm6, mm1, mm5 movq [%1+0*16], mm7 movq [%1+1*16], mm3 movq [%1+2*16], mm1 movq [%1+3*16], mm5 movq [%1+4*16], mm4 movq [%1+5*16], mm0 movq [%1+6*16], mm2 movq [%1+7*16], mm6 %endmacro ; 135c (131c without the pshufw reordering) xvid_Hadamard_SSE: mov eax,[esp+4] ; In HADAMARD_HPASS 0*16, 1 HADAMARD_HPASS 1*16, 1 HADAMARD_HPASS 2*16, 1 HADAMARD_HPASS 3*16, 1 HADAMARD_HPASS 4*16, 1 HADAMARD_HPASS 5*16, 1 HADAMARD_HPASS 6*16, 1 HADAMARD_HPASS 7*16, 1 HADAMARD_VPASS eax HADAMARD_VPASS eax+8 ret ;////////////////////////////////////////////////////////////////////// -------------- next part -------------- A non-text attachment was scrubbed... Name: hadamard.c Type: text/x-c Size: 2111 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030225/50d5caa9/hadamard.bin From chl at math.uni-bonn.de Tue Feb 25 18:50:45 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Tue Feb 25 18:50:48 2003 Subject: [XviD-devel] Quality optimization In-Reply-To: <1046193644.1444.48.camel@latitude344> Message-ID: Hi Skal, since you are still (or again) amongst us ;-) I saw in your xvid_bench.c code that it checks e.g. SAD speed on 16*16 arrays (so stride is 16) and only in perfect alignment. Isn't that untypical, because in "real life" stride should be something like 720, in any way much larger than cacheline, and also only "Reference" pointer would be aligned, not "Current"? Or doesn't this matter on x86? Also, even though your code is so fast, I didn't find any "prefetch" instructions in ASM or C whereas ffmpeg's SAD routines are full of them. Didn't you test them, or didn't they yield a speedup? gruel On 25 Feb 2003, skal wrote: > almost forgot this one too: > > On Wed, 2003-01-22 at 20:01, Marco Al wrote: > > Christoph Lampert wrote: > > > > >> Do we have some timings for a 8 bit Hadamard transform yet? > > > > > > I did some a while ago of skal's MMXEXT(?) version and posted them to > > > the list. I don't remember, but might have been twice the speed of DCT, > > > but half the speed of SAD. > > > > The non attributed asm code only managed 173 cycles with 8 bits accourding to > > the source, that is not twice as fast as DCT AFAIK. > > > here's a C/MMX/SSE version of the Hadamard transform (16bits). > Without the 'pshufw' re-ordering, output columns are re-ordered > according to: [03127465]. C-version spits the correct order... > Note: Output is also scaled by 8. > > > bye! > > Skal > From chl at math.uni-bonn.de Tue Feb 25 19:19:28 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Tue Feb 25 19:19:31 2003 Subject: [XviD-devel] Forward: [Ffmpeg-devel] Sparse IDCT (fwd) Message-ID: Hi, wouldn't this be possible for XVID, too? Two or three separate dequant/iDCT routines depending on where the last non-zero coefficient is? Since data is available at decoding anyway, I can see no drawback. gruel ---------- Forwarded message ---------- Date: Tue, 25 Feb 2003 11:08:39 -0700 (MST) From: Mike Melanson Reply-To: ffmpeg-devel@lists.sourceforge.net To: ffmpeg-devel@lists.sourceforge.net Subject: [Ffmpeg-devel] Sparse IDCT Hi, A curious feature in the VP3 codec is that the decoder maintains statistics about where the last non-zero DCT coefficient lives in a particular DCT block. It then uses this information to call 1 of 3 different IDCT functions. One function is the basic 8x8 IDCT. The other 2 handle sparse matrices of coefficients. One handles a matrix where the non-zero coefficients are concentrated in the upper left corner (IDct10()). The other handles a matrix where only the DC coeff. is non-zero (IDct1()). The latter transform is particularly simple since it copies the dequantized/scaled DC coeff. to every other position in the block. My question is: Would it be worthwhile to support these sparse IDCT functions in ffmpeg's DSP context? I know that for IDct1(), an AltiVec-capable PPC could use a vector splat instruction followed by a series of vector store ops. Would these transforms be useful for other codecs? I wondered how frequently the functions are called. On the keyframe where I am doing most of my testing and validation, I found that the full 64-element IDCT was never called even once; only the 1- and 10-element transforms were called. Thanks... -- -Mike Melanson ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Ffmpeg-devel mailing list Ffmpeg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ffmpeg-devel From skal at planet-d.net Wed Feb 26 12:14:46 2003 From: skal at planet-d.net (skal) Date: Wed Feb 26 12:15:33 2003 Subject: [XviD-devel] Quality optimization In-Reply-To: <1046193644.1444.48.camel@latitude344> References: <004c01c2c248$ba532440$bca45982@student.utwente.nl> <1046193644.1444.48.camel@latitude344> Message-ID: <1046258086.2234.14.camel@latitude344> Hi, I forward an answer to a question I received, since it can be of general interest: On Tue, 2003-02-25 at 18:20, skal wrote: > here's a C/MMX/SSE version of the Hadamard transform (16bits). Q: > Would there be any improvement between SSE and SSE2? Well, most probably. The obvious improvement is for the vertical pass: instead of dealing with 4 + 4 columns subsequently, they could all be done in one pass, replacing: HADAMARD_VPASS eax HADAMARD_VPASS eax+8 by a single HADAMARD_VPASS eax where all the 'mm?' registers are replaced by 'xmm?' in this macro (and taking care of alignments). This being said, such heavily SIMD'd functions rapidly hit the memory bandwith bottleneck. Actually, in the Hadamard transform I posted, only HALF of the time (tick-wise) is spent doing the arithmetic computations. The rest is spent loading/storing data. For the F/Idct, data I/O is also a great part of the stuff, considering how cheap are the mults. Note also that for this in-place funcs, prefetching is almost useless (haven't tested it, though). > Without the 'pshufw' re-ordering, output columns are re-ordered > according to: [03127465]. C-version spits the correct order... > Note: Output is also scaled by 8. oops! Output is scaled by 64, not 8!. bye, Skal From skal at planet-d.net Wed Feb 26 15:56:57 2003 From: skal at planet-d.net (skal) Date: Wed Feb 26 15:57:44 2003 Subject: [XviD-devel] Quality optimization In-Reply-To: References: Message-ID: <1046271417.2234.55.camel@latitude344> Hi On Tue, 2003-02-25 at 18:50, Christoph Lampert wrote: > since you are still (or again) amongst us ;-) bwehe > I saw in your xvid_bench.c code that it checks e.g. SAD speed on > 16*16 arrays (so stride is 16) and only in perfect alignment. Isn't that > untypical, because in "real life" stride should be something like 720, > in any way much larger than cacheline, well, actually, xvid_bench.c is meant to: a) perform some unit tests and non-regression (CRC) b) provide a *lower* bound about how fast a func could run, given perfect condition. In real life, most xvid_bench.c's funcs will run slower, for sure, and a test-suite of sequence will prove it :) > and also only "Reference" pointer > would be aligned, not "Current"? Or doesn't this matter on x86? Well, you of course get a (few ticks) penalty in case of misalignment during memory access. It starts to matter with SSE2, where special instructions are provided for known aligned (or un-aligned) read/write. Sure, a good assumption is that 'current' is aligned (to 16 for SSE2. no chroma here!) whereas 'ref' isn't. Here's for instance a 16x8 simple ref->cur SSE2 copy: movdqu xmm0, [eax] movdqu xmm1, [eax+edx] movdqu xmm2, [eax+2*edx] movdqu xmm3, [eax+ebx] lea eax, [eax+4*edx] movdqu xmm4, [eax] movdqu xmm5, [eax+edx] movdqu xmm6, [eax+2*edx] movdqu xmm7, [eax+ebx] movdqa [ecx], xmm0 movdqa [ecx+edx], xmm1 movdqa [ecx+2*edx],xmm2 movdqa [ecx+ebx], xmm3 lea ecx, [ecx+4*edx] movdqa [ecx], xmm4 movdqa [ecx+edx], xmm5 movdqa [ecx+2*edx],xmm6 movdqa [ecx+ebx], xmm7 > > Also, even though your code is so fast, I didn't find any > "prefetch" instructions in ASM or C whereas ffmpeg's SAD routines are full > of them. Didn't you test them, or didn't they yield a speedup? I've played a little with, without any definitive conclusion to provide. I thought Pentium4's hardware prefetch would be the cure, but it appears that this platform is sometimes slower (with my code, not xvid) than a PIII. Since I'm most of the time limited by memory bandwith, now, it might be time to really use the prefetch. As a rule of the thumb, I'd say, taking motion-compensation as instance, that 'ref' should be prefetched, and 'cur' should be non-temporal-moved (except for b-frames). From my small experience, prefetch can eventually be very powerful (cf. all the various memcpy() flavors), but it's also very very easy to use it very very badly, especially for data whose lifespan is not clear enough. So... bye, Skal From skal at planet-d.net Wed Feb 26 16:16:40 2003 From: skal at planet-d.net (skal) Date: Wed Feb 26 16:17:21 2003 Subject: [XviD-devel] Forward: [Ffmpeg-devel] Sparse IDCT (fwd) In-Reply-To: References: Message-ID: <1046272600.2234.76.camel@latitude344> Hi, On Tue, 2003-02-25 at 19:19, Christoph Lampert wrote: > Hi, > > wouldn't this be possible for XVID, too? Two or three separate > dequant/iDCT routines depending on where the last non-zero coefficient > is? Since data is available at decoding anyway, I can see no drawback. > I've tried several similar approaches (for decoder): a) During Inter-AC decoding, keep track of occupied rows and pass the info to the Idct. b) Inside the Idct, test that a row is non-zero before going for the corresponding vertical pass. Surprisingly, method b) performs better than a). Note however that method a) can be advantageous for the dequantization too. And in both cases, the gain is really worth it (~10%-15% for decoding highly quantized stuff). Note that method a) is harder to implement for Intra blocks, because of (vertical) AC-prediction. Mismatch ctrl of Inter block is also painful. Another (lighter) gain is grouping the copy / add of Idct's result toward 'cur' image within the vertical pass. It saves memory read/write... If you're interested, you can have a look at the file 'src/dsp_src/skl_dct_sse.asm' in my codec sources ( http://skal.planet-d.net/coding/mpeg4codec.html ) I didn't submitted this Idct here (although it seems the fastest around ) because it's deliberately not IEEE-1173 compliant. This might hurt some sensibilities :) bye! Skal > gruel > > > ---------- Forwarded message ---------- > Date: Tue, 25 Feb 2003 11:08:39 -0700 (MST) > From: Mike Melanson > Reply-To: ffmpeg-devel@lists.sourceforge.net > To: ffmpeg-devel@lists.sourceforge.net > Subject: [Ffmpeg-devel] Sparse IDCT > > Hi, > A curious feature in the VP3 codec is that the decoder maintains > statistics about where the last non-zero DCT coefficient lives in a > particular DCT block. It then uses this information to call 1 of 3 > different IDCT functions. One function is the basic 8x8 IDCT. The other 2 > handle sparse matrices of coefficients. One handles a matrix where the > non-zero coefficients are concentrated in the upper left corner > (IDct10()). The other handles a matrix where only the DC coeff. is > non-zero (IDct1()). The latter transform is particularly simple since > it copies the dequantized/scaled DC coeff. to every other position in the > block. > > My question is: Would it be worthwhile to support these sparse > IDCT functions in ffmpeg's DSP context? I know that for IDct1(), an > AltiVec-capable PPC could use a vector splat instruction followed by a > series of vector store ops. Would these transforms be useful for other > codecs? > > I wondered how frequently the functions are called. On the > keyframe where I am doing most of my testing and validation, I found that > the full 64-element IDCT was never called even once; only the 1- and > 10-element transforms were called. > > Thanks... > -- > -Mike Melanson > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Ffmpeg-devel mailing list > Ffmpeg-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ffmpeg-devel > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel > From chl at math.uni-bonn.de Wed Feb 26 19:24:19 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Wed Feb 26 19:24:28 2003 Subject: [XviD-devel] Quality optimization In-Reply-To: <1046193644.1444.48.camel@latitude344> Message-ID: On 25 Feb 2003, skal wrote: > > Hi, > > almost forgot this one too: > > On Wed, 2003-01-22 at 20:01, Marco Al wrote: > > Christoph Lampert wrote: > > > > >> Do we have some timings for a 8 bit Hadamard transform yet? > > > > > > I did some a while ago of skal's MMXEXT(?) version and posted them to > > > the list. I don't remember, but might have been twice the speed of DCT, > > > but half the speed of SAD. > > > > The non attributed asm code only managed 173 cycles with 8 bits accourding to > > the source, that is not twice as fast as DCT AFAIK. > > > here's a C/MMX/SSE version of the Hadamard transform (16bits). > Without the 'pshufw' re-ordering, output columns are re-ordered > according to: [03127465]. C-version spits the correct order... Do you really say this routines calculate Hadamard? Boy, you _are_ good, they are hyperfast! DCT on Athlon XP is: PLAINC - 1.110 usec MMX - 0.258 usec MMXEXT - 0.258 usec SSE2 - 0.272 usec 3DNOW - 1.121 usec 3DNOWE - 1.118 usec IDCT is PLAINC - 1.395 usec (<- slower than fDCT?) MMX - 0.219 usec MMXEXT - 0.199 usec SSE2 - 0.219 usec 3DNOW - 1.247 usec 3DNOWE - 0.184 usec whereas Hadamard is PLAINC - 0.549 usec MMXEXT - 0.089 usec 0.089 is about the time of sad16() with MMXEXT needs, too, so a search routine based on hadamard+sad should not slow things down too much. Btw. what we would need in the end is a SATD function (SAD of transformed), so either, we would have to do SAD ( Hadamard(Cur) , Hadamard(Ref) ) (*) with usual sad-routine or sum(abs( ( Hadamard( Cur - Ref ) )) (**) In theory these should be identical (Hadamard is linear), but maybe they are not... Anyway, would it be faster to combine these steps into a larger routine, or rather not? Again, I would believe it would, because for (**) the result of Hadamard doesn't have to be saved, only summed up, but of course I'm no expert... gruel From elcabesa at inwind.it Wed Feb 26 23:18:59 2003 From: elcabesa at inwind.it (elcabesa) Date: Wed Feb 26 23:23:07 2003 Subject: [XviD-devel] help with new configure Message-ID: <200302262318.59663.elcabesa@inwind.it> hi i found some problem trying to use xvid and mplayer and all things goes in the best way until new bootstrap code, symply until there was make -f Makefile.linix i can make it work=) now, mplayer symply doesn't found xvid library. .has something changed? do you know if something has changed in mplayer?? reading this forum i read that you told that MPLay statiallcy link xvid lib in his exec? is this a new way or it's the way it has always worked , ocuse sometimes ago i used to simply recompile xvid library and mplayer used new library even not compiling mplayer thank you From suxen_drol at hotmail.com Thu Feb 27 21:31:50 2003 From: suxen_drol at hotmail.com (suxen_drol) Date: Thu Feb 27 11:31:52 2003 Subject: [XviD-devel] b-frames api question In-Reply-To: References: <19414253046.20030225225249@syskin.cjb.net> Message-ID: <20030227212553.126B.SUXEN_DROL@hotmail.com> On Tue, 25 Feb 2003 15:03:04 +0100 (CET) Christoph Lampert wrote: > > What do you think? I'm in favour of the second solution, but maybe the > > first has better future... > > I vote for the first. agree: too many options is better than too few.. as long as theyre sensible. because we force the applications to memset(,0,) strucutres before usage, when sensitity is zero, a default (~50%) sensitity should be used. ALSO regarding regarding the api: does any think we make more use of float/double fields? ie. bquant ratio and offset could be floats. -- pete; life is like a box of ammo From chl at math.uni-bonn.de Thu Feb 27 12:08:11 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Thu Feb 27 12:08:16 2003 Subject: [XviD-devel] b-frames api question In-Reply-To: <20030227212553.126B.SUXEN_DROL@hotmail.com> Message-ID: On Thu, 27 Feb 2003, suxen_drol wrote: > > On Tue, 25 Feb 2003 15:03:04 +0100 (CET) Christoph Lampert wrote: > > > > What do you think? I'm in favour of the second solution, but maybe the > > > first has better future... > > > > I vote for the first. > > agree: too many options is better than too few.. as long as theyre > sensible. > > because we force the applications to memset(,0,) strucutres before usage, > when sensitity is zero, a default (~50%) sensitity should be used. > > ALSO regarding regarding the api: does any think we make more use of > float/double fields? ie. bquant ratio and offset could be floats. No, let's stick to int with 100th or 128th or 256th resolution (it's not for users eyes anyway). I can't think of anything that really needs float, and who knows, maybe we can save a few conversions then. Bzw. 0 should mean a default value for quant_ratio... we should check for this. I think, floats should only be used in special routines, so one knows when emms() or similar has to be called an when not. GMC is such a routine, but bframe quantization I'd rather think not. gruel From skal at planet-d.net Thu Feb 27 16:30:45 2003 From: skal at planet-d.net (skal) Date: Thu Feb 27 16:31:51 2003 Subject: [XviD-devel] Quality optimization In-Reply-To: References: Message-ID: <1046359845.1443.26.camel@latitude344> Hi, On Wed, 2003-02-26 at 19:24, Christoph Lampert wrote: > IDCT is > > PLAINC - 1.395 usec (<- slower than fDCT?) most of the time, yes, because iDCT needs final [-256,255] clipping... > MMX - 0.219 usec > MMXEXT - 0.199 usec > SSE2 - 0.219 usec > 3DNOW - 1.247 usec > 3DNOWE - 0.184 usec > > whereas Hadamard is > > PLAINC - 0.549 usec > MMXEXT - 0.089 usec > > 0.089 is about the time of sad16() with MMXEXT needs, too, > so a search routine based on hadamard+sad should not slow things down too > much. That's not that easy :) In fact, having the Hadamard transform done doesn't mean you're off with the hard work. Taking the abs values with MMX is painful. For SSE, we have the mighty 'psadbw' instr., but it works on 8bits data, whereas the output of Hadamard is 11bits (yes, it's scaled by 8, not 64!:). So? Should we descale 11->8bits? Another idea would be to multiply the Hadamard output by a pseudo-quant matrix that mimics the real quantizers (and the missing cosines, maybe)... Dunno. Anyway, here's an Hadamard_SAD for 8x8 or 16x16 byte input, in replacement for SAD. I'm not quite satisfied with it mainly because of the above (and not just because it's 8 times slower than pure SAD :) bye! Skal I > > > > > Btw. what we would need in the end is a SATD function (SAD of > transformed), so either, we would have to do > > SAD ( Hadamard(Cur) , Hadamard(Ref) ) (*) > > with usual sad-routine or > > sum(abs( ( Hadamard( Cur - Ref ) )) (**) > > In theory these should be identical (Hadamard is linear), but maybe they > are not... > > Anyway, would it be faster to combine these steps into a larger routine, > or rather not? Again, I would believe it would, because for (**) the > result of Hadamard doesn't have to be saved, only summed up, but of course > I'm no expert... -------------- next part -------------- ; int Skl_Hadamard_SAD_8x8_MMX(const uint8_t *Src1, const uint8_t *Src2, int BpS) ; int Skl_Hadamard_SAD_16x16_MMX(const uint8_t *Src1, const uint8_t *Src2, int BpS) cglobal xvid_Hadamard_SAD_8x8_MMX cglobal xvid_Hadamard_SAD_16x16_MMX ;////////////////////////////////////////////////////////////////////// section .data One: times 8 dw 1 ; for summing 4 words section .text ;////////////////////////////////////////////////////////////////////// ;// Hadamard SAD %macro BUTF2 4 ; a, b, c, d paddw %2, %1 ; a+b paddw %4, %3 ; c+d paddw %1, %1 ; 2a paddw %3, %3 ; 2c psubw %1, %2 ; a-b psubw %3, %4 ; c-d %endmacro %macro ADD_ABS 2 ; %1/%2:in reg pxor mm7, mm7 pcmpgtw mm7, %1 pxor mm5, mm5 psubw mm6, mm7 pcmpgtw mm5, %2 psubw mm6, mm5 pxor mm7, %1 pxor mm5, %2 paddw mm6, mm7 paddw mm6, mm5 %endmacro ;////////////////////////////////////////////////////////////////////// %macro HADAMARD_SAD_HPASS 3 ; %1:dst offset1 %2:dst offset2 %3:src offset [eax=cur,ecx=ref] ; first, upload 8b->16b the diff Src1[i]-Src2[i] movd mm0, [eax+%3] ; [0123] punpcklbw mm0, mm6 movd mm2, [ecx+%3] ; [0123] punpcklbw mm2, mm6 movd mm1, [eax+%3+4] ; [4567] movd mm3, [ecx+%3+4] ; [4567] punpcklbw mm1, mm6 punpcklbw mm3, mm6 psubw mm0, mm2 psubw mm1, mm3 ; now, go with the transform movq mm7, mm0 paddw mm0, mm1 ; [abcd] psubw mm7, mm1 ; [efgh] movq mm1,mm0 punpcklwd mm0,mm7 ; [aebf] punpckhwd mm1,mm7 ; [cgdh] movq mm7,mm0 paddw mm0,mm1 ; [ABCD] psubw mm7,mm1 ; [EFGH] movq mm1,mm0 punpcklwd mm0,mm7 ; [ABEF] punpckhwd mm1,mm7 ; [CDGH] movq mm7,mm0 paddw mm0,mm1 ; [0312] psubw mm7,mm1 ; [7465] movq [esp+%1], mm0 movq [esp+%2], mm7 %endmacro %macro HADAMARD_SAD_VPASS 2 ; %1:src/dst, %2:SAD movq mm0, [%1+0*16] movq mm1, [%1+1*16] movq mm2, [%1+2*16] movq mm3, [%1+3*16] movq mm4, [%1+4*16] movq mm5, [%1+5*16] movq mm6, [%1+6*16] movq mm7, [%1+7*16] BUTF2 mm0, mm1, mm2, mm3 BUTF2 mm1, mm3, mm0, mm2 BUTF2 mm4, mm5, mm6, mm7 BUTF2 mm4, mm6, mm5, mm7 BUTF2 mm3, mm7, mm0, mm4 BUTF2 mm2, mm6, mm1, mm5 ; time to sum up the abs val of mm0..mm7 ; -> make room for 3 regs movq [esp+0*16], mm7 ; Spill movq [esp+1*16], mm6 ; ... movq [esp+2*16], mm5 ; ... movq mm6, %2 ADD_ABS mm0,mm1 ADD_ABS mm2,mm3 movq mm0, [esp+0*16] movq mm1, [esp+1*16] movq mm2, [esp+2*16] ADD_ABS mm0, mm1 ADD_ABS mm2, mm4 %endmacro ;////////////////////////////////////////////////////////////////////// %define LOCAL_TMP_SIZE 16*16 %define SAD esp+LOCAL_TMP_SIZE align 16 xvid_Hadamard_SAD_8x8_MMX: ; 226c mov eax,[esp+ 4] ; Src1 mov ecx,[esp+ 8] ; Src2 mov edx,[esp+12] ; BpS push ebp mov ebp, esp lea esp, [esp-LOCAL_TMP_SIZE-16] and esp, ~0xf ; align to 16b pxor mm6, mm6 movq [SAD], mm6 HADAMARD_SAD_HPASS 0*16, 8*16, 0 HADAMARD_SAD_HPASS 1*16, 9*16, edx lea eax, [eax+2*edx] lea ecx, [ecx+2*edx] HADAMARD_SAD_HPASS 2*16, 10*16, 0 HADAMARD_SAD_HPASS 3*16, 11*16, edx lea eax, [eax+2*edx] lea ecx, [ecx+2*edx] HADAMARD_SAD_HPASS 4*16, 12*16, 0 HADAMARD_SAD_HPASS 5*16, 13*16, edx lea eax, [eax+2*edx] lea ecx, [ecx+2*edx] HADAMARD_SAD_HPASS 6*16, 14*16, 0 HADAMARD_SAD_HPASS 7*16, 15*16, edx HADAMARD_SAD_VPASS esp, [SAD] movq [SAD], mm6 ; save intermediate SAD HADAMARD_SAD_VPASS esp+8*16, [SAD] ; mm6 = [SAD]. Now, collapse it. pmaddwd mm6, [One] movq mm7, mm6 psrlq mm6, 32 mov esp, ebp paddd mm6, mm7 pop ebp movd eax, mm6 ret %undef LOCAL_TMP_SIZE %undef SAD ;////////////////////////////////////////////////////////////////////// %define LOCAL_TMP_SIZE 64*16 %define SAD esp+LOCAL_TMP_SIZE %define SAD2 SAD+8 align 16 xvid_Hadamard_SAD_16x16_MMX: ; 831c mov eax,[esp+ 4] ; Src1 mov ecx,[esp+ 8] ; Src2 mov edx,[esp+12] ; BpS push ebp mov ebp, esp lea esp, [esp-LOCAL_TMP_SIZE-16] and esp, ~0xf ; align to 16b pxor mm6, mm6 movq [SAD], mm6 HADAMARD_SAD_HPASS 0*16, 8*16, 0 HADAMARD_SAD_HPASS 16*16, 24*16, 8 HADAMARD_SAD_HPASS 1*16, 9*16, edx HADAMARD_SAD_HPASS 17*16, 25*16, edx+8 lea eax, [eax+2*edx] lea ecx, [ecx+2*edx] HADAMARD_SAD_HPASS 2*16, 10*16, 0 HADAMARD_SAD_HPASS 18*16, 26*16, 8 HADAMARD_SAD_HPASS 3*16, 11*16, edx HADAMARD_SAD_HPASS 19*16, 27*16, edx+8 lea eax, [eax+2*edx] lea ecx, [ecx+2*edx] HADAMARD_SAD_HPASS 4*16, 12*16, 0 HADAMARD_SAD_HPASS 20*16, 28*16, 8 HADAMARD_SAD_HPASS 5*16, 13*16, edx HADAMARD_SAD_HPASS 21*16, 29*16, edx+8 lea eax, [eax+2*edx] lea ecx, [ecx+2*edx] HADAMARD_SAD_HPASS 6*16, 14*16, 0 HADAMARD_SAD_HPASS 22*16, 30*16, 8 HADAMARD_SAD_HPASS 7*16, 15*16, edx HADAMARD_SAD_HPASS 23*16, 31*16, edx+8 lea eax, [eax+2*edx] lea ecx, [ecx+2*edx] HADAMARD_SAD_HPASS 32*16, 40*16, 0 HADAMARD_SAD_HPASS 48*16, 56*16, 8 HADAMARD_SAD_HPASS 33*16, 41*16, edx HADAMARD_SAD_HPASS 49*16, 57*16, edx+8 lea eax, [eax+2*edx] lea ecx, [ecx+2*edx] HADAMARD_SAD_HPASS 34*16, 42*16, 0 HADAMARD_SAD_HPASS 50*16, 58*16, 8 HADAMARD_SAD_HPASS 35*16, 43*16, edx HADAMARD_SAD_HPASS 51*16, 59*16, edx+8 lea eax, [eax+2*edx] lea ecx, [ecx+2*edx] HADAMARD_SAD_HPASS 36*16, 44*16, 0 HADAMARD_SAD_HPASS 52*16, 60*16, 8 HADAMARD_SAD_HPASS 37*16, 45*16, edx HADAMARD_SAD_HPASS 53*16, 61*16, edx+8 lea eax, [eax+2*edx] lea ecx, [ecx+2*edx] HADAMARD_SAD_HPASS 38*16, 46*16, 0 HADAMARD_SAD_HPASS 54*16, 62*16, 8 HADAMARD_SAD_HPASS 39*16, 47*16, edx HADAMARD_SAD_HPASS 55*16, 63*16, edx+8 HADAMARD_SAD_VPASS esp+ 0*16, [SAD] movq [SAD], mm6 ; save intermediate SAD HADAMARD_SAD_VPASS esp+ 8*16, [SAD] movq [SAD], mm6 HADAMARD_SAD_VPASS esp+16*16, [SAD] movq [SAD], mm6 HADAMARD_SAD_VPASS esp+24*16, [SAD] ; we need to split SAD accums in two, because of ; overflow... Store partially collapsed current SAD pmaddwd mm6, [One] pxor mm7, mm7 movq [SAD], mm6 movq [SAD2], mm7 HADAMARD_SAD_VPASS esp+32*16, [SAD2] movq [SAD2], mm6 HADAMARD_SAD_VPASS esp+40*16, [SAD2] movq [SAD2], mm6 HADAMARD_SAD_VPASS esp+48*16, [SAD2] movq [SAD2], mm6 HADAMARD_SAD_VPASS esp+56*16, [SAD2] ; mm6 = [SAD2]. Now, collapse it (with [SAD]). pmaddwd mm6, [One] paddd mm6, [SAD] movq mm7, mm6 psrlq mm6, 32 mov esp, ebp paddd mm7, mm6 pop ebp movd eax, mm7 ret %undef LOCAL_TMP_SIZE %undef SAD ;////////////////////////////////////////////////////////////////////// -------------- next part -------------- A non-text attachment was scrubbed... Name: skl_hadamard.c Type: text/x-c Size: 5309 bytes Desc: not available Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030227/1477908d/skl_hadamard.bin From chl at math.uni-bonn.de Thu Feb 27 16:58:29 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Thu Feb 27 16:58:32 2003 Subject: [XviD-devel] Quality optimization In-Reply-To: <1046359845.1443.26.camel@latitude344> Message-ID: On 27 Feb 2003, skal wrote: > In fact, having the Hadamard transform done doesn't mean > you're off with the hard work. Taking the abs values with > MMX is painful. For SSE, we have the mighty 'psadbw' instr., > but it works on 8bits data, whereas the output of Hadamard > is 11bits (yes, it's scaled by 8, not 64!:). So? Should we > descale 11->8bits? Sure... results are gonna be quantized anyway... or would it be possible to do Hadamard in saturated 8 bit (7 bit+sign?), acting on the residue? Because if value overflows, then we most likely won't use the block anyway. > Another idea would be to multiply the > Hadamard output by a pseudo-quant matrix that mimics the real > quantizers (and the missing cosines, maybe)... Dunno. > Anyway, here's an Hadamard_SAD for 8x8 or 16x16 byte input, > in replacement for SAD. I'm not quite satisfied with it > mainly because of the above (and not just because it's > 8 times slower than pure SAD :) Thanks! I'll check this weekend (no time before) gruel From trbarry at trbarry.com Thu Feb 27 12:02:10 2003 From: trbarry at trbarry.com (trbarry@trbarry.com) Date: Thu Feb 27 18:02:24 2003 Subject: [XviD-devel] Quality optimization In-Reply-To: <1046359845.1443.26.camel@latitude344> Message-ID: <000801c2de81$f7690e80$0400a8c0@com.robot> This post reminded me of a section I'd seen in the Intel Optimization reference for the abs diff of signed numbers. I've copied it here: ------ quote ----------- The technique used here is to first sort the corresponding elements of the input operands into packed words of the maximum values, and packed words of the minimum values. Then the minimum values are subtracted from the maximum values to generate the required absolute difference. The key is a fast sorting technique that uses the fact that B = xor(A, xor(A,B)) and A = xor(A,0). Thus in a packed data type, having some elements being xor(A,B) and some being 0, you could xor such an operand with A and receive in some places values of A and in some values of B. The following examples assume a packed-word data type, each element being a signed value. Example 4-17 Absolute Difference of Signed Numbers ;Input: ; MM0 signed source operand ; MM1 signed source operand ;Output: ; MM0 absolute difference of the unsigned operands movq MM2, MM0 ; make a copy of source1 (A) pcmpgtw MM0, MM1 ; create mask of ; source1>source2 (A>B) movq MM4, MM2 ; make another copy of A pxor MM2, MM1 ; create the intermediate value of ; the swap operation - xor(A,B) pand MM2, MM0 ; create a mask of 0s and xor(A,B) ; elements. Where A>B there will ; be a value xor(A,B) and where ; A<=B there will be 0. pxor MM4, MM2 ; minima-xor(A, swap mask) pxor MM1, MM2 ; maxima-xor(B, swap mask) psubw MM1, MM4 ; absolute difference = ; maxima-minima ---------- /quote --------------------------- Although thinking about it, for machines that support these instructions it seems you could just use: movq mm2, mm0 ; make a copy of source pminsw mm0, mm1 ; signed word min pmaxsw mm1, mm2 ; signed word max psubw mm1, mm0 ; big - small - Tom | -----Original Message----- | From: xvid-devel-bounces@xvid.org | [mailto:xvid-devel-bounces@xvid.org]On | Behalf Of skal | Sent: Thursday, February 27, 2003 10:31 AM | To: xvid-devel@xvid.org | Subject: Re: [XviD-devel] Quality optimization | | | | Hi, | | On Wed, 2003-02-26 at 19:24, Christoph Lampert wrote: | | > IDCT is | > | > PLAINC - 1.395 usec (<- slower than fDCT?) | | most of the time, yes, because iDCT needs final | [-256,255] clipping... | | > MMX - 0.219 usec | > MMXEXT - 0.199 usec | > SSE2 - 0.219 usec | > 3DNOW - 1.247 usec | > 3DNOWE - 0.184 usec | > | > whereas Hadamard is | > | > PLAINC - 0.549 usec | > MMXEXT - 0.089 usec | > | > 0.089 is about the time of sad16() with MMXEXT needs, too, | > so a search routine based on hadamard+sad should not slow | things down too | > much. | | That's not that easy :) | In fact, having the Hadamard transform done doesn't mean | you're off with the hard work. Taking the abs values with | MMX is painful. For SSE, we have the mighty 'psadbw' instr., | but it works on 8bits data, whereas the output of Hadamard | is 11bits (yes, it's scaled by 8, not 64!:). So? Should we | descale 11->8bits? Another idea would be to multiply the | Hadamard output by a pseudo-quant matrix that mimics the real | quantizers (and the missing cosines, maybe)... Dunno. | Anyway, here's an Hadamard_SAD for 8x8 or 16x16 byte input, | in replacement for SAD. I'm not quite satisfied with it | mainly because of the above (and not just because it's | 8 times slower than pure SAD :) | | bye! | | Skal | | I | > | > | > | > | > Btw. what we would need in the end is a SATD function (SAD of | > transformed), so either, we would have to do | > | > SAD ( Hadamard(Cur) , Hadamard(Ref) ) (*) | > | > with usual sad-routine or | > | > sum(abs( ( Hadamard( Cur - Ref ) )) (**) | > | > In theory these should be identical (Hadamard is linear), | but maybe they | > are not... | > | > Anyway, would it be faster to combine these steps into a | larger routine, | > or rather not? Again, I would believe it would, because for (**) the | > result of Hadamard doesn't have to be saved, only summed | up, but of course | > I'm no expert... | | From skal at planet-d.net Thu Feb 27 18:32:17 2003 From: skal at planet-d.net (skal) Date: Thu Feb 27 18:33:23 2003 Subject: [XviD-devel] Quality optimization In-Reply-To: <000801c2de81$f7690e80$0400a8c0@com.robot> References: <000801c2de81$f7690e80$0400a8c0@com.robot> Message-ID: <1046367137.1443.45.camel@latitude344> Hi Tom, On Thu, 2003-02-27 at 18:02, trbarry@trbarry.com wrote: > Although thinking about it, for machines that support these instructions > it seems you > could just use: > > movq mm2, mm0 ; make a copy of source > pminsw mm0, mm1 ; signed word min > pmaxsw mm1, mm2 ; signed word max > psubw mm1, mm0 ; big - small > the problem with this method is that it uses 1 register for copy; even with the special case mm1==0 i'm interested in. Moreover, 'mm0' can't be a memory address here. Hence, instead, I've used: pxor mm7, mm7 pcmpgtw mm7, %1 pxor mm5, mm5 pcmpgtw mm5, %2 psubw mm6, mm7 pxor mm7, %1 psubw mm6, mm5 paddw mm6, mm7 pxor mm5, %2 paddw mm6, mm5 to perform two abs value in //. It uses 2 regs, 1 accum (mm6) and sources [%1] and [%2] can be in memory... bye Skal From elcabesa at inwind.it Fri Feb 28 12:35:43 2003 From: elcabesa at inwind.it (elcabesa) Date: Fri Feb 28 12:39:57 2003 Subject: [XviD-devel] huffman question Message-ID: <200302281235.43605.elcabesa@inwind.it> hi i saw in code that is possilbe to change in bitstream quantization matrix, is possible to change huffman talbes or there are a set of ISO matrix? From michael at xvid.org Fri Feb 28 14:24:07 2003 From: michael at xvid.org (Michael Militzer) Date: Fri Feb 28 14:25:19 2003 Subject: [XviD-devel] huffman question References: <200302281235.43605.elcabesa@inwind.it> Message-ID: <006101c2df2c$bc6eac80$1702a8c0@michipc> Hi, ----- Original Message ----- From: "elcabesa" To: Sent: Friday, February 28, 2003 12:35 PM Subject: [XviD-devel] huffman question > hi > > i saw in code that is possilbe to change in bitstream quantization matrix, is > possible to change huffman talbes or there are a set of ISO matrix? you can't switch between different huffman tables unfortunately. However literature suggests it would have been a good idea: http://www.nt.e-technik.uni-erlangen.de/~hartung/publications/762.ps.gz bye, Michael From chl at math.uni-bonn.de Fri Feb 28 15:32:05 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Fri Feb 28 15:32:08 2003 Subject: [XviD-devel] a bug, I think In-Reply-To: <8844943281.20030301001512@syskin.cjb.net> Message-ID: On Sat, 1 Mar 2003, Radek Czyz wrote: > I found a bug. If adaptive quantization is active and b-frames are > used, bframes have strange quantizers. For example two frames have an > average quantizer of 4..5 while a bframe between them has quant 13, > and that's with ratio 150% and offset 100... > > I guess that lumimasking changes the quantizer for a frame to match > quantizer of first macroblock. That would be logical, BUT if b-frames > use this quantizer to compute their own, it's a bug. > > Is it the case? I'll check that myslf tommorow, but if anyone can > give me a good answer or tip how to fix it, I'll be grateful. I remember that bug from an earlier post. Hasn't it been fixed a while ago? gruel From piccarre at elet.polimi.it Fri Feb 28 17:59:30 2003 From: piccarre at elet.polimi.it (Luca Piccarreta) Date: Fri Feb 28 17:59:37 2003 Subject: [XviD-devel] Quality optimization References: <000801c2de81$f7690e80$0400a8c0@com.robot> Message-ID: <002b01c2df4a$c295b400$4b7baf83@piccarreta> Is it not faster to make them positive (by adding something) and then using psubusb or psubusw (does the latter exist?) //mm0,mm1 contains 4 packed shorts paddw mm0,something paddw mm1,something movq mm2,mm0 psubusw mm0,mm1 psubusw mm1,mm2 paddw mm0,mm1 <-- abs diff or (similar to yours...) movq mm2,mm0 pcmpgtw mm2,mm1 pxor mm0,mm2 maximum or (65535-minimum) pxor mm1,mm2 mininum or (65535-maximum) psubw mm1,mm0 <-- abs diff (maximum-minimum) or ((65535-minimum)-(65535-maximum)-->maximum-minimum) Just ----- Original Message ----- From: To: Sent: Thursday, February 27, 2003 6:02 PM Subject: RE: [XviD-devel] Quality optimization > This post reminded me of a section I'd seen in the Intel Optimization > reference for the abs diff of signed numbers. I've copied it here: > > ------ quote ----------- > The technique used here is to first sort the corresponding elements of > the input > operands into packed words of the maximum values, and packed words of > the > minimum values. Then the minimum values are subtracted from the maximum > values > to generate the required absolute difference. The key is a fast sorting > technique that > uses the fact that B = xor(A, xor(A,B)) and A = xor(A,0). Thus in a > packed data > type, having some elements being xor(A,B) and some being 0, you could > xor such an > operand with A and receive in some places values of A and in some values > of B. The > following examples assume a packed-word data type, each element being a > signed > value. > > Example 4-17 Absolute Difference of Signed Numbers > > ;Input: > ; MM0 signed source operand > ; MM1 signed source operand > ;Output: > ; MM0 absolute difference of the unsigned operands > movq MM2, MM0 ; make a copy of source1 (A) > pcmpgtw MM0, MM1 ; create mask of > ; source1>source2 (A>B) > movq MM4, MM2 ; make another copy of A > pxor MM2, MM1 ; create the intermediate value of > ; the swap operation - xor(A,B) > pand MM2, MM0 ; create a mask of 0s and xor(A,B) > ; elements. Where A>B there will > ; be a value xor(A,B) and where > ; A<=B there will be 0. > pxor MM4, MM2 ; minima-xor(A, swap mask) > pxor MM1, MM2 ; maxima-xor(B, swap mask) > psubw MM1, MM4 ; absolute difference = > ; maxima-minima > ---------- /quote --------------------------- > > Although thinking about it, for machines that support these instructions > it seems you > could just use: > > movq mm2, mm0 ; make a copy of source > pminsw mm0, mm1 ; signed word min > pmaxsw mm1, mm2 ; signed word max > psubw mm1, mm0 ; big - small > > - Tom > > > > > > > | -----Original Message----- > | From: xvid-devel-bounces@xvid.org > | [mailto:xvid-devel-bounces@xvid.org]On > | Behalf Of skal > | Sent: Thursday, February 27, 2003 10:31 AM > | To: xvid-devel@xvid.org > | Subject: Re: [XviD-devel] Quality optimization > | > | > | > | Hi, > | > | On Wed, 2003-02-26 at 19:24, Christoph Lampert wrote: > | > | > IDCT is > | > > | > PLAINC - 1.395 usec (<- slower than fDCT?) > | > | most of the time, yes, because iDCT needs final > | [-256,255] clipping... > | > | > MMX - 0.219 usec > | > MMXEXT - 0.199 usec > | > SSE2 - 0.219 usec > | > 3DNOW - 1.247 usec > | > 3DNOWE - 0.184 usec > | > > | > whereas Hadamard is > | > > | > PLAINC - 0.549 usec > | > MMXEXT - 0.089 usec > | > > | > 0.089 is about the time of sad16() with MMXEXT needs, too, > | > so a search routine based on hadamard+sad should not slow > | things down too > | > much. > | > | That's not that easy :) > | In fact, having the Hadamard transform done doesn't mean > | you're off with the hard work. Taking the abs values with > | MMX is painful. For SSE, we have the mighty 'psadbw' instr., > | but it works on 8bits data, whereas the output of Hadamard > | is 11bits (yes, it's scaled by 8, not 64!:). So? Should we > | descale 11->8bits? Another idea would be to multiply the > | Hadamard output by a pseudo-quant matrix that mimics the real > | quantizers (and the missing cosines, maybe)... Dunno. > | Anyway, here's an Hadamard_SAD for 8x8 or 16x16 byte input, > | in replacement for SAD. I'm not quite satisfied with it > | mainly because of the above (and not just because it's > | 8 times slower than pure SAD :) > | > | bye! > | > | Skal > | > | I > | > > | > > | > > | > > | > Btw. what we would need in the end is a SATD function (SAD of > | > transformed), so either, we would have to do > | > > | > SAD ( Hadamard(Cur) , Hadamard(Ref) ) (*) > | > > | > with usual sad-routine or > | > > | > sum(abs( ( Hadamard( Cur - Ref ) )) (**) > | > > | > In theory these should be identical (Hadamard is linear), > | but maybe they > | > are not... > | > > | > Anyway, would it be faster to combine these steps into a > | larger routine, > | > or rather not? Again, I would believe it would, because for (**) the > | > result of Hadamard doesn't have to be saved, only summed > | up, but of course > | > I'm no expert... > | > | > > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel From chl at math.uni-bonn.de Fri Feb 28 19:23:06 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Fri Feb 28 19:23:12 2003 Subject: [XviD-devel] Dicas / mpegable Encoder/Player Message-ID: Hi, did any of you ever test encoder and/or player from mpegable (www.mpegable.com) ? It claims to encode and decoder Simple and Advanced Simple Profile including quarterpel and it's free, downloadable without registration. They also have a non-free encoder calls "X4 live" (30 day trial) which supports MPEG-4 Simple Profile, Advanced Simple Profile all levels (I-VOP, P-VOP, B-VOP, AC/DC Prediction, 4-Motion Vector, Unrestricted Motion Vector, Quantization Method 1, Method 2) including "Arbitrary number of B-frames" which sound almost as interesting as XVID itself. Did anyone ever test it? gruel From chl at math.uni-bonn.de Fri Feb 28 19:27:42 2003 From: chl at math.uni-bonn.de (Christoph Lampert) Date: Fri Feb 28 19:27:43 2003 Subject: [XviD-devel] IRT encoded sequences Message-ID: Hi, I just found another interesting site: http://radio.irt.de/vida (Vida = Video Internet Demonstration Aid) They have a big number of encoded VQEG test sequences of many different encoders, including DivX3.11, several MPEG-4s, WMV8, Sorenson, Fraunhofer H263, etc. at many different bitrates (from 56k for Modem to Highspeed >1MBit). DivX5 is there, too, but XVID isn't... maybe we should contact them, send our source so they can include us? gruel From BRmultiaccess at ctf.com.br Fri Feb 28 16:35:26 2003 From: BRmultiaccess at ctf.com.br (BRmultiaccess@ctf.com.br) Date: Fri Feb 28 21:35:30 2003 Subject: [XviD-devel] =?iso-8859-1?q?=28BRMA=29_Mensagem_n=E3o_autorizada?= Message-ID: <200302281935.h1SJZQf12746@ctf.com.br> Mensagem não autorizada ---------------------------------------- Virus Encontrado no email de Saida /var/spool/mqueue/dfh1SJZCT12710/forum2[1].bat infected: I-Worm.Klez.h ---------------------------------------- Para: dknop@gwdg.de Assunto: The Garden of Eden