From xvid-devel-bounces@xvid.org Tue Mar 1 00:28:19 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 2963A126D85 for ; Tue, 1 Mar 2005 00:28:19 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id AE5C3183B2; Tue, 1 Mar 2005 00:28:15 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from web52501.mail.yahoo.com (web52501.mail.yahoo.com [206.190.39.122]) by edu.bnhof.de (Postfix) with SMTP id 8EC86183AF for ; Tue, 1 Mar 2005 00:28:12 +0100 (CET) Received: (qmail 93347 invoked by uid 60001); 28 Feb 2005 23:28:11 -0000 Message-ID: <20050228232811.93345.qmail@web52501.mail.yahoo.com> Received: from [200.42.34.5] by web52501.mail.yahoo.com via HTTP; Mon, 28 Feb 2005 20:28:11 ART Date: Mon, 28 Feb 2005 20:28:11 -0300 (ART) From: Dark Sylinc Subject: Re: [XviD-devel] Where can I download the latest static xvidcore lib for VC++? To: xvid-devel@xvid.org In-Reply-To: <000b01c51d3b$019e1360$93140a0a@xiebo> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Status: O X-Status: X-Keywords: X-UID: 2685 >Where can I download the latest static > xvidcore lib for VC++? Latest release from www.xvid.org (v 1.1.0beta1) has a static project as well as a dynamic library one, just open the one you need. Or use old versions (below 1.0.x) Dark_Sylinc ___________________________________________________________ 250MB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Mar 1 14:23:14 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (unknown [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id C7BA8126DA1 for ; Tue, 1 Mar 2005 14:23:14 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 954A214636; Tue, 1 Mar 2005 14:22:50 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from web51902.mail.yahoo.com (web51902.mail.yahoo.com [206.190.39.45]) by edu.bnhof.de (Postfix) with SMTP id A8CCA141D7 for ; Tue, 1 Mar 2005 14:22:45 +0100 (CET) Received: (qmail 72706 invoked by uid 60001); 1 Mar 2005 13:22:40 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=zrXbLNa1vX8aeEO+0ZaoxFRoBlx2wlPvEh+z+myrirl+SfHbRyuSuBqCjRA7MQH1DSq73OFfIx315VbphI3W0/goN8rhCv5im3sxL86JPfCR8jIIY6vIs9BCuGQUjTKuQyWuSZnWFh5NmcskphQwN+OYBEwkhinhneXqAVvEc7A= ; Message-ID: <20050301132240.72704.qmail@web51902.mail.yahoo.com> Received: from [203.200.200.162] by web51902.mail.yahoo.com via HTTP; Tue, 01 Mar 2005 05:22:40 PST Date: Tue, 1 Mar 2005 05:22:40 -0800 (PST) From: viswanath veera Subject: Re: [XviD-devel] Regarding interlaced streams To: xvid-devel@xvid.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.4 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Status: O X-Status: X-Keywords: X-UID: 2717 Hi Christopher ..... I downloaded Xvid 1.1.0 version latest Source code .... In that, iam working on Xvid Decoder part. Iam having some encoded mpeg4 testing streams with me. All are working fine ..except interlaced streams (for example: foreman_inl.bits). For this stream the output is getting distorted. Iam really thankful to you if you can suggest something for this .. anyway thanks for your reply.... Thanks Viswanath Veera Christoph Lampert wrote: On Sun, 27 Feb 2005, viswanath veera wrote: > I downloaded Xvid 1.1.0 version and tried with different streams. It is working nice. > > But for interlaced streams , the output is getting distorted. > > Can you please suggest me ,where the problem might be.... I badly need that .. Hi, the problem with interlaced material is that it is interlaced. Normal encoding often doesn't work there. You can switch on "interlacing" mode in XviD, then it should work. gruel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel Hi --------------------------------- Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Mar 1 20:20:29 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id F2C33126D85 for ; Tue, 1 Mar 2005 20:20:28 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id D2F86A82A; Tue, 1 Mar 2005 20:20:18 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (mail.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id D01409C84 for ; Tue, 1 Mar 2005 20:20:15 +0100 (CET) Received: from login.math.uni-bonn.de (login.math.uni-bonn.de [131.220.120.13]) by nil.math.uni-bonn.de (Postfix) with ESMTP id 3994359BB3 for ; Tue, 1 Mar 2005 20:20:46 +0100 (CET) Date: Tue, 1 Mar 2005 20:20:14 +0100 (CET) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Regarding interlaced streams In-Reply-To: <20050301132240.72704.qmail@web51902.mail.yahoo.com> Message-ID: References: <20050301132240.72704.qmail@web51902.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Status: O X-Status: X-Keywords: X-UID: 2730 On Tue, 1 Mar 2005, viswanath veera wrote: > In that, iam working on Xvid Decoder part. Iam having some encoded > mpeg4 testing streams with me. All are working fine ..except interlaced > streams (for example: foreman_inl.bits). For this stream the output is > getting distorted. Oh, it was decoding... sorry then. It the foreman_inl.bits or others available publically? I don't remember XviD having any trouble with interlaced, but if that really is the case, it would be important to find out. Btw. have you tried with an earlier version of XviD? 1.1 seems less tested than expected. gruel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Mar 2 21:28:16 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 71646126D84 for ; Wed, 2 Mar 2005 21:28:16 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 96ACA14734; Wed, 2 Mar 2005 21:28:06 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from s5.lansco.de (s5.lansco.de [212.63.130.170]) by edu.bnhof.de (Postfix) with ESMTP id EAC731470B for ; Wed, 2 Mar 2005 21:28:03 +0100 (CET) Received: from localhost (s5.lansco.de [212.63.130.170]) by s5.lansco.de (Postfix) with ESMTP id 67262B267 for ; Wed, 2 Mar 2005 21:28:03 +0100 (CET) Received: from pD9E37F7C.dip.t-dialin.net (pD9E37F7C.dip.t-dialin.net [217.227.127.124]) by www.lansco.de (IMP) with HTTP for ; Wed, 2 Mar 2005 21:28:03 +0100 Message-ID: <1109795283.422621d33ca9e@www.lansco.de> Date: Wed, 2 Mar 2005 21:28:03 +0100 From: Michael Militzer To: xvid-devel@xvid.org Subject: Re: [XviD-devel] XviD-1.1-Beta 1 bugs summary References: <200502272022.j1RKM5sS032757@mailserver2.hushmail.com> <1109596710.42231a26f400c@www.lansco.de> In-Reply-To: <1109596710.42231a26f400c@www.lansco.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 217.227.127.124 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Status: O X-Status: X-Keywords: X-UID: 2824 Hi, I've applied a very trivial fix for cartoon mode. Seems the semantics of a helper function cartoon mode was using have changed without updating cartoon mode accordingly. Because of this, cartoon mode was too aggressively forcing not-coded MBs. Since I have no test input material to reproduce the fault, please check again with the latest cvs version if the problems with cartoon mode are fixed now. bye, Michael Quoting Michael Militzer : > Hi, > > thanks for the links. One thing's for sure: cartoon mode is not intended > to be used for coding natural images. This will produce artifacts and I > wouldn't consider this a bug. Regarding the artifacts in cartoon-like > images, > it looks as if MBs are skipped that actually shouldn't have been skipped > (because they're moving). It seems this effect is amplified by either > adaptive quantization or b-frames (or both). > > Cartoon mode is rather aggressively forcing skip mode because cartoons have > a lot of stationary motion. Wrong skip decisions cause artifacts. I'll try > to think of something, which eliminates these wrong decisions without > harming the compression efficiency... > > bye, > Michael > > > Quoting nvidiadx@hushmail.com: > > > > > > > On Wed, 23 Feb 2005 23:49:30 -0800 Dirk Knop > goettingen.de> wrote: > > >Aloha! > > > > > >Michael Militzer wrote: > > > > > >>Hi, > > >> > > >>Quoting Dirk Knop : > > >> > > >> > > >> > > >>>- GMC has a bug. With very much motion, some blocks get totally > > >>>displaced. The issue is the same no matter if decoded with > > >libavcodec or > > >>>xvid. > > >>> > > >>> > > >> > > >>Do you have a sample demonstrating this effect? Either the coded > > >(wrong) > > >>bitstream or a source file + settings to reproduce the problem? > > >> > > >> > > > > > >Someone reporting this bug at doom9 posted an archive here: > > >http://s2.yousendit.com/d.aspx?id=1IRU00JPFMEFR26USGL9OUJOF1 > > > > > >Don't know if it's still online, but it contains the source, the > > >avs > > >script and some broken encodes ;) > > > > > >>>- Some issue with cartoon mode and bvhq (well, cruncher may > > >report it > > >>>better :) ): some white blocks sometimes floating around within > > >high motion. > > >>> > > >>> > > >> > > >>Is this really _only_ happening with bvhq? Iirc, the cartoon mode > > >doesn't add > > >>any special optimizations for b-frames - in fact, it wasn't even > > >meant for > > >>using it with b-frames (at least I didn't test it much). Do you > > >have a sample > > >>clip for this problem? I suspect that probably some MBs are > > >skipped in > > >>b-frames, which shouldn't have been skipped - but you know, > > >cartoon mode > > >>rather aggressively forces the use of skip mode... > > >> > > >> > > >This is a cruncher-report, he says he can always reproduce it. > > >Will ask > > >him to report more on it. > > > > > >Regards > > >Koepi > > > > Yes my initial thought was b-vop is couseing this behaviour in use > > with cartoon mode but that assumption was wrong it is cartoon mode > > + adaptive quantization thats couseing it, other reports and > > samples showing that problem can be found @ the following places > > > > http://forum.doom9.org/showthread.php?s=&threadid=90596 > > http://forum.doom9.org/showthread.php?s=&threadid=88367 > > http://cruncher.mufflastig.com/XviD/cartoonbug/ > > > > SCNR > > CruNcher > > > > > > > > > > > > Concerned about your privacy? Follow this link to get > > secure FREE email: http://www.hushmail.com/?l=2 > > > > Free, ultra-private instant messaging with Hush Messenger > > http://www.hushmail.com/services-messenger?l=434 > > > > Promote security and make money with the Hushmail Affiliate Program: > > http://www.hushmail.com/about-affiliate?l=427 > > > > _______________________________________________ > > XviD-devel mailing list > > XviD-devel@xvid.org > > http://list.xvid.org/mailman/listinfo/xvid-devel > > > > > > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel > _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Mar 3 02:07:22 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 9B26F126D84 for ; Thu, 3 Mar 2005 02:07:22 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id C84DA1426A; Thu, 3 Mar 2005 02:07:18 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by edu.bnhof.de (Postfix) with ESMTP id 0FA90141C8 for ; Thu, 3 Mar 2005 02:07:16 +0100 (CET) Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 97779A32A2 for ; Wed, 2 Mar 2005 17:07:14 -0800 (PST) Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Wed, 2 Mar 2005 17:07:14 -0800 (PST) Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.11/8.12.9/Submit) id j2317D3n005936 for xvid-devel@xvid.org; Wed, 2 Mar 2005 17:07:13 -0800 (PST) (envelope-from nvidiadx@hushmail.com) Message-Id: <200503030107.j2317D3n005936@mailserver3.hushmail.com> Date: Wed, 2 Mar 2005 17:07:11 -0800 To: xvid-devel@xvid.org Cc: Subject: Re: [XviD-devel] XviD-1.1-Beta 1 bugs summary From: X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Status: O X-Status: X-Keywords: X-UID: 2833 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 02 Mar 2005 12:28:03 -0800 Michael Militzer wrote: >Hi, > >I've applied a very trivial fix for cartoon mode. Seems the >semantics of a >helper function cartoon mode was using have changed without >updating cartoon >mode accordingly. Because of this, cartoon mode was too >aggressively forcing >not-coded MBs. > >Since I have no test input material to reproduce the fault, please >check >again with the latest cvs version if the problems with cartoon >mode are >fixed now. > >bye, >Michael The fix is crashing XviD now in the 1pass when cartoon mode is active for that Real footage Sample, for me. -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.4 wkYEARECAAYFAkImYy8ACgkQLlB05LlrB+rgwgCfVDKmyxKhdEGYK53bnwq7XrURf+MA oJmR1A7VERksVgeBLEWiCB1dDLL/ =Cf+x -----END PGP SIGNATURE----- Concerned about your privacy? Follow this link to get secure FREE email: http://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger http://www.hushmail.com/services-messenger?l=434 Promote security and make money with the Hushmail Affiliate Program: http://www.hushmail.com/about-affiliate?l=427 _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Mar 3 18:05:15 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id B1E7D126D85 for ; Thu, 3 Mar 2005 18:05:15 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 31D9314270; Thu, 3 Mar 2005 18:05:09 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from s5.lansco.de (s5.lansco.de [212.63.130.170]) by edu.bnhof.de (Postfix) with ESMTP id A92DF141CE for ; Thu, 3 Mar 2005 18:05:06 +0100 (CET) Received: from localhost (s5.lansco.de [212.63.130.170]) by s5.lansco.de (Postfix) with ESMTP id B7BA2A3D2 for ; Thu, 3 Mar 2005 18:05:05 +0100 (CET) Received: from pD953954C.dip.t-dialin.net (pD953954C.dip.t-dialin.net [217.83.149.76]) by www.lansco.de (IMP) with HTTP for ; Thu, 3 Mar 2005 18:05:05 +0100 Message-ID: <1109869505.422743c191793@www.lansco.de> Date: Thu, 3 Mar 2005 18:05:05 +0100 From: Michael Militzer To: xvid-devel@xvid.org Subject: Re: [XviD-devel] XviD-1.1-Beta 1 bugs summary References: <200503030107.j2317D3n005936@mailserver3.hushmail.com> In-Reply-To: <200503030107.j2317D3n005936@mailserver3.hushmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 217.83.149.76 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Status: O X-Status: X-Keywords: X-UID: 2878 Hi, hm strange, it's not crashing for me. But nonetheless, there was a mistake in my initial patch. I've comitted a fix for that already yesterday night - but I don't expect it'll help with regard to the crashes. But you may want to try anyway... Michael Quoting nvidiadx@hushmail.com: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On Wed, 02 Mar 2005 12:28:03 -0800 Michael Militzer > wrote: > >Hi, > > > >I've applied a very trivial fix for cartoon mode. Seems the > >semantics of a > >helper function cartoon mode was using have changed without > >updating cartoon > >mode accordingly. Because of this, cartoon mode was too > >aggressively forcing > >not-coded MBs. > > > >Since I have no test input material to reproduce the fault, please > >check > >again with the latest cvs version if the problems with cartoon > >mode are > >fixed now. > > > >bye, > >Michael > > The fix is crashing XviD now in the 1pass when cartoon mode is > active for that Real footage Sample, for me. > -----BEGIN PGP SIGNATURE----- > Note: This signature can be verified at https://www.hushtools.com/verify > Version: Hush 2.4 > > wkYEARECAAYFAkImYy8ACgkQLlB05LlrB+rgwgCfVDKmyxKhdEGYK53bnwq7XrURf+MA > oJmR1A7VERksVgeBLEWiCB1dDLL/ > =Cf+x > -----END PGP SIGNATURE----- > > > > > Concerned about your privacy? Follow this link to get > secure FREE email: http://www.hushmail.com/?l=2 > > Free, ultra-private instant messaging with Hush Messenger > http://www.hushmail.com/services-messenger?l=434 > > Promote security and make money with the Hushmail Affiliate Program: > http://www.hushmail.com/about-affiliate?l=427 > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel > _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Sun Mar 6 07:09:14 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 3F9E6126D83 for ; Sun, 6 Mar 2005 07:09:14 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 0F83015008; Sun, 6 Mar 2005 07:09:04 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from hotmail.com (bay20-f35.bay20.hotmail.com [64.4.54.124]) by edu.bnhof.de (Postfix) with ESMTP id BA30F15005 for ; Sun, 6 Mar 2005 07:09:00 +0100 (CET) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 5 Mar 2005 22:08:58 -0800 Message-ID: Received: from 210.50.248.62 by by20fd.bay20.hotmail.msn.com with HTTP; Sun, 06 Mar 2005 06:08:58 GMT X-Originating-IP: [210.50.248.62] X-Originating-Email: [a_dunstan@hotmail.com] X-Sender: a_dunstan@hotmail.com From: "Andrew Dunstan" To: xvid-devel@xvid.org Date: Sun, 06 Mar 2005 17:08:58 +1100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 06 Mar 2005 06:08:58.0728 (UTC) FILETIME=[FC484E80:01C52212] Subject: [XviD-devel] Dmitry's SSE2 idct X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Status: O X-Status: X-Keywords: X-UID: 2999 Is there any reason Dmitry's SSE2 idct isn't used? I know Skal's isn't used because it doesn't match the other idcts but from what I can tell Dmitry's produces identical output to idct_xmm. _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Mar 8 16:45:39 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 6EFA7126D83 for ; Tue, 8 Mar 2005 16:45:39 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id EB82A14926; Tue, 8 Mar 2005 16:45:25 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from s5.lansco.de (s5.lansco.de [212.63.130.170]) by edu.bnhof.de (Postfix) with ESMTP id 6C73F148D7 for ; Tue, 8 Mar 2005 16:45:20 +0100 (CET) Received: from localhost (s5.lansco.de [212.63.130.170]) by s5.lansco.de (Postfix) with ESMTP id AA124235FF for ; Tue, 8 Mar 2005 16:45:19 +0100 (CET) Received: from pD9539057.dip.t-dialin.net (pD9539057.dip.t-dialin.net [217.83.144.87]) by www.lansco.de (IMP) with HTTP for ; Tue, 8 Mar 2005 16:45:19 +0100 Message-ID: <1110296719.422dc88f564e3@www.lansco.de> Date: Tue, 8 Mar 2005 16:45:19 +0100 From: Michael Militzer To: xvid-devel@xvid.org Subject: Re: [XviD-devel] XviD-1.1-Beta 1 bugs summary References: <4219DB69.7030305@stud.uni-goettingen.de> In-Reply-To: <4219DB69.7030305@stud.uni-goettingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 217.83.144.87 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi, ok, so let's update on this: - the GMC bug has been fixed by SysKin. - the cartoon mode issues seem fixed as well - at least I received positive feedback on doom9. - interpolation cannot easily be used for chroma upsampling in our current colorspace conversion framework. The code relies on the fact that just a fixed (and even) number of vertical lines are processed/converted per iteration. This scheme wouldn't work anymore for interpolated chroma up- sampling. We could interpolate just every second line, then three out of four lines would be optimal - but I don't know if that really helps... bye, Michael Quoting Dirk Knop : > Hi all, > > for fixing some bugs and make the progress to 1.1-beta2 a little faster, > I'll sum up what I read as reports over at doom9's forum until now: > > - GMC has a bug. With very much motion, some blocks get totally > displaced. The issue is the same no matter if decoded with libavcodec or > xvid. > - Interlaced decoding got broken. Decoding interlaced streams encoded > with 1.1-beta1 with libavcodec(also with xvid-1.0.3) doesn't show this > problem, so it must be XviD's 1.1-beta1 decoder. > - Some issue with cartoon mode and bvhq (well, cruncher may report it > better :) ): some white blocks sometimes floating around within high motion. > - Vfw calculator: file sizes >2GB cause a variable overflow somewhere > resulting in wrong results. > - Not a real bug: in colour space conversion we seem to use nearest > neighbour-upsampling when upsampling chroma. This should be, as xvid is > seen as high quality codec out there in the world, interpolated. Maybe > make it switchable for speed reasons. (The mmx code makes me dizzy %) ) > > I think those are the major problems with beta1 so far. > > Maybe we should report into this "thread" if we make any progress, so > people can see that XviD is still alive and kickin'? :-) > > Best regards > Koepi > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel > _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Mar 9 10:50:06 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 1607D126D83 for ; Wed, 9 Mar 2005 10:50:06 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 20A3514FD1; Wed, 9 Mar 2005 10:49:53 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from library.ntu-kpi.kiev.ua (library.ntu-kpi.kiev.ua [195.245.194.78]) by edu.bnhof.de (Postfix) with ESMTP id D9BFD14FCC for ; Wed, 9 Mar 2005 10:49:49 +0100 (CET) Received: from antonz (helo=localhost) by library.ntu-kpi.kiev.ua with local-esmtp (Exim 4.50 (FreeBSD)) id 1D8xoc-0006lb-O5 for xvid-devel@xvid.org; Wed, 09 Mar 2005 11:49:43 +0200 Date: Wed, 9 Mar 2005 11:49:18 +0200 (EET) From: "Anton N. Breusov" To: xvid-devel@xvid.org Message-ID: <20050309114804.Q24366@library.ntu-kpi.kiev.ua> MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="0-467643078-1109766014=:81658" Content-ID: <20050309114804.K24366@library.ntu-kpi.kiev.ua> X-Spam-Score: -0.2 (/) Subject: [XviD-devel] XVid DirectShow decoder filter patch suggestion. X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-467643078-1109766014=:81658 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed Content-ID: <20050309114804.B24366@library.ntu-kpi.kiev.ua> Good day, XVid team! I'm using XVid DirectShow decoder in our application (RTS game with some "Cinematic interface" in main menu via DShow and VMR-9), and found some problems with it, which want to describe here (sorry for my English). Problem description: XVid Direct Show filter causes crashing of application using it in some cases. After some investigation I found that it is very picky in it's CTransformFilter::CheckInputType () function. If anything other than MEDIATYPE_Video supplied on input Pin, than CXvidDecoder object unloads XVid decoder DLL library and never loads it again even if after this was supplied supported stream (because it loaded only once, in constructor) but leaves pointer to xvid_decore_func intact, and later tries to call this function (pointing to freed by FreeLibrary() mem) and this causes crashes. Though in default graphs such behavior works fine (MEDIATYPE_Video type suggested first) in many players and other applications that builds own graph from scratch (or semi-manually) such behaviour is incorrect because it's OK when some types other than supported suggested on Input Pin, Intelligent Connect depends on this, and filter must not go into unusable state after this. How to reproduce: Open GraphEdit (from DirectX SDK utils), manually insert two filters: "XVid MPEG-4 video decoder" and "File source (Async.)", give some compatible DivX/XVid AVI video file to File Source filter. Then try to directly connect this filters (yes, AVI splitter will be inserted between them), after this try to at least render XVid filter output pin to insert Video Renderer (or manually place standard "Video renderer" or "Video Mixing Renderer 9"). And then try to play file -- video window appears and then program crashes in functions CXvidDecoder::Transform() at call of xvid_decore_func() .This happens because when we trying to link source filter with XVid decoder, then DShow Intelligent Connect mechanism tries direct linking first and this link is rejected by XVid decoder (here library will be freed and pointers become invalid) and only after this it finds and loads AVI splitter and tries connecting via it. Problem persist in XVid v1.1.0 Beta 1 and also was clearly reported some time ago here: http://www.xvid.org/modules.php?op=modload&name=phpBB2&file=viewtopic&t=2329 I'm attaching to this message patch against 1.1.0B1 (created by SVN). Hope it helps and will be intergrated into future releases. Patch details: I'm created private function OpenLib() in CXvidDecoder class, now it's complementary to OpenLib(). In this function I moved most of constructor's code (only LoadRegistryInfo() was left here), added unconditional call of it to constructor, and conditional call into CheckInputType (). Also added code for resetting pointer to functions and DLL handle to NULL (in constructor and in CloseLib()) and added a few helpful or just paranoid ;-) checks here and there. After testing seems that it works fine -- we now can probe any connections to XVid filter without crashes -- so it's fully reusable. I'm wandering if we really need to Close library and reopen it again, I think this needed only in case of input pin reconnection, but I'm not really familliar yet with XVid source code, so decided to do this in more slow, but "clear" way. -- Anton N. Breusov 'Antonz', AB21-UANIC. --0-467643078-1109766014=:81658 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=xvid-dshow.patch Content-Transfer-Encoding: BASE64 Content-ID: <20050302142013.C81658@library.ntu-kpi.kiev.ua> Content-Description: Content-Disposition: ATTACHMENT; FILENAME=xvid-dshow.patch SW5kZXg6IGRzaG93L3NyYy9DWHZpZERlY29kZXIuY3BwDQ0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0NCi0tLSBkc2hvdy9zcmMvQ1h2aWREZWNvZGVyLmNw cAkocmV2aXNpb24gNDQ0KQ0NCisrKyBkc2hvdy9zcmMvQ1h2aWREZWNvZGVy LmNwcAkod29ya2luZyBjb3B5KQ0NCkBAIC0yMDMsMTEgKzIwMywyNyBAQA0N CiANCiAjZGVmaW5lIFhWSURfRExMX05BTUUgInh2aWRjb3JlLmRsbCINCiAN Ci1DWHZpZERlY29kZXI6OkNYdmlkRGVjb2RlcihMUFVOS05PV04gcHVuaywg SFJFU1VMVCAqcGhyKSA6DQotICAgIENWaWRlb1RyYW5zZm9ybUZpbHRlcihO QU1FKCJDWHZpZERlY29kZXIiKSwgcHVuaywgQ0xTSURfWFZJRCkNCitDWHZp ZERlY29kZXI6OkNYdmlkRGVjb2RlcihMUFVOS05PV04gcHVuaywgSFJFU1VM VCAqcGhyKQ0KKzogQ1ZpZGVvVHJhbnNmb3JtRmlsdGVyKE5BTUUoIkNYdmlk RGVjb2RlciIpLCBwdW5rLCBDTFNJRF9YVklEKQ0KKywgbV9oZGxsIChOVUxM KQ0KIHsNCiAJRFBSSU5URigiQ29uc3RydWN0b3IiKTsNCiANCisJeHZpZF9k ZWNvcmVfZnVuYyA9IE5VTEw7IC8vIEhtbSwgc29tZSBzdHJhbmdlIGVycm9y cyBhcHBlYXJpbmcgaWYgSSB0cnkgdG8gaW5pdGlhbGl6ZS4uLg0KKwl4dmlk X2dsb2JhbF9mdW5jID0gTlVMTDsgLy8gLi4udGhpcyBpbiBjb25zdHJ1Y3Rv cidzIGluaXQtbGlzdC4gU28sIHRoZXkgYXNzaWduZWQgaGVyZS4NCisNCisJ TG9hZFJlZ2lzdHJ5SW5mbygpOw0KKw0KKwkqcGhyID0gT3BlbkxpYigpOw0K K30NCisNCitIUkVTVUxUIENYdmlkRGVjb2Rlcjo6T3BlbkxpYigpDQorew0N CisJRFBSSU5URigiT3BlbkxpYiIpOw0KKw0NCisJaWYgKG1faGRsbCAhPSBO VUxMKQ0KKwkJcmV0dXJuIEVfVU5FWFBFQ1RFRDsgLy8gU2VlbXMsIHRoYXQg bGlicmFyeSBhbHJlYWR5IG9wZW5lZC4NCisNDQogCXh2aWRfZ2JsX2luaXRf dCBpbml0Ow0KIAltZW1zZXQoJmluaXQsIDAsIHNpemVvZihpbml0KSk7DQog CWluaXQudmVyc2lvbiA9IFhWSURfVkVSU0lPTjsNCkBAIC0yMTYsMjUgKzIz MiwzNCBAQA0NCiAJaWYgKG1faGRsbCA9PSBOVUxMKSB7DQogCQlEUFJJTlRG KCJkbGwgbG9hZCBmYWlsZWQiKTsNCiAJCU1lc3NhZ2VCb3goMCwgWFZJRF9E TExfTkFNRSAiIG5vdCBmb3VuZCIsIkVycm9yIiwgTUJfVE9QTU9TVCk7DQot CQlyZXR1cm47DQorCQlyZXR1cm4gRV9GQUlMOw0KIAl9DQogDQogCXh2aWRf Z2xvYmFsX2Z1bmMgPSAoaW50IChfX2NkZWNsICopKHZvaWQgKiwgaW50LCB2 b2lkICosIHZvaWQgKikpR2V0UHJvY0FkZHJlc3MobV9oZGxsLCAieHZpZF9n bG9iYWwiKTsNCiAJaWYgKHh2aWRfZ2xvYmFsX2Z1bmMgPT0gTlVMTCkgew0K KwkJRnJlZUxpYnJhcnkobV9oZGxsKTsNCisJCW1faGRsbCA9IE5VTEw7DQog CQlNZXNzYWdlQm94KDAsICJ4dmlkX2dsb2JhbCgpIG5vdCBmb3VuZCIsICJF cnJvciIsIE1CX1RPUE1PU1QpOw0KLQkJcmV0dXJuOw0KKwkJcmV0dXJuIEVf RkFJTDsNCiAJfQ0KIA0KIAl4dmlkX2RlY29yZV9mdW5jID0gKGludCAoX19j ZGVjbCAqKSh2b2lkICosIGludCwgdm9pZCAqLCB2b2lkICopKUdldFByb2NB ZGRyZXNzKG1faGRsbCwgInh2aWRfZGVjb3JlIik7DQogCWlmICh4dmlkX2Rl Y29yZV9mdW5jID09IE5VTEwpIHsNCisJCXh2aWRfZ2xvYmFsX2Z1bmMgPSBO VUxMOw0KKwkJRnJlZUxpYnJhcnkobV9oZGxsKTsNCisJCW1faGRsbCA9IE5V TEw7DQogCQlNZXNzYWdlQm94KDAsICJ4dmlkX2RlY29yZSgpIG5vdCBmb3Vu ZCIsICJFcnJvciIsIE1CX1RPUE1PU1QpOw0KLQkJcmV0dXJuOw0KKwkJcmV0 dXJuIEVfRkFJTDsNCiAJfQ0KIA0KIAlpZiAoeHZpZF9nbG9iYWxfZnVuYygw LCBYVklEX0dCTF9JTklULCAmaW5pdCwgTlVMTCkgPCAwKQ0KIAl7DQorCQl4 dmlkX2dsb2JhbF9mdW5jID0gTlVMTDsNCisJCXh2aWRfZGVjb3JlX2Z1bmMg PSBOVUxMOw0KKwkJRnJlZUxpYnJhcnkobV9oZGxsKTsNCisJCW1faGRsbCA9 IE5VTEw7DQogCQlNZXNzYWdlQm94KDAsICJ4dmlkX2dsb2JhbCgpIGZhaWxl ZCIsICJFcnJvciIsIE1CX1RPUE1PU1QpOw0KLQkJcmV0dXJuOw0KKwkJcmV0 dXJuIEVfRkFJTDsNCiAJfQ0KIA0KIAltZW1zZXQoJm1fY3JlYXRlLCAwLCBz aXplb2YobV9jcmVhdGUpKTsNCkBAIC0yNDQsOCArMjY5LDYgQEANDQogCW1l bXNldCgmbV9mcmFtZSwgMCwgc2l6ZW9mKG1fZnJhbWUpKTsNCiAJbV9mcmFt ZS52ZXJzaW9uID0gWFZJRF9WRVJTSU9OOw0KIA0KLQlMb2FkUmVnaXN0cnlJ bmZvKCk7DQotDQogCVVTRV9JWVVWID0gZmFsc2U7DQogCVVTRV9ZVjEyID0g ZmFsc2U7DQogCVVTRV9ZVVkyID0gZmFsc2U7DQpAQCAtMzAyLDEzICszMjUs MTYgQEANDQogCQlhcl95ID0gMjA7DQogCQlicmVhazsNCiAJfQ0KKwkNCisJ cmV0dXJuIFNfT0s7DQogfQ0KIA0KIHZvaWQgQ1h2aWREZWNvZGVyOjpDbG9z ZUxpYigpDQogew0KLQlEUFJJTlRGKCJEZXN0cnVjdG9yIik7DQorCURQUklO VEYoIkNsb3NlTGliIik7DQogDQotCWlmIChtX2NyZWF0ZS5oYW5kbGUgIT0g TlVMTCkgew0KKwlpZiAoKG1fY3JlYXRlLmhhbmRsZSAhPSBOVUxMKSAmJiAo eHZpZF9kZWNvcmVfZnVuYyAhPSBOVUxMKSkNCisJew0KIAkJeHZpZF9kZWNv cmVfZnVuYyhtX2NyZWF0ZS5oYW5kbGUsIFhWSURfREVDX0RFU1RST1ksIDAs IDApOw0KIAkJbV9jcmVhdGUuaGFuZGxlID0gTlVMTDsNCiAJfQ0KQEAgLTMx NywxMiArMzQzLDE1IEBADQ0KIAkJRnJlZUxpYnJhcnkobV9oZGxsKTsNCiAJ CW1faGRsbCA9IE5VTEw7DQogCX0NCisJeHZpZF9kZWNvcmVfZnVuYyA9IE5V TEw7DQorCXh2aWRfZ2xvYmFsX2Z1bmMgPSBOVUxMOw0KIH0NCiANCiAvKiBk ZXN0cnVjdG9yICovDQogDQogQ1h2aWREZWNvZGVyOjp+Q1h2aWREZWNvZGVy KCkNCiB7DQorCURQUklOVEYoIkRlc3RydWN0b3IiKTsNCiAJQ2xvc2VMaWIo KTsNCiB9DQogDQpAQCAtMzQ0LDYgKzM3MywxMyBAQA0NCiAJCXJldHVybiBW RldfRV9UWVBFX05PVF9BQ0NFUFRFRDsNCiAJfQ0KIA0KKwlpZiAobV9oZGxs ID09IE5VTEwpDQorCXsNDQorCQlIUkVTVUxUIGhyID0gT3BlbkxpYigpOw0N CisJCWlmIChGQUlMRUQoaHIpIHx8IChtX2hkbGwgPT0gTlVMTCkpIC8vIFBh cmFub2lkIGNoZWNrcy4NDQorCQkJcmV0dXJuIFZGV19FX1RZUEVfTk9UX0FD Q0VQVEVEOw0NCisJfQ0KKw0KIAlpZiAoKm10SW4tPkZvcm1hdFR5cGUoKSA9 PSBGT1JNQVRfVmlkZW9JbmZvKQ0KIAl7DQogCQlWSURFT0lORk9IRUFERVIg KiB2aWggPSAoVklERU9JTkZPSEVBREVSICopIG10SW4tPkZvcm1hdCgpOw0K QEAgLTcxMCw2ICs3NDYsOSBAQA0NCiANCiAJaWYgKG1fY3JlYXRlLmhhbmRs ZSA9PSBOVUxMKQ0KIAl7DQorCQlpZiAoeHZpZF9kZWNvcmVfZnVuYyA9PSBO VUxMKQ0KKwkJCXJldHVybiBFX0ZBSUw7DQorCQ0KIAkJaWYgKHh2aWRfZGVj b3JlX2Z1bmMoMCwgWFZJRF9ERUNfQ1JFQVRFLCAmbV9jcmVhdGUsIDApIDwg MCkNCiAJCXsNCiAgICAgICAgICAgICBEUFJJTlRGKCIqKiogWFZJRF9ERUNf Q1JFQVRFIGVycm9yIik7DQpAQCAtNzY5LDkgKzgwOCwxMCBAQA0NCiAJbV9m cmFtZS5vdXRwdXQuY3NwICY9IH5YVklEX0NTUF9WRkxJUDsNCiAJbV9mcmFt ZS5vdXRwdXQuY3NwIHw9IHJnYl9mbGlwXihnX2NvbmZpZy5uRmxpcFZpZGVv ID8gWFZJRF9DU1BfVkZMSVAgOiAwKTsNCiANCisJLy8gUGFyYW5vaWQgY2hl Y2suDQorCWlmICh4dmlkX2RlY29yZV9mdW5jID09IE5VTEwpDQorCQlyZXR1 cm4gRV9GQUlMOw0KIA0KLQ0KLQ0KIHJlcGVhdCA6DQogDQogCWlmIChwSW4t PklzUHJlcm9sbCgpICE9IFNfT0spDQpJbmRleDogZHNob3cvc3JjL0NYdmlk RGVjb2Rlci5oDQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0NCi0tLSBkc2hv dy9zcmMvQ1h2aWREZWNvZGVyLmgJKHJldmlzaW9uIDQ0NCkNDQorKysgZHNo b3cvc3JjL0NYdmlkRGVjb2Rlci5oCSh3b3JraW5nIGNvcHkpDQ0KQEAgLTgx LDYgKzgxLDcgQEANDQogcHJpdmF0ZSA6DQogDQogCUhSRVNVTFQgQ2hhbmdl Q29sb3JzcGFjZShHVUlEIHN1YnR5cGUsIEdVSUQgZm9ybWF0dHlwZSwgdm9p ZCAqIGZvcm1hdCk7DQorCUhSRVNVTFQgT3BlbkxpYigpOw0KIAl2b2lkIENs b3NlTGliKCk7DQogDQogCXh2aWRfZGVjX2NyZWF0ZV90IG1fY3JlYXRlOw0K --0-467643078-1109766014=:81658 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel --0-467643078-1109766014=:81658-- From xvid-devel-bounces@xvid.org Wed Mar 9 11:10:11 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 5572B126D83 for ; Wed, 9 Mar 2005 11:10:11 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 245B714FF1; Wed, 9 Mar 2005 11:10:07 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from hugin.optimalstream.net (unknown [130.226.208.162]) by edu.bnhof.de (Postfix) with ESMTP id 41C1D14FEB for ; Wed, 9 Mar 2005 11:10:01 +0100 (CET) Received: from maersk-moller.net (IDENT:1121@localhost [127.0.0.1]) by hugin.optimalstream.net (8.12.10/8.12.4) with ESMTP id j29A9wkh020426 for ; Wed, 9 Mar 2005 11:09:58 +0100 Message-ID: <422ECB76.3040901@maersk-moller.net> Date: Wed, 09 Mar 2005 11:09:58 +0100 From: Peter Maersk-Moller Organization: Kabel-TV over Internettet User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xvid-devel@xvid.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [XviD-devel] Hyperthreading and XviD X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi. I'm trying to add YUV-denoising to mp4live in MPEG4IP project and it seems to work rather well (with XviD) when live encoding an analogue source. However, YUV-denoising (nonaccel, XMM and XMME) is rather CPU intensive so with my current implementation, YUV-denoising with XviD encoding of 480x576@25fps requires something like a 6 GHz HT P4, so for now I have to do with smaller video geometries. Analyzing the load, I noticed that on a P4HT, the load on both (virtual) processors is far from equal thus not exploiting HT to the its limits. I tried rewriting my code so the YUV-denoising ran in one thread and XviD encoding in another thread, but I observed little performance gain and little improvement in equal loading. Now for my questions. Is there anyone here with MMX/MMXE-knowledge that can confirm or deny that HT (Hyperthreading) means next to nothing for an MMX/MMXE-intensive application because MMX/MMXE is not hyperthreaded ? Kind regards --PMM _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Mar 9 12:10:52 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 5BCD9126D83 for ; Wed, 9 Mar 2005 12:10:52 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id B3789141AE; Wed, 9 Mar 2005 12:10:48 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (mail.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id 6D29113ED7 for ; Wed, 9 Mar 2005 12:10:44 +0100 (CET) Received: from login.math.uni-bonn.de (login.math.uni-bonn.de [131.220.120.13]) by nil.math.uni-bonn.de (Postfix) with ESMTP id 0E329590E2 for ; Wed, 9 Mar 2005 12:11:24 +0100 (CET) Date: Wed, 9 Mar 2005 12:10:43 +0100 (CET) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Hyperthreading and XviD In-Reply-To: <422ECB76.3040901@maersk-moller.net> Message-ID: References: <422ECB76.3040901@maersk-moller.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org On Wed, 9 Mar 2005, Peter Maersk-Moller wrote: > However, YUV-denoising (nonaccel, XMM and XMME) is rather > CPU intensive so with my current implementation, YUV-denoising > with XviD encoding of 480x576@25fps requires something > like a 6 GHz HT P4, so for now I have to do with smaller > video geometries. > > Analyzing the load, I noticed that on a P4HT, the load on both > (virtual) processors is far from equal thus not exploiting > HT to the its limits. > > I tried rewriting my code so the YUV-denoising ran in one thread > and XviD encoding in another thread, but I observed little > performance gain and little improvement in equal loading. > > Now for my questions. Is there anyone here with MMX/MMXE-knowledge > that can confirm or deny that HT (Hyperthreading) means > next to nothing for an MMX/MMXE-intensive application because > MMX/MMXE is not hyperthreaded ? Yes. Two things: XviD itself isn't threaded at all, so you won't get any speedup in the core. Using a multithreaded encoding application like transcode in Linux will somewhat be sped up though. Regarding the SIMD, I guess the problem is that HT is not dualcore or real SMP, but the threads share the functional units on the CPU. If two (hyper)threads try to use the SIMD unit at the same time, there won't be a speedup because the SIMD throughput is the bottleneck for both. chl _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Fri Mar 11 06:02:18 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 09A7B126D84 for ; Fri, 11 Mar 2005 06:02:18 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id E363414FD2; Fri, 11 Mar 2005 06:02:09 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from mx.sjtu.edu.cn (unknown [202.112.26.55]) by edu.bnhof.de (Postfix) with ESMTP id 6B4FED969 for ; Fri, 11 Mar 2005 06:02:00 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mx.sjtu.edu.cn (Postfix) with ESMTP id 9DBDA63D27 for ; Fri, 11 Mar 2005 13:01:45 +0800 (CST) Received: from mx.sjtu.edu.cn ([127.0.0.1]) by localhost (mx.sjtu.edu.cn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03123-07 for ; Fri, 11 Mar 2005 13:01:44 +0800 (CST) Received: from xiebo (unknown [202.120.34.22]) by mx.sjtu.edu.cn (Postfix) with ESMTP id 2646C638D5 for ; Fri, 11 Mar 2005 13:01:44 +0800 (CST) Message-ID: <002c01c525f7$68232250$93140a0a@xiebo> From: "Xie Bo" To: Date: Fri, 11 Mar 2005 13:01:38 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at sjtu.edu.cn X-Content-Filtered-By: Mailman/MimeDel 2.1.4 Subject: [XviD-devel] Is there stretch/scale source codes in xvid project? X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1943093786==" Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org This is a multi-part message in MIME format. --===============1943093786== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCiAgICBJIGhhdmUgYSA2NDAqNDgwIFlVWTIgdmlkZW8gaW5wdXQgYW5kIHdhbnQg dG8gZW5jb2RlciBpdCB0byAxNzYqMTQ0IGJ5IHh2aWQuIEhvdyB0byBkbyBpdD8gSXMgdGhlcmUg c3RyZXRjaC9zY2FsZSBzb3VyY2UgY29kZXMgaW4geHZpZCBwcm9qZWN0Pw0KICANCiAgICBUaGFu ayB5b3UgdmVyeSBtdWNoIQ0KDQpCZXN0IFJlZ2FyZHMsDQpYaWUgQm8= --===============1943093786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel --===============1943093786==-- From xvid-devel-bounces@xvid.org Fri Mar 11 20:50:03 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 3182A126D84 for ; Fri, 11 Mar 2005 20:50:03 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 9660414969; Fri, 11 Mar 2005 20:49:52 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from kepler.fjfi.cvut.cz (kepler.fjfi.cvut.cz [147.32.6.11]) by edu.bnhof.de (Postfix) with ESMTP id 4CFD71494F for ; Fri, 11 Mar 2005 20:49:49 +0100 (CET) Received: from kepler.fjfi.cvut.cz (localhost.localdomain [127.0.0.1]) by kepler.fjfi.cvut.cz (8.12.11/8.12.11) with ESMTP id j2BJnl2N023902 for ; Fri, 11 Mar 2005 20:49:47 +0100 Received: from localhost (drab@localhost) by kepler.fjfi.cvut.cz (8.12.11/8.12.11/Submit) with ESMTP id j2BJnlek023897 for ; Fri, 11 Mar 2005 20:49:47 +0100 Date: Fri, 11 Mar 2005 20:49:47 +0100 (CET) From: Martin Drab To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Is there stretch/scale source codes in xvid project? In-Reply-To: <002c01c525f7$68232250$93140a0a@xiebo> Message-ID: References: <002c01c525f7$68232250$93140a0a@xiebo> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org On Fri, 11 Mar 2005, Xie Bo wrote: > Hello, > > I have a 640*480 YUY2 video input and want to encoder it to 176*144 by xvid. How to do it? Is there stretch/scale source codes in xvid project? Try mencoder. Martin _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Sun Mar 13 17:05:54 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (unknown [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 16660126D88 for ; Sun, 13 Mar 2005 17:05:54 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id C384714FB2; Sun, 13 Mar 2005 17:05:44 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from viefep20-int.chello.at (viefep12-int.chello.at [213.46.255.25]) by edu.bnhof.de (Postfix) with ESMTP id 4035B14FB2 for ; Sun, 13 Mar 2005 17:05:40 +0100 (CET) Received: from Rpv ([84.114.133.201]) by viefep20-int.chello.at (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with SMTP id <20050313160536.PNQX17835.viefep20-int.chello.at@Rpv> for ; Sun, 13 Mar 2005 17:05:36 +0100 From: skal To: xvid-devel@xvid.org MIME-Version: 1.0 Message-Id: <20050313160536.PNQX17835.viefep20-int.chello.at@Rpv> Date: Sun, 13 Mar 2005 17:05:40 +0100 Content-Type: text/plain;charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.4 Subject: [XviD-devel] A very good tool X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org -------- Virus Warning Message -------- The virus (W32/Klez.h@MM) was detected in the attachment 2002.exe. The attached File 2002.exe has been removed. Nachfolgender Virus (W32/Klez.h@MM) wurde im Attachment 2002.exe gefunden, deshalb wurde das Attachment 2002.exe gel=F6scht. F=FCr Fragen dazu steht Ihnen der chello Helpdesk sehr gerne zur Verf=FCgung. Weitere Informationen zum Virenschutz: http://portal.chello.at/av-info.html Le serveur de mail chello a d=E9tect=E9 le virus W32/Klez.h@MM dans le fichier 2002.exe inclus dans ce mail. Ce fichier 2002.exe a donc =E9t=E9 supprim=E9e pour en =E9viter la diffusion. Pour plus d'information, merci de cliquer sur le lien suivant http://www.chello.fr Az =D6nnek k=E9zbes=EDtett lev=E9l mell=E9klet=E9ben a v=EDrussz=FBr=F5 rendszer a(z) W32/Klez.h@MM nev=FB v=EDrust tal=E1lta, ez=E9rt a(z) 2002.exe nev=FB = mell=E9kletet biztons=E1gi okokb=F3l elt=E1vol=EDtotta. Tov=E1bbi inform=E1ci=F3=E9rt, k=E9rj=FCk kattintson az al=E1bbi hivatkoz=E1sra: http://home.hun.chello.hu/upcmnfc/start/tamogatas/virusszures/ V p=F8=EDloze 2002.exe byl detekov=E1n virus W32/Klez.h@MM. P=F8=EDloha = 2002.exe byla proto odstran=ECna. Pro dotazy kontaktujte pros=EDm technickou podporu. W za=B3=B1czniku 2002.exe wykryto wirus W32/Klez.h@MM. Plik 2002.exe zosta=B3 usuni=EAty. Wi=EAcej informacji znajdziesz na stronie internetowej: http://home.pol.chello.pl/upcmnfc/start/pomoc/wirusy/ V prilo=BEenom s=FAbore 2002.exe bol zisten=FD v=EDrus (W32/Klez.h@MM). S=FAbor 2002.exe bol odstr=E1nen=FD. V pr=EDpade ot=E1zok pros=EDm kontaktujte linku technickej podpory. http://www.chello.sk ---------------------------------------- _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Mon Mar 14 12:11:38 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 700D5126D85 for ; Mon, 14 Mar 2005 12:11:38 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 9B4CA14FF0; Mon, 14 Mar 2005 12:11:27 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from s5.lansco.de (s5.lansco.de [212.63.130.170]) by edu.bnhof.de (Postfix) with ESMTP id E6A7814FE5 for ; Mon, 14 Mar 2005 12:11:22 +0100 (CET) Received: from localhost (s5.lansco.de [212.63.130.170]) by s5.lansco.de (Postfix) with ESMTP id 971A225573 for ; Mon, 14 Mar 2005 12:11:21 +0100 (CET) Received: from pD9539F77.dip.t-dialin.net (pD9539F77.dip.t-dialin.net [217.83.159.119]) by www.lansco.de (IMP) with HTTP for ; Mon, 14 Mar 2005 12:11:21 +0100 Message-ID: <1110798681.423571597495e@www.lansco.de> Date: Mon, 14 Mar 2005 12:11:21 +0100 From: Michael Militzer To: xvid-devel@xvid.org Subject: Re: [XviD-devel] vbv patch References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 217.83.159.119 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Pete, your patch file seems damaged (at least for me). However, from looking it over it seems ok. I just believe we shouldn't offer the 'strict conformance' option. Could you apply the patch and commit to cvs please? bye, Michael Quoting suxen_drol : > hey michael, > > radek suggested removing "strict conformance" checkbox. however" and > always force these extra constraints. does anyone have any further > thoughts on the matter? i argue that having the checkbox allows some > experimentation with the divx profiles. again, i dont use these profiles, > so my position on this is mostly irrelevant. > > -- pete > > On Wed, 16 Feb 2005 18:47:35 +0100 Michael Militzer > wrote: > > Hi, > > > > since vbv compliance and the DivX profile are an important new feature in > > XviD 1.1, I think the patch should be applied and another beta should be > > released. After all, the current implementation of the DXN profiles in 1.1 > > beta1 is wrong, so your patch is imho more a bugfix than a new feature. > > > > bye, > > Michael > > > > > > Quoting peter ross : > > > > > gday, > > > > > > divxnetworks has advised the our current dxn profiles do not conform to > > > their latest > > > certification standard, and should be modificied to incorporate the > > > following constraints: > > > > > > * 4mv is disabled for the handheld profile > > > * 1:1 picture aspect only > > > * disable bframes if interlacing is enabled > > > * force maximum of 1 consecutive bvop for the portable and ht profiles, > and > > > 2 bvops for the hd profile > > > * always write divx 5 userdata string to bitstream "DivX503b1393(p)" > > > * force packed bitstream option > > > * update vbv params > > > > > > i have assembled a patch, that adds an additional "strict conformance to > dxn > > > > > > profile > > > standard" checkbox. this is checked by default, but can be unchecked by > > > advanced > > > users who wish to experiment. since the v1.1 release is impending and > > > feature > > > frozen, i have attached the patch below for review. perhaps we need > another > > > beta, > > > to give users a chance to test the "new" profiles with hardware players? > > > > > > christoph: dxn now uses a "max bits over 1sec constraint" instead of the > > > > 3sec constraint. > > > this needs to be changed within xvidcore. currently, vfw multiplies the > > > 1second > > > constraint by 3 before passing it to xvidcore. > > > > > > FULL CHANGE LOG: > > > > > > xvidcore > > > ======== > > > added XVID_GLOBAL_DIVX5_USERDATA global flag > > > removed the bvop delay warning text. this confuses joe user. > > > "warning: nothing to output" > > > "bframe decoder lag" > > > minor changed to closed gop image_printf statement: > > > s/"DX50 BVOP->PVOP"/"CLOSED GOP BVOP->PVOP" > > > additional comments for low_delay_default mode within decoder_decode() > > > divx userdata string: s/DivX999b000/DivX503b1393 > > > this has been suggested by dxn for improved hardware compatibility > > > [nb: i dont have a hardware player to confirm this] > > > vbv_peakrate constraint is ignored if <= 0 > > > > > > vfw frontend > > > ============ > > > "strict conformance to DXN profile standard" checkbox: > > > force 1:1 picture aspect ratio > > > disable bframes if interlacing is enabled > > > force maximum of 1 consecutive bvops for the portable and ht profiles, > 2 > > > bvops for the hd profile > > > always write divx 5 userdata string to bitstream > > > force packed bitstream option > > > updated dxn vbv parameters > > > > > > added PROFILE_4MV flag. 4mv is now disabled for the dxn handheld > profile. > > > moved PROFILE_AS/PROFILE_ARTS/PROFILE_S to config.c > > > profile[].max_bitrate now measured in bit/sec (not kbps) > > > > > > profile->level box: widgets are now greyed-out if they are not used. > > > increase vertical size of profile drop down list. > > > > > > about box button: s/Dismiss/OK > > > > > > cheers, > > > -- pete > > > > > > > > > > > > > > > > _______________________________________________ > > XviD-devel mailing list > > XviD-devel@xvid.org > > http://list.xvid.org/mailman/listinfo/xvid-devel > > > -- pete > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel > _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Mon Mar 14 20:10:54 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id C6E99126D85 for ; Mon, 14 Mar 2005 20:10:54 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 733DD14FD5; Mon, 14 Mar 2005 20:10:41 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from s5.lansco.de (s5.lansco.de [212.63.130.170]) by edu.bnhof.de (Postfix) with ESMTP id 6824814FB1 for ; Mon, 14 Mar 2005 19:59:38 +0100 (CET) Received: from localhost (s5.lansco.de [212.63.130.170]) by s5.lansco.de (Postfix) with ESMTP id 1631BD8A for ; Mon, 14 Mar 2005 19:59:38 +0100 (CET) Received: from pD9539C48.dip.t-dialin.net (pD9539C48.dip.t-dialin.net [217.83.156.72]) by www.lansco.de (IMP) with HTTP for ; Mon, 14 Mar 2005 19:59:37 +0100 Message-ID: <1110826777.4235df19e9ba1@www.lansco.de> Date: Mon, 14 Mar 2005 19:59:37 +0100 From: Michael Militzer To: xvid-devel@xvid.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-MOQ1110826777d0167c5e8136bc7e0772d5d629d48649" User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 217.83.156.72 X-Mailman-Approved-At: Mon, 14 Mar 2005 20:08:36 +0100 X-Content-Filtered-By: Mailman/MimeDel 2.1.4 Subject: [XviD-devel] low-bitrate patch X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org This message is in MIME format. ---MOQ1110826777d0167c5e8136bc7e0772d5d629d48649 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi all, I've committed a patch to cvs that improves XVID's performance at low- bitrates by using better lambda values for R-D vector search. By this also mode decision (SAD-based) is improved at low-bitrates. At mid/higher bitrates there's no change in performance, so only people who aim at really low bitrate (and quality) encodes will benefit from this patch. I've attached some R-D graphs that compare the behavior of patched and unpatched XVID for various sequences and different bit-rates. Note that I've used a logarithmic scale, so that the differences at low bitrates can be better perceived. As can be clearly noticed, the compression performance is enhanced significantly at very low bitrates (up to 2-3 dB PSNR). Well, it's another question how useful this patch actually is because such extremely low bit-rates are barely used. But for completeness, XVID should perform equally great at all bitrates... bye, Michael ---MOQ1110826777d0167c5e8136bc7e0772d5d629d48649 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel ---MOQ1110826777d0167c5e8136bc7e0772d5d629d48649-- From xvid-devel-bounces@xvid.org Mon Mar 14 20:21:39 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 531ED126D85 for ; Mon, 14 Mar 2005 20:21:39 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 6FD2114FE0; Mon, 14 Mar 2005 20:21:36 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from s5.lansco.de (s5.lansco.de [212.63.130.170]) by edu.bnhof.de (Postfix) with ESMTP id 7F10214FDC for ; Mon, 14 Mar 2005 20:21:32 +0100 (CET) Received: from localhost (s5.lansco.de [212.63.130.170]) by s5.lansco.de (Postfix) with ESMTP id CFA4725559 for ; Mon, 14 Mar 2005 20:21:31 +0100 (CET) Received: from pD9539C48.dip.t-dialin.net (pD9539C48.dip.t-dialin.net [217.83.156.72]) by www.lansco.de (IMP) with HTTP for ; Mon, 14 Mar 2005 20:21:31 +0100 Message-ID: <1110828091.4235e43bbd672@www.lansco.de> Date: Mon, 14 Mar 2005 20:21:31 +0100 From: Michael Militzer To: xvid-devel@xvid.org Subject: Re: [XviD-devel] low-bitrate patch References: <1110826777.4235df19e9ba1@www.lansco.de> In-Reply-To: <1110826777.4235df19e9ba1@www.lansco.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 217.83.156.72 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi, oops. The attachment got stripped by the mailing list. So here are the graphs: http://www.xvid.org/images/carphone.png http://www.xvid.org/images/highway.png http://www.xvid.org/images/mother.png http://www.xvid.org/images/paris.png http://www.xvid.org/images/tempete.png bye, Michael Quoting Michael Militzer : > Hi all, > > I've committed a patch to cvs that improves XVID's performance at low- > bitrates by using better lambda values for R-D vector search. By this also > mode decision (SAD-based) is improved at low-bitrates. At mid/higher > bitrates > there's no change in performance, so only people who aim at really low > bitrate (and quality) encodes will benefit from this patch. > > I've attached some R-D graphs that compare the behavior of patched and > unpatched XVID for various sequences and different bit-rates. Note that I've > used a logarithmic scale, so that the differences at low bitrates can be > better perceived. As can be clearly noticed, the compression performance is > enhanced significantly at very low bitrates (up to 2-3 dB PSNR). > > Well, it's another question how useful this patch actually is because such > extremely low bit-rates are barely used. But for completeness, XVID should > perform equally great at all bitrates... > > bye, > Michael > _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Mar 15 15:48:19 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 966CB126D83 for ; Tue, 15 Mar 2005 15:48:19 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id D9A69148D7; Tue, 15 Mar 2005 15:48:15 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (mail.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id 3D9AF1488D for ; Tue, 15 Mar 2005 15:48:10 +0100 (CET) Received: from login.math.uni-bonn.de (login.math.uni-bonn.de [131.220.120.13]) by nil.math.uni-bonn.de (Postfix) with ESMTP id 88D1159210 for ; Tue, 15 Mar 2005 15:48:57 +0100 (CET) Date: Tue, 15 Mar 2005 15:48:10 +0100 (CET) From: Christoph Lampert To: xvid-devel@xvid.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [XviD-devel] 8bit greyscale X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi, old story, new reason: I had an inquiry if XviD supports plain 8bit-greyscale input, and for my amazement, I found out it still doesn't. It's of course just 2 lines to add this to the color space routines, just use YUV and set U and V to fixed 128, I can patch this in. But how about VfW, could somebody add an option for this? chl _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Mar 15 16:04:12 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 5B471126D83 for ; Tue, 15 Mar 2005 16:04:12 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id E92081463D; Tue, 15 Mar 2005 16:04:08 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from s5.lansco.de (s5.lansco.de [212.63.130.170]) by edu.bnhof.de (Postfix) with ESMTP id 3474D13ED3 for ; Tue, 15 Mar 2005 16:04:06 +0100 (CET) Received: from localhost (s5.lansco.de [212.63.130.170]) by s5.lansco.de (Postfix) with ESMTP id 8F00525554 for ; Tue, 15 Mar 2005 16:04:06 +0100 (CET) Received: from pD9539EDE.dip.t-dialin.net (pD9539EDE.dip.t-dialin.net [217.83.158.222]) by www.lansco.de (IMP) with HTTP for ; Tue, 15 Mar 2005 16:04:06 +0100 Message-ID: <1110899046.4236f96677465@www.lansco.de> Date: Tue, 15 Mar 2005 16:04:06 +0100 From: Michael Militzer To: xvid-devel@xvid.org Subject: Re: [XviD-devel] 8bit greyscale References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 217.83.158.222 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi, there's a greyscale encoding option in XVID already for a long time (and such an option also exists in the VfW GUI). If the XVID_VOP_GREYSCALE flag is set, chroma information is dropped in the encoder. That should be sufficient I think - there's no need to set U and V to 128 in colorspace conversion if the chroma information is later omitted anyway... Michael Quoting Christoph Lampert : > > Hi, > > old story, new reason: I had an inquiry if XviD supports plain > 8bit-greyscale input, and for my amazement, I found out it still doesn't. > It's of course just 2 lines to add this to the color space routines, > just use YUV and set U and V to fixed 128, I can patch this in. > > But how about VfW, could somebody add an option for this? > > chl > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel > _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Mar 15 17:51:37 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 85358126D85 for ; Tue, 15 Mar 2005 17:51:37 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 6835715002; Tue, 15 Mar 2005 17:51:31 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (mail.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id 83EF115000 for ; Tue, 15 Mar 2005 17:51:27 +0100 (CET) Received: from login.math.uni-bonn.de (login.math.uni-bonn.de [131.220.120.13]) by nil.math.uni-bonn.de (Postfix) with ESMTP id 682B55A006 for ; Tue, 15 Mar 2005 17:52:14 +0100 (CET) Date: Tue, 15 Mar 2005 17:51:27 +0100 (CET) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] 8bit greyscale In-Reply-To: <1110899046.4236f96677465@www.lansco.de> Message-ID: References: <1110899046.4236f96677465@www.lansco.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org On Tue, 15 Mar 2005, Michael Militzer wrote: > Hi, > > there's a greyscale encoding option in XVID already for a long time (and > such an option also exists in the VfW GUI). If the XVID_VOP_GREYSCALE flag > is set, chroma information is dropped in the encoder. That should be > sufficient I think - there's no need to set U and V to 128 in colorspace > conversion if the chroma information is later omitted anyway... Yes, I know about the GREYSCALE flag (wasn't it me who added it? I don't remember). But I didn't mean only encoding at greyscale (possibly from color input), but about using only planar 8bit greyscale as input colorspace. It seems that there is no possiblity to feed that directly into XviD without padding it with 128s, although it seems that some cameras can produce it. Internally, one can of course use XVID_CSP_USER and set U and V point to something constant, but it seems that the VfW-GUI doesn't accept 8bit input in that way. gruel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Mar 16 23:23:18 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id B37C4126D83 for ; Wed, 16 Mar 2005 23:23:18 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 9AE5F140AD; Wed, 16 Mar 2005 23:23:11 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from s5.lansco.de (s5.lansco.de [212.63.130.170]) by edu.bnhof.de (Postfix) with ESMTP id 54CBC13ED7 for ; Wed, 16 Mar 2005 23:23:07 +0100 (CET) Received: from localhost (s5.lansco.de [212.63.130.170]) by s5.lansco.de (Postfix) with ESMTP id 10AA525724 for ; Wed, 16 Mar 2005 23:23:07 +0100 (CET) Received: from pD9E37EB1.dip.t-dialin.net (pD9E37EB1.dip.t-dialin.net [217.227.126.177]) by www.lansco.de (IMP) with HTTP for ; Wed, 16 Mar 2005 23:23:06 +0100 Message-ID: <1111011786.4238b1cae5f97@www.lansco.de> Date: Wed, 16 Mar 2005 23:23:06 +0100 From: Michael Militzer To: xvid-devel@xvid.org Subject: Re: [XviD-devel] 8bit greyscale References: <1110899046.4236f96677465@www.lansco.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 217.227.126.177 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi, Quoting Christoph Lampert : > On Tue, 15 Mar 2005, Michael Militzer wrote: > > > Hi, > > > > there's a greyscale encoding option in XVID already for a long time (and > > such an option also exists in the VfW GUI). If the XVID_VOP_GREYSCALE flag > > is set, chroma information is dropped in the encoder. That should be > > sufficient I think - there's no need to set U and V to 128 in colorspace > > conversion if the chroma information is later omitted anyway... > > Yes, I know about the GREYSCALE flag (wasn't it me who added it? I > don't remember). But I didn't mean only encoding at greyscale (possibly > from color input), but about using only planar 8bit greyscale as input > colorspace. It seems that there is no possiblity to feed that directly > into XviD without padding it with 128s, although it seems that some > cameras can produce it. > > Internally, one can of course use XVID_CSP_USER and set U and V point to > something constant, but it seems that the VfW-GUI doesn't accept 8bit > input in that way. Well, internally you could use XVID_CSP_USER, use the greyscale image as y-plane and don't care about U/V values at all. Iirc, if you set the XVID_VOP_GREYSCALE flag the chroma information is omitted anyway, so there's no need to set the chroma planes to constant values. So VfW support could be added without modifying xvidcore. I just wonder if VfW supports 8-bit greyscale input at all. I only know of 8-bit indexed RGB in VfW - but I'm no expert regarding the supported VfW colorspaces. So even if a camera natively works in 8-bit greyscale mode, the VfW driver may automatically convert the images to RGB... Michael _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Fri Mar 18 18:37:29 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id B90B4126D84 for ; Fri, 18 Mar 2005 18:37:29 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id C589A14191; Fri, 18 Mar 2005 18:37:20 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from edgomez.kicks-ass.org (edgomez.kicks-ass.org [82.225.208.184]) by edu.bnhof.de (Postfix) with ESMTP id 82B8F13ECB for ; Fri, 18 Mar 2005 18:37:15 +0100 (CET) Received: from edy by edgomez.kicks-ass.org with local (Exim 4.50) id 1DCLPP-00036a-20 for xvid-devel@xvid.org; Fri, 18 Mar 2005 18:37:15 +0100 Date: Fri, 18 Mar 2005 18:37:15 +0100 From: Edouard Gomez To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Bug in 64-bit interlacing_mmx.asm Message-ID: <20050318173714.GA11679@edgomez.kicks-ass.org> Mail-Followup-To: Edouard Gomez , xvid-devel@xvid.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Andrew Dunstan (a_dunstan@hotmail.com) wrote: > Found a bug while doing interlaced encoding using the 64-bit port. > line 182 in utils\x86_64_asm\interlacing_mmx.asm: > mov rcx, [r9+rax*4] > > Should be a 32-bit move: > mov ecx, [r9+rax*4] Patched in my branch, will be in cvs in a short time -- Edouard Gomez _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Fri Mar 18 19:06:01 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 02E42126D84 for ; Fri, 18 Mar 2005 19:06:01 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id F2ACD14975; Fri, 18 Mar 2005 19:05:56 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from edgomez.kicks-ass.org (edgomez.kicks-ass.org [82.225.208.184]) by edu.bnhof.de (Postfix) with ESMTP id DFDA61496F for ; Fri, 18 Mar 2005 19:05:53 +0100 (CET) Received: from edy by edgomez.kicks-ass.org with local (Exim 4.50) id 1DCLr7-0003XL-1Y for xvid-devel@xvid.org; Fri, 18 Mar 2005 19:05:53 +0100 Date: Fri, 18 Mar 2005 19:05:53 +0100 From: Edouard Gomez To: xvid-devel ML Message-ID: <20050318180553.GA5955@edgomez.kicks-ass.org> Mail-Followup-To: Edouard Gomez , xvid-devel ML Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i Subject: [XviD-devel] [CVS commit] Summary of the last patches merged X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hello, Found 1h to sync my branch with CVS and apply two patches sent to me. As a bonus, i generated the ChangeLog again, so i post here a summary of the last changes. I see that fixes to VBV are still pending, pete ? See ya. ------------------------8<--------------------------------- 2005-03-18 17:53:24 GMT patch-2 Summary: Colorspace code for PPC Revision: xvidcore--head--0.0--patch-2 From Christoph Nageli: - Colorspace function fixes for non 16bytes aligned target adresses. modified files: src/image/ppc_asm/colorspace_altivec.c 2005-03-18 17:39:00 GMT patch-1 Summary: Fix for 64bit interlacing Revision: xvidcore--head--0.0--patch-1 From Andrew Dunstan: * Fixed bug where 64bit mov shoud have been 32bit modified files: src/utils/x86_64_asm/interlacing_mmx.asm 2005-03-18 17:28:00 GMT base-0 Summary: tag of ed.gomez@free.fr--2004-1/xvidcore--head--0.0--patch-121 Revision: xvidcore--head--0.0--base-0 (automatically generated log message) # Change of arch/tla archive, explains the patch number wraparound 2005-03-18 16:58:08 GMT patch-121 Summary: ME work Revision: xvidcore--head--0.0--patch-121 From Isiibar: - Cartoon mode bugfix - New lambda tables for R-D motion search. The old tables were obviously taken from h.264, which uses a logarithmic quantizer scale. This lead to bad results at very low bit-rates. With this patch, compression efficiency at low bit-rates is greatly improved. modified files: src/motion/estimation.h src/motion/estimation_bvop.c src/motion/estimation_common.c src/motion/estimation_pvop.c 2005-03-18 16:56:13 GMT patch-120 Summary: Better instruction pairing in sad mmx Revision: xvidcore--head--0.0--patch-120 From Dark sylinc (dark_sylinc at yahoo dor com dor ar), commited by Isiibar: * Better instruction pairing in sad_mmx.asm, improves speed. modified files: src/motion/x86_asm/sad_mmx.asm src/utils/emms.c 2005-03-18 16:53:00 GMT patch-119 Summary: Fixed resource leak in Dshow Revision: xvidcore--head--0.0--patch-119 From antonz, commited by Isiibar: * Fixed resource leaking caused by poor xvidcore initialization tracking. modified files: dshow/src/CXvidDecoder.cpp dshow/src/CXvidDecoder.h 2005-03-18 16:50:44 GMT patch-118 Summary: Debug flag support in vfw Revision: xvidcore--head--0.0--patch-118 From pete: * debug flag support for vfw decoder. modified files: vfw/src/codec.c ######################################################################### # 1.1.0-beta1 (Bitstream Version 38) ######################################################################### 2005-01-16 10:27:41 GMT patch-117 Summary: License was using wrong linefeeds for vfw Revision: xvidcore--head--0.0--patch-117 License was using wrong linefeeds for vfw new files: vfw/.arch-ids/LICENSE.id vfw/LICENSE modified files: vfw/src/resource.rc 2005-01-10 22:59:46 GMT patch-116 Summary: Last minutes vfw bugfixes/improvements Revision: xvidcore--head--0.0--patch-116 From sysKin: * last minute fixes and improvements to vfw frontend. modified files: vfw/src/codec.c vfw/src/config.c vfw/src/config.h vfw/src/resource.rc ------------------------8<--------------------------------- -- Edouard Gomez _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Sat Mar 19 00:19:57 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 80F99126D84 for ; Sat, 19 Mar 2005 00:19:57 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id E013313F58; Sat, 19 Mar 2005 00:19:52 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from web52506.mail.yahoo.com (web52506.mail.yahoo.com [206.190.39.127]) by edu.bnhof.de (Postfix) with SMTP id B8A35D940 for ; Sat, 19 Mar 2005 00:19:49 +0100 (CET) Received: (qmail 54761 invoked by uid 60001); 18 Mar 2005 23:19:48 -0000 Message-ID: <20050318231948.54759.qmail@web52506.mail.yahoo.com> Received: from [200.42.34.120] by web52506.mail.yahoo.com via HTTP; Fri, 18 Mar 2005 20:19:48 ART Date: Fri, 18 Mar 2005 20:19:48 -0300 (ART) From: Dark Sylinc Subject: Re: [XviD-devel] 8bit greyscale To: xvid-devel@xvid.org In-Reply-To: <1111011786.4238b1cae5f97@www.lansco.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org >So VfW support could be added without modifying xvidcore. I just wonder >if >VfW supports 8-bit greyscale input at all. I only know of 8-bit indexed >RGB >in VfW - but I'm no expert regarding the supported VfW colorspaces. So >even >if a camera natively works in 8-bit greyscale mode, the VfW driver may >automatically convert the images to RGB... >Michael Plattform SDK documentation says that HBITMAPINFOHEADER uses _only_ 8-bit INDEXED (so grayscale images use pixels with '0xfe' in this way: pal[0xfe].red = pal[0xfe].blue = pal[0xfe].green = 0xfe ) This also applies BITMAPV4HEADER and BITMAPV5HEADER. This are the three structs that VFW handles, so VFW does not support 8-bit grayscale. Custom applications may force VFW frontends to whatever they want, but even so, there is no way to tell the driver to use 8-bit grayscale instead of indexed) Take in mind that XviD VFW frontend doesn't support drawing. I don't know if drawing routines may be in grayscale.... (despite the input format) Dark_Sylinc __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Mon Mar 21 13:03:24 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id EAC39126D84 for ; Mon, 21 Mar 2005 13:03:23 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id CD98D13EB3; Mon, 21 Mar 2005 13:03:12 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from centomila.elet.polimi.it (centomila.elet.polimi.it [131.175.120.12]) by edu.bnhof.de (Postfix) with ESMTP id 052D08A57 for ; Mon, 21 Mar 2005 13:03:09 +0100 (CET) Received: from localhost (centomila.elet.polimi.it [127.0.0.1]) by centomila.elet.polimi.it (Postfix) with ESMTP id 6B7A413899 for ; Mon, 21 Mar 2005 13:03:06 +0100 (CET) Received: from centomila.elet.polimi.it ([127.0.0.1]) by localhost (centomila.elet.polimi.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21530-09 for ; Mon, 21 Mar 2005 13:03:04 +0100 (CET) Received: from piccarreta (piccarreta.elet.polimi.it [131.175.18.42]) by centomila.elet.polimi.it (Postfix) with ESMTP id 0A2DB13892 for ; Mon, 21 Mar 2005 13:03:04 +0100 (CET) Message-ID: <000801c52e0d$fcdf43b0$2a12af83@piccarreta> From: "Luca Piccarreta" To: References: <20050318231948.54759.qmail@web52506.mail.yahoo.com> Subject: Re: [XviD-devel] 8bit greyscale Date: Mon, 21 Mar 2005 13:03:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.224 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.224 X-Virus-Scanned: by amavisd-new-20030616-p10 at elet.polimi.it X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Even though this might not be such a clean solution, there is a Y800 (or similars) FourCC for greyscale images.... Luca Piccarrta ----- Original Message ----- From: "Dark Sylinc" To: Sent: Saturday, March 19, 2005 12:19 AM Subject: Re: [XviD-devel] 8bit greyscale >So VfW support could be added without modifying xvidcore. I just wonder >if >VfW supports 8-bit greyscale input at all. I only know of 8-bit indexed >RGB >in VfW - but I'm no expert regarding the supported VfW colorspaces. So >even >if a camera natively works in 8-bit greyscale mode, the VfW driver may >automatically convert the images to RGB... >Michael Plattform SDK documentation says that HBITMAPINFOHEADER uses _only_ 8-bit INDEXED (so grayscale images use pixels with '0xfe' in this way: pal[0xfe].red = pal[0xfe].blue = pal[0xfe].green = 0xfe ) This also applies BITMAPV4HEADER and BITMAPV5HEADER. This are the three structs that VFW handles, so VFW does not support 8-bit grayscale. Custom applications may force VFW frontends to whatever they want, but even so, there is no way to tell the driver to use 8-bit grayscale instead of indexed) Take in mind that XviD VFW frontend doesn't support drawing. I don't know if drawing routines may be in grayscale.... (despite the input format) Dark_Sylinc __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Mar 22 00:48:43 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id CE356126D84 for ; Tue, 22 Mar 2005 00:48:43 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id C2BA41316D; Tue, 22 Mar 2005 00:48:34 +0100 (CET) X-Original-To: XviD-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from priv-edtnes44.telusplanet.net (outbound05.telus.net [199.185.220.224]) by edu.bnhof.de (Postfix) with ESMTP id B27FCD9C6 for ; Tue, 22 Mar 2005 00:48:31 +0100 (CET) Received: from tor.lat ([205.250.104.75]) by priv-edtnes44.telusplanet.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050321234829.DXFQ29753.priv-edtnes44.telusplanet.net@tor.lat>; Mon, 21 Mar 2005 16:48:29 -0700 Received: by tor.lat (Postfix, from userid 1001) id DCD9F320862; Mon, 21 Mar 2005 15:48:28 -0800 (PST) Received: from [192.168.179.9] (kas.ruz.lat [192.168.179.9]) by tor.lat (Postfix) with ESMTP id 69A59320860; Mon, 21 Mar 2005 15:48:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: 232658@bugs.debian.org, XviD-devel@xvid.org From: ms419@freezone.co.uk Date: Mon, 21 Mar 2005 15:48:23 -0800 X-Mailer: Apple Mail (2.619.2) X-Face: #..0OTm4cDCHwG[!aCF/-vw$N5mfb58T+T\IP+^JU{FpY!%; y6(71_LfzLJn6Q)3th4.Db{ e4P)Cjq&5t~_<"OJ<+*5:($4eJck-+`; C%SnMgY}PN[(j; &O8Y(WY=cZm; }<(P_7p8V7E%.8i(; -Ga W)>KDF0sJO!ap4-:fcXd=jq, fb-&)KiBd9)F`rD42:p.\k/t%, V3^fGMyb[8w$K{f3>[/%vR@Z0[1Q @kf|_a''|[n6:CJ8&_$1e(rp8jj0bj\lw6z`-9;0Pw!cd$/)SnC'9;vjC2?%11+rPmw X-Hashcash: 1:20:050321:232658@bugs.debian.org::4RB2BAdrZJrNHIA9:00000 00000000000000000000000000000000003kDH X-Hashcash: 1:20:050321:xvid-devel@xvid.org::Ied/LPKv1gIBIFdM:00000000 0000000000000000000000000000000000064a Cc: Subject: [XviD-devel] Debian Package Situation X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org I gather xvidcore didn't make it into Debian? I googled/gmaned a bit to understand why it was rejected, without luck. I found only - * Debian bug #232658 * The XviD changelog, stating xvidcore wasn't accepted into Debian - http://www.xvid.org/modules.php? op=modload&name=News&file=article&sid=57 * This promising thread - http://thread.gmane.org/gmane.linux.debian.devel.general/76094 What's the xvidcore Debian package situation? Thanks! Jack _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Mar 23 00:40:45 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 2267C126D83 for ; Wed, 23 Mar 2005 00:40:45 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 199E91314B; Wed, 23 Mar 2005 00:40:37 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from wtf.sd.dreamhost.com (gnat.sd.dreamhost.com [66.33.206.8]) by edu.bnhof.de (Postfix) with ESMTP id 13739122B0 for ; Wed, 23 Mar 2005 00:40:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by wtf.sd.dreamhost.com (Postfix) with ESMTP id C2D8EA3066 for ; Tue, 22 Mar 2005 15:40:32 -0800 (PST) Date: Tue, 22 Mar 2005 15:40:32 -0800 (PST) From: sage weil To: xvid-devel@xvid.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [XviD-devel] stereo video streams X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi, I'm looking for a way to efficiently encode a pair of video streams from a stereo camera. A few obvious possibilities present themselves but are not entirely ideal: - Put frames side by side and encode as usual. Macroblock searches won't find similar blocks from the other camera with a localized search... - Interleave left and right frames. If xvid searches more than one frame back then this would work reasonably well, but I'm pretty sure it doesn't? And if it did the motion prediction would end up way off, resulting in suboptimal performance... Does anybody have any thoughts about what might be necessary in terms of code changes to make this work well? thanks- sage _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Mar 23 09:23:51 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 838F7126D83 for ; Wed, 23 Mar 2005 09:23:51 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 5238115037; Wed, 23 Mar 2005 09:23:47 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from mxout-04.mxes.net (mxout-04.mxes.net [205.237.194.35]) by edu.bnhof.de (Postfix) with ESMTP id EC74A15034 for ; Wed, 23 Mar 2005 09:23:44 +0100 (CET) Received: from [131.246.244.204] (timbuktu.informatik.uni-kl.de [131.246.244.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id E48F0A32B1 for ; Wed, 23 Mar 2005 03:23:36 -0500 (EST) Message-ID: <4241276B.8060705@math.uni-bonn.de> Date: Wed, 23 Mar 2005 09:23:07 +0100 From: Christoph Lampert User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xvid-devel@xvid.org Subject: Re: [XviD-devel] stereo video streams References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi, sage weil wrote: > Hi, > > I'm looking for a way to efficiently encode a pair of video streams > from a stereo camera. A few obvious possibilities present themselves > but are not entirely ideal: > > - Put frames side by side and encode as usual. Macroblock searches > won't find similar blocks from the other camera with a localized > search... This will not make a significant difference to encoding both independently, you are right. > - Interleave left and right frames. If xvid searches more than one > frame back then this would work reasonably well, but I'm pretty sure > it doesn't? And if it did the motion prediction would end up way off, > resulting in suboptimal performance... This might indeed work well with codecs that support more than 1 reference frame (e.g. H.264 aka H.26L aka AVC aka MPEG4v10), but XviD is MPEG4v2 and there it's not possible. I would also strongly advise against hacking the format to support this, because it would need quite some new syntax elements and would be completely incompatible, causing major confusion. > Does anybody have any thoughts about what might be necessary in terms > of code changes to make this work well? My idea was to interleave left and right row by row and test encoding with or without interlaced DCT. You can still access them independently by using a twice as high stride value, and in areas where the displacement is low, it might be beneficial to have both views as close to each other as possible. gruel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Mar 23 09:51:59 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 1DA71126D83 for ; Wed, 23 Mar 2005 09:51:59 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 6180415051; Wed, 23 Mar 2005 09:51:55 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from vsmtp4.tin.it (vsmtp4.tin.it [212.216.176.224]) by edu.bnhof.de (Postfix) with ESMTP id DA28D1504A for ; Wed, 23 Mar 2005 09:51:52 +0100 (CET) Received: from bigclit (213.45.39.111) by vsmtp4.tin.it (7.0.027) (authenticated as luigi.piccarreta@tin.it) id 42384649002DA7FB for xvid-devel@xvid.org; Wed, 23 Mar 2005 09:51:50 +0100 Message-ID: <001b01c52f85$8844c010$6f272dd5@bigclit> From: "Luca Piccarreta" To: References: <4241276B.8060705@math.uni-bonn.de> Subject: Re: [XviD-devel] stereo video streams Date: Wed, 23 Mar 2005 09:51:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.224 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.224 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org You could think of rectifying images before interlacing them. Rectification is a homography (projection) of both images in such a way that corresponding points on both images share the same y-coord. (I'm assuming that you're talking about a calibrated stereo camera) This *might* give you some improvement in coding efficiency. Luca Piccarreta. ----- Original Message ----- From: "Christoph Lampert" To: Sent: Wednesday, March 23, 2005 9:23 AM Subject: Re: [XviD-devel] stereo video streams > Hi, > > > sage weil wrote: > > > Hi, > > > > I'm looking for a way to efficiently encode a pair of video streams > > from a stereo camera. A few obvious possibilities present themselves > > but are not entirely ideal: > > > > - Put frames side by side and encode as usual. Macroblock searches > > won't find similar blocks from the other camera with a localized > > search... > > This will not make a significant difference to encoding both > independently, you are right. > > > - Interleave left and right frames. If xvid searches more than one > > frame back then this would work reasonably well, but I'm pretty sure > > it doesn't? And if it did the motion prediction would end up way off, > > resulting in suboptimal performance... > > This might indeed work well with codecs that support more than 1 > reference frame (e.g. H.264 aka H.26L aka AVC aka MPEG4v10), but XviD is > MPEG4v2 and there it's not possible. I would also strongly advise > against hacking the format to support this, because it would need quite > some new syntax elements and would be completely incompatible, causing > major confusion. > > > Does anybody have any thoughts about what might be necessary in terms > > of code changes to make this work well? > > My idea was to interleave left and right row by row and test encoding > with or without interlaced DCT. You can still access them independently > by using a twice as high stride value, and in areas where the > displacement is low, it might be beneficial to > have both views as close to each other as possible. > > > gruel > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Mar 23 10:07:19 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 613BA126D83 for ; Wed, 23 Mar 2005 10:07:19 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 88E731505E; Wed, 23 Mar 2005 10:07:16 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from s2.stud.uni-goettingen.de (s2.stud.uni-goettingen.de [134.76.60.22]) by edu.bnhof.de (Postfix) with ESMTP id 1EA6E15059 for ; Wed, 23 Mar 2005 10:07:12 +0100 (CET) Received: from p213.54.70.74.tisdip.tiscali.de ([213.54.70.74] helo=[192.168.0.101]) by s2.stud.uni-goettingen.de with asmtp (Exim 4.22) id 1DE1pX-0006Ut-BT for xvid-devel@xvid.org; Wed, 23 Mar 2005 10:07:11 +0100 Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.8.0]); Wed, 23 Mar 2005 10:08:07 +0100 Message-ID: <424131F7.7070207@stud.uni-goettingen.de> Date: Wed, 23 Mar 2005 10:08:07 +0100 From: Dirk Knop User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050320) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xvid-devel@xvid.org Subject: Re: [XviD-devel] stereo video streams References: <4241276B.8060705@math.uni-bonn.de> <001b01c52f85$8844c010$6f272dd5@bigclit> In-Reply-To: <001b01c52f85$8844c010$6f272dd5@bigclit> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi, wouldn't it be safer and equally efficient to just vertically stack the images and strip the images again after decoding? You could use any codec with such a solution then. Cheers Koepi Luca Piccarreta wrote: >You could think of rectifying images before interlacing them. >Rectification is a homography (projection) of both images >in such a way that corresponding points on both images >share the same y-coord. >(I'm assuming that you're talking about a calibrated stereo >camera) >This *might* give you some improvement in coding efficiency. >Luca Piccarreta. > >----- Original Message ----- >From: "Christoph Lampert" >To: >Sent: Wednesday, March 23, 2005 9:23 AM >Subject: Re: [XviD-devel] stereo video streams > > > > >>Hi, >> >> >>sage weil wrote: >> >> >> >>>Hi, >>> >>>I'm looking for a way to efficiently encode a pair of video streams >>>from a stereo camera. A few obvious possibilities present themselves >>>but are not entirely ideal: >>> >>>- Put frames side by side and encode as usual. Macroblock searches >>>won't find similar blocks from the other camera with a localized >>>search... >>> >>> >>This will not make a significant difference to encoding both >>independently, you are right. >> >> >> >>>- Interleave left and right frames. If xvid searches more than one >>>frame back then this would work reasonably well, but I'm pretty sure >>>it doesn't? And if it did the motion prediction would end up way off, >>>resulting in suboptimal performance... >>> >>> >>This might indeed work well with codecs that support more than 1 >>reference frame (e.g. H.264 aka H.26L aka AVC aka MPEG4v10), but XviD is >>MPEG4v2 and there it's not possible. I would also strongly advise >>against hacking the format to support this, because it would need quite >>some new syntax elements and would be completely incompatible, causing >>major confusion. >> >> >> >>>Does anybody have any thoughts about what might be necessary in terms >>>of code changes to make this work well? >>> >>> >>My idea was to interleave left and right row by row and test encoding >>with or without interlaced DCT. You can still access them independently >>by using a twice as high stride value, and in areas where the >>displacement is low, it might be beneficial to >>have both views as close to each other as possible. >> >> >>gruel >> >>_______________________________________________ >>XviD-devel mailing list >>XviD-devel@xvid.org >>http://list.xvid.org/mailman/listinfo/xvid-devel >> >> > >_______________________________________________ >XviD-devel mailing list >XviD-devel@xvid.org >http://list.xvid.org/mailman/listinfo/xvid-devel > > > _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Mar 23 10:21:01 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id CC5F2126D83 for ; Wed, 23 Mar 2005 10:21:01 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 3829515068; Wed, 23 Mar 2005 10:20:48 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from vsmtp3.tin.it (vsmtp3alice.tin.it [212.216.176.143]) by edu.bnhof.de (Postfix) with ESMTP id 833F315065 for ; Wed, 23 Mar 2005 10:20:45 +0100 (CET) Received: from bigclit (213.45.39.111) by vsmtp3.tin.it (7.0.027) (authenticated as luigi.piccarreta@tin.it) id 423ABE9E001EE090 for xvid-devel@xvid.org; Wed, 23 Mar 2005 10:20:42 +0100 Message-ID: <000901c52f89$90b2f740$6f272dd5@bigclit> From: "Luca Piccarreta" To: References: <4241276B.8060705@math.uni-bonn.de><001b01c52f85$8844c010$6f272dd5@bigclit> <424131F7.7070207@stud.uni-goettingen.de> Subject: Re: [XviD-devel] stereo video streams Date: Wed, 23 Mar 2005 10:20:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.224 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.224 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org For sure safer but not much more efficient than coding sequences separately :) Luca. ----- Original Message ----- From: "Dirk Knop" To: Sent: Wednesday, March 23, 2005 10:08 AM Subject: Re: [XviD-devel] stereo video streams > Hi, > > wouldn't it be safer and equally efficient to just vertically stack the > images and strip the images again after decoding? You could use any > codec with such a solution then. > > Cheers > Koepi > > Luca Piccarreta wrote: > > >You could think of rectifying images before interlacing them. > >Rectification is a homography (projection) of both images > >in such a way that corresponding points on both images > >share the same y-coord. > >(I'm assuming that you're talking about a calibrated stereo > >camera) > >This *might* give you some improvement in coding efficiency. > >Luca Piccarreta. > > > >----- Original Message ----- > >From: "Christoph Lampert" > >To: > >Sent: Wednesday, March 23, 2005 9:23 AM > >Subject: Re: [XviD-devel] stereo video streams > > > > > > > > > >>Hi, > >> > >> > >>sage weil wrote: > >> > >> > >> > >>>Hi, > >>> > >>>I'm looking for a way to efficiently encode a pair of video streams > >>>from a stereo camera. A few obvious possibilities present themselves > >>>but are not entirely ideal: > >>> > >>>- Put frames side by side and encode as usual. Macroblock searches > >>>won't find similar blocks from the other camera with a localized > >>>search... > >>> > >>> > >>This will not make a significant difference to encoding both > >>independently, you are right. > >> > >> > >> > >>>- Interleave left and right frames. If xvid searches more than one > >>>frame back then this would work reasonably well, but I'm pretty sure > >>>it doesn't? And if it did the motion prediction would end up way off, > >>>resulting in suboptimal performance... > >>> > >>> > >>This might indeed work well with codecs that support more than 1 > >>reference frame (e.g. H.264 aka H.26L aka AVC aka MPEG4v10), but XviD is > >>MPEG4v2 and there it's not possible. I would also strongly advise > >>against hacking the format to support this, because it would need quite > >>some new syntax elements and would be completely incompatible, causing > >>major confusion. > >> > >> > >> > >>>Does anybody have any thoughts about what might be necessary in terms > >>>of code changes to make this work well? > >>> > >>> > >>My idea was to interleave left and right row by row and test encoding > >>with or without interlaced DCT. You can still access them independently > >>by using a twice as high stride value, and in areas where the > >>displacement is low, it might be beneficial to > >>have both views as close to each other as possible. > >> > >> > >>gruel > >> > >>_______________________________________________ > >>XviD-devel mailing list > >>XviD-devel@xvid.org > >>http://list.xvid.org/mailman/listinfo/xvid-devel > >> > >> > > > >_______________________________________________ > >XviD-devel mailing list > >XviD-devel@xvid.org > >http://list.xvid.org/mailman/listinfo/xvid-devel > > > > > > > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Mar 23 10:40:33 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id D5FB1126D83 for ; Wed, 23 Mar 2005 10:40:33 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 1AF4015072; Wed, 23 Mar 2005 10:40:29 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from s2.stud.uni-goettingen.de (s2.stud.uni-goettingen.de [134.76.60.22]) by edu.bnhof.de (Postfix) with ESMTP id AB05A1506E for ; Wed, 23 Mar 2005 10:40:26 +0100 (CET) Received: from p213.54.70.74.tisdip.tiscali.de ([213.54.70.74] helo=[192.168.0.101]) by s2.stud.uni-goettingen.de with asmtp (Exim 4.22) id 1DE2Lh-00035l-Dr for xvid-devel@xvid.org; Wed, 23 Mar 2005 10:40:25 +0100 Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.8.0]); Wed, 23 Mar 2005 10:41:21 +0100 Message-ID: <424139C1.20807@stud.uni-goettingen.de> Date: Wed, 23 Mar 2005 10:41:21 +0100 From: Dirk Knop User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050320) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xvid-devel@xvid.org Subject: Re: [XviD-devel] stereo video streams References: <4241276B.8060705@math.uni-bonn.de><001b01c52f85$8844c010$6f272dd5@bigclit> <424131F7.7070207@stud.uni-goettingen.de> <000901c52f89$90b2f740$6f272dd5@bigclit> In-Reply-To: <000901c52f89$90b2f740$6f272dd5@bigclit> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi again, ok, right :-) How about interleaving the frames like this: - cam 1: =A - cam 2: =B A1 B1 A2 B2... so you don't use real interlaced frames but "sequentially interlaced" ones. If I'm not mistaken, the difference in two images for stereoscopic targets isn't really much, you could describe it as a angle-rotation on the z-axis with a small "residue error" - sounds like GMC can be of help here. At least it's worth testing that I think. Cheers Koepi Luca Piccarreta wrote: >For sure safer but not much more efficient than coding >sequences separately :) >Luca. > >----- Original Message ----- >From: "Dirk Knop" >To: >Sent: Wednesday, March 23, 2005 10:08 AM >Subject: Re: [XviD-devel] stereo video streams > > > > >>Hi, >> >>wouldn't it be safer and equally efficient to just vertically stack the >>images and strip the images again after decoding? You could use any >>codec with such a solution then. >> >>Cheers >>Koepi >> >> _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Mar 23 12:16:43 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id F21DE126D83 for ; Wed, 23 Mar 2005 12:16:42 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id E3C5713E45; Wed, 23 Mar 2005 12:16:38 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by edu.bnhof.de (Postfix) with ESMTP id DE6E5D9AB for ; Wed, 23 Mar 2005 12:16:35 +0100 (CET) Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DE3ql-00021G-00 for xvid-devel@xvid.org; Wed, 23 Mar 2005 12:16:35 +0100 Received: from [217.231.188.247] (helo=[10.0.0.2]) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1DE3ql-0004j7-00 for xvid-devel@xvid.org; Wed, 23 Mar 2005 12:16:35 +0100 Message-ID: <4241500E.1060400@lucas-berlin.de> Date: Wed, 23 Mar 2005 12:16:30 +0100 From: Jan Lucas User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: xvid-devel@xvid.org Subject: Re: [XviD-devel] stereo video streams References: <4241276B.8060705@math.uni-bonn.de><001b01c52f85$8844c010$6f272dd5@bigclit> <424131F7.7070207@stud.uni-goettingen.de> <000901c52f89$90b2f740$6f272dd5@bigclit> In-Reply-To: <000901c52f89$90b2f740$6f272dd5@bigclit> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:f34d8fd11200caf8bbb9b302dc0548d9 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Luca Piccarreta schrieb: > For sure safer but not much more efficient than coding > sequences separately :) 1) Rectify the images 2) Code the left image into one stream 3) Search for block translation due to disparity (like a motion search, limited to x-motion) 4) Predict the right image using your left image and subtract from the right image 5) Code the residue in another stream Sure, it is more work than a simple interleaving scheme, but should also be pretty effective. Jan _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Mar 24 03:53:41 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 4A463126D83 for ; Thu, 24 Mar 2005 03:53:41 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 4844E1509A; Thu, 24 Mar 2005 03:53:36 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from dintop.com (unknown [211.155.234.103]) by edu.bnhof.de (Postfix) with ESMTP id 1B27715096 for ; Thu, 24 Mar 2005 03:53:28 +0100 (CET) Received: from ARTHUR [220.184.140.106] by dintop.com with ESMTP (SMTPD32-7.14) id ABFE14801B6; Thu, 24 Mar 2005 10:54:54 +0800 Message-ID: <005601c5301c$a441a430$1400a8c0@ARTHUR> From: To: References: <4241276B.8060705@math.uni-bonn.de><001b01c52f85$8844c010$6f272dd5@bigclit> <424131F7.7070207@stud.uni-goettingen.de><000901c52f89$90b2f740$6f272dd5@bigclit> <4241500E.1060400@lucas-berlin.de> Date: Thu, 24 Mar 2005 10:53:22 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [XviD-devel] Questions on Quantization X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2012115384==" Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org --===============2012115384== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 RGVhciBFeHBlcnRzLA0KDQpJJ20gc3R1ZGluZyB4dmlkY29yZS0xLjEuMC1iZXRhMSBhbmQgaGFz IGJlbG93IHF1ZXN0aW9ucyBvbiBxdWF0aXphdGlvbjoNCg0KMSkgVGhlIGltcGxlbWVudGF0aW9u IG9mIEguMjYzIHF1YW50aXphdGlvbiBtZXRob2QgaW4geHZpZGNvcmUgaXMgYmFzZWQgb24gTjM5 ODAgc3RhbmRhcmQsIGJ1dCB0aGlzIG1ldGhvZCBoYXMgYmVlbiByZXZpc2VkIGZyb20gTjM5MDgg dG8gTjQzNTAuIFRoYXQgaXMsIHh2aWRjb3JlIGlzbid0IGluY29tcGxpYW50IHRvIGxhdGVzdCBz dGFuZGFyZC4gQXMgYSByZXN1bHQsIHRoZSBkZWNvZGVyIHdpdGggeHZpZGNvcmUgbWF5IGhhcyBy ZWFzb25sZXNzIHN1YmplY3RpdmUgcGVyZm9ybWFuY2UgdG8gcGxheWJhY2sgc3VjaCBiaXRzdHJl YW1zIGVuY29kZWQgYnkgbm9uLXh2aWQgZW5jb2RlcnMuIEFuZCB0aGVuIGhvdyB0byBpbXBsZW1l bnQgYW4gc2VsZi1hZGFwdGl2ZSBxdWFudGl6YXRpb24gaW4gZGVjb2RlciBzaWRlIHRvIHN1cHBv cnQgdGhlIGJvdGggbWV0aG9kcz8NCg0KMikgQWNjb3JkaW5nIHRvIHRoZSBpbXBsZW1lbnRhdGlv biBvZiBNUEVHIHF1YW50aXphdGlvbiBtZXRob2QgaW4geHZpZGNvcmUsIHRoZSBtaXNtYXRjaCBj b250cm9sIGlzbid0IHBlcmZvcm1lZCBmb3IgaW50cmEtYmxvY2suIFdoeT8gVGhlIG1pc21hdGNo IGNvbnRyb2wgc2hvdWxkIGJlIHBlcmZvcm1lZCBmb3IgYm90aCBpbnRlci1ibG9jayBhbmQgaW50 cmEtYmxvY2sgYWNjb3JkaW5nIHRvIHRoZSBzdGFuZGFyZCdzIGRlc2NyaXB0aW9uLg0KDQpUaGFu a3MsIEJlc3QgUmVnYXJkcywNCkFydGh1cg== --===============2012115384== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel --===============2012115384==-- From xvid-devel-bounces@xvid.org Thu Mar 24 07:26:00 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 5B8E0126D83 for ; Thu, 24 Mar 2005 07:25:49 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id D047C1502C; Thu, 24 Mar 2005 07:25:36 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from dintop.com (unknown [211.155.234.103]) by edu.bnhof.de (Postfix) with ESMTP id 820B915029 for ; Thu, 24 Mar 2005 07:25:27 +0100 (CET) Received: from ARTHUR [220.184.140.106] by dintop.com with ESMTP (SMTPD32-7.14) id ADB22BB01CC; Thu, 24 Mar 2005 14:26:58 +0800 Message-ID: <00ba01c5303a$44a8d980$1400a8c0@ARTHUR> From: To: References: <4241276B.8060705@math.uni-bonn.de><001b01c52f85$8844c010$6f272dd5@bigclit> <424131F7.7070207@stud.uni-goettingen.de><000901c52f89$90b2f740$6f272dd5@bigclit><4241500E.1060400@lucas-berlin.de> <005601c5301c$a441a430$1400a8c0@ARTHUR> Subject: Re: [XviD-devel] Questions on Quantization Date: Thu, 24 Mar 2005 14:25:26 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1831745983==" Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org --===============1831745983== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 RGVhciBFeHBlcnRzLA0KDQpJJ20gdmVyeSBzb3JyeS4gSSBmb3VuZCBJIGhhZCBtaXN1bmRlcnN0 b29kIHRoZSBzdGFuZGFyZC4gVGhlIGZpcnN0IHF1ZXN0aW9uIGlzbid0IGEgcXVlc3Rpb24uIFBs ZWFzZSBqdXN0IGlnbm9yZSBpdC4gSSdtIHZlcnkgc29ycnkgZm9yIHRoaXMgdHJvdWJsZS4gQnV0 IGNvdWxkIHlvdSBnaXZlIG1lIHlvdXIgaGFuZCBvbiB0aGUgc2Vjb25kIHF1ZXN0aW9uPw0KDQpU aGFua3MgJiBCZXN0IFJlZ2FyZHMsDQpBcnRodXINCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0gDQpGcm9tOiA8QXJ0aHVyLkppYW5nQGRpbnRvcC5jb20+DQpUbzogPHh2aWQtZGV2ZWxAeHZp ZC5vcmc+DQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMjQsIDIwMDUgMTA6NTMgQU0NClN1YmplY3Q6 IFtYdmlELWRldmVsXSBRdWVzdGlvbnMgb24gUXVhbnRpemF0aW9uDQoNCg0KPiBEZWFyIEV4cGVy dHMsDQo+IA0KPiBJJ20gc3R1ZGluZyB4dmlkY29yZS0xLjEuMC1iZXRhMSBhbmQgaGFzIGJlbG93 IHF1ZXN0aW9ucyBvbiBxdWF0aXphdGlvbjoNCj4gDQo+IDEpIFRoZSBpbXBsZW1lbnRhdGlvbiBv ZiBILjI2MyBxdWFudGl6YXRpb24gbWV0aG9kIGluIHh2aWRjb3JlIGlzIGJhc2VkIG9uIE4zOTgw IHN0YW5kYXJkLCBidXQgdGhpcyBtZXRob2QgaGFzIGJlZW4gcmV2aXNlZCBmcm9tIE4zOTA4IHRv IE40MzUwLiBUaGF0IGlzLCB4dmlkY29yZSBpc24ndCBpbmNvbXBsaWFudCB0byBsYXRlc3Qgc3Rh bmRhcmQuIEFzIGEgcmVzdWx0LCB0aGUgZGVjb2RlciB3aXRoIHh2aWRjb3JlIG1heSBoYXMgcmVh c29ubGVzcyBzdWJqZWN0aXZlIHBlcmZvcm1hbmNlIHRvIHBsYXliYWNrIHN1Y2ggYml0c3RyZWFt cyBlbmNvZGVkIGJ5IG5vbi14dmlkIGVuY29kZXJzLiBBbmQgdGhlbiBob3cgdG8gaW1wbGVtZW50 IGFuIHNlbGYtYWRhcHRpdmUgcXVhbnRpemF0aW9uIGluIGRlY29kZXIgc2lkZSB0byBzdXBwb3J0 IHRoZSBib3RoIG1ldGhvZHM/DQo+IA0KPiAyKSBBY2NvcmRpbmcgdG8gdGhlIGltcGxlbWVudGF0 aW9uIG9mIE1QRUcgcXVhbnRpemF0aW9uIG1ldGhvZCBpbiB4dmlkY29yZSwgdGhlIG1pc21hdGNo IGNvbnRyb2wgaXNuJ3QgcGVyZm9ybWVkIGZvciBpbnRyYS1ibG9jay4gV2h5PyBUaGUgbWlzbWF0 Y2ggY29udHJvbCBzaG91bGQgYmUgcGVyZm9ybWVkIGZvciBib3RoIGludGVyLWJsb2NrIGFuZCBp bnRyYS1ibG9jayBhY2NvcmRpbmcgdG8gdGhlIHN0YW5kYXJkJ3MgZGVzY3JpcHRpb24uDQo+IA0K PiBUaGFua3MsIEJlc3QgUmVnYXJkcywNCj4gQXJ0aHVyDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IFh2aUQtZGV2ZWwgbWFpbGluZyBsaXN0DQo+IFh2aUQtZGV2ZWxAeHZpZC5vcmcNCj4g aHR0cDovL2xpc3QueHZpZC5vcmcvbWFpbG1hbi9saXN0aW5mby94dmlkLWRldmVsDQo+IA== --===============1831745983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel --===============1831745983==-- From xvid-devel-bounces@xvid.org Thu Mar 24 10:35:12 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 27C08126D83 for ; Thu, 24 Mar 2005 10:35:12 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id BAAE88E96; Thu, 24 Mar 2005 10:34:57 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from ftp.ilog.fr (ftp.ilog.fr [81.80.162.195]) by edu.bnhof.de (Postfix) with ESMTP id B2B01896B for ; Thu, 24 Mar 2005 10:34:51 +0100 (CET) Received: from laposte.ilog.fr (cerbere-qfe0 [81.80.162.193]) by ftp.ilog.fr (8.13.3/8.13.3) with ESMTP id j2O9YegX000789 for ; Thu, 24 Mar 2005 10:34:41 +0100 (MET) Received: from marbore.ilog.biz (marbore1.ilog.fr [172.17.2.61]) by laposte.ilog.fr (8.13.1/8.13.1) with ESMTP id j2O9YZEU003569 for ; Thu, 24 Mar 2005 10:34:35 +0100 (MET) Received: from parmbx01.ilog.biz ([172.17.2.64]) by marbore.ilog.biz with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 10:35:27 +0100 Received: from 6ttgg1j ([172.17.4.73]) by parmbx01.ilog.biz with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 10:35:27 +0100 Subject: Re: [XviD-devel] Questions on Quantization From: Skal To: xvid-devel@xvid.org In-Reply-To: <005601c5301c$a441a430$1400a8c0@ARTHUR> References: <4241276B.8060705@math.uni-bonn.de><001b01c52f85$8844c010$6f272dd5@bigclit> <424131F7.7070207@stud.uni-goettingen.de> <000901c52f89$90b2f740$6f272dd5@bigclit> <4241500E.1060400@lucas-berlin.de> <005601c5301c$a441a430$1400a8c0@ARTHUR> Content-Type: text/plain Message-Id: <1111656913.3388.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) Date: Thu, 24 Mar 2005 10:35:13 +0100 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2005 09:35:27.0464 (UTC) FILETIME=[CFFAE680:01C53054] X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi Arthur, On Thu, 2005-03-24 at 03:53, Arthur.Jiang@dintop.com wrote: > > 2) According to the implementation of MPEG quantization method in xvidcore, > > the mismatch control isn't performed for intra-block. Why? > The mismatch control should be performed for both inter-block and intra-block according to the standard's description. two remarks: you should be precise about what 'standard' you are referring to. MPEG-2 (ISO 13818-2) do have mismatch control for Intra, but MPEG-4 (ISO 14496-2) hasn't. Only inter dequantization needs it. Moreover: you are talking about *quantization*, not *dequantization*, right? In such case (quantization. that is: the encoder), one is free to do anything he wants during quantization (including feeding the matrix with random numbers;). And taking the mismatch-controlled coefficient #63 into account for RD-opt, e.g, really isn't worth the hassle. hope it helps, Skal _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Mar 24 12:22:43 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 1D580126D83 for ; Thu, 24 Mar 2005 12:22:43 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 112F9D969; Thu, 24 Mar 2005 12:22:39 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from vsmtp1.tin.it (vsmtp1.tin.it [212.216.176.141]) by edu.bnhof.de (Postfix) with ESMTP id 868F0C176 for ; Thu, 24 Mar 2005 12:22:34 +0100 (CET) Received: from bigclit (213.45.39.15) by vsmtp1.tin.it (7.0.027) (authenticated as luigi.piccarreta@tin.it) id 4238611B0036DC91 for xvid-devel@xvid.org; Thu, 24 Mar 2005 12:22:27 +0100 Message-ID: <001601c53063$bb49f910$0f272dd5@bigclit> From: "Luca Piccarreta" To: References: <4241276B.8060705@math.uni-bonn.de><001b01c52f85$8844c010$6f272dd5@bigclit><424131F7.7070207@stud.uni-goettingen.de><000901c52f89$90b2f740$6f272dd5@bigclit><4241500E.1060400@lucas-berlin.de><005601c5301c$a441a430$1400a8c0@ARTHUR> <1111656913.3388.10.camel@localhost.localdomain> Subject: Re: [XviD-devel] Questions on Quantization Date: Thu, 24 Mar 2005 12:22:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.224 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.224 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi Skal, Are you sure about what you said about Intra DCT Mismatch Control? I checked the MS ref sw (W4866) and it looks like mismatch control for intra dct is there (see inverseQuantizeIntraDCTcoefMPEG). Of course it's not there for H263 Quant Type (see inverseQuantizeDCTcoefH263). I'm also checking the latest 14496/2 I have available (N5546,March 2003) and I can't see anything about different mismatch control for Intra DCT. Now, for my personal opinion, I think that the whole float DCT stuff is crazy, mismatch control is crazy, long live integer-defined transform and bit exact conformance :) And of course the impact of not having mismatch control for Intra frames is almost null. Regards, Luca Piccarreta. ----- Original Message ----- From: "Skal" To: Sent: Thursday, March 24, 2005 10:35 AM Subject: Re: [XviD-devel] Questions on Quantization > > Hi Arthur, > > On Thu, 2005-03-24 at 03:53, Arthur.Jiang@dintop.com wrote: > > > > > 2) According to the implementation of MPEG quantization method in xvidcore, > > > > the mismatch control isn't performed for intra-block. Why? > > > The mismatch control should be performed for both inter-block and intra-block according to the standard's description. > > two remarks: > > you should be precise about what 'standard' you are referring to. > MPEG-2 (ISO 13818-2) do have mismatch control for Intra, but MPEG-4 > (ISO 14496-2) hasn't. Only inter dequantization needs it. > > Moreover: you are talking about *quantization*, not > *dequantization*, right? In such case (quantization. > that is: the encoder), one is free to do anything he > wants during quantization (including feeding the matrix > with random numbers;). And taking the mismatch-controlled > coefficient #63 into account for RD-opt, e.g, really isn't > worth the hassle. > > hope it helps, > Skal > > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Mar 24 14:06:47 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id D6329126D83 for ; Thu, 24 Mar 2005 14:06:47 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id BF51614638; Thu, 24 Mar 2005 14:06:43 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from ftp.ilog.fr (ftp.ilog.fr [81.80.162.195]) by edu.bnhof.de (Postfix) with ESMTP id 8FFF5140AD for ; Thu, 24 Mar 2005 14:06:35 +0100 (CET) Received: from laposte.ilog.fr (cerbere-qfe0 [81.80.162.193]) by ftp.ilog.fr (8.13.3/8.13.3) with ESMTP id j2OD6YOg008464 for ; Thu, 24 Mar 2005 14:06:34 +0100 (MET) Received: from marbore.ilog.biz (marbore1.ilog.fr [172.17.2.61]) by laposte.ilog.fr (8.13.1/8.13.1) with ESMTP id j2OD6T4v014426 for ; Thu, 24 Mar 2005 14:06:29 +0100 (MET) Received: from parmbx01.ilog.biz ([172.17.2.64]) by marbore.ilog.biz with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 14:07:23 +0100 Received: from 6ttgg1j ([172.17.4.73]) by parmbx01.ilog.biz with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Mar 2005 14:07:10 +0100 Subject: Re: [XviD-devel] Questions on Quantization From: Skal To: xvid-devel@xvid.org In-Reply-To: <001601c53063$bb49f910$0f272dd5@bigclit> References: <4241276B.8060705@math.uni-bonn.de><001b01c52f85$8844c010$6f272dd5@bigclit> <424131F7.7070207@stud.uni-goettingen.de> <000901c52f89$90b2f740$6f272dd5@bigclit><4241500E.1060400@lucas-berlin.de> <005601c5301c$a441a430$1400a8c0@ARTHUR> <1111656913.3388.10.camel@localhost.localdomain> <001601c53063$bb49f910$0f272dd5@bigclit> Content-Type: text/plain Message-Id: <1111669626.5323.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) Date: Thu, 24 Mar 2005 14:07:06 +0100 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2005 13:07:10.0810 (UTC) FILETIME=[63C3ABA0:01C53072] X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi Luca (nice to see you here;) On Thu, 2005-03-24 at 12:22, Luca Piccarreta wrote: > Hi Skal, > Are you sure about what you said about Intra DCT Mismatch Control? > I checked the MS ref sw (W4866) and it looks like mismatch control > for intra dct is there (see inverseQuantizeIntraDCTcoefMPEG). > Of course it's not there for H263 Quant Type > (see inverseQuantizeDCTcoefH263). > I'm also checking the latest 14496/2 I have available (N5546,March 2003) > and I can't see anything about different mismatch control for Intra DCT. Oops, you're right! Xvid is lacking mismatch control for MPEG4 intra-dequant. And it's been so since a loooong time! (as long as i can recall, actually) > Now, for my personal opinion, I think that the whole float DCT stuff is > crazy, mismatch control is crazy, long live integer-defined transform and > bit exact conformance :) Fully agreed. Carving in stone some fixed 16bits (or 8bits, even) coeffs for the iDCT in MPEG2/4 would have saved a lot of troubles, instead of opening the luring floating-point Pandora box. > And of course the impact of not having mismatch control for Intra frames > is almost null. Well, i'm not sure (until i test it). Correcting this mistake in XviD would be easy, but i fear it might slightly break decoding of previously encoded material: one might notice a faint chessboard effect on intra blocks, due to the toggling of coeff #63. Any opinion? later! Skal _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Mar 24 14:24:30 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id E7468126D83 for ; Thu, 24 Mar 2005 14:24:29 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 5358E14FA8; Thu, 24 Mar 2005 14:24:26 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by edu.bnhof.de (Postfix) with ESMTP id A279114BC1 for ; Thu, 24 Mar 2005 14:24:22 +0100 (CET) Received: from imp4-q.free.fr (imp4-q.free.fr [212.27.42.4]) by postfix3-2.free.fr (Postfix) with ESMTP id 6DDF3C135 for ; Thu, 24 Mar 2005 14:24:22 +0100 (CET) Received: by imp4-q.free.fr (Postfix, from userid 33) id 6427B31AA7; Thu, 24 Mar 2005 14:24:22 +0100 (MET) Received: from 195.101.164.35 ([195.101.164.35]) by imp4-q.free.fr (IMP) with HTTP for ; Thu, 24 Mar 2005 14:24:22 +0100 Message-ID: <1111670662.4242bf865c84c@imp4-q.free.fr> Date: Thu, 24 Mar 2005 14:24:22 +0100 From: Edouard Gomez To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Questions on Quantization References: <4241276B.8060705@math.uni-bonn.de><001b01c52f85$8844c010$6f272dd5@bigclit> <424131F7.7070207@stud.uni-goettingen.de> <000901c52f89$90b2f740$6f272dd5@bigclit><4241500E.1060400@lucas-berlin.de> <005601c5301c$a441a430$1400a8c0@ARTHUR> <1111656913.3388.10.camel@localhost.localdomain> <001601c53063$bb49f910$0f272dd5@bigclit> <1111669626.5323.8.camel@localhost.localdomain> In-Reply-To: <1111669626.5323.8.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 195.101.164.35 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Selon Skal : > Oops, you're right! Xvid is lacking mismatch control > for MPEG4 intra-dequant. And it's been so since a > loooong time! (as long as i can recall, actually) > When refactoring the quantization functions, i remember chocking on this mismatch control for intra also, but i think we have based xvid on outdated MPEG4 Part2 standard. Personnaly i used ISO 14496-2 2001 Edition for all the reviews i've done, and there was no mismatch control for intra blocks decoding. If other xvid devs used the same version of the standard, i'm pretty sure it would explain why we lack this mismatch control. I can double check my says late this night when i'll be home. -- Edouard Gomez _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Mar 24 14:46:49 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 22A58126D83 for ; Thu, 24 Mar 2005 14:46:49 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 32B25135E9; Thu, 24 Mar 2005 14:46:45 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from s5.lansco.de (s5.lansco.de [212.63.130.170]) by edu.bnhof.de (Postfix) with ESMTP id CAA4712268 for ; Thu, 24 Mar 2005 14:46:43 +0100 (CET) Received: from localhost (s5.lansco.de [212.63.130.170]) by s5.lansco.de (Postfix) with ESMTP id DA0A39E14 for ; Thu, 24 Mar 2005 14:46:42 +0100 (CET) Received: from pD9539CB0.dip.t-dialin.net (pD9539CB0.dip.t-dialin.net [217.83.156.176]) by www.lansco.de (IMP) with HTTP for ; Thu, 24 Mar 2005 14:46:42 +0100 Message-ID: <1111672002.4242c4c2a98b3@www.lansco.de> Date: Thu, 24 Mar 2005 14:46:42 +0100 From: Michael Militzer To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Questions on Quantization References: <4241276B.8060705@math.uni-bonn.de><001b01c52f85$8844c010$6f272dd5@bigclit> <424131F7.7070207@stud.uni-goettingen.de> <000901c52f89$90b2f740$6f272dd5@bigclit><4241500E.1060400@lucas-berlin.de> <005601c5301c$a441a430$1400a8c0@ARTHUR> <1111656913.3388.10.camel@localhost.localdomain> <001601c53063$bb49f910$0f272dd5@bigclit> <1111669626.5323.8.camel@localhost.localdomain> <1111670662.4242bf865c84c@imp4-q.free.fr> In-Reply-To: <1111670662.4242bf865c84c@imp4-q.free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 217.83.156.176 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi, I'm not sure but I think we even had mismatch control for intra dequant in very early versions but it had been removed for some reason - Pete? Michael Quoting Edouard Gomez : > Selon Skal : > > Oops, you're right! Xvid is lacking mismatch control > > for MPEG4 intra-dequant. And it's been so since a > > loooong time! (as long as i can recall, actually) > > > > When refactoring the quantization functions, i remember chocking on this > mismatch control for intra also, but i think we have based xvid on outdated > MPEG4 Part2 standard. > > Personnaly i used ISO 14496-2 2001 Edition for all the reviews i've done, > and > there was no mismatch control for intra blocks decoding. If other xvid devs > used the same version of the standard, i'm pretty sure it would explain why > we > lack this mismatch control. > > I can double check my says late this night when i'll be home. > > -- > Edouard Gomez > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel > _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Mar 24 14:57:00 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 4D9A7126D83 for ; Thu, 24 Mar 2005 14:57:00 +0100 (CET) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id EE70A13EBD; Thu, 24 Mar 2005 14:56:56 +0100 (CET) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from centomila.elet.polimi.it (centomila.elet.polimi.it [131.175.120.12]) by edu.bnhof.de (Postfix) with ESMTP id 315EC13EB0 for ; Thu, 24 Mar 2005 14:56:53 +0100 (CET) Received: from localhost (centomila.elet.polimi.it [127.0.0.1]) by centomila.elet.polimi.it (Postfix) with ESMTP id E161B1388F for ; Thu, 24 Mar 2005 14:56:50 +0100 (CET) Received: from centomila.elet.polimi.it ([127.0.0.1]) by localhost (centomila.elet.polimi.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32045-02 for ; Thu, 24 Mar 2005 14:56:48 +0100 (CET) Received: from piccarreta (piccarreta.elet.polimi.it [131.175.18.42]) by centomila.elet.polimi.it (Postfix) with ESMTP id 409591388D for ; Thu, 24 Mar 2005 14:56:48 +0100 (CET) Message-ID: <001401c53079$56a35d10$2a12af83@piccarreta> From: "Luca Piccarreta" To: References: <4241276B.8060705@math.uni-bonn.de><001b01c52f85$8844c010$6f272dd5@bigclit><424131F7.7070207@stud.uni-goettingen.de><000901c52f89$90b2f740$6f272dd5@bigclit><4241500E.1060400@lucas-berlin.de><005601c5301c$a441a430$1400a8c0@ARTHUR><1111656913.3388.10.camel@localhost.localdomain><001601c53063$bb49f910$0f272dd5@bigclit> <1111669626.5323.8.camel@localhost.localdomain> Subject: Re: [XviD-devel] Questions on Quantization Date: Thu, 24 Mar 2005 14:56:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.224 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.224 X-Virus-Scanned: by amavisd-new-20030616-p10 at elet.polimi.it X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi Skal, don't be so frightened... that 1 value on the 63th coefficient it's not visible... I don't have floating point iDCT here, but it should be something like a +1/16,-1/16 grid. The objective should be "waking up" the iDCT as to avoid situations in which small varying blocks are coded with some DCT coefficients, but the encoder side iDCT transforms to a null block...at the decoder side, another iDCT might decode to a non null block, and after a while, very visible drifts appear. (I can't really hope I was clear). Actually, this situation is true only for very low QPs (1,2...) If you come up with some numbers/results (I'm not sure about that 1/16), let me know.... Ciao, Luca. ----- Original Message ----- From: "Skal" To: Sent: Thursday, March 24, 2005 2:07 PM Subject: Re: [XviD-devel] Questions on Quantization > > Hi Luca (nice to see you here;) > > On Thu, 2005-03-24 at 12:22, Luca Piccarreta wrote: > > Hi Skal, > > Are you sure about what you said about Intra DCT Mismatch Control? > > I checked the MS ref sw (W4866) and it looks like mismatch control > > for intra dct is there (see inverseQuantizeIntraDCTcoefMPEG). > > Of course it's not there for H263 Quant Type > > (see inverseQuantizeDCTcoefH263). > > I'm also checking the latest 14496/2 I have available (N5546,March 2003) > > and I can't see anything about different mismatch control for Intra DCT. > > Oops, you're right! Xvid is lacking mismatch control > for MPEG4 intra-dequant. And it's been so since a > loooong time! (as long as i can recall, actually) > > > Now, for my personal opinion, I think that the whole float DCT stuff is > > crazy, mismatch control is crazy, long live integer-defined transform and > > bit exact conformance :) > > Fully agreed. Carving in stone some fixed 16bits (or 8bits, > even) coeffs for the iDCT in MPEG2/4 would have saved a lot > of troubles, instead of opening the luring floating-point > Pandora box. > > > And of course the impact of not having mismatch control for Intra frames > > is almost null. > > Well, i'm not sure (until i test it). Correcting this mistake > in XviD would be easy, but i fear it might slightly break > decoding of previously encoded material: one might notice a > faint chessboard effect on intra blocks, due to the toggling > of coeff #63. Any opinion? > > > later! > Skal > > > _______________________________________________ > XviD-devel mailing list > XviD-devel@xvid.org > http://list.xvid.org/mailman/listinfo/xvid-devel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Mon Mar 28 04:42:21 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 63EB1126D83 for ; Mon, 28 Mar 2005 04:42:21 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 7B74215002; Mon, 28 Mar 2005 04:42:13 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from MAIL.yulong.com (unknown [210.75.16.21]) by edu.bnhof.de (Postfix) with ESMTP id C66EA14FFE for ; Mon, 28 Mar 2005 04:41:58 +0200 (CEST) Received: from dengxiongshu ([128.1.4.26]) by MAIL.yulong.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Mar 2005 10:42:14 +0800 Message-ID: <005601c5333f$c109d350$1a040180@dengxiongshu> From: =?gb2312?B?tcvQ28rp?= To: Subject: [XviD-devel] Questions on Dquant Date: Mon, 28 Mar 2005 10:42:16 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 28 Mar 2005 02:42:14.0819 (UTC) FILETIME=[C0107F30:01C5333F] X-Content-Filtered-By: Mailman/MimeDel 2.1.4 X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0968109426==" Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org This is a multi-part message in MIME format. --===============0968109426== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 ZGVhciAxNDQ5Ni0yIGV4cGVydDoNCg0KICAgIEkgZmluZCBvbmx5IFdoZW4gbWFjcm8gdHlwZSBp cyBpbnRlcitxIGFuZCBpbnRyYStxIGNhbiB3cml0ZSBkcXVhbnQgdmFsdWUgaW4gbXBlZzQgcGFy dCAyIHN0YW5kYXJkLHNvIHdoZW4gbWFjcm8gdHlwZSBpcyBpbnRlcjR2IGNhbid0IHdyaXRlIGRx dWFudCB2YWx1ZSBiZWNhdXNlIGhhdmUgbm90IGludGVyNHYrcSBtYWNybyBtb2RlICx0aGF0IGlz IHRvIHNheSB3aGVuIG1hY3JvIGhhdmUgZm91ciBtb3Rpb24gdmVjdG9yICxpdCBjYW4gbm90IGNo YW5nZSBxdWFudCB2YWx1ZS4gU28gSSB3YXMgcXVlc3Rpb24gaG93IGNhbiBpbXBsZW1lbnQgbWFj cm8gbGV2ZWwgcmF0ZSBjb250cm9sIHdoZW4gYSBmcmFtZSBoYXZlIGEgbG90IGludGVyNHYgbWFj cm8/IEhhdmUgSSBtaXN1bmRlcnN0b29kIDE0NDk2LTIgc3RhbmRhcmQ/IEJ1dCBJIGZpbmQgeHZp ZCB3cml0ZSBkcXVhbnQgYW5kIGRlY29kZSBkcXVhbnQgYXMgYWJvdmUuIEFuZCBILjI2NCBjYW4g Y2hhbmdlIHF1YW50IGV2ZW4gaW4gNKHBNCBibG9jayAuQ2FuIHNvbWVib2R5IGFuc3dlciBteSBx dWVzdGlvbj8NCg0KdGhhbmtzDQoNCnhpb25nc2h1IGRlbmcNCg0KIA0K --===============0968109426== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel --===============0968109426==-- From xvid-devel-bounces@xvid.org Mon Mar 28 04:48:32 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 4E6B8126D83 for ; Mon, 28 Mar 2005 04:48:32 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 4159815009; Mon, 28 Mar 2005 04:48:29 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from MAIL.yulong.com (unknown [210.75.16.21]) by edu.bnhof.de (Postfix) with ESMTP id 76ADF15001 for ; Mon, 28 Mar 2005 04:48:20 +0200 (CEST) Received: from dengxiongshu ([128.1.4.26]) by MAIL.yulong.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Mar 2005 10:48:52 +0800 Message-ID: <001c01c53340$ae140bc0$1a040180@dengxiongshu> From: =?utf-8?B?6YKT6ZuE5Lmm?= To: Date: Mon, 28 Mar 2005 10:48:54 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 28 Mar 2005 02:48:52.0512 (UTC) FILETIME=[AD1BA200:01C53340] X-Content-Filtered-By: Mailman/MimeDel 2.1.4 Subject: [XviD-devel] question on dquant X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1877401822==" Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org This is a multi-part message in MIME format. --===============1877401822== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpkZWFyIDE0NDk2LTIgZXhwZXJ0Og0KDQogICAgSSBmaW5kIG9ubHkgV2hlbiBtYWNybyB0eXBl IGlzIGludGVyK3EgYW5kIGludHJhK3EgY2FuIHdyaXRlIGRxdWFudCB2YWx1ZSBpbiBtcGVnNCBw YXJ0IDIgc3RhbmRhcmQsc28gd2hlbiBtYWNybyB0eXBlIGlzIGludGVyNHYgY2FuJ3Qgd3JpdGUg ZHF1YW50IHZhbHVlIGJlY2F1c2UgaGF2ZSBub3QgaW50ZXI0ditxIG1hY3JvIG1vZGUgLHRoYXQg aXMgdG8gc2F5IHdoZW4gbWFjcm8gaGF2ZSBmb3VyIG1vdGlvbiB2ZWN0b3IgLGl0IGNhbiBub3Qg Y2hhbmdlIHF1YW50IHZhbHVlLiBTbyBJIHdhcyBxdWVzdGlvbiBob3cgY2FuIGltcGxlbWVudCBt YWNybyBsZXZlbCByYXRlIGNvbnRyb2wgd2hlbiBhIGZyYW1lIGhhdmUgYSBsb3QgaW50ZXI0diBt YWNybz8gSGF2ZSBJIG1pc3VuZGVyc3Rvb2QgMTQ0OTYtMiBzdGFuZGFyZD8gQnV0IEkgZmluZCB4 dmlkIHdyaXRlIGRxdWFudCBhbmQgZGVjb2RlIGRxdWFudCBhcyBhYm92ZS4gQW5kIEguMjY0IGNh biBjaGFuZ2UgcXVhbnQgZXZlbiBpbiA0w5c0IGJsb2NrIC5DYW4gc29tZWJvZHkgYW5zd2VyIG15 IHF1ZXN0aW9uPw0KDQp0aGFua3MNCg0KeGlvbmdzaHUgZGVuZw0KDQogDQo= --===============1877401822== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel --===============1877401822==-- From xvid-devel-bounces@xvid.org Tue Mar 29 09:05:31 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id 3B300126D83 for ; Tue, 29 Mar 2005 09:05:31 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 74A7B14FD7; Tue, 29 Mar 2005 09:05:24 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (mail.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id D768614FDC for ; Tue, 29 Mar 2005 09:05:20 +0200 (CEST) Received: from login.math.uni-bonn.de (login.math.uni-bonn.de [131.220.120.13]) by nil.math.uni-bonn.de (Postfix) with ESMTP id 4BCD993963 for ; Mon, 28 Mar 2005 20:00:39 +0200 (CEST) Date: Mon, 28 Mar 2005 19:59:37 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] question on dquant In-Reply-To: <001c01c53340$ae140bc0$1a040180@dengxiongshu> Message-ID: References: <001c01c53340$ae140bc0$1a040180@dengxiongshu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org For ratecontrol, you don't need to change the quantizer very often=20 per frame, if at all. And, inter4v is rather rarely the best mode,=20 usually, normal inter is better.=20 Both together should suffice to give you enough control over the=20 bitrate. If not, simply use less inter4v mode, it's always the encoder's=20 choice. gruel On Mon, 28 Mar 2005, ??? wrote: > dear 14496-2 expert: >=20 > I find only When macro type is inter+q and intra+q can write dquant v= alue in mpeg4 part 2 standard,so when macro type is inter4v can't write dqu= ant value because have not inter4v+q macro mode ,that is to say when macro = have four motion vector ,it can not change quant value. So I was question h= ow can implement macro level rate control when a frame have a lot inter4v m= acro? Have I misunderstood 14496-2 standard? But I find xvid write dquant a= nd decode dquant as above. And H.264 can change quant even in 4=C3=974 bloc= k .Can somebody answer my question? >=20 > thanks >=20 > xiongshu deng >=20 > =20 >=20 _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Mar 31 17:07:04 2005 Return-Path: X-Original-To: itdp@fh-biergarten.de Delivered-To: itdp@localhost Received: from edu.bnhof.de (edu.bnhof.de [213.167.167.52]) by mail.kliche.org (Postfix) with ESMTP id DB682126D83 for ; Thu, 31 Mar 2005 17:07:04 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 8B3D713EA2; Thu, 31 Mar 2005 17:06:45 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from ouessant.kereval.com (kereval.net1.nerim.net [213.41.138.211]) by edu.bnhof.de (Postfix) with ESMTP id BB15813C3E for ; Thu, 31 Mar 2005 17:06:37 +0200 (CEST) Received: from pcgpr.kereval.com ([192.168.10.179]) by ouessant.kereval.com with esmtp (Kereval Mail Server) id 1DH1Ff-0000SP-00 for ; Thu, 31 Mar 2005 17:06:31 +0200 Message-ID: <424C127F.6010002@etudiant.univ-rennes1.fr> Date: Thu, 31 Mar 2005 17:08:47 +0200 From: Guillaume POIRIER User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: fr, en MIME-Version: 1.0 To: xvid-devel@xvid.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Kereval-MailScanner: Found to be clean Subject: [XviD-devel] Better defaults encoding options in MEncoder X-BeenThere: xvid-devel@xvid.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: xvid-devel@xvid.org List-Id: xvid-devel.xvid.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xvid-devel-bounces@xvid.org Errors-To: xvid-devel-bounces@xvid.org Hi there, On this post: http://edu.bnhof.de/pipermail/xvid-devel/2004-September/004546.html , Edouard Gomez seemed not satisfied with the default settings of XviD in MEncoder. Basically, the problem was that at that time, there were no way to unset a particular encoding option. Well, this problem has been fixed for a while now, before the -pre6 release actually, so all XviD "option" has a "nooption" counterpart. It's therefore now possible to change default settings to the one you like. Either post a patch here or on MPlayer ML, or give me a list of them here, and I'll make sure that they'll make it into MPlayer's CVS. Regards, Guillaume _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel