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: