From xvid-devel-bounces@xvid.org Wed Sep 1 00:18:26 2004 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 2383F126D8B for ; Wed, 1 Sep 2004 00:18:26 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id B509313AD7; Wed, 1 Sep 2004 00:21:36 +0200 (CEST) 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 C922A9CC5 for ; Wed, 1 Sep 2004 00:21:33 +0200 (CEST) Received: from edy by edgomez.kicks-ass.org with local (Exim 4.34) id 1C2GxG-0003eG-4t for xvid-devel@xvid.org; Wed, 01 Sep 2004 00:18:18 +0200 Date: Wed, 1 Sep 2004 00:18:18 +0200 From: Edouard Gomez To: xvid-devel ML Message-ID: <20040831221818.GA13829@edgomez.dyndns.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+20040818i Subject: [XviD-devel] [FRONTEND UPDATE] mplayer modules. 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 Hey hey, i've been working on mplayer's frontends these last two weeks (by small touches). Decoder updates: - reads width and height from stream, doesn't trust container values - display aspect ratio support Encoder updates: - merged stuff from mplayer's cvs (better fps, par/dar support, psnr gathering using the same format as lavc module). Of course that is a "value added"(tm) merge, cleaned the stuff, moved things where they belong to, and so on. - added support for bvhq option if compiled with cvs head xvidcore headers. - what else... hell just test and give feedback Everything up on my site until it's accepted upstream: http://ed.gomez.free.fr/#mencoder_modules -- Edouard Gomez _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Sep 1 00:39:03 2004 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 3DE0E126D8B for ; Wed, 1 Sep 2004 00:39:03 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id DEC8414A96; Wed, 1 Sep 2004 00:42:14 +0200 (CEST) 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 E79E714A91 for ; Wed, 1 Sep 2004 00:42:12 +0200 (CEST) Received: from edy by edgomez.kicks-ass.org with local (Exim 4.34) id 1C2HHF-0003km-EJ for xvid-devel@xvid.org; Wed, 01 Sep 2004 00:38:57 +0200 Date: Wed, 1 Sep 2004 00:38:57 +0200 From: Edouard Gomez To: xvid-devel ML Subject: Re: [XviD-devel] [FRONTEND UPDATE] mplayer modules. Message-ID: <20040831223857.GB13829@edgomez.dyndns.org> Mail-Followup-To: Edouard Gomez , xvid-devel ML References: <20040831221818.GA13829@edgomez.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040831221818.GA13829@edgomez.dyndns.org> User-Agent: Mutt/1.5.6+20040818i 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 Edouard Gomez (ed.gomez@free.fr) wrote: > Encoder updates: > - merged stuff from mplayer's cvs (better fps, par/dar support, > psnr gathering using the same format as lavc module). > Of course that is a "value added"(tm) merge, cleaned > the stuff, moved things where they belong to, and so on. > - added support for bvhq option if compiled with cvs head > xvidcore headers. > - what else... hell just test and give feedback Ah yes i forgot: - default settings changed, because upstream authors thought so. packed=0 is now default (not a bad idea anyway as packed isn't really MPEG4), chroma_me is off, and vhq=0. So now you must set these values on the command line by yourself. PS: the rationale behind these upstream changes were: packed is a flag so packed=0 doesn't work, and packed could not be disabled. Adding nopacked flag was refused afaik. chroma_me=0 because they said this was too slow :\ vhq=0 same reason Basically, they want xvid 1.0 behave as xvid 0.9... i won't fight. -- 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 Sep 2 15:40:59 2004 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 E81B7126D90 for ; Thu, 2 Sep 2004 15:40:58 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id BFC0813D58; Thu, 2 Sep 2004 15:44:11 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from smartmx-01.inode.at (smartmx-01.inode.at [213.229.60.33]) by edu.bnhof.de (Postfix) with ESMTP id C98A213F2D for ; Wed, 1 Sep 2004 06:55:35 +0200 (CEST) Received: from [62.99.252.218] (port=61318 helo=[192.168.0.2]) by smartmx-01.inode.at with esmtp (Exim 4.30) id 1C2N6Z-0007yo-64 for xvid-devel@xvid.org; Wed, 01 Sep 2004 06:52:19 +0200 Message-ID: <4135557E.8040607@x-ray.at> Date: Wed, 01 Sep 2004 06:52:14 +0200 From: Reini Urban User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8a2) Gecko/20040714 X-Accept-Language: de, en MIME-Version: 1.0 To: xvid-devel@xvid.org Subject: Re: [XviD-devel] [FRONTEND UPDATE] mplayer modules. References: <20040831221818.GA13829@edgomez.dyndns.org> In-Reply-To: <20040831221818.GA13829@edgomez.dyndns.org> Content-Type: multipart/mixed; boundary="------------000504080102040907020801" 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 is a multi-part message in MIME format. --------------000504080102040907020801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Edouard Gomez schrieb: > i've been working on mplayer's frontends these last two weeks > (by small touches). > > Decoder updates: > - reads width and height from stream, doesn't trust container > values > - display aspect ratio support > > Encoder updates: > - merged stuff from mplayer's cvs (better fps, par/dar support, > psnr gathering using the same format as lavc module). > Of course that is a "value added"(tm) merge, cleaned > the stuff, moved things where they belong to, and so on. > - added support for bvhq option if compiled with cvs head > xvidcore headers. > - what else... hell just test and give feedback > > Everything up on my site until it's accepted upstream: > http://ed.gomez.free.fr/#mencoder_modules well, for me mencoder adds a 1px green line between the video and the 50px subtitle bar. (the first line at the added bottom border) mingw build. arial.ttf I haven't found the error in the subtitle code. maybe you know more :) mencoder -vf expand=0:-50:0:0 -sub sub.srt -ovc xvid -xvidencopts \ bitrate=850 -oac copy video.avi BTW: attached is also a fixed menc2pass script. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ --------------000504080102040907020801 Content-Type: text/plain; name="menc2pass" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="menc2pass" #!/usr/bin/perl -w # Helper script to ease MEncoder two pass encoding # Copyleft 2001 by Felix Buenemann # This file comes under GPL, see http://www.gnu.org/copyleft/gpl.html for more # information on it's licensing. # # 2004-08-24 15:38:17 rurban@x-ray.at # - fix system() arg usage with recent perl versions # - fix from -xvidopts to -xvidencopts option # - TODO: 3pass version with possible size optimization # for 800MB CD after LAME use strict; my $mencoder="mencoder"; # Path to MEncoder (including binary name) die <<"EOF" unless @ARGV; menc2pass: No arguments given! Please give all usual encoding parameters you would give to mencoder, but leave away the pass= suboption. EOF for (my $i=1; $i<=2; $i++) { my (@parms, $prev); my $parm = $prev = ''; foreach my $val (@ARGV) { if ($prev =~ /-lavcopts/) { push @parms,("vpass=$i:$val"); $parm.="$val vpass=$i:"; } elsif ($prev =~ /-(divx4)|(xvidenc)opts/) { push @parms,("pass=$i:$val"); $parm.="$val pass=$i:"; } elsif ($val =~ /\s/) { push @parms,($val); $parm .= "\"$val\" "; } else { push @parms,($val); $parm .= "$val "; } $prev = $val; } print "\nPASS $i: Running $mencoder ",join(' ',@parms),"\n"; # print "\nPASS $i: Running $mencoder $parm\n"; system($mencoder, @parms) and die "mencoder pass $i failed!\n" } --------------000504080102040907020801 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 --------------000504080102040907020801-- From xvid-devel-bounces@xvid.org Thu Sep 2 15:45:19 2004 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 EBE51126D90 for ; Thu, 2 Sep 2004 15:45:18 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id EBD0013F19; Thu, 2 Sep 2004 15:48:33 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.47]) by edu.bnhof.de (Postfix) with ESMTP id 2141313EF2 for ; Thu, 2 Sep 2004 08:10:00 +0200 (CEST) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i8266emL007631 for ; Wed, 1 Sep 2004 23:06:40 -0700 (PDT) Received: from [10.0.1.192] (catv-50626dee.catv.broadband.hu [80.98.109.238]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i8266cCv014189 for ; Wed, 1 Sep 2004 23:06:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: quoted-printable Message-Id: <1B5F9EFA-FCA6-11D8-A9E2-0003936A8632@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed To: xvid-devel@xvid.org From: =?ISO-8859-1?Q?Sebesty=E9n_G=E1bor?= Date: Thu, 2 Sep 2004 08:05:36 +0200 X-Mailer: Apple Mail (2.619) Subject: [XviD-devel] xvidcore-1.0.2 rel, timer.c NOT fixed 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 Dear Developers, Please fix this annoying bug(? or feature? :o) ) which exists since=20 version 1.0. On Mac OS X ranlib always complains about src/utils/timer.c not having=20= any symbols therefore I cannot link the static lib to my app. All the source is embraced with a #if defined(_PROFILING_) / #endif=20 pair which results empty code in "normal" case. Please put a dummy variable in the #else branch or remove timer.c from=20= the non-debug source file list. I always have to do it manually every time after downloading a new=20 release. Thanks in advance, G=E1bor "Put your message in a modem and throw it in the Cyber Sea." - N. Peart= _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Sep 2 15:46:57 2004 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 0435B126D90 for ; Thu, 2 Sep 2004 15:46:57 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id AD72113F2A; Thu, 2 Sep 2004 15:50:11 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from kbw.ch (kbw.ch [62.2.169.166]) by edu.bnhof.de (Postfix) with ESMTP id 2945E9C1A for ; Thu, 2 Sep 2004 15:26:01 +0200 (CEST) Received: from [62.167.59.92] (account chn HELO [192.168.0.100]) by kbw.ch (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 5347799 for xvid-devel@xvid.org; Thu, 02 Sep 2004 15:21:16 +0200 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <2985461A-FCE3-11D8-8BFE-000A95772E90@kbw.ch> Content-Type: text/plain; charset=US-ASCII; format=flowed To: xvid-devel@xvid.org From: =?ISO-8859-1?Q?Christoph_N=E4geli?= Date: Thu, 2 Sep 2004 15:22:39 +0200 X-Mailer: Apple Mail (2.619) Subject: [XviD-devel] Altivec DCT Sample Code Found 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 all, I found this sample code of a DCT written in C (and assembly) at freescale's homepage but I got little knowledge about DCT so I have two questions: 1. Can this algorithm be used? There's a pdf file in there which describes the DCT used (and it says it's not strictly follow H.263, whatever that means). 2. I don't see a license for this file, do you think I can use that with a header like "copied from ..." or something like that? If we could use that, it would be great because about 50% (depends on settings) is taken by fDCT encoding a movie, so a little speedup there would be nice. What do you think? The zip archive can be downloaded from: http://www.freescale.com/files/32bit/doc/app_note/AVEC_2DCOSTRANS.zip -- Christoph _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Sep 2 16:35:17 2004 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 AD015126D90 for ; Thu, 2 Sep 2004 16:35:17 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 4572F13BDB; Thu, 2 Sep 2004 16:38:27 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id 8D0C89CA2 for ; Thu, 2 Sep 2004 16:38:23 +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 A7F8351A39 for ; Thu, 2 Sep 2004 16:36:31 +0200 (CEST) Date: Thu, 2 Sep 2004 16:35:05 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Altivec DCT Sample Code Found In-Reply-To: <2985461A-FCE3-11D8-8BFE-000A95772E90@kbw.ch> Message-ID: References: <2985461A-FCE3-11D8-8BFE-000A95772E90@kbw.ch> 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 Thu, 2 Sep 2004, Christoph N?geli wrote: > 2. I don't see a license for this file, do you think I can use that > with a header like "copied from ..." or something like that? Definitely not! If there isn't a license on a piece of source, it's still protected by the authors copyright. Since there even is a "(c) Copyright Motorola Inc. 1998" in one of the file, including this source into XviD (or any other project) is a no-go. What you can do, is search the Web for the original release, if there is a (free?) license somewhere, contact the author (i.e. Motorola), asking to release it under GPL, or write your own DCT based on the algorithm described, but that's about it. gruel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Sep 2 16:49:45 2004 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 71102126D90 for ; Thu, 2 Sep 2004 16:49:45 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id ADD1D13EF3; Thu, 2 Sep 2004 16:52:55 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from weed.lut.ac.uk (weed.lut.ac.uk [158.125.1.226]) by edu.bnhof.de (Postfix) with ESMTP id 172CD13BED for ; Thu, 2 Sep 2004 16:52:52 +0200 (CEST) Received: from [158.125.1.220] (helo=jamie.lut.ac.uk) by weed.lut.ac.uk with esmtp (Exim 4.41) id 1C2su4-00033m-7N for xvid-devel@xvid.org; Thu, 02 Sep 2004 15:49:32 +0100 Received: from apache by jamie.lut.ac.uk with local (Exim 4.30) id 1C2su4-00032V-1K for xvid-devel@xvid.org; Thu, 02 Sep 2004 15:49:32 +0100 Received: from elvc-linux3.lut.ac.uk (elvc-linux3.lut.ac.uk [158.125.51.81]) by staff-webmail.lboro.ac.uk (IMP) with HTTP for ; Thu, 2 Sep 2004 15:49:31 +0100 Message-ID: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> Date: Thu, 2 Sep 2004 15:49:32 +0100 From: Tom Jacobs To: xvid-devel@xvid.org 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: 158.125.51.81 X-Scan-Signature: 5a36bda3904d05fd053fd54b64d98d6d Subject: [XviD-devel] Changes to get_pmv2 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 am currently doing thread-level parallelism on the encoder and have great difficulty in motion_estimation. can the left (lp) block be changed on case 0 and 2 so that it reads the top left blocks mvs instead. this would lead to mvs to be read from either the line above or the current block in every case. this would allow for the whole line to be calculated simultaneously. i cant say i understand the reasoning for the locations used in get_pmv2 or why certain mvs[] are read and cos of that this probably cant be done but it would help me Tom _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Sep 2 17:02:49 2004 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 077B9126D90 for ; Thu, 2 Sep 2004 17:02:49 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id C591513F43; Thu, 2 Sep 2004 17:06:03 +0200 (CEST) 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 372C813F2E for ; Thu, 2 Sep 2004 17:06:00 +0200 (CEST) Received: from edy by edgomez.kicks-ass.org with local (Exim 4.34) id 1C2t6o-0003VX-52 for xvid-devel@xvid.org; Thu, 02 Sep 2004 17:02:42 +0200 Date: Thu, 2 Sep 2004 17:02:42 +0200 From: Edouard Gomez To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 Message-ID: <20040902150242.GA2286@edgomez.dyndns.org> Mail-Followup-To: Edouard Gomez , xvid-devel@xvid.org References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> User-Agent: Mutt/1.5.6+20040818i 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 Tom Jacobs (T.R.Jacobs@lboro.ac.uk) wrote: > i am currently doing thread-level parallelism on the encoder and have great > difficulty in motion_estimation. can the left (lp) block be changed on case > 0 and 2 so that it reads the top left blocks mvs instead. this would lead > to mvs to be read from either the line above or the current block in every > case. this would allow for the whole line to be calculated simultaneously. > > i cant say i understand the reasoning for the locations used in get_pmv2 or > why certain mvs[] are read and cos of that this probably cant be done but > it would help me get_pmv2 returns the predicted motion vector as described in the MPEG4 standard. We can't change the way it works. PS: though i'm mostly sure of what i've said, i must admit i've always been confused by get_pmv/get_pmv2 similiraties, so maybe i'm wrong. in that case, correct me. -- 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 Sep 2 17:30:34 2004 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 91863126D90 for ; Thu, 2 Sep 2004 17:30:34 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id AA4EC13F52; Thu, 2 Sep 2004 17:33:49 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id D97FD13F2A for ; Thu, 2 Sep 2004 17:33:46 +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 9209750689 for ; Thu, 2 Sep 2004 17:31:50 +0200 (CEST) Date: Thu, 2 Sep 2004 17:30:24 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 In-Reply-To: <20040902150242.GA2286@edgomez.dyndns.org> Message-ID: References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> <20040902150242.GA2286@edgomez.dyndns.org> 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 Thu, 2 Sep 2004, Edouard Gomez wrote: > > i cant say i understand the reasoning for the locations used in get_pmv2 or > > why certain mvs[] are read and cos of that this probably cant be done but > > it would help me > > get_pmv2 returns the predicted motion vector as described in > the MPEG4 standard. We can't change the way it works. > > PS: though i'm mostly sure of what i've said, i must admit > i've always been confused by get_pmv/get_pmv2 similiraties, so > maybe i'm wrong. in that case, correct me. There is no get_pmv() anymore, only get_pmv2(). As Edouard correctly states, that calculates the MPEG4 motion vector predictor and its modus operandi cannot be changed (nor would there reason to change it, since the prediction works very well). There once used to be a get_pmv() routine for that purpose, but long ago that had been replaced by a faster version which does exactly the same, only in a completely different way. For a while, both version were in the code, so I had to come up with a different name for the new version. Okay, calling is "get_pmv2" was not very original, but it served the purpose. After we verified that get_pmv2 really behaved identical to get_pmv, we only kept the faster version, but didn't change the name. Voila, no confusion anymore. gruel P.S. The MVs are read in the following way: You would like to predict a block MV from its neighbours all direction: top, bottom, left and right. However, when scanning through the blocks in reading order, you don't have the information from the right and the bottom, yet, so you choose left and top, and in addition include top-right, which is the "most right" neighbour that is available at that time. All the rest of get_pmv2() only deals with the question of when to do when some of these neighbours aren't available, etc. chl _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Sep 2 19:14:28 2004 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 B85EE126D90 for ; Thu, 2 Sep 2004 19:14:28 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 0F9CA14047; Thu, 2 Sep 2004 19:17:44 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from kbw.ch (kbw.ch [62.2.169.166]) by edu.bnhof.de (Postfix) with ESMTP id EAE3514042 for ; Thu, 2 Sep 2004 19:17:41 +0200 (CEST) Received: from [62.167.59.92] (account chn HELO [192.168.0.103]) by kbw.ch (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 5372140 for xvid-devel@xvid.org; Thu, 02 Sep 2004 19:13:14 +0200 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <1B5F9EFA-FCA6-11D8-A9E2-0003936A8632@mac.com> References: <1B5F9EFA-FCA6-11D8-A9E2-0003936A8632@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8F6EE779-FD03-11D8-819A-000A95772E90@kbw.ch> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Christoph_N=E4geli?= Subject: Re: [XviD-devel] xvidcore-1.0.2 rel, timer.c NOT fixed Date: Thu, 2 Sep 2004 19:14:34 +0200 To: xvid-devel@xvid.org X-Mailer: Apple Mail (2.619) 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 ranlib complains I know but that doesn't matter, you can just ignore it. After running ranlib the static library is ok and can be linked. btw I don't think 1.0.2 has altivec code... -- Christoph On 2 Sep, 2004, at 8:05, Sebesty=E9n G=E1bor wrote: > Dear Developers, > > Please fix this annoying bug(? or feature? :o) ) which exists since=20 > version 1.0. > On Mac OS X ranlib always complains about src/utils/timer.c not having=20= > any symbols therefore I cannot link the static lib to my app. > All the source is embraced with a #if defined(_PROFILING_) / #endif=20 > pair which results empty code in "normal" case. > > Please put a dummy variable in the #else branch or remove timer.c from=20= > the non-debug source file list. > I always have to do it manually every time after downloading a new=20 > release. > > Thanks in advance, > > G=E1bor > > "Put your message in a modem and throw it in the Cyber Sea." - N. = Peart > _______________________________________________ > 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 Sep 2 19:19:24 2004 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 9D01A126D90 for ; Thu, 2 Sep 2004 19:19:24 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 096031404F; Thu, 2 Sep 2004 19:22:40 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.45]) by edu.bnhof.de (Postfix) with ESMTP id BC5111404B for ; Thu, 2 Sep 2004 19:22:36 +0200 (CEST) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i82HJHH3006970 for ; Thu, 2 Sep 2004 10:19:17 -0700 (PDT) Received: from [10.0.1.192] (catv-50626dee.catv.broadband.hu [80.98.109.238]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id i82HJEWd013296 for ; Thu, 2 Sep 2004 10:19:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <8F6EE779-FD03-11D8-819A-000A95772E90@kbw.ch> References: <1B5F9EFA-FCA6-11D8-A9E2-0003936A8632@mac.com> <8F6EE779-FD03-11D8-819A-000A95772E90@kbw.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <1426FBC8-FD04-11D8-A789-0003936A8632@mac.com> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Sebesty=E9n_G=E1bor?= Subject: Re: [XviD-devel] xvidcore-1.0.2 rel, timer.c NOT fixed Date: Thu, 2 Sep 2004 19:18:16 +0200 To: xvid-devel@xvid.org X-Mailer: Apple Mail (2.619) 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 2004. Sep 2, , at 7:14 du, Christoph N=E4geli wrote: > After running ranlib the static library is ok and can be linked. > Well, my experiences shows the opposite. Xcode always fail to add=20 libxvidcore.a to my app if ranlib already complained "timer.c has no=20 symbols" during linking xvid. I could only prevent link failure by adding an extra dummy variable to=20= timer.c to the #else branch. Sorry.., :) Best regards, G=E1bor To be is to do. - Socrates To do is to be. - Sartre Do be do be do. - Sinatra _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Sep 2 19:25:44 2004 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 0799C126D91 for ; Thu, 2 Sep 2004 19:25:44 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 4944714051; Thu, 2 Sep 2004 19:28:59 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from kbw.ch (kbw.ch [62.2.169.166]) by edu.bnhof.de (Postfix) with ESMTP id C0FD713F18 for ; Thu, 2 Sep 2004 19:28:49 +0200 (CEST) Received: from [62.167.59.92] (account chn HELO [192.168.0.103]) by kbw.ch (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 5373393 for xvid-devel@xvid.org; Thu, 02 Sep 2004 19:24:26 +0200 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <1426FBC8-FD04-11D8-A789-0003936A8632@mac.com> References: <1B5F9EFA-FCA6-11D8-A9E2-0003936A8632@mac.com> <8F6EE779-FD03-11D8-819A-000A95772E90@kbw.ch> <1426FBC8-FD04-11D8-A789-0003936A8632@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <21ECE171-FD05-11D8-819A-000A95772E90@kbw.ch> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Christoph_N=E4geli?= Subject: Re: [XviD-devel] xvidcore-1.0.2 rel, timer.c NOT fixed Date: Thu, 2 Sep 2004 19:25:49 +0200 To: xvid-devel@xvid.org X-Mailer: Apple Mail (2.619) 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, On 2 Sep, 2004, at 19:18, Sebesty=E9n G=E1bor wrote: > On 2004. Sep 2, , at 7:14 du, Christoph N=E4geli wrote: > >> After running ranlib the static library is ok and can be linked. >> > Well, my experiences shows the opposite. Xcode always fail to add=20 > libxvidcore.a to my app if ranlib already complained "timer.c has no=20= > symbols" during linking xvid. > I could only prevent link failure by adding an extra dummy variable to=20= > timer.c to the #else branch. Just curious because it's working on my machine: You did something like ./configure --enable-macosx_module make sudo make install sudo ranlib /usr/local/lib/libxvidcore.a and then linking in Xcode doesn't work? -- Christoph= _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Sep 2 19:39:55 2004 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 EF7B7126D91 for ; Thu, 2 Sep 2004 19:39:54 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 4C28113BB5; Thu, 2 Sep 2004 19:43:09 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.45]) by edu.bnhof.de (Postfix) with ESMTP id D3F6213BB5 for ; Thu, 2 Sep 2004 19:43:06 +0200 (CEST) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i82HdlH3018035 for ; Thu, 2 Sep 2004 10:39:47 -0700 (PDT) Received: from [10.0.1.192] (catv-50626dee.catv.broadband.hu [80.98.109.238]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id i82HdjCv021112 for ; Thu, 2 Sep 2004 10:39:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <21ECE171-FD05-11D8-819A-000A95772E90@kbw.ch> References: <1B5F9EFA-FCA6-11D8-A9E2-0003936A8632@mac.com> <8F6EE779-FD03-11D8-819A-000A95772E90@kbw.ch> <1426FBC8-FD04-11D8-A789-0003936A8632@mac.com> <21ECE171-FD05-11D8-819A-000A95772E90@kbw.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Sebesty=E9n_G=E1bor?= Subject: Re: [XviD-devel] xvidcore-1.0.2 rel, timer.c NOT fixed Date: Thu, 2 Sep 2004 19:38:47 +0200 To: xvid-devel@xvid.org X-Mailer: Apple Mail (2.619) 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 2004. Sep 2, , at 7:25 du, Christoph N=E4geli wrote: > You did something like > > ./configure --enable-macosx_module I skipped configure. Issuing 'make' does it. Maybe it is essential in=20 this case ... :) > make > After making and linking xvidcore I copy the libxvidcore.a file to the=20= 'lib' folder of my project. > and then linking in Xcode doesn't work? > It simply fails. G=E1bor PS.: you can read a similar case here: = http://edu.bnhof.de/pipermail/xvid-users/2003-December/000264.html "Never trust a computer you can't throw out a window." - Steve Wozniak _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Sep 2 22:52:43 2004 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 750B2126D91 for ; Thu, 2 Sep 2004 22:52:43 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id A587E13F19; Thu, 2 Sep 2004 22:55:58 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from mwinf0408.wanadoo.fr (smtp4.wanadoo.fr [193.252.22.27]) by edu.bnhof.de (Postfix) with ESMTP id 169AF13EF2 for ; Thu, 2 Sep 2004 22:55:55 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0408.wanadoo.fr (SMTP Server) with SMTP id 162BD18000CB for ; Thu, 2 Sep 2004 22:52:34 +0200 (CEST) Received: from blackbird.bzh (Mix-Rennes312-2-23.w80-9.abo.wanadoo.fr [80.9.224.23]) by mwinf0408.wanadoo.fr (SMTP Server) with ESMTP id 3E14118000F2 for ; Thu, 2 Sep 2004 22:52:33 +0200 (CEST) Received: from Sketches.bzh (Sketches.bzh [192.168.1.66]) by blackbird.bzh (Postfix) with ESMTP id 9E95813426 for ; Wed, 1 Sep 2004 06:07:41 +0200 (CEST) Received: by Sketches.bzh (Postfix, from userid 500) id 6E55C264BA; Thu, 2 Sep 2004 22:29:10 +0200 (CEST) Subject: Re: [XviD-devel] [FRONTEND UPDATE] mplayer modules. From: Guillaume POIRIER To: xvid-devel ML In-Reply-To: <20040831223857.GB13829@edgomez.dyndns.org> References: <20040831221818.GA13829@edgomez.dyndns.org> <20040831223857.GB13829@edgomez.dyndns.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1094156950.3129.2.camel@Sketches> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 02 Sep 2004 22:29:10 +0200 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, I'm taking care of XviD options in English and French's mplayer manpage. I plan to document all the options not already on the manpage. I looked into ve_xvid4.c, and found quite a great deal of options that I'd need to work on. I saw that "4mv" was removed (which I somewhat figured out as mencoder refused to transcode a stream if that 0.9.x option was there)... Is that just a omission, or is this option actually out with XviD-1.0.x? ... or maybe it is always active? I also saw that the option that allowed manually raise the quantizers for credits (at least with a 0.9.x build) was out too... Is it also not supported by XviD-1.0.x too? I personally find this kind of option quite convenient. Please consider not this mail as a user request, but as someone who wants to bless mencoder users with the best XviD support I can afford. Also, if you want a user to test some new XviD features with mencoder, I'm your man! ;-) Regards, Guillaume _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Sep 2 23:22:37 2004 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 C3D28126D91 for ; Thu, 2 Sep 2004 23:22:37 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 9B3AF13F2E; Thu, 2 Sep 2004 23:25:53 +0200 (CEST) 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 56A8E13F1A for ; Thu, 2 Sep 2004 23:25:50 +0200 (CEST) Received: from edy by edgomez.kicks-ass.org with local (Exim 4.34) id 1C2z2N-00077l-QH for xvid-devel@xvid.org; Thu, 02 Sep 2004 23:22:31 +0200 Date: Thu, 2 Sep 2004 23:22:31 +0200 From: Edouard Gomez To: xvid-devel@xvid.org Subject: Re: [XviD-devel] [FRONTEND UPDATE] mplayer modules. Message-ID: <20040902212231.GC2286@edgomez.dyndns.org> Mail-Followup-To: Edouard Gomez , xvid-devel@xvid.org References: <20040831221818.GA13829@edgomez.dyndns.org> <20040831223857.GB13829@edgomez.dyndns.org> <1094156950.3129.2.camel@Sketches> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094156950.3129.2.camel@Sketches> User-Agent: Mutt/1.5.6+20040818i 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 Guillaume POIRIER (guigui-nospam@laposte.net) wrote: > I saw that "4mv" was removed (which I somewhat figured out as mencoder > refused to transcode a stream if that 0.9.x option was there)... Is that > just a omission, or is this option actually out with XviD-1.0.x? > ... or maybe it is always active? mencoder support of xvidcore 0.9.0 is clearly to geeky oriented, moreover all the terminology between transcode, mencoder and win32 worlds was different. When i prepared xvid 1.0 transition for mencoder and transcode, i tried to stick to win32 options because of two reasons: - even if they're still a bit power user oriented, at least that doesn't go so far as 4mv (what user may ever know what this option really does ?!). This was a first step toward user friendlynes - that way linux app users could still use the guides published by the numerous win32 user base. So what happenned then... transcode did accept all the terminology change, after all, that was a major change, so users were to learn new option (for their own good). mplayers' maintainers refused the changes, because, according to their opinions, there is no point in changing codec options. I refused stating that this was a major rewrite of the module, not a simple -- common let's port this to xvid 1.0. So in the end, my module has been accepted minus lot of options renamed to their old equivalent. Why all this history (no rant involved) ? That explains why, today, you have a ve_xvid4.c module sharing lot of options names with the old ve_xvid.c though their behavior differs slightly. Same remark concerning the codec's default, some maintainers complained that xvid 1.0 was too slow and they wanted it to be as fast as xvidcore 0.9.x... they didn't find any better solution than returning to 0.9.x codec default values... that is disabling almost all new features in xvid 1.0 except bframes. So now i understand your position, you want to ddoucment all this, but you're left with a mess. To answer your very specific question: 4mv was depreciated, and all is taken care by the me_quality option, me_quality>4, 4mv is activated. If at anytime you need precise information about what option does what, refer to the dispatch_settings() function. It embends the entire logic hidden behind the options. > I also saw that the option that allowed manually raise the quantizers > for credits (at least with a 0.9.x build) was out too... Is it also not > supported by XviD-1.0.x too ? > I personally find this kind of option quite convenient. There is no strict equivalent, but a better solution in xvid 1.x. That's called zones. What kept me from offering a user interface to this feature on GNU/linux apps, is that it's not easy at all expressing a zone as flat text. Its parsing can become PITA quite fast. What's a zone: - a zone is an open frame range (range of type [start..[) for which you can set a specific quantizer and disable/enable some features. Why is it so difficult to describe a zone with mencoder. - Let's suppose you want to do that through cmd line options, then old config system (the one that was operational when i started writing the module) didn't allowed that because it supported only certain type of data: float, string, integr, flag and so on. mplayer switched to a better config system, allowing function hooking for parameters, that can help. But transcode still uses the fixed model, so it's very tricky, and i don't want to have two completely different zone description "language" So... the time going, i just forgot about this feature. > Please consider not this mail as a user request, but as someone who > wants to bless mencoder users with the best XviD support I can afford. All feedback is good, even if sometimes it's negative. > Also, if you want a user to test some new XviD features with mencoder, > I'm your man! ;-) Cheers -- 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 Sep 3 03:44:00 2004 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 1CBD1126D91 for ; Fri, 3 Sep 2004 03:44:00 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 1F41A14060; Fri, 3 Sep 2004 03:47:13 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: by edu.bnhof.de (Postfix, from userid 30) id 4F4BB13F15; Fri, 3 Sep 2004 03:47:11 +0200 (CEST) Received: from pD9539EDB.dip.t-dialin.net (pD9539EDB.dip.t-dialin.net [217.83.158.219]) by www.xvid.org (IMP) with HTTP for ; Fri, 3 Sep 2004 03:47:11 +0200 Message-ID: <1094176031.4137cd1f3cdfa@www.xvid.org> Date: Fri, 3 Sep 2004 03:47:11 +0200 From: Michael Militzer To: xvid-devel@xvid.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-MOQ10941760319dc36e9cc92f6a62fd8b0b6da2c49098" User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 217.83.158.219 X-Content-Filtered-By: Mailman/MimeDel 2.1.4 Subject: [XviD-devel] Fwd: is a bug? 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. ---MOQ10941760319dc36e9cc92f6a62fd8b0b6da2c49098 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi all, I received this 'bug report' today by private mail. Actually, it's not really a bug because it just describes a potential situation where we might do a diamond search twice but without any bad side effects (apart from the speed loss). I believe the report is correct and it might indeed be possible to slightly speed up extsearch by adding some more checks. The question is just whether the additional checks would really make things faster or whether the described case(s) are so rare that no speed-up is achieved. However, the (0,0) case should be rather frequent... Michael ----- Forwarded message from µËÐÛÊé ----- Date: Thu, 2 Sep 2004 17:24:47 +0800 From: µËÐÛÊé Reply-To: µËÐÛÊé Subject: is a bug? To: michael@xvid.org Dear michael: When I read xivd source code,and I read function of SearchP in estimation_pvop.c,and I find when MainSearch start from vector(0,0) used xvid_me_DiamondSearch, if result motion vector is vector(0,0) and if define XVID_ME_EXTSEARCH16 , then it will reapt seach from vector(0,0) used xvid_me_DiamondSearch,it is necessarily? I think it should check (MVequal(startMV,zeroMV)),and don't neet to search again. thanks your friends xiongshudeng, deng mobile£º86-13246602770 e_mail£ºdengxiongshu@yulong.com xiongshudeng@sohu.com xiongshudeng@hotmail.com ----- End forwarded message ----- ---MOQ10941760319dc36e9cc92f6a62fd8b0b6da2c49098 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 ---MOQ10941760319dc36e9cc92f6a62fd8b0b6da2c49098-- From xvid-devel-bounces@xvid.org Fri Sep 3 03:51:13 2004 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 B39D6126D91 for ; Fri, 3 Sep 2004 03:51:13 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 38BB61406C; Fri, 3 Sep 2004 03:54:30 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from grunt23.ihug.com.au (grunt23.ihug.com.au [203.109.249.143]) by edu.bnhof.de (Postfix) with ESMTP id 0389A14069 for ; Fri, 3 Sep 2004 03:54:27 +0200 (CEST) Received: from dsl-158.160.240.220.lns02-waym-adl.dsl.comindico.com.au [220.240.160.158] by grunt23.ihug.com.au with asmtp (Exim 3.35 #1 (Debian)) id 1C33EE-0003u0-00; Fri, 03 Sep 2004 11:51:02 +1000 Message-ID: <4137CE88.3010204@ihug.com.au> Date: Fri, 03 Sep 2004 11:23:12 +0930 From: Radek Czyz User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Fwd: is a bug? References: <1094176031.4137cd1f3cdfa@www.xvid.org> In-Reply-To: <1094176031.4137cd1f3cdfa@www.xvid.org> Content-Type: text/plain; charset=us-ascii; 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 Michael Militzer wrote: > Hi all, > > I received this 'bug report' today by private mail. Actually, it's not > really a bug because it just describes a potential situation where we > might do a diamond search twice but without any bad side effects (apart > from the speed loss). > > I believe the report is correct and it might indeed be possible to > slightly speed up extsearch by adding some more checks. The question is > just whether the additional checks would really make things faster or > whether the described case(s) are so rare that no speed-up is achieved. > However, the (0,0) case should be rather frequent... Hi Michael, it's being discussed here: http://www.xvid.org/modules.php?op=modload&name=phpBB2&file=viewtopic&t=2254 In short, the guy is not exactly right in this particular case - but in general yes, extsearch might be a big waste of time because there is no checks whether we're doing the same thing twice. This is contrary to non-extsearch search, which avoids double-checks beautifully... Radek PS. SearchP takes so little time at defaults, that even good speedups are hardly worth it :/ _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Fri Sep 3 04:11:40 2004 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 AB64C126D91 for ; Fri, 3 Sep 2004 04:11:40 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 3A31913F74; Fri, 3 Sep 2004 04:14:57 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: by edu.bnhof.de (Postfix, from userid 30) id B0DC113EE0; Fri, 3 Sep 2004 04:14:54 +0200 (CEST) Received: from pD9539EDB.dip.t-dialin.net (pD9539EDB.dip.t-dialin.net [217.83.158.219]) by www.xvid.org (IMP) with HTTP for ; Fri, 3 Sep 2004 04:14:54 +0200 Message-ID: <1094177694.4137d39ea7979@www.xvid.org> Date: Fri, 3 Sep 2004 04:14:54 +0200 From: Michael Militzer To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Fwd: is a bug? References: <1094176031.4137cd1f3cdfa@www.xvid.org> <4137CE88.3010204@ihug.com.au> In-Reply-To: <4137CE88.3010204@ihug.com.au> 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.219 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 Radek, I think the (0,0) case the guy describes is just a special case and I think his proposed patch is not correct (as I wrote him already in private mail). I think his point is the following: _If_ the prediction value is the zero vector and this vector is chosen as the best predictor from our initial predictor set and therefore becomes the center of the diamond in our regular search, it is possible that we're performing the same diamond (around the (0,0) predictor value) again in extsearch. Now the correct fix for this (imho) would be to store the motion vector that was used as center of the first diamond in our regular search and then check in extsearch whether this former diamond center vector is identical to our prediction vector. If yes, then skip the first diamond search in extsearch. This check could/should replace the current check against backupMV (if I'm not mistaken ;-))... Michael Quoting Radek Czyz : > Michael Militzer wrote: > > Hi all, > > > > I received this 'bug report' today by private mail. Actually, it's not > > really a bug because it just describes a potential situation where we > > might do a diamond search twice but without any bad side effects (apart > > from the speed loss). > > > > I believe the report is correct and it might indeed be possible to > > slightly speed up extsearch by adding some more checks. The question is > > just whether the additional checks would really make things faster or > > whether the described case(s) are so rare that no speed-up is achieved. > > However, the (0,0) case should be rather frequent... > > Hi Michael, > > it's being discussed here: > http://www.xvid.org/modules.php?op=modload&name=phpBB2&file=viewtopic&t=2254 > > In short, the guy is not exactly right in this particular case - but in > general yes, extsearch might be a big waste of time because there is no > checks whether we're doing the same thing twice. This is contrary to > non-extsearch search, which avoids double-checks beautifully... > > Radek > > PS. SearchP takes so little time at defaults, that even good speedups > are hardly worth it :/ > _______________________________________________ > 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 Fri Sep 3 11:13:58 2004 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 25D92126D91 for ; Fri, 3 Sep 2004 11:13:58 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id BAD98140B8; Fri, 3 Sep 2004 11:17:12 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from sphere.barak.net.il (sphere.barak.net.il [212.150.48.98]) by edu.bnhof.de (Postfix) with ESMTP id CF44213F59 for ; Fri, 3 Sep 2004 11:17:10 +0200 (CEST) Received: from f-m.fm ([82.166.252.209]) by sphere.barak.net.il (InterMail vK.4.04.00.00 201-232-137 license e5bc39f1001e7dfa47fa92d56cd12779) with ESMTP id <20040903091220.MNKY10368.sphere@f-m.fm>; Fri, 3 Sep 2004 12:12:20 +0300 Message-ID: <413835CA.1040701@f-m.fm> Date: Fri, 03 Sep 2004 12:13:46 +0300 From: glfinish User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 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] option for GMC with 1 warp point 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 Many DVD standalones are based on the Mediatek 1389 chip. It can play GMC with only single warp point. divx when doing GMC is only capable of producing single warp point. xvid can do GMC with _three_ warp points. Therefore, although this chip is 'divxnetworks certified', but borks on GMC produced by xvid. My suggestion is to have a 'reduced GMC quality' mode that will make xvid GMC encodes play correctly on this chip. I did the necessary modification to the 1.0.2 source tree. I tested the encoding with this mode on a real player -- it plays correctly. Please consider if you want to merge this into the source. Don't know if I can post attachments here, you can download the diff file from http://glfinish.tripod.com/diff-xvid-1warp-1.0.zip or http://glfinish.tripod.com/diff-xvid-1warp-1.0.2 Since I compiled with VS7 , the rc file in vfw was generated with a lot of differences. vfw/src/resource.rc I hope this is ok, I cannot check if it works with VS6 because I dont have it. _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Fri Sep 3 11:32:57 2004 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 7CCE0126D91 for ; Fri, 3 Sep 2004 11:32:57 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id D103214038; Fri, 3 Sep 2004 11:36:13 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id DEB3713F13 for ; Fri, 3 Sep 2004 11:36:11 +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 86F64500ED for ; Fri, 3 Sep 2004 11:34:18 +0200 (CEST) Date: Fri, 3 Sep 2004 11:32:51 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] option for GMC with 1 warp point In-Reply-To: <413835CA.1040701@f-m.fm> Message-ID: References: <413835CA.1040701@f-m.fm> 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, 3 Sep 2004, glfinish wrote: > My suggestion is to have a 'reduced GMC quality' mode that will make > xvid GMC encodes > play correctly on this chip. > I did the necessary modification to the 1.0.2 source tree. > I tested the encoding with this mode on a real player -- it plays correctly. Hi, have you also tested if enabling this mode is beneficial to encoding efficiency in any way? Because, XviD (of course) had 1-point GMC in the beginning, but it turned out to be plain useless. 1-point GMC can encode translational-only camera motion at the expense of 1 extra bit per MB. But translational motion is already easily captured by block motion ME, and due to prediction and differential encoding, this comes essentially without any bit penalty. So, instead of adding 1pt-mode, it's simpler to just switch GMC of, get the same results (in terms of quality) and have no problems with compatibility at all. gruel P.S. IIRC, even DivXnetworks doesn't recommend actually using their 1-pt-GMC. _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Fri Sep 3 13:43:11 2004 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 8C980126D91 for ; Fri, 3 Sep 2004 13:43:11 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id DC8BA140F0; Fri, 3 Sep 2004 13:17:47 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from mwinf1004.wanadoo.fr (smtp10.wanadoo.fr [193.252.22.21]) by edu.bnhof.de (Postfix) with ESMTP id 52BAD13F14 for ; Fri, 3 Sep 2004 13:17:45 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1004.wanadoo.fr (SMTP Server) with SMTP id 73EE618000E7 for ; Fri, 3 Sep 2004 13:14:23 +0200 (CEST) Received: from blackbird.bzh (Mix-Rennes301-2-168.w193-250.abo.wanadoo.fr [193.250.83.168]) by mwinf1004.wanadoo.fr (SMTP Server) with ESMTP id 67A9B1800098 for ; Fri, 3 Sep 2004 13:14:22 +0200 (CEST) Received: from Sketches.bzh (Sketches.bzh [192.168.1.66]) by blackbird.bzh (Postfix) with ESMTP id 1906A135F6 for ; Wed, 1 Sep 2004 10:12:41 +0200 (CEST) Received: by Sketches.bzh (Postfix, from userid 500) id 6D743252E0; Fri, 3 Sep 2004 13:13:47 +0200 (CEST) Subject: Re: [XviD-devel] [FRONTEND UPDATE] mplayer modules. From: Guillaume POIRIER To: xvid-devel ML In-Reply-To: <20040902212231.GC2286@edgomez.dyndns.org> References: <20040831221818.GA13829@edgomez.dyndns.org> <20040831223857.GB13829@edgomez.dyndns.org> <1094156950.3129.2.camel@Sketches> <20040902212231.GC2286@edgomez.dyndns.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Message-Id: <1094210027.2985.127.camel@Sketches> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 03 Sep 2004 13:13:47 +0200 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, First of all, thanks for this lengthy and detailed response to my mail. You guys a pretty busy people, so I'm pleased that you took time to answer both questions Le jeu 02/09/2004 =E0 23:22, Edouard Gomez a =E9crit : > Guillaume POIRIER (guigui-nospam@laposte.net) wrote: > So what happenned then... transcode did accept all the > terminology change, after all, that was a major change, so > users were to learn new option (for their own good). >=20 > mplayers' maintainers refused the changes, because, according > to their opinions, there is no point in changing codec > options. I refused stating that this was a major rewrite of > the module, not a simple -- common let's port this to xvid > 1.0. So in the end, my module has been accepted minus lot of > options renamed to their old equivalent. Ok, so does that mean that the documentation of XviD options in the manpage might be incorrect? (you can check that on a fresh mplayer's cvs) I understand though why having a great codec, and not being able to squeeze all the juice outta it because mplayers' maintainers seem to do all what they can to put libavcodec in front, despite doom9 codec comparison, can be frustrating. > That explains why, today, you have a ve_xvid4.c module sharing > lot of options names with the old ve_xvid.c though their > behavior differs slightly. Same remark concerning the codec's > default, some maintainers complained that xvid 1.0 was too > slow and they wanted it to be as fast as xvidcore 0.9.x... > they didn't find any better solution than returning to 0.9.x > codec default values... that is disabling almost all new > features in xvid 1.0 except bframes. Umm... I'm kinda puzzled... did those people benchmarked a XviD-2-pass with lavc-2-pass? With all XviD advanced options activated (including qpel and turbo mode) XviD beasts lavc right up both speed-wise and quality-wise. Ok, maybe lavc has so many options that you can carefully tune them to reach XviD's quality and speed, but I gave up. > So now i understand your position, you want to ddoucment all > this, but you're left with a mess. >=20 > To answer your very specific question: > 4mv was depreciated, and all is taken care by the me_quality > option, me_quality>4, 4mv is activated. >=20 > If at anytime you need precise information about what option > does what, refer to the dispatch_settings() function. It > embends the entire logic hidden behind the options. Thanks for pointing me to this piece of code. It was pretty enlightening. > > I also saw that the option that allowed manually raise the quantizers > > for credits (at least with a 0.9.x build) was out too... Is it also not > > supported by XviD-1.0.x too ? > > I personally find this kind of option quite convenient. >=20 > There is no strict equivalent, but a better solution in xvid > 1.x. That's called zones. I saw some occurrences in libmpcodecs/ve_xvid4.c /* Encodings zones */ memset(mod->zones, 0, sizeof(mod->zones)); create->zones =3D mod->zones; create->num_zones =3D 0; and (about CBR) /* Quantizer mode uses the same plugin, we have only to define * a constant quantizer zone beginning at frame 0 */ So, if I understand correctly, zone are currently used in XviD, but instead of having several zone, for normal movie, credits and stuff, there's just one zone? > So... the time going, i just forgot about this feature. That's maybe a silly question, but do you have any idea if it would make sense (would it be wise too?) to partially support multiple zones with a semantic close to lavc's "vrc_override"? > > Please consider not this mail as a user request, but as someone who > > wants to bless mencoder users with the best XviD support I can afford. >=20 > All feedback is good, even if sometimes it's negative. Glad to know that. I have one more questions if you don't mind: when compressing an intrelaced video (say, from a camcorder) is it still wise to activate the "interlacing" option when the video is rescaled? (I tend, from my experiments, to think that "interlacing" can't work well on rescaled content, but I'm maybe wrong). Thanks for the good work and I'll see you around Linuxfr! ;-) Regards, Guillaume _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Fri Sep 3 14:26:41 2004 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 0CB19126D91 for ; Fri, 3 Sep 2004 14:26:41 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id CCF611408F; Fri, 3 Sep 2004 14:29:56 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id E8D2E14086 for ; Fri, 3 Sep 2004 14:29:53 +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 835265071F for ; Fri, 3 Sep 2004 14:27:58 +0200 (CEST) Date: Fri, 3 Sep 2004 14:26:31 +0200 (CEST) From: Christoph Lampert To: xvid-devel ML Subject: Re: [XviD-devel] [FRONTEND UPDATE] mplayer modules. In-Reply-To: <1094210027.2985.127.camel@Sketches> Message-ID: References: <20040831221818.GA13829@edgomez.dyndns.org> <20040831223857.GB13829@edgomez.dyndns.org> <1094156950.3129.2.camel@Sketches> <20040902212231.GC2286@edgomez.dyndns.org> <1094210027.2985.127.camel@Sketches> 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, 3 Sep 2004, Guillaume POIRIER wrote: > I have one more questions if you don't mind: > when compressing an intrelaced video (say, from a camcorder) is it still > wise to activate the "interlacing" option when the video is rescaled? (I > tend, from my experiments, to think that "interlacing" can't work well > on rescaled content, but I'm maybe wrong). Interlacing and rescaling (with "normal" algorithms) doesn't work together, the result will look awful. Then it also won't help (or hurt) to switch on interlacing mode. You would need a interlace-aware resizer (which I don't know of to exist in mencoder). If you really have to resize interlaced material, deinterlace it first, and when encoding then, the interlacing flag should of course be off. gruel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Fri Sep 3 15:53:22 2004 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 015FD126D91 for ; Fri, 3 Sep 2004 15:53:22 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 4C32B14059; Fri, 3 Sep 2004 15:56:38 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by edu.bnhof.de (Postfix) with SMTP id 715A61404D for ; Fri, 3 Sep 2004 15:56:35 +0200 (CEST) Received: (qmail 20017 invoked by uid 65534); 3 Sep 2004 13:53:15 -0000 Received: from chello080109116125.4.15.vie.surfer.at (EHLO michaelsnb) (80.109.116.125) by mail.gmx.net (mp019) with SMTP; 03 Sep 2004 15:53:15 +0200 X-Authenticated: #3831892 From: Michael Niedermayer To: xvid-devel@xvid.org Subject: Re: [XviD-devel] [FRONTEND UPDATE] mplayer modules. Date: Fri, 3 Sep 2004 15:53:11 +0200 User-Agent: KMail/1.6.1 References: <20040831221818.GA13829@edgomez.dyndns.org> <1094210027.2985.127.camel@Sketches> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409031553.11330.michaelni@gmx.at> 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 On Friday 03 September 2004 14:26, Christoph Lampert wrote: > On Fri, 3 Sep 2004, Guillaume POIRIER wrote: > > I have one more questions if you don't mind: > > when compressing an intrelaced video (say, from a camcorder) is it still > > wise to activate the "interlacing" option when the video is rescaled? (I > > tend, from my experiments, to think that "interlacing" can't work well > > on rescaled content, but I'm maybe wrong). > > Interlacing and rescaling (with "normal" algorithms) doesn't work > together, the result will look awful. Then it also won't help (or > hurt) to switch on interlacing mode. You would need a interlace-aware > resizer (which I don't know of to exist in mencoder). -vf scale=::1 [...] -- Michael level[i]= get_vlc(); i+=get_vlc(); (violates patent EP0266049) median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]); (violates patent #5,905,535) buf[i]= qp - buf[i-1]; (violates patent #?) for more examples, see http://mplayerhq.hu/~michael/patent.html stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Fri Sep 3 16:05:57 2004 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 74216126D91 for ; Fri, 3 Sep 2004 16:05:57 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 56608140C2; Fri, 3 Sep 2004 16:09:09 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from mwinf0501.wanadoo.fr (smtp5.wanadoo.fr [193.252.22.26]) by edu.bnhof.de (Postfix) with ESMTP id 8B526140BF for ; Fri, 3 Sep 2004 16:09:06 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0501.wanadoo.fr (SMTP Server) with SMTP id E71F840031A for ; Fri, 3 Sep 2004 16:05:45 +0200 (CEST) Received: from blackbird.bzh (Mix-Rennes301-1-130.w193-250.abo.wanadoo.fr [193.250.27.130]) by mwinf0501.wanadoo.fr (SMTP Server) with ESMTP id 270144002FA for ; Fri, 3 Sep 2004 16:05:45 +0200 (CEST) Received: from Sketches.bzh (Sketches.bzh [192.168.1.66]) by blackbird.bzh (Postfix) with ESMTP id DCDE614386 for ; Fri, 3 Sep 2004 15:42:07 +0200 (CEST) Received: by Sketches.bzh (Postfix, from userid 500) id 9E6322529C; Fri, 3 Sep 2004 15:42:07 +0200 (CEST) Subject: Re: [XviD-devel] [FRONTEND UPDATE] mplayer modules. From: Guillaume POIRIER To: xvid-devel ML In-Reply-To: References: <20040831221818.GA13829@edgomez.dyndns.org> <20040831223857.GB13829@edgomez.dyndns.org> <1094156950.3129.2.camel@Sketches> <20040902212231.GC2286@edgomez.dyndns.org> <1094210027.2985.127.camel@Sketches> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Message-Id: <1094218927.9805.27.camel@Sketches> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 03 Sep 2004 15:42:07 +0200 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 Le ven 03/09/2004 =E0 14:26, Christoph Lampert a =E9crit : > On Fri, 3 Sep 2004, Guillaume POIRIER wrote: > Interlacing and rescaling (with "normal" algorithms) doesn't work=20 > together, the result will look awful. Then it also won't help (or=20 > hurt) to switch on interlacing mode. You would need a interlace-aware=20 > resizer (which I don't know of to exist in mencoder).=20 >=20 > If you really have to resize interlaced material, deinterlace it first,=20 > and when encoding then, the interlacing flag should of course be off. So the "interlacing" flag is just the way to go for people who want to backup interlaced video with the best compression ratio as the codec will know how to best take care of those funny interlaced fields? Regards, Guillaume _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Fri Sep 3 16:09:53 2004 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 101EF126D91 for ; Fri, 3 Sep 2004 16:09:53 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 05D93140C1; Fri, 3 Sep 2004 16:13:09 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id 3E43A13BB8 for ; Fri, 3 Sep 2004 16:13:03 +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 82231519A2 for ; Fri, 3 Sep 2004 16:11:10 +0200 (CEST) Date: Fri, 3 Sep 2004 16:09:43 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] [FRONTEND UPDATE] mplayer modules. In-Reply-To: <200409031553.11330.michaelni@gmx.at> Message-ID: References: <20040831221818.GA13829@edgomez.dyndns.org> <1094210027.2985.127.camel@Sketches> <200409031553.11330.michaelni@gmx.at> 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, 3 Sep 2004, Michael Niedermayer wrote: > -vf scale=::1 Oops, okay. I should take a couple of days off to finally read the full mplayer manpage. Anyway, then rescaling and interlaced flag can (and should) be combined. gruel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Fri Sep 3 16:28:05 2004 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 41A4F126D91 for ; Fri, 3 Sep 2004 16:28:05 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 203B914064; Fri, 3 Sep 2004 16:31:20 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from grunt22.ihug.com.au (grunt22.ihug.com.au [203.109.249.142]) by edu.bnhof.de (Postfix) with ESMTP id F2EB814060 for ; Fri, 3 Sep 2004 16:31:10 +0200 (CEST) Received: from dsl-158.160.240.220.lns02-waym-adl.dsl.comindico.com.au [220.240.160.158] by grunt22.ihug.com.au with asmtp (Exim 3.35 #1 (Debian)) id 1C3F2Y-0003Ug-00; Sat, 04 Sep 2004 00:27:46 +1000 Message-ID: <41387FE5.7060204@ihug.com.au> Date: Fri, 03 Sep 2004 23:59:57 +0930 From: Radek Czyz User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) 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] better trellis? 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 everyone. I'm starting to think about a backend for HVS modules. One of the possible ways of using HVS data in encoder is to modulate lambda during trellis quantization - more important parts of the picture get higher lambda, less important get lower. It's a good method, more precise and less costly than adaptive quantization. There is a problem with current trellis though. It is only able to decrease bitrate with low lambda, I can't count on it when I try to increase quality. This is because of the way it works: Firstly, normal quantization is performed. Secondly, trellis optimizes the coefficients, but mostly by decreasing levels. It will try to increase some zeroes to ones but only some. The most extreme case is when block is zero after "normal" quantization. Trellis will not be able to touch it at all, even if HVS model suggests high lambda. What I have done: instead of doing "normal" quantization before trellis, I'm using a "minimum error" quantization. Such quantization has no deadzone and no bias, and if the coefficients were kept this way, it would be horribly inefficient. But this is where trellis kicks in: it lowers (ONLY lowers) the levels to make it efficient. Since it only lowers, it does less work (in many cases) than before, as there is only one "direction" to check. Depending on lambda, it is now perfectly possible to lower the coefficients less or more, to achive a per-block quality that we need. My current test results are a bit surprising. Bitrate at Q4 goes up by whole 6%, PSNR goes up accordingly. At 2-pass, average PSNR is the same as before (+/- 0.02dB) but the minimum PSNR (worst frame) goes up by as much as 0.5dB. This seems to be the only benefit until we have HVS models to modulate the quality - but this benefit is quite high, as it's exactly the worst-case that is seen. I don't have a proper code to show you yet, but I'll create something interesting soon. In particular, I'll try moving trellis to separate file - it's so messy currently :/ There is also a couple of ther fixes I want to try (cbp cost in not 2 bits per coded block, especially not in bframes). Comments, suggestions? Radek PS. perhaps such trellis will like another lambda by default - quality might increase _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Fri Sep 3 16:58:27 2004 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 B376D126D91 for ; Fri, 3 Sep 2004 16:58:27 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 6A28E14090; Fri, 3 Sep 2004 17:01:44 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: by edu.bnhof.de (Postfix, from userid 30) id 194ED1408C; Fri, 3 Sep 2004 17:01:42 +0200 (CEST) Received: from pD9E37D7D.dip.t-dialin.net (pD9E37D7D.dip.t-dialin.net [217.227.125.125]) by www.xvid.org (IMP) with HTTP for ; Fri, 3 Sep 2004 17:01:41 +0200 Message-ID: <1094223701.413887552cc6f@www.xvid.org> Date: Fri, 3 Sep 2004 17:01:41 +0200 From: Michael Militzer To: xvid-devel@xvid.org Subject: Re: [XviD-devel] better trellis? References: <41387FE5.7060204@ihug.com.au> In-Reply-To: <41387FE5.7060204@ihug.com.au> 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.125.125 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 Radek, using a bias of zero in quantization before trellis could definitively pay off as the original paper about trellis quantization did even suggest to use the unquantized DCT coefficients as input for the trellis iirc. But imho there are some things that should be checked: I suspect that trellis quantization will become (significantly) slower when using quantization without bias. That's simply because we have more non- zero coefficients among the quantized DCT coefficients and therefore more nodes in the trellis. I guess even when you only check for lowering levels, it might still be slower than the current implementation. As another note, I would expect that higher quality (no bias + high lambda) might only pay off in certain situations PSNR-wise. I know that you're aiming to improve perceived quality and not PSNR, but a good quality/size ratio is required. I'd expect that no bias and high lambda may perform rather well in scenes with high motion, a lot of texture data and just few skipped blocks. In this case, we don't have long runs anyway and from a quality/size perspective it might be beneficial to reduce the quantization error as much as possible (bias = 0), since this won't increase the size of the coded bitstream that much while the quality improvement could be large. On the other hand, in 'easy' scenes where we would normally skip many blocks or have long runs (with bias=Q/2 iirc), switching to bias=0 may not improve the quality much (because all blocks can rather well be predicted from the reference frame with just few stored coefficients) while the coding efficiency might be severely harmed when runs become significantly shorter and only fewer blocks can be skipped with bias = 0. So probably, your lambda should also take motion or current avrg. texture size into consideration. On the other hand: from a HVS perspective we may not like to have best quality in high motion scenes as the human eye may not be capable at all to perceive the extra quality here - oh well, just some thoughts... Michael Quoting Radek Czyz : > Hi everyone. > > I'm starting to think about a backend for HVS modules. One of the > possible ways of using HVS data in encoder is to modulate lambda during > trellis quantization - more important parts of the picture get higher > lambda, less important get lower. > > It's a good method, more precise and less costly than adaptive quantization. > > There is a problem with current trellis though. It is only able to > decrease bitrate with low lambda, I can't count on it when I try to > increase quality. > > This is because of the way it works: Firstly, normal quantization is > performed. Secondly, trellis optimizes the coefficients, but mostly by > decreasing levels. It will try to increase some zeroes to ones but only > some. > The most extreme case is when block is zero after "normal" quantization. > Trellis will not be able to touch it at all, even if HVS model suggests > high lambda. > > What I have done: instead of doing "normal" quantization before trellis, > I'm using a "minimum error" quantization. Such quantization has no > deadzone and no bias, and if the coefficients were kept this way, it > would be horribly inefficient. But this is where trellis kicks in: it > lowers (ONLY lowers) the levels to make it efficient. Since it only > lowers, it does less work (in many cases) than before, as there is only > one "direction" to check. > > Depending on lambda, it is now perfectly possible to lower the > coefficients less or more, to achive a per-block quality that we need. > > My current test results are a bit surprising. Bitrate at Q4 goes up by > whole 6%, PSNR goes up accordingly. At 2-pass, average PSNR is the same > as before (+/- 0.02dB) but the minimum PSNR (worst frame) goes up by as > much as 0.5dB. This seems to be the only benefit until we have HVS > models to modulate the quality - but this benefit is quite high, as it's > exactly the worst-case that is seen. > > I don't have a proper code to show you yet, but I'll create something > interesting soon. In particular, I'll try moving trellis to separate > file - it's so messy currently :/ There is also a couple of ther fixes I > want to try (cbp cost in not 2 bits per coded block, especially not in > bframes). > > Comments, suggestions? > > Radek > > PS. perhaps such trellis will like another lambda by default - quality > might increase > _______________________________________________ > 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 Fri Sep 3 17:13:51 2004 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 200AA126D91 for ; Fri, 3 Sep 2004 17:13:51 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 2E8F813AD1; Fri, 3 Sep 2004 17:17:08 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from grunt22.ihug.com.au (grunt22.ihug.com.au [203.109.249.142]) by edu.bnhof.de (Postfix) with ESMTP id 02B829CC6 for ; Fri, 3 Sep 2004 17:17:05 +0200 (CEST) Received: from dsl-158.160.240.220.lns02-waym-adl.dsl.comindico.com.au [220.240.160.158] by grunt22.ihug.com.au with asmtp (Exim 3.35 #1 (Debian)) id 1C3Fl2-0000uR-00; Sat, 04 Sep 2004 01:13:44 +1000 Message-ID: <41388AAC.7010201@ihug.com.au> Date: Sat, 04 Sep 2004 00:45:56 +0930 From: Radek Czyz User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xvid-devel@xvid.org Subject: Re: [XviD-devel] better trellis? References: <41387FE5.7060204@ihug.com.au> <1094223701.413887552cc6f@www.xvid.org> In-Reply-To: <1094223701.413887552cc6f@www.xvid.org> Content-Type: text/plain; charset=us-ascii; 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 :) Michael Militzer wrote: > I suspect that trellis quantization will become (significantly) slower when > using quantization without bias. That's simply because we have more non- > zero coefficients among the quantized DCT coefficients and therefore more > nodes in the trellis. I guess even when you only check for lowering levels, > it might still be slower than the current implementation. Yes it probably will. I tried to measure it and it was nothing serious (definitely not a killer) but I can't tell how much exactly, because I'm using C code for quantization. Of course, I will take it into account. > So probably, your lambda should also take motion or current avrg. texture > size into consideration. On the other hand: from a HVS perspective we may > not like to have best quality in high motion scenes as the human eye may > not be capable at all to perceive the extra quality here - oh well, just > some thoughts... The trellis is just a backend for HVS models. Currently lambda is fixed, and remains at the same value at which it used to be. The actual implementations are supposed to take a form of HVS plugins, which will work together to describe the suggested quality of different parts of the picture. Core will simply use trellis to make these values actually have any effect. Trellis is not the only way to enforce HVS results, but the most natural one. There is also lambda during VHQ and there are motion skip thresholds, just to name two - but I would like to have the trellis part fully functional before I do anything else. Thanks for the mail, Radek _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Fri Sep 3 17:16:19 2004 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 1127A126D91 for ; Fri, 3 Sep 2004 17:16:19 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 51CDB13EDF; Fri, 3 Sep 2004 17:19:36 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id 1D6D913CFF for ; Fri, 3 Sep 2004 17:19:33 +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 90E86519BA for ; Fri, 3 Sep 2004 17:17:40 +0200 (CEST) Date: Fri, 3 Sep 2004 17:16:13 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] better trellis? In-Reply-To: <1094223701.413887552cc6f@www.xvid.org> Message-ID: References: <41387FE5.7060204@ihug.com.au> <1094223701.413887552cc6f@www.xvid.org> 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, 3 Sep 2004, Michael Militzer wrote: > So probably, your lambda should also take motion or current avrg. texture > size into consideration. On the other hand: from a HVS perspective we may > not like to have best quality in high motion scenes as the human eye may > not be capable at all to perceive the extra quality here - oh well, just > some thoughts... Basically, chosing a variable lambda boils down to optimizing a different quality metric than SSD, hopefully HVS-based. There is of course prior work on that, e.g. (for the "reasonable" ones): http://ise.stanford.edu/class/ee392j/projects/xiao_report.pdf He classifies scenes as static or not, and then uses just the MPEG quantization matrix for static scenes, and a weighted power thereof for non-static. So, maybe using a similar approach based on a typical weight matrix would be a good starting point. chl _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Sat Sep 4 13:58:37 2004 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 1E58B126D91 for ; Sat, 4 Sep 2004 13:58:37 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 46C9113EDB; Sat, 4 Sep 2004 14:01:54 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from grunt22.ihug.com.au (grunt22.ihug.com.au [203.109.249.142]) by edu.bnhof.de (Postfix) with ESMTP id 0C9DC13BB8 for ; Sat, 4 Sep 2004 14:01:40 +0200 (CEST) Received: from dsl-158.160.240.220.lns02-waym-adl.dsl.comindico.com.au [220.240.160.158] by grunt22.ihug.com.au with asmtp (Exim 3.35 #1 (Debian)) id 1C3ZBE-0000ta-00; Sat, 04 Sep 2004 21:58:04 +1000 Message-ID: <4139AE53.9050505@ihug.com.au> Date: Sat, 04 Sep 2004 21:30:19 +0930 From: Radek Czyz User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) 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] trellis questions 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 everyone, I'm still breaking trellis search :) and I have a question: There is a code /* source (w/ CBP penalty) */ Run_Costs[-1] = 2< 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 AC5EC126D91 for ; Sun, 5 Sep 2004 01:43:36 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id C494113F40; Sun, 5 Sep 2004 01:46:53 +0200 (CEST) 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 77BFC13B93 for ; Sun, 5 Sep 2004 01:06:02 +0200 (CEST) Received: from edy by edgomez.kicks-ass.org with local (Exim 4.34) id 1C3jYA-0006UU-Tq for xvid-devel@xvid.org; Sun, 05 Sep 2004 01:02:26 +0200 Date: Sun, 5 Sep 2004 01:02:26 +0200 From: Edouard Gomez To: xvid-devel ML Message-ID: <20040904230226.GC2508@edgomez.dyndns.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+20040818i X-Mailman-Approved-At: Sun, 05 Sep 2004 01:46:09 +0200 Subject: [XviD-devel] Flushing frames oddity ? 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, I'm currently trying to complete the mencoder module for full bvop support, that means flushing the last frames :-) The problem i'm facing is that, even if i patch mencoder.c to allow muxing during uninit, xvidcore doesn't flush as many frames as i would like. With packed mode, even if i see one buffered frame at the encoding beginning, then when flushing nothing comes out at the end of the encode: xvid: buffering frame Skipping frame! <-- dunno what that means Skipping frame! <-- same xvid: flushed all frames (End of stream reached) When using no packed mode i can get a frame out: xvid: buffering frame Skipping frame! Skipping frame! xvid: muxing buffered frame xvid: flushed all frames (End of stream reached) The twopass file has: $ grep -v "^$" underworld-trailer-c026193d361978eab559429164b0ddae.stats | grep -v ".*#" | wc -l 3536 <-- that stats for no packed $ grep -v "^$" underworld-trailer-960ab3711c3046eafb0350a82d32b4ae.stats | grep -v ".*#" | wc -l 3535 <-- that stats for packed So the same "eat one" frame behavior exists for both passes. Is that expected behavior that packed munges always one frame (isn't returned by flush loop) and that two frames are always missing ? -- Edouard Gomez _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Sun Sep 5 15:54:37 2004 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 14A8D126D91 for ; Sun, 5 Sep 2004 15:54:37 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 148601408C; Sun, 5 Sep 2004 15:57:56 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from mwinf0107.wanadoo.fr (smtp1.wanadoo.fr [193.252.22.30]) by edu.bnhof.de (Postfix) with ESMTP id 5A71814079 for ; Sun, 5 Sep 2004 15:57:43 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0107.wanadoo.fr (SMTP Server) with SMTP id E0815180004E for ; Sun, 5 Sep 2004 15:54:15 +0200 (CEST) Received: from blackbird.bzh (Mix-Rennes210-2-187.w193-249.abo.wanadoo.fr [193.249.226.187]) by mwinf0107.wanadoo.fr (SMTP Server) with ESMTP id 47F8A1800040 for ; Sun, 5 Sep 2004 15:54:15 +0200 (CEST) Received: from Sketches.bzh (Sketches.bzh [192.168.1.66]) by blackbird.bzh (Postfix) with ESMTP id B26B329A3 for ; Sun, 5 Sep 2004 13:51:03 +0200 (CEST) Received: by Sketches.bzh (Postfix, from userid 500) id CD523229C2; Sun, 5 Sep 2004 15:43:39 +0200 (CEST) Subject: Re: [XviD-devel] [FRONTEND UPDATE] mplayer modules. From: Guillaume POIRIER To: xvid-devel ML In-Reply-To: <20040831221818.GA13829@edgomez.dyndns.org> References: <20040831221818.GA13829@edgomez.dyndns.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Message-Id: <1094391819.3275.9.camel@Sketches> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 05 Sep 2004 15:43:39 +0200 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, Le mer 01/09/2004 =E0 00:18, Edouard Gomez a =E9crit : > Encoder updates: > - added support for bvhq option if compiled with cvs head > xvidcore headers. > - what else... hell just test and give feedback Ok, I tested bvhq with low bitrate... It's looks impressive! It does not seem to affect encoding time, and increases PSNR quite a bit. without bvhq: Video stream: 644,510 kbit/s (80563 bps) size: 1601607 bytes 19,880 secs 500 frames The value 99.99dB is a special value and represents the upper range limit xvid: Min PSNR y : 39,11 dB, u : 43,57 dB, v : 44,06 dB, in frame 374 xvid: Average PSNR y : 41,12 dB, u : 44,43 dB, v : 44,54 dB, for 495 frames xvid: Max PSNR y : 45,30 dB, u : 46,90 dB, v : 47,14 dB, in frame 250 with bvhq: Video stream: 652,880 kbit/s (81610 bps) size: 1622407 bytes 19,880 secs 500 frames The value 99.99dB is a special value and represents the upper range limit xvid: Min PSNR y : 39,14 dB, u : 43,68 dB, v : 43,96 dB, in frame 386 xvid: Average PSNR y : 41,20 dB, u : 44,49 dB, v : 44,59 dB, for 495 frames xvid: Max PSNR y : 45,30 dB, u : 46,90 dB, v : 47,14 dB, in frame 250 The slight problem I see here is it affects target size by 1.3%, but I guess that's not much. What is bvhq supposed to do anyway? Google and grep didn't help me much... _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Sun Sep 5 16:20:05 2004 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 78CB3126D91 for ; Sun, 5 Sep 2004 16:20:05 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id E5AA814079; Sun, 5 Sep 2004 16:23:24 +0200 (CEST) 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 C671F13BD9 for ; Sun, 5 Sep 2004 16:23:10 +0200 (CEST) Received: from edy by edgomez.kicks-ass.org with local (Exim 4.34) id 1C3xro-0002J7-0m for xvid-devel@xvid.org; Sun, 05 Sep 2004 16:19:40 +0200 Date: Sun, 5 Sep 2004 16:19:39 +0200 From: Edouard Gomez To: xvid-devel@xvid.org Subject: Re: [XviD-devel] [FRONTEND UPDATE] mplayer modules. Message-ID: <20040905141939.GD2508@edgomez.dyndns.org> Mail-Followup-To: Edouard Gomez , xvid-devel@xvid.org References: <20040831221818.GA13829@edgomez.dyndns.org> <1094391819.3275.9.camel@Sketches> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094391819.3275.9.camel@Sketches> User-Agent: Mutt/1.5.6+20040818i 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 Guillaume POIRIER (guigui-nospam@laposte.net) wrote: > It does not seem to affect encoding time, and increases PSNR quite a bit. Not much in fact. > without bvhq: > Video stream: 644,510 kbit/s (80563 bps) size: 1601607 bytes 19,880 secs 500 frames > The value 99.99dB is a special value and represents the upper range limit > xvid: Min PSNR y : 39,11 dB, u : 43,57 dB, v : 44,06 dB, in frame 374 > xvid: Average PSNR y : 41,12 dB, u : 44,43 dB, v : 44,54 dB, for 495 frames > xvid: Max PSNR y : 45,30 dB, u : 46,90 dB, v : 47,14 dB, in frame 250 > > with bvhq: > Video stream: 652,880 kbit/s (81610 bps) size: 1622407 bytes 19,880 > secs 500 frames > The value 99.99dB is a special value and represents the upper range limit > xvid: Min PSNR y : 39,14 dB, u : 43,68 dB, v : 43,96 dB, in frame 386 > xvid: Average PSNR y : 41,20 dB, u : 44,49 dB, v : 44,59 dB, for 495 frames > xvid: Max PSNR y : 45,30 dB, u : 46,90 dB, v : 47,14 dB, in frame 250 0.1dB is a good improvement, but not really perceivable by HVS... > The slight problem I see here is it affects target size by 1.3%, but I > guess that's not much. Your sequence length was too short for 2pass to be really efficient at predicting, so i guess it's just the result of some misprediction errors on a few frames that take a big importance given the small number of frames. > What is bvhq supposed to do anyway? Google and grep didn't help me > much... bvhq is VHQ for bframes. In 1.0.x series, vhq was implemented for P frames. For 1.1.x series, bframes can use vhq too. So the real question is: what is vhq ? - The name... only sysKin knows why it's called vhq. Sounded cool iirc - the magic behind the scenes is simple: ME step tries to figure out what vector is best for a block. But, most of ME routines use SAD which gives the distance between two blocks in the usual YUV space. That's sub-optimal because of one thing: - what the coder encodes is not the YUV difference between the prediction and the coded block, it's DCTed coefficients, rearranged as (run,last,level) tuples. VHQ is the answer to this simple problem, it does Rate-Distortion optimized decision. Rate-Distortion optimized means that for a decision, the (rate,distortion) tuple is a local minimum (rate is bits spent to code the block, distortion is the energy of the residual of the block, squared sum of pixel distance): - vhq1 looks what block mode for the *chosen* candidate is RD best - VHQ>1 uses RD decision for choosing *candiates*. The bigger VHQ, the more RD decisions (and thus costly RD operators) are used. VHQ4 makes use of RD operators for nearly all decisions. bvhq, as stated in my frontend update announce is now just bvhq=(0|1), which means vector candidates for bframes are choosed the usual SAD operator way, but the final decision made to choose which to use for the coding is done using a RD optimized operator. More than a small PSNR increase, i think this option brings better looking bocks for bvops, even if that isn't directly appearing in the "articificial" PSNR value. For me, bvhq is just more pleasant bvops. -- Edouard Gomez _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Sun Sep 5 21:58:55 2004 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 91568126D91 for ; Sun, 5 Sep 2004 21:58:55 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id D7D9B13BD3; Sun, 5 Sep 2004 22:02:13 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from mwinf0812.wanadoo.fr (smtp8.wanadoo.fr [193.252.22.23]) by edu.bnhof.de (Postfix) with ESMTP id 1D5CA13BB5 for ; Sun, 5 Sep 2004 22:01:59 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0812.wanadoo.fr (SMTP Server) with SMTP id 7DE3C180008B for ; Sun, 5 Sep 2004 21:58:31 +0200 (CEST) Received: from blackbird.bzh (Mix-Rennes312-3-136.w80-9.abo.wanadoo.fr [80.9.225.136]) by mwinf0812.wanadoo.fr (SMTP Server) with ESMTP id DA4D6180008A for ; Sun, 5 Sep 2004 21:58:29 +0200 (CEST) Received: from Sketches.bzh (Sketches.bzh [192.168.1.66]) by blackbird.bzh (Postfix) with ESMTP id 57D26134ED for ; Sun, 5 Sep 2004 20:05:02 +0200 (CEST) Received: by Sketches.bzh (Postfix, from userid 500) id CBCFA4CE0; Sun, 5 Sep 2004 21:57:37 +0200 (CEST) Subject: Re: [XviD-devel] [FRONTEND UPDATE] mplayer modules. From: Guillaume POIRIER To: xvid-devel ML In-Reply-To: <20040905141939.GD2508@edgomez.dyndns.org> References: <20040831221818.GA13829@edgomez.dyndns.org> <1094391819.3275.9.camel@Sketches> <20040905141939.GD2508@edgomez.dyndns.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Message-Id: <1094414257.19933.37.camel@Sketches> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 05 Sep 2004 21:57:37 +0200 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, Le dim 05/09/2004 =E0 16:19, Edouard Gomez a =E9crit : > Guillaume POIRIER (guigui-nospam@laposte.net) wrote: > > It does not seem to affect encoding time, and increases PSNR quite a bi= t. >=20 > Not much in fact. I agree. Small increase of encoding time, and small PSNR increase.=20 To me, it looks like a win-win option that is worth being activated all the time, totally the opposite of qpel, which can sometimes harm. > Your sequence length was too short for 2pass to be really > efficient at predicting, so i guess it's just the result of > some misprediction errors on a few frames that take a big > importance given the small number of frames. I re-encoded the video (a 30-min camcorder clip with lots of movements). There might me a little bit of jitter on encoding time as there were other process running during the encoding process. with bvhq: 2nd pass at 9fps, total encoding time: 1hrs 51min 56sec Video stream: 1375,072 kbit/s (171884 bps) size: 332183093 bytes=20 1932,600 secs 48318 frames The value 99.99dB is a special value and represents the upper range limit xvid: Min PSNR y : 37,35 dB, u : 46,05 dB, v : 46,89 dB, in frame 8398 xvid: Average PSNR y : 43,47 dB, u : 46,33 dB, v : 46,42 dB, for 48313 frames xvid: Max PSNR y : 48,01 dB, u : 47,00 dB, v : 47,98 dB, in frame 0 without bvhq: 2nd pass at 9fps, total encoding time: 1hrs 46min 49sec Video stream: 1375,080 kbit/s (171885 bps) size: 332184983 bytes=20 1932,600 secs 48318 frames The value 99.99dB is a special value and represents the upper range limit xvid: Min PSNR y : 37,57 dB, u : 45,32 dB, v : 45,53 dB, in frame 48026 xvid: Average PSNR y : 43,40 dB, u : 46,30 dB, v : 46,40 dB, for 48313 frames xvid: Max PSNR y : 48,01 dB, u : 47,00 dB, v : 47,98 dB, in frame 0 For the sake of comprehensiveness, the encoding options were: me_quality=3D6:chroma_me:chroma_opt:gmc:trellis:closed_gop: max_bframes=3D2:hq_ac:vhq=3D4:qpel:autoaspect:psnr (apart from bvqh, off course) So we'got a Y +0.07, U +0.03, V -0.02 dB gain, and the video is slightly smaller. Not bad! Regarding the quality of the output with my very own eyes, I couldn't say..= . That's maybe because the input video was a little bit noisy. I should try it on a whole hollywood movie. If you have other test-cases suggestions, please let me know (but no "The Matrix", scene xxx test! ;-)) > bvhq is VHQ for bframes. In 1.0.x series, vhq was implemented > for P frames. For 1.1.x series, bframes can use vhq too. [..] Thanks for the explanation. Although I have little video knowledge, I understood it very well. Did you ever though about being a teacher instead of an engineer? ;-) > bvhq, as stated in my frontend update announce is now just > bvhq=3D(0|1), which means vector candidates for bframes are > choosed the usual SAD operator way, but the final decision > made to choose which to use for the coding is done using a RD > optimized operator. Do you plan to add other "incremental modes" to bvhq, just like vhq? > More than a small PSNR increase, i think this option brings > better looking bocks for bvops, even if that isn't directly > appearing in the "articificial" PSNR value. >=20 > For me, bvhq is just more pleasant bvops. Does that means that it reduces the likelihood of having a blocky video? Regards, Guillaume _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Mon Sep 6 21:35:34 2004 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 44596126D8B for ; Mon, 6 Sep 2004 21:35:34 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 44E251405D; Mon, 6 Sep 2004 21:38:47 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from mwinf1012.wanadoo.fr (smtp10.wanadoo.fr [193.252.22.21]) by edu.bnhof.de (Postfix) with ESMTP id D67FB14057 for ; Mon, 6 Sep 2004 21:38:32 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1012.wanadoo.fr (SMTP Server) with SMTP id BA49518000D7 for ; Mon, 6 Sep 2004 21:35:00 +0200 (CEST) Received: from blackbird.bzh (Mix-Rennes301-1-139.w193-250.abo.wanadoo.fr [193.250.27.139]) by mwinf1012.wanadoo.fr (SMTP Server) with ESMTP id 41F2218000C4 for ; Mon, 6 Sep 2004 21:35:00 +0200 (CEST) Received: from Sketches.bzh (Sketches.bzh [192.168.1.66]) by blackbird.bzh (Postfix) with ESMTP id 68DAB1370A for ; Mon, 6 Sep 2004 17:08:56 +0200 (CEST) Received: by Sketches.bzh (Postfix, from userid 500) id 110C1229BF; Mon, 6 Sep 2004 21:33:34 +0200 (CEST) From: Guillaume POIRIER To: xvid-devel ML Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Message-Id: <1094499214.5277.33.camel@Sketches> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 06 Sep 2004 21:33:34 +0200 Subject: [XviD-devel] XviD options nearly all documented in mencoder... need you help! 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, As you probably know already, I'm taking care of XviD options in English and French's mplayer manpage. Pretty much all options are documented now (the latest patch is on its way to the CVS), except 3 options regarding Aspect Ratio: par, par_width and par_height. par_width and par_height need an integer parameter, and par a string, but I don't know what they mean. If any of you guys can help me here, I'd really appreciate it. Regards, Guillaume --=20 Enfer chr=E9tien, du feu. Enfer pa=EFen, du feu. Enfer mahom=E9tan, du feu.= =20 Enfer hindou, des flammes. =C0 en croire les religions, Dieu est n=E9=20 r=F4tisseur. -+- Hugo, Victor -+- _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Sep 7 00:01:59 2004 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 2FE70126D8B for ; Tue, 7 Sep 2004 00:01:59 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id D5C8A13BD9; Tue, 7 Sep 2004 00:05:21 +0200 (CEST) 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 59DA013AA8 for ; Tue, 7 Sep 2004 00:05:14 +0200 (CEST) Received: from edy by edgomez.kicks-ass.org with local (Exim 4.34) id 1C4RYW-0001FC-GG for xvid-devel@xvid.org; Tue, 07 Sep 2004 00:01:44 +0200 Date: Tue, 7 Sep 2004 00:01:44 +0200 From: Edouard Gomez To: xvid-devel@xvid.org Subject: Re: [XviD-devel] XviD options nearly all documented in mencoder... need you help! Message-ID: <20040906220144.GA2459@edgomez.dyndns.org> Mail-Followup-To: Edouard Gomez , xvid-devel@xvid.org References: <1094499214.5277.33.camel@Sketches> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094499214.5277.33.camel@Sketches> User-Agent: Mutt/1.5.6+20040818i 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 Guillaume POIRIER (guigui-nospam@laposte.net) wrote: > Aspect Ratio: par, par_width and par_height. > par_width and par_height need an integer parameter, and par a string, > but I don't know what they mean. > > If any of you guys can help me here, I'd really appreciate it. PAR means Pixel Aspect Ratio. Not to be confused with DAR which is Display Aspect Ratio. PAR is the ratio of the width and height of a single pixel ! So both ar related as follow: width DAR = PAR * ------- height Ok so here is the par option description: MPEG4 defines 5 standard Pixel Aspect Ratio and one extended one, giving the opportunity to specify a specific pixel aspect ratio. 5 standard modes can be specified using par=xxx, where xx is one of these items: - vga11: it's the usual PAR for PC content. Pixels are a square unit. - pal43: PAL standard 4:3 PAR (see code for exact ratio). Pixels are rectangles - pal169: same here - ntsc43: same here - ntsc169: same here (don't forget to give the exact ratio) You can specify your own pixel aspect ratio using, the "ext" one. So for par=ext, two new options are accessible to specify the width and height rationals for a pixel. - par_width: 0 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 4ADA4126D8B for ; Tue, 7 Sep 2004 17:10:16 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 77E4213F2D; Tue, 7 Sep 2004 17:13:38 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from mwinf0603.wanadoo.fr (smtp6.wanadoo.fr [193.252.22.25]) by edu.bnhof.de (Postfix) with ESMTP id 9CAD613F25 for ; Tue, 7 Sep 2004 17:13:24 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0603.wanadoo.fr (SMTP Server) with SMTP id 3A8C62400141 for ; Tue, 7 Sep 2004 17:09:51 +0200 (CEST) Received: from blackbird.bzh (Mix-Rennes312-3-89.w80-9.abo.wanadoo.fr [80.9.225.89]) by mwinf0603.wanadoo.fr (SMTP Server) with ESMTP id 441802400092 for ; Tue, 7 Sep 2004 17:09:50 +0200 (CEST) Received: from Sketches.bzh (Sketches.bzh [192.168.1.66]) by blackbird.bzh (Postfix) with ESMTP id DD9E6D7A7 for ; Tue, 7 Sep 2004 15:40:54 +0200 (CEST) Received: by Sketches.bzh (Postfix, from userid 500) id 03407252E6; Tue, 7 Sep 2004 17:08:50 +0200 (CEST) Subject: Re: [XviD-devel] XviD options nearly all documented in mencoder... need you help! From: Guillaume POIRIER To: xvid-devel ML In-Reply-To: <20040906220144.GA2459@edgomez.dyndns.org> References: <1094499214.5277.33.camel@Sketches> <20040906220144.GA2459@edgomez.dyndns.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Message-Id: <1094569730.16892.48.camel@Sketches> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 07 Sep 2004 17:08:50 +0200 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, Le mar 07/09/2004 =E0 00:01, Edouard Gomez a =E9crit : > Ok so here is the par option description: [..] Ok, I documented them, and the description looks a lot like what you wrote. It should get into the cvs by tomorrow. > You should insist about the fact what users usually know, is > the DAR not the PAR. It's quite disturbing to set a PAR to > pal43, and don't get a display ratio of 4:3 because the > f(DAR)=3DPAR relation depends also on the sampled image width > and height. Hope you get the idea, better using, autoaspect or > aspect for joe user, it's something he's more used to. Yes, I insisted on that too. > If my module updates go into the CVS, you can also add that if > an extended PAR is specified and matches a standard one, then > the standard will be used for the bitstream syntax, even if > the extended one is still valid syntax. No problem. Could you maybe post on this list or send a private email to me when it get committed? Anyway, big thanks for your explanations. Apart from that I'm still testing the new front-end. I mencoded ;-) "21 grams", which pictures are fairly noisy on some scenes, and it is shot with a "camera on the shoulder" so the camera is pretty much moving all the time, and GMC was probably a bit win here (didn't test with or without, just bvop_hq) without bvop_hq: Video stream: 1487,243 kbit/s (185905 bps) size: 1332027218 bytes=20 7165,080 secs 179130 frames The value 99.99dB is a special value and represents the upper range limit xvid: Min PSNR y : 34,06 dB, u : 42,46 dB, v : 44,47 dB, in frame 112543 xvid: Average PSNR y : 40,76 dB, u : 48,13 dB, v : 48,75 dB, for 179125 frames xvid: Max PSNR y : 99,99 dB, u : 65,35 dB, v : 65,35 dB, in frame 0 with bvop_hq: Video stream: 1487,194 kbit/s (185899 bps) size: 1331982600 bytes=20 7165,080 secs 179130 frames The value 99.99dB is a special value and represents the upper range limit xvid: Min PSNR y : 33,84 dB, u : 44,37 dB, v : 46,44 dB, in frame 145386 xvid: Average PSNR y : 40,86 dB, u : 48,12 dB, v : 48,73 dB, for 179125 frames xvid: Max PSNR y : 99,99 dB, u : 65,35 dB, v : 65,35 dB, in frame 0 Just like last time, bvop_hq improves PSNR and slightly reduces the size of the movie. With my very own eyes, I'd say that the "bvop_hq" option seems to produce smoother pictures, I like its pictures better. If you'd like more tests, you're sure welcome to ask. oh... and did you fix the "duplicate frame" problem? Regards, Guillaume La science n'a pas de patrie. -+- Louis Pasteur -+- _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Sep 7 17:47:59 2004 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 17C04126D8B for ; Tue, 7 Sep 2004 17:47:59 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 4EC7F14092; Tue, 7 Sep 2004 17:51:23 +0200 (CEST) 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 B636B1408E for ; Tue, 7 Sep 2004 17:51:16 +0200 (CEST) Received: from edy by edgomez.kicks-ass.org with local (Exim 4.34) id 1C4iC8-0008EE-Ae for xvid-devel@xvid.org; Tue, 07 Sep 2004 17:47:44 +0200 Date: Tue, 7 Sep 2004 17:47:44 +0200 From: Edouard Gomez To: xvid-devel@xvid.org Subject: Re: [XviD-devel] XviD options nearly all documented in mencoder... need you help! Message-ID: <20040907154744.GB2459@edgomez.dyndns.org> Mail-Followup-To: Edouard Gomez , xvid-devel@xvid.org References: <1094499214.5277.33.camel@Sketches> <20040906220144.GA2459@edgomez.dyndns.org> <1094569730.16892.48.camel@Sketches> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094569730.16892.48.camel@Sketches> User-Agent: Mutt/1.5.6+20040818i 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 Guillaume POIRIER (guigui-nospam@laposte.net) wrote: > If you'd like more tests, you're sure welcome to ask. That's fine. Thanks > oh... and did you fix the "duplicate frame" problem? No, wasn't home yesterday evening/night. I won't have time until... i dunno, all depends on real life stuff i have to do first. -- 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 Sep 11 07:35:07 2004 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 3261F126D8F for ; Sat, 11 Sep 2004 07:35:07 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 3513114172; Sat, 11 Sep 2004 07:38:36 +0200 (CEST) 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 C529D1416F for ; Sat, 11 Sep 2004 07:38:34 +0200 (CEST) Received: from nas-cbv-9-213-228-44-113.dial.proxad.net (nas-cbv-9-213-228-44-113.dial.proxad.net [213.228.44.113]) by postfix3-2.free.fr (Postfix) with ESMTP id 04CD3C354 for ; Sat, 11 Sep 2004 09:30:46 +0200 (CEST) Subject: Re: [XviD-devel] trellis questions From: skal To: xvid-devel@xvid.org In-Reply-To: <4139AE53.9050505@ihug.com.au> References: <4139AE53.9050505@ihug.com.au> Content-Type: text/plain Organization: Message-Id: <1094877932.1876.13.camel@latitude344> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 11 Sep 2004 07:33:27 +0200 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 Syskin and all, On Sat, 2004-09-04 at 14:00, Radek Czyz wrote: > Hi everyone, > > I'm still breaking trellis search :) and I have a question: > > There is a code > > /* source (w/ CBP penalty) */ > Run_Costs[-1] = 2< > As far as I understand, it's an approximation of CBP cost - but I have > absolutely no idea how it works... so, how? It's really a rough approximation, based on few experimentations. This pseudo-cost associated to the node -1 is just an artificial barrier to overcome when any coeff gets coded at all. > Also, how do I change the code if the block is initially empty and I'm > running trellis anyway? (IF I do that. if.) > > Or maybe CBP is just not taken into account? Sure, the real CBP is not taken into account. We only evaluate the save for not coding a block as 2 bits/block, on average. (maybe the real value is a little lower, btw). bye! Skal _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Sep 14 20:57:28 2004 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 ECAFC126D8F for ; Tue, 14 Sep 2004 20:57:27 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id A2B3A13F43; Tue, 14 Sep 2004 21:01:03 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from smtp3k.poczta.onet.pl (smtp3k.poczta.onet.pl [213.180.130.37]) by edu.bnhof.de (Postfix) with ESMTP id CDA2A13F09 for ; Tue, 14 Sep 2004 21:01:01 +0200 (CEST) Received: from pk3.test.onet.pl ([192.168.241.243]:26853 "EHLO pk3.test.onet.pl") by kps3.test.onet.pl with ESMTP id ; Tue, 14 Sep 2004 20:57:03 +0200 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7BIT MIME-Version: 1.0 Received: from 213.180.130.13 by 192.168.240.59 with HTTP; Tue, 14 Sep 2004 20:57:03 +0200 , from 83.27.72.88 by 213.180.130.13 with HTTP Date: Tue, 14 Sep 2004 20:57:03 +0200 From: podolany@autograf.pl To: xvid-devel@xvid.org X-Priority: 3 X-Mailer: onet.poczta Message-Id: <20040914185714Z2663047-3135+49324@kps3.test.onet.pl> Subject: [XviD-devel] problem with xvid bitrate and... partial solution (?) 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 xvid 1.0.2 (or 1.0.1) mplayer 1.0pre5 with ot without --enable-largefiles small (input) files are ok (<500MB, <1h) big (input) files are ok (around 3,6GB mpeg2) in one-pass mode but in the second pass bitrate doesn't make sense (the filesize is the same as in the 1-pass - sometimes >8GB!!!) observation: at the end of the 1-pass xvid-twopass.stats is truncated!!! (my mpeg have over 136000 frames, >90min). If I replace xvid-twopass (I copy it every 5 second, and get one just before truncation) bitrate have more sense (predicted file size is about 680MB, I don't know exactly, bacause the coding is in progress). M. _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Sep 14 21:06:04 2004 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 29DA7126D8F for ; Tue, 14 Sep 2004 21:06:04 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id D7F4913F87; Tue, 14 Sep 2004 21:09:41 +0200 (CEST) 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 9B06C13F22 for ; Tue, 14 Sep 2004 21:09:39 +0200 (CEST) Received: from edy by edgomez.kicks-ass.org with local (Exim 4.34) id 1C7Ico-0001fr-LG for xvid-devel@xvid.org; Tue, 14 Sep 2004 21:05:58 +0200 Date: Tue, 14 Sep 2004 21:05:58 +0200 From: Edouard Gomez To: xvid-devel@xvid.org Subject: Re: [XviD-devel] problem with xvid bitrate and... partial solution (?) Message-ID: <20040914190558.GA2398@edgomez.dyndns.org> Mail-Followup-To: Edouard Gomez , xvid-devel@xvid.org References: <20040914185714Z2663047-3135+49324@kps3.test.onet.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040914185714Z2663047-3135+49324@kps3.test.onet.pl> User-Agent: Mutt/1.5.6+20040818i 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 podolany@autograf.pl (podolany@autograf.pl) wrote: > observation: > at the end of the 1-pass xvid-twopass.stats is truncated!!! This is a known problem of mencoder, the encoding chain is reset when an End Of Stream code is found in the original MPEG sequence (or any other format having similar code). This happens even for small files. This has been discussed long ago, and no solution exists except removing the EOS code from the original stream. -- Edouard Gomez _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Sep 14 21:13:10 2004 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 65027126D8F for ; Tue, 14 Sep 2004 21:13:10 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id C081E1403F; Tue, 14 Sep 2004 21:16:47 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from smtp2k.poczta.onet.pl (smtp2k.poczta.onet.pl [213.180.130.34]) by edu.bnhof.de (Postfix) with ESMTP id A5C6D13BA6 for ; Tue, 14 Sep 2004 21:16:44 +0200 (CEST) Received: from pk4.test.onet.pl ([192.168.241.244]:22674 "EHLO pk4.test.onet.pl") by kps2.test.onet.pl with ESMTP id ; Tue, 14 Sep 2004 21:12:46 +0200 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7BIT MIME-Version: 1.0 Received: from 213.180.130.13 by 192.168.240.54 with HTTP; Tue, 14 Sep 2004 21:12:46 +0200 , from 83.27.72.88 by 213.180.130.13 with HTTP Date: Tue, 14 Sep 2004 21:12:46 +0200 From: podolany@autograf.pl To: xvid-devel@xvid.org Subject: Re: Re: [XviD-devel] problem with xvid bitrate and... partial solution (?) X-Priority: 3 X-Mailer: onet.poczta In-Reply-To: <20040914190558.GA2398@edgomez.dyndns.org> Message-Id: <20040914191256Z135702-28605+83329@kps2.test.onet.pl> 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 User Edouard Gomez wrote: >podolany@autograf.pl (podolany@autograf.pl) wrote: >> observation: >> at the end of the 1-pass xvid-twopass.stats is truncated!!! > > >This is a known problem of mencoder, the encoding chain is >reset when an End Of Stream code is found in the original MPEG >sequence (or any other format having similar code). This >happens even for small files. > >This has been discussed long ago, and no solution exists >except removing the EOS code from the original stream. > >-- >Edouard Gomez >_______________________________________________ >XviD-devel mailing list >XviD-devel@xvid.org >http://list.xvid.org/mailman/listinfo/xvid-devel but.... truncation is done BEFORE the end of the coding (and then the size of the xvid-twopass.. grows). Of course mpeg2 stream can be "corrupted" (created with Pinnacle Studio 9.1..). Is a simple solution to remove EOS from mpeg? M. _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Sep 14 21:23:26 2004 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 0F9F1126D8F for ; Tue, 14 Sep 2004 21:23:26 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 3F1421406A; Tue, 14 Sep 2004 21:27:03 +0200 (CEST) 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 543EB14069 for ; Tue, 14 Sep 2004 21:26:59 +0200 (CEST) Received: from edy by edgomez.kicks-ass.org with local (Exim 4.34) id 1C7Ita-0001mb-Sa for xvid-devel@xvid.org; Tue, 14 Sep 2004 21:23:18 +0200 Date: Tue, 14 Sep 2004 21:23:18 +0200 From: Edouard Gomez To: xvid-devel@xvid.org Subject: Re: Re: [XviD-devel] problem with xvid bitrate and... partial solution (?) Message-ID: <20040914192318.GB2398@edgomez.dyndns.org> Mail-Followup-To: Edouard Gomez , xvid-devel@xvid.org References: <20040914190558.GA2398@edgomez.dyndns.org> <20040914191256Z135702-28605+83329@kps2.test.onet.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040914191256Z135702-28605+83329@kps2.test.onet.pl> User-Agent: Mutt/1.5.6+20040818i 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 podolany@autograf.pl (podolany@autograf.pl) wrote: > but.... > truncation is done BEFORE the end of the coding > (and then the size of the xvid-twopass.. grows). > > Of course mpeg2 stream can be "corrupted" (created > with Pinnacle Studio 9.1..). EOS can happen whenever the MPEG encoder decides to put one. So truncation is caused by mencoder resting the encoding pipeline, as xvid module is just "uninit" and then "config" again, the twopass module happens to truncate the file stats file. > Is a simple solution to remove EOS from mpeg ? Hmmm thibking of a workaround, but that doesn't fix mencoder behavior, it will just make xvid avoid truncating the file. Btw there is even a more detailed description of the mencoder bug you experience right after the patch chunk. --- orig/src/plugins/plugin_2pass1.c +++ mod/src/plugins/plugin_2pass1.c @@ -69,7 +69,7 @@ rc->stat_file = NULL; /* Open the 1st pass file */ - if((rc->stat_file = fopen(param->filename, "w+b")) == NULL) + if((rc->stat_file = fopen(param->filename, "ab")) == NULL) return(XVID_ERR_FAIL); /* I swear xvidcore isn't buggy, but when using mencoder+xvid4 i observe -- Edouard Gomez _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Sep 14 21:37:16 2004 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 36FEA126D8F for ; Tue, 14 Sep 2004 21:37:16 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 0ABCA14097; Tue, 14 Sep 2004 21:40:54 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from smtp3k.poczta.onet.pl (smtp3k.poczta.onet.pl [213.180.130.37]) by edu.bnhof.de (Postfix) with ESMTP id 6721114082 for ; Tue, 14 Sep 2004 21:40:49 +0200 (CEST) Received: from pk4.test.onet.pl ([192.168.241.244]:37288 "EHLO pk4.test.onet.pl") by kps3.test.onet.pl with ESMTP id ; Tue, 14 Sep 2004 21:36:54 +0200 Content-Type: text/plain; charset="iso-8859-2" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Received: from 213.180.130.13 by 192.168.240.59 with HTTP; Tue, 14 Sep 2004 21:36:53 +0200 , from 83.27.72.88 by 213.180.130.13 with HTTP Date: Tue, 14 Sep 2004 21:36:55 +0200 From: podolany@autograf.pl To: xvid-devel@xvid.org Subject: =?ISO-8859-2?Q?Re: Re: Re: [XviD-devel] problem with xvid bitrate and... partial solution = (?)?= X-Priority: 3 X-Mailer: onet.poczta In-Reply-To: <20040914192318.GB2398@edgomez.dyndns.org> Message-Id: <20040914193700Z2661389-6338+86221@kps3.test.onet.pl> 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 U¿ytkownik Edouard Gomez napisa³: >podolany@autograf.pl (podolany@autograf.pl) wrote: >> but.... >> truncation is done BEFORE the end of the coding >> (and then the size of the xvid-twopass.. grows). >> >> Of course mpeg2 stream can be "corrupted" (created >> with Pinnacle Studio 9.1..). > >EOS can happen whenever the MPEG encoder decides to put one. >So truncation is caused by mencoder resting the encoding >pipeline, as xvid module is just "uninit" and then "config" >again, the twopass module happens to truncate the file stats >file. > >> Is a simple solution to remove EOS from mpeg ? > >Hmmm thibking of a workaround, but that doesn\'t fix mencoder >behavior, it will just make xvid avoid truncating the file. >Btw there is even a more detailed description of the mencoder >bug you experience right after the patch chunk. > >--- orig/src/plugins/plugin_2pass1.c >+++ mod/src/plugins/plugin_2pass1.c >@@ -69,7 +69,7 @@ > rc->stat_file = NULL; > > /* Open the 1st pass file */ >- if((rc->stat_file = fopen(param->filename, "w+b")) == NULL) >+ if((rc->stat_file = fopen(param->filename, "ab")) == NULL) > return(XVID_ERR_FAIL); > > /* I swear xvidcore isn\'t buggy, but when using mencoder+xvid4 i observe > >-- >Edouard Gomez Thanks. I'll try it. I think the only disadvantage is that I have to manully remove xvid-two... before another coding. Am I right? M. _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Sep 14 21:44:27 2004 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 07092126D8F for ; Tue, 14 Sep 2004 21:44:27 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 88AE31406B; Tue, 14 Sep 2004 21:48:04 +0200 (CEST) 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 6EA7614056 for ; Tue, 14 Sep 2004 21:48:01 +0200 (CEST) Received: from edy by edgomez.kicks-ass.org with local (Exim 4.34) id 1C7JDx-0001u2-P5 for xvid-devel@xvid.org; Tue, 14 Sep 2004 21:44:21 +0200 Date: Tue, 14 Sep 2004 21:44:21 +0200 From: Edouard Gomez To: xvid-devel@xvid.org Subject: Re: =?us-ascii?B?PT9JU08tODg1OS0yP1E/UmU6?= =?us-ascii?Q?_Re=3A_Re=3A_=5BXviD-devel=5D_proble?= =?us-ascii?Q?m?= with xvid bitrate and... partial solution = (?)?= Message-ID: <20040914194421.GC2398@edgomez.dyndns.org> Mail-Followup-To: Edouard Gomez , xvid-devel@xvid.org References: <20040914192318.GB2398@edgomez.dyndns.org> <20040914193700Z2661389-6338+86221@kps3.test.onet.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040914193700Z2661389-6338+86221@kps3.test.onet.pl> User-Agent: Mutt/1.5.6+20040818i 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 podolany@autograf.pl (podolany@autograf.pl) wrote: > the only disadvantage is that I have to manully remove > xvid-two... before another coding. Am I right? Yup, the "a" flag will never truncate the file, so if a xvid-twopass.stats file exists in the encoding dir, then new stats will be appended to the existing one. -- Edouard Gomez _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Sep 14 21:44:51 2004 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 0C886126D8F for ; Tue, 14 Sep 2004 21:44:51 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id D80A8140BF; Tue, 14 Sep 2004 21:48:26 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from smtp5k.poczta.onet.pl (smtp5k.poczta.onet.pl [213.180.130.50]) by edu.bnhof.de (Postfix) with ESMTP id 811FD140BB for ; Tue, 14 Sep 2004 21:48:23 +0200 (CEST) Received: from pk5.test.onet.pl ([192.168.241.245]:15328 "EHLO pk5.test.onet.pl") by kps5.test.onet.pl with ESMTP id ; Tue, 14 Sep 2004 21:43:52 +0200 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7BIT MIME-Version: 1.0 Received: from 213.180.130.13 by 192.168.240.56 with HTTP; Tue, 14 Sep 2004 21:43:52 +0200 , from 83.27.72.88 by 213.180.130.13 with HTTP Date: Tue, 14 Sep 2004 21:43:52 +0200 From: podolany@autograf.pl To: xvid-devel@xvid.org Subject: =?ISO-8859-2?Q?Re: Re: Re: Re: [XviD-devel] problem with xvid bitrate and... partial solut= ion =3D (?)?= X-Priority: 3 X-Mailer: onet.poczta In-Reply-To: <20040914193700Z2661389-6338+86221@kps3.test.onet.pl> Message-Id: <20040914194359Z4892932-1360+40183@kps5.test.onet.pl> 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 >User Edouard Gomez wrote: >>podolany@autograf.pl (podolany@autograf.pl) wrote: >>> but.... >>> truncation is done BEFORE the end of the coding >>> (and then the size of the xvid-twopass.. grows). >>> >>> Of course mpeg2 stream can be "corrupted" (created >>> with Pinnacle Studio 9.1..). >> >>EOS can happen whenever the MPEG encoder decides to put one. >>So truncation is caused by mencoder resting the encoding >>pipeline, as xvid module is just "uninit" and then "config" >>again, the twopass module happens to truncate the file stats >>file. >> >>> Is a simple solution to remove EOS from mpeg ? >> >>Hmmm thibking of a workaround, but that doesn\\\'t fix mencoder >>behavior, it will just make xvid avoid truncating the file. >>Btw there is even a more detailed description of the mencoder >>bug you experience right after the patch chunk. >> >>--- orig/src/plugins/plugin_2pass1.c >>+++ mod/src/plugins/plugin_2pass1.c >>@@ -69,7 +69,7 @@ >> rc->stat_file = NULL; >> >> /* Open the 1st pass file */ >>- if((rc->stat_file = fopen(param->filename, "w+b")) == NULL) >>+ if((rc->stat_file = fopen(param->filename, "ab")) == NULL) >> return(XVID_ERR_FAIL); >> >> /* I swear xvidcore isn\\\'t buggy, but when using mencoder+xvid4 i observe >> >>-- >>Edouard Gomez > >Thanks. I\'ll try it. I think the only disadvantage is that I have to manully remove >xvid-two... before another coding. Am I right? > > M. > Ok, I'm not right ;-) M. _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Tue Sep 14 22:10:45 2004 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 4232D126D8F for ; Tue, 14 Sep 2004 22:10:45 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id EF4DA140DE; Tue, 14 Sep 2004 22:14:20 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from smtp6k.poczta.onet.pl (smtp6k.poczta.onet.pl [213.180.130.51]) by edu.bnhof.de (Postfix) with ESMTP id 79F93140D6 for ; Tue, 14 Sep 2004 22:14:18 +0200 (CEST) Received: from pk4.test.onet.pl ([192.168.241.244]:62405 "EHLO pk4.test.onet.pl") by kps6.test.onet.pl with ESMTP id ; Tue, 14 Sep 2004 22:09:41 +0200 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7BIT MIME-Version: 1.0 Received: from 213.180.130.13 by 192.168.240.50 with HTTP; Tue, 14 Sep 2004 22:09:41 +0200 , from 83.27.72.88 by 213.180.130.13 with HTTP Date: Tue, 14 Sep 2004 22:09:41 +0200 From: podolany@autograf.pl To: xvid-devel@xvid.org Subject: =?ISO-8859-2?Q?Re: Re: Re: Re: [XviD-devel] problem with xvid bitrate and... partial solut= ion =3D(?)?= X-Priority: 3 X-Mailer: onet.poczta Message-Id: <20040914200953Z4870152-32085+52800@kps6.test.onet.pl> 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 ... > Yup, the "a" flag will never truncate the file, so if a > xvid-twopass.stats file exists in the encoding dir, then new > stats will be appended to the existing one. ..but if I restart mencoder the new file is created. I've just tried it. Coding will last at least 4 hours so I don't know if this change solve my problem. M _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Sep 16 14:00:34 2004 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 7EC96126D8B for ; Thu, 16 Sep 2004 14:00:34 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id CAC5C9C7C; Thu, 16 Sep 2004 14:04:09 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: by edu.bnhof.de (Postfix, from userid 30) id 63EBE9C81; Thu, 16 Sep 2004 14:04:06 +0200 (CEST) Received: from pD9539853.dip.t-dialin.net (pD9539853.dip.t-dialin.net [217.83.152.83]) by www.xvid.org (IMP) with HTTP for ; Thu, 16 Sep 2004 14:04:06 +0200 Message-ID: <1095336246.414981360beef@www.xvid.org> Date: Thu, 16 Sep 2004 14:04:06 +0200 From: Michael Militzer To: xvid-devel@xvid.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-MOQ1095336245faad849eecd3e42d57b182bc3319c31b" User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 217.83.152.83 X-Content-Filtered-By: Mailman/MimeDel 2.1.4 Subject: [XviD-devel] Fwd: Xvid install 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. ---MOQ1095336245faad849eecd3e42d57b182bc3319c31b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, I received this question by private mail. Anyone has an idea? Christoph, iirc you once ported XviD to Solaris (a long time ago), right? Michael ----- Forwarded message from "Coville, Vincent" ----- Date: Tue, 14 Sep 2004 14:24:47 -0400 From: "Coville, Vincent" Reply-To: "Coville, Vincent" Subject: Xvid install To: isibaar@xvid.org Hi I am trying to insall xvid soft. After a succesful "configure" when I do a make I get the following error: make: Fatal error in reader: Makefile, line 81: Badly formed macro assignment Makefile 81 : $(OBJECTS): platform.inc I am working on a Solaris 5.8 platform. Do you have any clue what is wrong here ? Regards Vincent ------------------------------------------------------ Vincent Coville Mentor Emulation Division Technical Marketing Engineer 1001 Ridder Park Drive San Jose CA 95131 Tel: 408 487 7233 http://www.mentor.com Fax: 408 487 7111 vincent_coville@mentor.com ------------------------------------------------------ ----- End forwarded message ----- ---MOQ1095336245faad849eecd3e42d57b182bc3319c31b 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 ---MOQ1095336245faad849eecd3e42d57b182bc3319c31b-- From xvid-devel-bounces@xvid.org Thu Sep 16 16:23:55 2004 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 B5599126D8B for ; Thu, 16 Sep 2004 16:23:55 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 072B6140A8; Thu, 16 Sep 2004 16:27:33 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id 843081409D for ; Thu, 16 Sep 2004 16:27:29 +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 DD34F44FCF for ; Thu, 16 Sep 2004 16:25:23 +0200 (CEST) Date: Thu, 16 Sep 2004 16:23:41 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Fwd: Xvid install In-Reply-To: <1095336246.414981360beef@www.xvid.org> Message-ID: References: <1095336246.414981360beef@www.xvid.org> 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 Thu, 16 Sep 2004, Michael Militzer wrote: > Hi, > > I received this question by private mail. Anyone has an idea? Christoph, > iirc you once ported XviD to Solaris (a long time ago), right? Ported... hm, well, I replaced "make " by "gmake" and it worked, if I remember correctly. So, maybe he just should use gmake instead of make. chl > ----- Forwarded message from "Coville, Vincent" > ----- > Date: Tue, 14 Sep 2004 14:24:47 -0400 > From: "Coville, Vincent" > Reply-To: "Coville, Vincent" > Subject: Xvid install > To: isibaar@xvid.org > > Hi > > I am trying to insall xvid soft. After a succesful "configure" when I > do > a make I get the following error: > > make: Fatal error in reader: Makefile, line 81: Badly formed macro > assignment > > > Makefile 81 : > > $(OBJECTS): platform.inc > > I am working on a Solaris 5.8 platform. > > Do you have any clue what is wrong here ? > > Regards > Vincent > ------------------------------------------------------ > Vincent Coville Mentor Emulation Division > Technical Marketing Engineer 1001 Ridder Park Drive > San Jose CA 95131 > Tel: 408 487 7233 > http://www.mentor.com > Fax: 408 487 7111 vincent_coville@mentor.com > ------------------------------------------------------ > > > > ----- End forwarded message ----- > > > > _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Sat Sep 18 20:30:40 2004 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 E0B02126D92 for ; Sat, 18 Sep 2004 20:30:40 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 2B51814142; Sat, 18 Sep 2004 20:34:22 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from obelix.ee.duth.gr (asterix.ee.duth.gr [193.92.243.98]) by edu.bnhof.de (Postfix) with ESMTP id C36831413E for ; Sat, 18 Sep 2004 20:34:18 +0200 (CEST) Received: from obelix.ee.duth.gr (localhost [127.0.0.1]) by obelix.ee.duth.gr (8.12.10+Sun/8.12.5) with ESMTP id i8IIWX1n017478 for ; Sat, 18 Sep 2004 21:32:33 +0300 (EEST) Received: from localhost (apostolo@localhost) by obelix.ee.duth.gr (8.12.10+Sun/8.12.5/Submit) with ESMTP id i8IIWX1i017475 for ; Sat, 18 Sep 2004 21:32:33 +0300 (EEST) Date: Sat, 18 Sep 2004 21:32:33 +0300 (EEST) From: Apostolos Syropoulos To: xvid-devel@xvid.org In-Reply-To: <1094492878.413ca2ce981e2@webmailb.liv.ac.uk> Message-ID: References: <1094492878.413ca2ce981e2@webmailb.liv.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [XviD-devel] Xvid and mplayer problem 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, I am trying to build MPlayer under Solaris 9 x86 with XviD support. However, when I proceed I am getting the following error messages: vd_xvid.c: In function `init': vd_xvid.c:72: `XVID_INIT_PARAM' undeclared (first use in this function) vd_xvid.c:72: (Each undeclared identifier is reported only once vd_xvid.c:72: for each function it appears in.) vd_xvid.c:72: syntax error before "ini" vd_xvid.c:73: `XVID_DEC_PARAM' undeclared (first use in this function) vd_xvid.c:93: `ini' undeclared (first use in this function) vd_xvid.c:94: `dec_p' undeclared (first use in this function) vd_xvid.c:124: `XVID_CSP_RGB24' undeclared (first use in this function) vd_xvid.c:127: `XVID_CSP_RGB32' undeclared (first use in this function) vd_xvid.c:140: `API_VERSION' undeclared (first use in this function) vd_xvid.c: In function `decode': vd_xvid.c:190: `XVID_DEC_FRAME' undeclared (first use in this function) vd_xvid.c:190: syntax error before "dec" vd_xvid.c:204: `dec' undeclared (first use in this function) Clearly, the undefined structures are documented in API XviD Web page, put they are not included in the file xvid.h. So my questions is what can be done to compile successfully MPlayer? A.S. **************************************************************** *Apostolos Syropoulos * *snail mail: 366, 28th October Str., GR-671 00 Xanthi, HELLAS * *email : apostolo@ocean1.ee.duth.gr * *phone num.: +30-(0)5410-28704 * *home page : http://obelix.ee.duth.gr/~apostolo * **************************************************************** _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Sat Sep 18 20:50:36 2004 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 8001F126D92 for ; Sat, 18 Sep 2004 20:50:36 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 7B58E14151; Sat, 18 Sep 2004 20:54:21 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id A4D401409C for ; Sat, 18 Sep 2004 20:54:18 +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 1BFCE522D2 for ; Sat, 18 Sep 2004 20:52:15 +0200 (CEST) Date: Sat, 18 Sep 2004 20:50:30 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Xvid and mplayer problem In-Reply-To: Message-ID: References: <1094492878.413ca2ce981e2@webmailb.liv.ac.uk> 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 Hi, your version of XviD is outdated. Please download a new (>1.0) version e.g. from the xvid.org homepage. gruel On Sat, 18 Sep 2004, Apostolos Syropoulos wrote: > I am trying to build MPlayer under Solaris 9 x86 with XviD support. > However, when I proceed I am getting the following error messages: > > vd_xvid.c: In function `init': > vd_xvid.c:72: `XVID_INIT_PARAM' undeclared (first use in this function) > vd_xvid.c:72: (Each undeclared identifier is reported only once > vd_xvid.c:72: for each function it appears in.) > vd_xvid.c:72: syntax error before "ini" > vd_xvid.c:73: `XVID_DEC_PARAM' undeclared (first use in this function) > vd_xvid.c:93: `ini' undeclared (first use in this function) > vd_xvid.c:94: `dec_p' undeclared (first use in this function) > vd_xvid.c:124: `XVID_CSP_RGB24' undeclared (first use in this function) > vd_xvid.c:127: `XVID_CSP_RGB32' undeclared (first use in this function) > vd_xvid.c:140: `API_VERSION' undeclared (first use in this function) > vd_xvid.c: In function `decode': > vd_xvid.c:190: `XVID_DEC_FRAME' undeclared (first use in this function) > vd_xvid.c:190: syntax error before "dec" > vd_xvid.c:204: `dec' undeclared (first use in this function) > > Clearly, the undefined structures are documented in API XviD Web page, > put they are not included in the file xvid.h. So my questions is > what can be done to compile successfully MPlayer? > > A.S. > > **************************************************************** > *Apostolos Syropoulos * > *snail mail: 366, 28th October Str., GR-671 00 Xanthi, HELLAS * > *email : apostolo@ocean1.ee.duth.gr * > *phone num.: +30-(0)5410-28704 * > *home page : http://obelix.ee.duth.gr/~apostolo * > **************************************************************** > _______________________________________________ > 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 Sat Sep 18 21:56:59 2004 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 8F1B6126D92 for ; Sat, 18 Sep 2004 21:56:59 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 3EDE013F3C; Sat, 18 Sep 2004 22:00:44 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from obelix.ee.duth.gr (asterix.ee.duth.gr [193.92.243.98]) by edu.bnhof.de (Postfix) with ESMTP id C114013F25 for ; Sat, 18 Sep 2004 22:00:35 +0200 (CEST) Received: from obelix.ee.duth.gr (localhost [127.0.0.1]) by obelix.ee.duth.gr (8.12.10+Sun/8.12.5) with ESMTP id i8IJwp1n017624 for ; Sat, 18 Sep 2004 22:58:51 +0300 (EEST) Received: from localhost (apostolo@localhost) by obelix.ee.duth.gr (8.12.10+Sun/8.12.5/Submit) with ESMTP id i8IJwpmP017621 for ; Sat, 18 Sep 2004 22:58:51 +0300 (EEST) Date: Sat, 18 Sep 2004 22:58:51 +0300 (EEST) From: Apostolos Syropoulos To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Xvid and mplayer problem In-Reply-To: Message-ID: References: <1094492878.413ca2ce981e2@webmailb.liv.ac.uk> 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 Sat, 18 Sep 2004, Christoph Lampert wrote: > > Hi, > > your version of XviD is outdated. Please download a new (>1.0) version > e.g. from the xvid.org homepage. Not really, my libxvidcore.a was build from xvidcore-1.0.2 sources. And strings libxvidcore.a |grep XVID produces nothing! Also, grep XVID_DEC_PARAM xvid.h gives nothing. BTW, can you send me your copy of xvid.h to compare it with mine? Kind regards, A.S. **************************************************************** *Apostolos Syropoulos * *snail mail: 366, 28th October Str., GR-671 00 Xanthi, HELLAS * *email : apostolo@ocean1.ee.duth.gr * *phone num.: +30-(0)5410-28704 * *home page : http://obelix.ee.duth.gr/~apostolo * **************************************************************** _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Sun Sep 19 12:35:40 2004 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 EEDA5126DA9 for ; Sun, 19 Sep 2004 12:35:39 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id F3AB813F5A; Sun, 19 Sep 2004 12:39:25 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id A763F13EEC for ; Sun, 19 Sep 2004 12:39:23 +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 944E15043A for ; Sun, 19 Sep 2004 12:37:19 +0200 (CEST) Date: Sun, 19 Sep 2004 12:35:34 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Xvid and mplayer problem In-Reply-To: Message-ID: References: <1094492878.413ca2ce981e2@webmailb.liv.ac.uk> 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 Oh, okay, then it was vice versa, sorry. Mplayer has two input/output module for XviD, "xvid" and "xvid4". For >=1.0 you need xvid4, and usually this is autodetected in configure. So, in case you didn't, you have to recompile Mplayer. If configure detects the wrong version, you might have an old xvid-lib lying around somewhere in your path. The configure scripts looks for a symbol "xvid_init" in the lib, which is only present in pre-1.0, and for "xvid_global", which is the one >=1.0 uses. gruel On Sat, 18 Sep 2004, Apostolos Syropoulos wrote: > On Sat, 18 Sep 2004, Christoph Lampert wrote: > > > > > Hi, > > > > your version of XviD is outdated. Please download a new (>1.0) version > > e.g. from the xvid.org homepage. > > Not really, my libxvidcore.a was build from xvidcore-1.0.2 sources. > And strings libxvidcore.a |grep XVID produces nothing! Also, > grep XVID_DEC_PARAM xvid.h gives nothing. BTW, can you send me your > copy of xvid.h to compare it with mine? > > Kind regards, > A.S. > > **************************************************************** > *Apostolos Syropoulos * > *snail mail: 366, 28th October Str., GR-671 00 Xanthi, HELLAS * > *email : apostolo@ocean1.ee.duth.gr * > *phone num.: +30-(0)5410-28704 * > *home page : http://obelix.ee.duth.gr/~apostolo * > **************************************************************** > _______________________________________________ > 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 Sep 20 09:58:31 2004 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 8E0E2126DCC for ; Mon, 20 Sep 2004 09:58:31 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 3B8D213F1A; Mon, 20 Sep 2004 10:02:14 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.83]) by edu.bnhof.de (Postfix) with ESMTP id 2616013D70 for ; Mon, 20 Sep 2004 10:01:08 +0200 (CEST) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i8K7vEtf010817 for ; Mon, 20 Sep 2004 00:57:14 -0700 (PDT) Received: from [10.0.1.192] (catv-50626dee.catv.broadband.hu [80.98.109.238]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id i8K7vCvl026847 for ; Mon, 20 Sep 2004 00:57:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: quoted-printable Message-Id: <84346494-0ADA-11D9-805D-0003936A8632@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed To: xvid-devel@xvid.org From: =?ISO-8859-1?Q?Sebesty=E9n_G=E1bor?= Date: Mon, 20 Sep 2004 09:56:02 +0200 X-Mailer: Apple Mail (2.619) Subject: [XviD-devel] accessing pre 1.0 xvid source 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, How can I download pre-1.0 xvid source package? Only the latest release=20= is available on the download page. Thanks, G=E1bor "ALERT! Windows not found! [C]heers, [P]arty or [D]ance?" _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Mon Sep 20 11:06:38 2004 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 E3F0B126DCC for ; Mon, 20 Sep 2004 11:06:38 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 343C614045; Mon, 20 Sep 2004 11:10:26 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from mwinf0603.wanadoo.fr (smtp6.wanadoo.fr [193.252.22.25]) by edu.bnhof.de (Postfix) with ESMTP id 386DA1403E for ; Mon, 20 Sep 2004 11:10:22 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0603.wanadoo.fr (SMTP Server) with SMTP id 3B2852400114 for ; Mon, 20 Sep 2004 11:06:29 +0200 (CEST) Received: from blackbird.bzh (Mix-Rennes312-1-75.w80-9.abo.wanadoo.fr [80.9.223.75]) by mwinf0603.wanadoo.fr (SMTP Server) with ESMTP id CE08C2400108 for ; Mon, 20 Sep 2004 11:06:27 +0200 (CEST) Received: from Sketches.bzh (Sketches.bzh [192.168.1.66]) by blackbird.bzh (Postfix) with ESMTP id 305A7143CB for ; Mon, 20 Sep 2004 11:05:36 +0200 (CEST) Received: by Sketches.bzh (Postfix, from userid 500) id C1A5519B2B; Mon, 20 Sep 2004 11:05:35 +0200 (CEST) Subject: Re: [XviD-devel] accessing pre 1.0 xvid source From: Guillaume POIRIER To: xvid-devel ML In-Reply-To: <84346494-0ADA-11D9-805D-0003936A8632@mac.com> References: <84346494-0ADA-11D9-805D-0003936A8632@mac.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Message-Id: <1095671135.2961.38.camel@Sketches> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 20 Sep 2004 11:05:35 +0200 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, Le lun 20/09/2004 =E0 09:56, Sebesty=E9n G=E1bor a =E9crit : > How can I download pre-1.0 xvid source package? Only the latest release=20 > is available on the download page. > Thanks, You may just wanna have a look at the cvs tarball (there's a link on the homepage). In that case, you'll have, if I recall right more a pre-1.1 than a pre-1.0 as 1.0 is, AFAIK feature-frozen and only for bug-fixes. If you plan to play with new features such as bvhq and use MEncoder for encoding, please make sure to visit Edouard Gomez website and download an updated front-end, and copy ve_xvid4.c and vc_xvid4.c of MPlayer's libmpcodecs/ directory. You might have to pick a cvs version of MPlayer too, but it works ok for me too. Regards, Guillaume --=20 Le style sur l'id=E9e, c'est l'=E9mail sur la dent. -+- Victor Hugo -+- _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Mon Sep 20 13:45:41 2004 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 C421C126DCC for ; Mon, 20 Sep 2004 13:45:41 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 6CF931418C; Mon, 20 Sep 2004 13:49:29 +0200 (CEST) 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 4ED2F14186 for ; Mon, 20 Sep 2004 13:49:25 +0200 (CEST) Received: from imp3-q.free.fr (imp3-q.free.fr [212.27.42.3]) by postfix3-2.free.fr (Postfix) with ESMTP id 3849DE93B for ; Mon, 20 Sep 2004 13:45:19 +0200 (CEST) Received: by imp3-q.free.fr (Postfix, from userid 33) id 28ED322CCE; Mon, 20 Sep 2004 13:45:19 +0200 (MEST) Received: from 195.101.164.39 ([195.101.164.39]) by imp3-q.free.fr (IMP) with HTTP for ; Mon, 20 Sep 2004 13:45:19 +0200 Message-ID: <1095680719.414ec2cf15085@imp3-q.free.fr> Date: Mon, 20 Sep 2004 13:45:19 +0200 From: Edouard Gomez To: xvid-devel@xvid.org Subject: Re: [XviD-devel] accessing pre 1.0 xvid source References: <84346494-0ADA-11D9-805D-0003936A8632@mac.com> In-Reply-To: <84346494-0ADA-11D9-805D-0003936A8632@mac.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.5 X-Originating-IP: 195.101.164.39 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 Sebestyén Gábor : > How can I download pre-1.0 xvid source package? Only the latest release > is available on the download page. > Thanks, You have two options to do so: - cvs, you'll have to dig the mailing list to have the description of all branches and tags to play with. - official tarballs are all available on my site, see: http://ed.gomez.free.fr/#xvid_releases -- Edouard Gomez _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Mon Sep 20 17:12:30 2004 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 54971126DDD for ; Mon, 20 Sep 2004 17:12:30 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 16EF71406F; Mon, 20 Sep 2004 17:16:16 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from weed.lut.ac.uk (weed.lut.ac.uk [158.125.1.226]) by edu.bnhof.de (Postfix) with ESMTP id 5FE151403C for ; Mon, 20 Sep 2004 17:16:12 +0200 (CEST) Received: from [158.125.1.222] (helo=torch.lut.ac.uk) by weed.lut.ac.uk with esmtp (Exim 4.41) id 1C9Ppr-0004Ft-8q for xvid-devel@xvid.org; Mon, 20 Sep 2004 16:12:11 +0100 Received: from apache by torch.lut.ac.uk with local (Exim 4.41) id 1C9Ppr-0005iv-09 for xvid-devel@xvid.org; Mon, 20 Sep 2004 16:12:11 +0100 Received: from elvc-linux3.lut.ac.uk (elvc-linux3.lut.ac.uk [158.125.51.81]) by staff-webmail.lboro.ac.uk (IMP) with HTTP for ; Mon, 20 Sep 2004 16:12:10 +0100 Message-ID: <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> Date: Mon, 20 Sep 2004 16:12:10 +0100 From: Tom Jacobs To: xvid-devel@xvid.org References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> In-Reply-To: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> 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: 158.125.51.81 X-Scan-Signature: e6d65593305a8d9d6cf82f88a7c2d75e Subject: [XviD-devel] Changes to get_pmv2 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 am still threading mostion estimation and am looking at ways of gettin around the problem of each blocks predictions being based on its neighbours. ideally we would make the prediction from the pixel above, below, left and right. because of the scan method used in ME we have changed it to left top and top right. you there be a great quality decrease if it was changed to top left, top, top right? for my work this would make it possible for a whole row to be processed in parallel. what is the best method of testing this change and get a quantitive result of the change. i am not looking to change the xvid source since it works perfectly well in its current state but for my purposes making this change would be handy, if the quality was still achieved. Tom _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Mon Sep 20 17:29:18 2004 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 53361126DDD for ; Mon, 20 Sep 2004 17:29:18 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id AC3C1140C6; Mon, 20 Sep 2004 17:33:06 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id D1A251405B for ; Mon, 20 Sep 2004 17:33:03 +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 0427751B1C for ; Mon, 20 Sep 2004 17:30:59 +0200 (CEST) Date: Mon, 20 Sep 2004 17:29:12 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 In-Reply-To: <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> Message-ID: References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> 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 Mon, 20 Sep 2004, Tom Jacobs wrote: > hi > > i am still threading mostion estimation and am looking at ways of gettin > around the problem of each blocks predictions being based on its > neighbours. > ideally we would make the prediction from the pixel above, below, left and > right. because of the scan method used in ME we have changed it to left top > and top right. > you there be a great quality decrease if it was changed to top left, top, > top right? for my work this would make it possible for a whole row to be > processed in parallel. Hi, the decrease in quality (or rather the raise in bitrate) wouldn't be big, but, if you write the resulting MVs to the bitstream like that, it would violate the MPEG-4 standard, the resulting bitstream wouldn't be playable by MPEG-4 codecs anymore. What you can do is do ME with the "wrong" predictors, but then afterwards use the right predictors to write the bitsream. This will slow the process down a little, and cause another raise in bitrate, but unless you target very low bitrates, I guess it would still be acceptable. However, more important, the gain in speed isn't that big by doing only ME in parallel. I tried a while ago (when machine were much slower), splitting the image vertically in two halfs. But the overhead of creating the threads, doing ME and rejoining the results was bigger than expected. The speedup was less than 10% for 2 CPUs. gruel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Mon Sep 20 18:28:38 2004 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 C6293126DDD for ; Mon, 20 Sep 2004 18:28:38 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id C6D6213BB5; Mon, 20 Sep 2004 18:32:26 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from weed.lut.ac.uk (weed.lut.ac.uk [158.125.1.226]) by edu.bnhof.de (Postfix) with ESMTP id 614C213AA8 for ; Mon, 20 Sep 2004 18:32:23 +0200 (CEST) Received: from [158.125.1.222] (helo=torch.lut.ac.uk) by weed.lut.ac.uk with esmtp (Exim 4.41) id 1C9R1k-0000H4-Hf for xvid-devel@xvid.org; Mon, 20 Sep 2004 17:28:32 +0100 Received: from apache by torch.lut.ac.uk with local (Exim 4.41) id 1C9R1k-00015r-8w for xvid-devel@xvid.org; Mon, 20 Sep 2004 17:28:32 +0100 Received: from elvc-linux3.lut.ac.uk (elvc-linux3.lut.ac.uk [158.125.51.81]) by staff-webmail.lboro.ac.uk (IMP) with HTTP for ; Mon, 20 Sep 2004 17:28:32 +0100 Message-ID: <1095697712.414f05303c7cb@staff-webmail.lboro.ac.uk> Date: Mon, 20 Sep 2004 17:28:32 +0100 From: Tom Jacobs To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> 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.5 X-Originating-IP: 158.125.51.81 X-Scan-Signature: 1a340f988051ab2c1454f838ee5f0a89 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 thank you guel. i will try this. if understand right, to give it a wrong prediction for the left macroblock i can, in get_pmv2, return zeroMV when it looks for the left block. this would make the prediction ignore the block, cos it hasnt got a vector. doing this will not stop the calculated prediction from being stored in the bitstream and from being used when the next row is being calculated. or have i confused myself? or would you need to call get_pmv2 again block my block (in serial) after the searches have been (in parallel) Tom Quoting Christoph Lampert : > On Mon, 20 Sep 2004, Tom Jacobs wrote: > > > hi > > > > i am still threading mostion estimation and am looking at ways of > gettin > > around the problem of each blocks predictions being based on its > > neighbours. > > ideally we would make the prediction from the pixel above, below, left > and > > right. because of the scan method used in ME we have changed it to left > top > > and top right. > > you there be a great quality decrease if it was changed to top left, > top, > > top right? for my work this would make it possible for a whole row to > be > > processed in parallel. > > Hi, > > the decrease in quality (or rather the raise in bitrate) wouldn't be big, > but, if you write the resulting MVs to the bitstream like that, it would > violate the MPEG-4 standard, the resulting bitstream wouldn't be playable > by MPEG-4 codecs anymore. > What you can do is do ME with the "wrong" predictors, but then afterwards > use the right predictors to write the bitsream. This will slow the > process down a little, and cause another raise in bitrate, but unless you > target very low bitrates, I guess it would still be acceptable. > > However, more important, the gain in speed isn't that big by doing only > ME > in parallel. I tried a while ago (when machine were much slower), > splitting the image vertically in two halfs. But the overhead of creating > the threads, doing ME and rejoining the results was bigger than expected. > The speedup was less than 10% for 2 CPUs. > > 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 Mon Sep 20 18:46:32 2004 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 69EA8126DDD for ; Mon, 20 Sep 2004 18:46:32 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 42C081413B; Mon, 20 Sep 2004 18:50:20 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id ECA5114137 for ; Mon, 20 Sep 2004 18:50:17 +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 1FDB251017 for ; Mon, 20 Sep 2004 18:48:13 +0200 (CEST) Date: Mon, 20 Sep 2004 18:46:26 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 In-Reply-To: <1095697712.414f05303c7cb@staff-webmail.lboro.ac.uk> Message-ID: References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> <1095697712.414f05303c7cb@staff-webmail.lboro.ac.uk> 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 Hi, On Mon, 20 Sep 2004, Tom Jacobs wrote: > thank you guel. i will try this. It's gruel with an 'r'. What's "guel" supposed to be? Never heard of it.;-] > if understand right, to give it a wrong prediction for the left macroblock > i can, in get_pmv2, return zeroMV when it looks for the left block. this > would make the prediction ignore the block, cos it hasnt got a vector. If you return zeroMV, it will _not_ ignore that block, but it will treat it as a block with zero motion, like an INTRA-block. That'll make prediction worse, but possibly not too much. It would however be better to use some other vector instead of 0, e.g. top-left or so. > doing this will not stop the calculated prediction from being stored in the > bitstream and from being used when the next row is being calculated. What do you mean by that? > or have i confused myself? > > or would you need to call get_pmv2 again block my block (in serial) after > the searches have been (in parallel) That it is. The predictor (Data->predMV) will be set to the wrong values, therefore the differential motion vector (=MV-predictor) is wrong. That has to be corrected before writing the bitstream, either in a separate loop, or, you have to call the correct get_pmv2() within the bitstream writing process again. gruel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Mon Sep 20 19:11:22 2004 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 0CB51126DDD for ; Mon, 20 Sep 2004 19:11:22 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 29091140D9; Mon, 20 Sep 2004 19:15:10 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from obelix.ee.duth.gr (asterix.ee.duth.gr [193.92.243.98]) by edu.bnhof.de (Postfix) with ESMTP id 43600140CA for ; Mon, 20 Sep 2004 19:15:04 +0200 (CEST) Received: from obelix.ee.duth.gr (localhost [127.0.0.1]) by obelix.ee.duth.gr (8.12.10+Sun/8.12.5) with ESMTP id i8KHD71n022138 for ; Mon, 20 Sep 2004 20:13:07 +0300 (EEST) Received: from localhost (apostolo@localhost) by obelix.ee.duth.gr (8.12.10+Sun/8.12.5/Submit) with ESMTP id i8KHD7Va022135 for ; Mon, 20 Sep 2004 20:13:07 +0300 (EEST) Date: Mon, 20 Sep 2004 20:13:07 +0300 (EEST) From: Apostolos Syropoulos To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Xvid and mplayer problem In-Reply-To: Message-ID: References: <1094492878.413ca2ce981e2@webmailb.liv.ac.uk> 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 Sun, 19 Sep 2004, Christoph Lampert wrote: > > Oh, okay, then it was vice versa, sorry. > > Mplayer has two input/output module for XviD, "xvid" and "xvid4". > For >=1.0 you need xvid4, and usually this is autodetected in configure. > So, in case you didn't, you have to recompile Mplayer. Okay thank you. That really explains the problem. A.S. **************************************************************** *Apostolos Syropoulos * *snail mail: 366, 28th October Str., GR-671 00 Xanthi, HELLAS * *email : apostolo@ocean1.ee.duth.gr * *phone num.: +30-(0)5410-28704 * *home page : http://obelix.ee.duth.gr/~apostolo * **************************************************************** _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Mon Sep 20 20:20:34 2004 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 2B6BB126DDD for ; Mon, 20 Sep 2004 20:20:34 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 52D8A14162; Mon, 20 Sep 2004 20:24:13 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from weed.lut.ac.uk (weed.lut.ac.uk [158.125.1.226]) by edu.bnhof.de (Postfix) with ESMTP id E987D1415F for ; Mon, 20 Sep 2004 20:24:10 +0200 (CEST) Received: from [83.146.12.210] (helo=toms) by weed.lut.ac.uk with smtp (Exim 4.41) id 1C9Slu-0003AF-NC for xvid-devel@xvid.org; Mon, 20 Sep 2004 19:20:19 +0100 Message-ID: <000801c49f3e$c46f1720$1530a8c0@toms> From: "Tom Jacobs" To: References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk><1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk><1095697712.414f05303c7cb@staff-webmail.lboro.ac.uk> Subject: Re: [XviD-devel] Changes to get_pmv2 Date: Mon, 20 Sep 2004 19:21:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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-Scan-Signature: a7cef7777d6de4bfd98ca81a785a349c 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 am I correct in thinking: get_pmv2 sets predMV, the predicted MV SEARCH taking in this prediction and set the &pMB->pmvs[*] if I make get_pmv2 use top left instead of left then it will give me a wrong predMV and hence a wrong pmvs are you saying that it is ok for pmvs to be wrong but I need to correct what? I obviously don't want to have to run SEARCH again since this is the main saving through parallelising it. sorry my depth of knowledge as to what exactly is going and what get written to the bitstream isn't the greatest. thanks for your help gruel Tom ----- Original Message ----- From: "Christoph Lampert" To: Sent: Monday, September 20, 2004 5:46 PM Subject: Re: [XviD-devel] Changes to get_pmv2 > Hi, > > On Mon, 20 Sep 2004, Tom Jacobs wrote: >> thank you guel. i will try this. > > It's gruel with an 'r'. What's "guel" supposed to be? Never heard of > it.;-] > >> if understand right, to give it a wrong prediction for the left >> macroblock >> i can, in get_pmv2, return zeroMV when it looks for the left block. this >> would make the prediction ignore the block, cos it hasnt got a vector. > > If you return zeroMV, it will _not_ ignore that block, but it will treat > it as a block with zero motion, like an INTRA-block. That'll make > prediction worse, but possibly not too much. It would however be better to > use some other vector instead of 0, e.g. top-left or so. > > >> doing this will not stop the calculated prediction from being stored in >> the >> bitstream and from being used when the next row is being calculated. > > What do you mean by that? > >> or have i confused myself? >> >> or would you need to call get_pmv2 again block my block (in serial) after >> the searches have been (in parallel) > > That it is. The predictor (Data->predMV) will be set to the wrong values, > therefore the differential motion vector (=MV-predictor) is wrong. That > has to be corrected before writing the bitstream, either in a separate > loop, or, you have to call the correct get_pmv2() within the bitstream > writing process again. > > 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 Mon Sep 20 20:20:36 2004 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 E866E126DDD for ; Mon, 20 Sep 2004 20:20:35 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id EC9DB14167; Mon, 20 Sep 2004 20:24:20 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from weed.lut.ac.uk (weed.lut.ac.uk [158.125.1.226]) by edu.bnhof.de (Postfix) with ESMTP id C6E6D14164 for ; Mon, 20 Sep 2004 20:24:16 +0200 (CEST) Received: from [83.146.12.210] (helo=toms) by weed.lut.ac.uk with smtp (Exim 4.41) id 1C9Slv-0003AF-P1 for xvid-devel@xvid.org; Mon, 20 Sep 2004 19:20:20 +0100 Message-ID: <000901c49f3e$c4af7b80$1530a8c0@toms> From: "Tom Jacobs" To: References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk><1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk><1095697712.414f05303c7cb@staff-webmail.lboro.ac.uk> Subject: Re: [XviD-devel] Changes to get_pmv2 Date: Mon, 20 Sep 2004 19:22:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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-Scan-Signature: a7cef7777d6de4bfd98ca81a785a349c 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 am I correct in thinking: get_pmv2 sets predMV, the predicted MV SEARCH taking in this prediction and set the &pMB->pmvs[*] if I make get_pmv2 use top left instead of left then it will give me a wrong predMV and hence a wrong pmvs are you saying that it is ok for pmvs to be wrong but I need to correct what? I obviously don't want to have to run SEARCH again since this is the main saving through parallelising it. sorry my depth of knowledge as to what exactly is going and what get written to the bitstream isn't the greatest. thanks for your help gruel Tom ----- Original Message ----- From: "Christoph Lampert" To: Sent: Monday, September 20, 2004 5:46 PM Subject: Re: [XviD-devel] Changes to get_pmv2 > Hi, > > On Mon, 20 Sep 2004, Tom Jacobs wrote: >> thank you guel. i will try this. > > It's gruel with an 'r'. What's "guel" supposed to be? Never heard of > it.;-] > >> if understand right, to give it a wrong prediction for the left >> macroblock >> i can, in get_pmv2, return zeroMV when it looks for the left block. this >> would make the prediction ignore the block, cos it hasnt got a vector. > > If you return zeroMV, it will _not_ ignore that block, but it will treat > it as a block with zero motion, like an INTRA-block. That'll make > prediction worse, but possibly not too much. It would however be better to > use some other vector instead of 0, e.g. top-left or so. > > >> doing this will not stop the calculated prediction from being stored in >> the >> bitstream and from being used when the next row is being calculated. > > What do you mean by that? > >> or have i confused myself? >> >> or would you need to call get_pmv2 again block my block (in serial) after >> the searches have been (in parallel) > > That it is. The predictor (Data->predMV) will be set to the wrong values, > therefore the differential motion vector (=MV-predictor) is wrong. That > has to be corrected before writing the bitstream, either in a separate > loop, or, you have to call the correct get_pmv2() within the bitstream > writing process again. > > 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 Sep 22 06:51:46 2004 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 0DDAB126E03 for ; Wed, 22 Sep 2004 06:51:42 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 9BEEF13F24; Wed, 22 Sep 2004 06:55:28 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from citilindia.com (unknown [61.11.16.237]) by edu.bnhof.de (Postfix) with ESMTP id 9553313EF3 for ; Wed, 22 Sep 2004 06:55:23 +0200 (CEST) Received: from mrugesh [192.168.1.27] by citilindia.com [130.94.222.106] with SMTP (MDaemon.PRO.v4.0.5.R) for ; Wed, 22 Sep 2004 10:25:43 +0530 Message-ID: <001001c49ae7$82036540$1b01a8c0@citpl> From: "prabhakar p" To: Date: Wed, 15 Sep 2004 11:17:37 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-MDRemoteIP: 192.168.1.27 X-Return-Path: prabhakar_p@citilindia.com X-MDaemon-Deliver-To: xvid-devel@xvid.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.4 Subject: [XviD-devel] why DCT image/video compression? 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 Guys, Hope ur doing fine there.Can anybody let me know, what all the = reasons DCT is preferred over other Transformations in image/video = compression techniques. Thanks and regards ---------------------------------------------------- P.Prabhakar (Software Engineer- DSP Group )=20 Conquest Integrated Technologies(india) Pvt.Ltd Aquarius Hous,Sheela Vihar colony, Erandwane,Off Karve road, Pune 400 027. Ph:020 25454081,82,83 Email:- prabhakar_p@citilindia.com URL: www.citilindia.com _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Sep 22 09:01:52 2004 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 A70C8126E12 for ; Wed, 22 Sep 2004 09:01:52 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 27DF113F09; Wed, 22 Sep 2004 09:05:43 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id 5D07A13EE0 for ; Wed, 22 Sep 2004 09:05:39 +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 5D25D51D69 for ; Wed, 22 Sep 2004 09:03:32 +0200 (CEST) Date: Wed, 22 Sep 2004 09:01:43 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] why DCT image/video compression? In-Reply-To: <001001c49ae7$82036540$1b01a8c0@citpl> Message-ID: References: <001001c49ae7$82036540$1b01a8c0@citpl> 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, 15 Sep 2004, prabhakar p wrote: > Hi Guys, > Hope ur doing fine there.Can anybody let me know, what all the > reasons DCT is preferred over other Transformations in image/video > compression techniques. Like _what_ other transformations? DCT is a classical approximation of PCA, and very succesful for it computational efficiency and very good energy compression property. DCT has been used for several decades, and people and device know how to work with it. The only alternatives, which only came up recently are * integer approximations of DCT like in H.264 or WMV9 (IIRC). Those are somehwat less effective, but can be done exact to the bit on PCs, which avoids error drift. So, it's not really a different approach, only an implementation better suited to PCs. * wavelet transforms, which might be "the future", but which are mathematically more difficult, and Motion Estimation has many more problem than in blockbased DCT. Rumors are that RealVideo uses Wavelets, but I never saw anything concrete about it. I haven't even heard rumors about hardware for those. DCT was first and works well, and so far, it's the method of choice (i.e. MPEG2, MPEG4, JPEG, DV), until the new standards really kick in (if they ever do). gruel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Sep 22 12:03:08 2004 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 2E25D126E12 for ; Wed, 22 Sep 2004 12:03:08 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 390CFA370; Wed, 22 Sep 2004 12:06:59 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by edu.bnhof.de (Postfix) with ESMTP id AD9B99C45 for ; Wed, 22 Sep 2004 12:06:56 +0200 (CEST) Received: from nas-cbv-8-213-228-38-169.dial.proxad.net (nas-cbv-8-213-228-38-169.dial.proxad.net [213.228.38.169]) by postfix4-1.free.fr (Postfix) with ESMTP id 2E6F71F337A for ; Wed, 22 Sep 2004 12:03:00 +0200 (CEST) Subject: Re: [XviD-devel] why DCT image/video compression? From: skal To: xvid-devel@xvid.org In-Reply-To: References: <001001c49ae7$82036540$1b01a8c0@citpl> Content-Type: text/plain Organization: Message-Id: <1095846972.3844.6.camel@latitude344> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 22 Sep 2004 11:58:12 +0200 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 all, On Wed, 2004-09-22 at 09:01, Christoph Lampert wrote: > On Wed, 15 Sep 2004, prabhakar p wrote: > > > Hi Guys, > > > Hope ur doing fine there.Can anybody let me know, what all the > > reasons DCT is preferred over other Transformations in image/video > > compression techniques. > more precisely: DCT is a (good) approximation of the optimal Karhunen-Loeve transform that is best at compacting and de-correlating signals modelled as 1rst-order Markov processes. You wouldn't use it for handling radio-activity signals, but for video, that's ok. bye! Skal > Like _what_ other transformations? > > DCT is a classical approximation of PCA, and very succesful for it > computational efficiency and very good energy compression property. > DCT has been used for several decades, and people and device know how to > work with it. The only alternatives, which only came up recently are > > * integer approximations of DCT like in H.264 or WMV9 (IIRC). Those are > somehwat less effective, but can be done exact to the bit on PCs, which > avoids error drift. So, it's not really a different approach, only an > implementation better suited to PCs. > > * wavelet transforms, which might be "the future", but which are > mathematically more difficult, and Motion Estimation has many more > problem than in blockbased DCT. Rumors are that RealVideo uses Wavelets, > but I never saw anything concrete about it. I haven't even heard rumors > about hardware for those. > > DCT was first and works well, and so far, it's the method of choice (i.e. > MPEG2, MPEG4, JPEG, DV), until the new standards really kick in (if they > ever do). -- skal _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Sep 22 12:49:17 2004 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 C0FEB126D8B for ; Wed, 22 Sep 2004 12:49:17 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 85F379C21; Wed, 22 Sep 2004 12:53:08 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from weed.lut.ac.uk (weed.lut.ac.uk [158.125.1.226]) by edu.bnhof.de (Postfix) with ESMTP id 931088E79 for ; Wed, 22 Sep 2004 12:53:06 +0200 (CEST) Received: from [158.125.1.222] (helo=torch.lut.ac.uk) by weed.lut.ac.uk with esmtp (Exim 4.41) id 1CA4gR-0008Gt-GY for xvid-devel@xvid.org; Wed, 22 Sep 2004 11:49:11 +0100 Received: from apache by torch.lut.ac.uk with local (Exim 4.41) id 1CA4gR-00071u-Ad for xvid-devel@xvid.org; Wed, 22 Sep 2004 11:49:11 +0100 Received: from elvc-linux3.lut.ac.uk (elvc-linux3.lut.ac.uk [158.125.51.81]) by staff-webmail.lboro.ac.uk (IMP) with HTTP for ; Wed, 22 Sep 2004 11:49:11 +0100 Message-ID: <1095850151.415158a749674@staff-webmail.lboro.ac.uk> Date: Wed, 22 Sep 2004 11:49:11 +0100 From: Tom Jacobs To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> <1095697712.414f05303c7cb@staff-webmail.lboro.ac.uk> 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.5 X-Originating-IP: 158.125.51.81 X-Scan-Signature: 68d8cd1ffb53493a16677a25202bc5c7 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 in ME is just just the MV for each block that is stored in the bitstream or is somehow the prediction there too? if a full search is taking place how does the predictions matter? does the prediction act as a centre for the search window? when the image is decoded does it just use the MV from the MB itself or does it look at the neighbours or prediction (if saved). im not sure about the differential vector, is this what is actually sorted? i know thats alot of questions in one go but am trying to get my head around what exactly is happening so i can better what i have to do and what can be done in parallel Thanks Tom Quoting Christoph Lampert : > Hi, > > On Mon, 20 Sep 2004, Tom Jacobs wrote: > > thank you guel. i will try this. > > It's gruel with an 'r'. What's "guel" supposed to be? Never heard of > it.;-] > > > if understand right, to give it a wrong prediction for the left > macroblock > > i can, in get_pmv2, return zeroMV when it looks for the left block. > this > > would make the prediction ignore the block, cos it hasnt got a vector. > > If you return zeroMV, it will _not_ ignore that block, but it will treat > it as a block with zero motion, like an INTRA-block. That'll make > prediction worse, but possibly not too much. It would however be better > to > use some other vector instead of 0, e.g. top-left or so. > > > > doing this will not stop the calculated prediction from being stored in > the > > bitstream and from being used when the next row is being calculated. > > What do you mean by that? > > > or have i confused myself? > > > > or would you need to call get_pmv2 again block my block (in serial) > after > > the searches have been (in parallel) > > That it is. The predictor (Data->predMV) will be set to the wrong values, > therefore the differential motion vector (=MV-predictor) is wrong. That > has to be corrected before writing the bitstream, either in a separate > loop, or, you have to call the correct get_pmv2() within the bitstream > writing process again. > > 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 Sep 22 13:50:09 2004 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 7B348126D8B for ; Wed, 22 Sep 2004 13:50:09 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id A6CCEC0B7; Wed, 22 Sep 2004 13:54:00 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from grunt26.ihug.com.au (grunt26.ihug.com.au [203.109.249.146]) by edu.bnhof.de (Postfix) with ESMTP id 59BE7C0B2 for ; Wed, 22 Sep 2004 13:53:56 +0200 (CEST) Received: from dsl-158.160.240.220.lns02-waym-adl.dsl.comindico.com.au [220.240.160.158] by grunt26.ihug.com.au with asmtp (Exim 3.35 #1 (Debian)) id 1CA5dF-0006ET-00; Wed, 22 Sep 2004 21:49:57 +1000 Message-ID: <415167AC.6000202@ihug.com.au> Date: Wed, 22 Sep 2004 21:23:16 +0930 From: Radek Czyz User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> <1095697712.414f05303c7cb@staff-webmail.lboro.ac.uk> <1095850151.415158a749674@staff-webmail.lboro.ac.uk> In-Reply-To: <1095850151.415158a749674@staff-webmail.lboro.ac.uk> 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 Tom Jacobs wrote: > hi > > in ME is just just the MV for each block that is stored in the bitstream or > is somehow the prediction there too? > if a full search is taking place how does the predictions matter? does the > prediction act as a centre for the search window? > when the image is decoded does it just use the MV from the MB itself or does > it look at the neighbours or prediction (if saved). > im not sure about the differential vector, is this what is actually sorted? > > i know thats alot of questions in one go but am trying to get my head around > what exactly is happening so i can better what i have to do and what can be > done in parallel > > Thanks > > Tom Hi, The prediction is also used to calculate how many bits a motion vector will take in a bitstream. Therefore, even at full search, it's pretty much neccessary to have it. Why won't you parallize b-frames first? Any row of any b-frame can be done in any order, so you can easly divide arbitrary number of b-frames into arbitrary number of threads. In 1.1, there is VHQ for b-frames, so I'm pretty sure ME is slow enough to make it worthy. Radek _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Sep 22 14:05:10 2004 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 0361E126D8B for ; Wed, 22 Sep 2004 14:05:10 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 4BA9AC0C5; Wed, 22 Sep 2004 14:09:01 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id 07057C0BF for ; Wed, 22 Sep 2004 14:08:58 +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 C5B5C5121A for ; Wed, 22 Sep 2004 14:06:52 +0200 (CEST) Date: Wed, 22 Sep 2004 14:05:04 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 In-Reply-To: <415167AC.6000202@ihug.com.au> Message-ID: References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> <1095697712.414f05303c7cb@staff-webmail.lboro.ac.uk> <1095850151.415158a749674@staff-webmail.lboro.ac.uk> <415167AC.6000202@ihug.com.au> 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, 22 Sep 2004, Radek Czyz wrote: > Tom Jacobs wrote: > > hi > > > > in ME is just just the MV for each block that is stored in the bitstream or > > is somehow the prediction there too? Not the MV for the block itself is stored to the bitstream, but the differential MV, that is MV minus prediction. When decoding, the predictor is calculated from the previous MVs (if there are any, otherwise it's set to 0), and the predictor plus the value from the bitstream make the current MV (which then is use for the next blocks etc.) > > if a full search is taking place how does the predictions matter? does the > > prediction act as a centre for the search window? That as well, yes. In a way it's the origin for the next MV. > > when the image is decoded does it just use the MV from the MB itself or does > > it look at the neighbours or prediction (if saved). Both. see above. > > im not sure about the differential vector, is this what is actually sorted? sorted? > > i know thats alot of questions in one go but am trying to get my head around > > what exactly is happening so i can better what i have to do and what can be > > done in parallel > > > > Thanks > > > > Tom > > Hi, > The prediction is also used to calculate how many bits a motion vector > will take in a bitstream. Therefore, even at full search, it's pretty > much neccessary to have it. That's what I meant when I said that using a wrong predictor during the search process will hurt compression performance a little. You will ME will find different vectors as "optimal", and possible they will be a little bit worse than the one from original ME. > Why won't you parallize b-frames first? Any row of any b-frame can be > done in any order, so you can easly divide arbitrary number of b-frames > into arbitrary number of threads. In 1.1, there is VHQ for b-frames, so > I'm pretty sure ME is slow enough to make it worthy. Okay, B-frames are a better playing field for speedup than normal ME, because prediction is much simpler. Good idea! Of a real speedup, I'm still not sure, though. I would rather suggest to use create a multithreaded encoder queue, so for one thing, color conversion/pre-/postprocessing etc. runs in parallel with encoding, and in the long run, different scenes (i.e. the segments between two I-VOPs) will be encoded in parallel. The coarses, the better. chl _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Sep 22 14:07:25 2004 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 9D62B126D8B for ; Wed, 22 Sep 2004 14:07:25 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 0CA47C0CE; Wed, 22 Sep 2004 14:11:16 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from weed.lut.ac.uk (weed.lut.ac.uk [158.125.1.226]) by edu.bnhof.de (Postfix) with ESMTP id 121A7C0C9 for ; Wed, 22 Sep 2004 14:11:12 +0200 (CEST) Received: from [158.125.1.222] (helo=torch.lut.ac.uk) by weed.lut.ac.uk with esmtp (Exim 4.41) id 1CA5u2-0004Tk-3t for xvid-devel@xvid.org; Wed, 22 Sep 2004 13:07:18 +0100 Received: from apache by torch.lut.ac.uk with local (Exim 4.41) id 1CA5u1-0003Az-TU for xvid-devel@xvid.org; Wed, 22 Sep 2004 13:07:17 +0100 Received: from elvc-linux3.lut.ac.uk (elvc-linux3.lut.ac.uk [158.125.51.81]) by staff-webmail.lboro.ac.uk (IMP) with HTTP for ; Wed, 22 Sep 2004 13:07:17 +0100 Message-ID: <1095854837.41516af5d7d43@staff-webmail.lboro.ac.uk> Date: Wed, 22 Sep 2004 13:07:17 +0100 From: Tom Jacobs To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> <1095697712.414f05303c7cb@staff-webmail.lboro.ac.uk> <1095850151.415158a749674@staff-webmail.lboro.ac.uk> <415167AC.6000202@ihug.com.au> In-Reply-To: <415167AC.6000202@ihug.com.au> 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: 158.125.51.81 X-Scan-Signature: fd3335a699d7648d35c4a1a5d1bc3849 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 > The prediction is also used to calculate how many bits a motion vector > will take in a bitstream. Therefore, even at full search, it's pretty > much neccessary to have it. but if i give it a wrong prediction andit uses this wrong prediction for its search then the size of the MV will be correct > Why won't you parallize b-frames first? Any row of any b-frame can be > done in any order, so you can easly divide arbitrary number of b-frames > into arbitrary number of threads. does that mean in a B-frame predictions are not made based on top and top right? im still not sure, if the predictions are not stored, why i cant let it predicted from the wrong blocks. i no this is not the way mpeg4 should be but i cant see why it would not be decodable. Tom _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Sep 22 14:14:46 2004 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 AFDC8126D8F for ; Wed, 22 Sep 2004 14:14:46 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id B54F7C0DA; Wed, 22 Sep 2004 14:18:36 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from weed.lut.ac.uk (weed.lut.ac.uk [158.125.1.226]) by edu.bnhof.de (Postfix) with ESMTP id 184B0C0D7 for ; Wed, 22 Sep 2004 14:18:34 +0200 (CEST) Received: from [158.125.1.222] (helo=torch.lut.ac.uk) by weed.lut.ac.uk with esmtp (Exim 4.41) id 1CA619-0004tH-FQ for xvid-devel@xvid.org; Wed, 22 Sep 2004 13:14:39 +0100 Received: from apache by torch.lut.ac.uk with local (Exim 4.41) id 1CA619-0003V0-5u for xvid-devel@xvid.org; Wed, 22 Sep 2004 13:14:39 +0100 Received: from elvc-linux3.lut.ac.uk (elvc-linux3.lut.ac.uk [158.125.51.81]) by staff-webmail.lboro.ac.uk (IMP) with HTTP for ; Wed, 22 Sep 2004 13:14:39 +0100 Message-ID: <1095855279.41516caf25467@staff-webmail.lboro.ac.uk> Date: Wed, 22 Sep 2004 13:14:39 +0100 From: Tom Jacobs To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> <1095697712.414f05303c7cb@staff-webmail.lboro.ac.uk> <1095850151.415158a749674@staff-webmail.lboro.ac.uk> <415167AC.6000202@ihug.com.au> 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.5 X-Originating-IP: 158.125.51.81 X-Scan-Signature: e629fa65265feb9c676f34414e2284f7 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 thanks i think i got the prediction and MV bit now, and yes i see how the prediction need to be correct since they are recalculated in the decoder. so if i set it up so that the main searches are done in parallel with the wrong predictions i can then, in serial, add the wrong predictions to the differential MV and then subtract the correct prediction. would this work? thanskd for the other suggestions and i am not just ignoring them but i am trying to fine grain parall xvid, ive already done it with mpeg2. Thanks Tom Quoting Christoph Lampert : > On Wed, 22 Sep 2004, Radek Czyz wrote: > > Tom Jacobs wrote: > > > hi > > > > > > in ME is just just the MV for each block that is stored in the > bitstream or > > > is somehow the prediction there too? > > Not the MV for the block itself is stored to the bitstream, but the > differential MV, that is MV minus prediction. > When decoding, the predictor is calculated from the previous MVs (if > there > are any, otherwise it's set to 0), and the predictor plus the value from > the bitstream make the current MV (which then is use for the next blocks > etc.) > > > > if a full search is taking place how does the predictions matter? > does the > > > prediction act as a centre for the search window? > > That as well, yes. In a way it's the origin for the next MV. > > > > when the image is decoded does it just use the MV from the MB itself > or does > > > it look at the neighbours or prediction (if saved). > > Both. see above. > > > > im not sure about the differential vector, is this what is actually > sorted? > > sorted? > > > > i know thats alot of questions in one go but am trying to get my head > around > > > what exactly is happening so i can better what i have to do and what > can be > > > done in parallel > > > > > > Thanks > > > > > > Tom > > > > Hi, > > The prediction is also used to calculate how many bits a motion vector > > will take in a bitstream. Therefore, even at full search, it's pretty > > much neccessary to have it. > > That's what I meant when I said that using a wrong predictor during the > search process will hurt compression performance a little. You will ME > will find different vectors as "optimal", and possible they will be a > little bit worse than the one from original ME. > > > Why won't you parallize b-frames first? Any row of any b-frame can be > > done in any order, so you can easly divide arbitrary number of b-frames > > into arbitrary number of threads. In 1.1, there is VHQ for b-frames, so > > I'm pretty sure ME is slow enough to make it worthy. > > Okay, B-frames are a better playing field for speedup than normal ME, > because prediction is much simpler. Good idea! Of a real speedup, I'm > still not sure, though. > I would rather suggest to use create a multithreaded encoder queue, so > for > one thing, color conversion/pre-/postprocessing etc. runs in parallel > with > encoding, and in the long run, different scenes (i.e. the segments > between > two I-VOPs) will be encoded in parallel. The coarses, the better. > > 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 Wed Sep 22 14:20:01 2004 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 824D6126D8F for ; Wed, 22 Sep 2004 14:20:01 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id DB798C0F0; Wed, 22 Sep 2004 14:23:52 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from grunt23.ihug.com.au (grunt23.ihug.com.au [203.109.249.143]) by edu.bnhof.de (Postfix) with ESMTP id 6EF4AC0EE for ; Wed, 22 Sep 2004 14:23:50 +0200 (CEST) Received: from dsl-158.160.240.220.lns02-waym-adl.dsl.comindico.com.au [220.240.160.158] by grunt23.ihug.com.au with asmtp (Exim 3.35 #1 (Debian)) id 1CA669-0001jC-00; Wed, 22 Sep 2004 22:19:49 +1000 Message-ID: <41516EAA.3030502@ihug.com.au> Date: Wed, 22 Sep 2004 21:53:06 +0930 From: Radek Czyz User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> <1095697712.414f05303c7cb@staff-webmail.lboro.ac.uk> <1095850151.415158a749674@staff-webmail.lboro.ac.uk> <415167AC.6000202@ihug.com.au> <1095854837.41516af5d7d43@staff-webmail.lboro.ac.uk> In-Reply-To: <1095854837.41516af5d7d43@staff-webmail.lboro.ac.uk> 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 Tom Jacobs wrote: >>The prediction is also used to calculate how many bits a motion vector >>will take in a bitstream. Therefore, even at full search, it's pretty >>much neccessary to have it. > > > but if i give it a wrong prediction andit uses this wrong prediction for its > search then the size of the MV will be correct Yes, such vector will still work: the differential can be re-calculated later, before it's written to the bitstream. However, any ME must take into account the motion overhead: how many bits it takes to code motion. Any mistake here, even any approximation, will simply ruin the quality of the video. >>Why won't you parallize b-frames first? Any row of any b-frame can be >>done in any order, so you can easly divide arbitrary number of b-frames >>into arbitrary number of threads. > > > does that mean in a B-frame predictions are not made based on top and top > right? Yes. It's much simpler in b-frames, very similar to mpeg 1/2. Every row is independant, prediction is only from left (and reset at boundary). Radek _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Sep 22 16:00:48 2004 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 73974126D8F for ; Wed, 22 Sep 2004 16:00:48 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 821E6BFDF; Wed, 22 Sep 2004 16:04:38 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id 91188BFDC for ; Wed, 22 Sep 2004 16:04:35 +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 7693D5201D for ; Wed, 22 Sep 2004 16:02:29 +0200 (CEST) Date: Wed, 22 Sep 2004 16:00:40 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 In-Reply-To: <1095855279.41516caf25467@staff-webmail.lboro.ac.uk> Message-ID: References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> <1095697712.414f05303c7cb@staff-webmail.lboro.ac.uk> <1095850151.415158a749674@staff-webmail.lboro.ac.uk> <415167AC.6000202@ihug.com.au> <1095855279.41516caf25467@staff-webmail.lboro.ac.uk> 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, 22 Sep 2004, Tom Jacobs wrote: > thanks > > i think i got the prediction and MV bit now, and yes i see how the > prediction need to be correct since they are recalculated in the decoder. > > so if i set it up so that the main searches are done in parallel with the > wrong predictions i can then, in serial, add the wrong predictions to the > differential MV and then subtract the correct prediction. would this work? It should, yes. I guess, it would be cleanst to modify the search then, such that it stores the vector itself (not the differential), and add a little code that before (or while) writing the bitstream, calculates the right predictors and subtracts them. That's a perfectly reasonable way to do ME, and we only chose to directly store the differential, because it saves a few CPU cycles by not having to calculate the predictor again. > thanskd for the other suggestions and i am not just ignoring them but i am > trying to fine grain parall xvid, ive already done it with mpeg2. That's interesting. What encoder, and what were your results? gruel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Sep 22 16:17:24 2004 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 65F35126D8F for ; Wed, 22 Sep 2004 16:17:24 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 69807C001; Wed, 22 Sep 2004 16:21:15 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from guard.polynet.lviv.ua (guard.polynet.lviv.ua [217.9.2.1]) by edu.bnhof.de (Postfix) with SMTP id BF9A6BFF7 for ; Wed, 22 Sep 2004 16:21:09 +0200 (CEST) Received: (qmail 75404 invoked from network); 22 Sep 2004 14:17:11 -0000 Received: from dial72.polynet.lviv.ua (HELO ?217.9.2.72?) (217.9.2.72) by 217.9.2.1 with SMTP; 22 Sep 2004 14:17:11 -0000 Message-ID: <41518964.8060201@polynet.lviv.ua> Date: Wed, 22 Sep 2004 17:17:08 +0300 From: Andrew Voznytsa User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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, Christoph Lampert wrote: >However, more important, the gain in speed isn't that big by doing only ME >in parallel. I tried a while ago (when machine were much slower), >splitting the image vertically in two halfs. But the overhead of creating >the threads, doing ME and rejoining the results was bigger than expected. >The speedup was less than 10% for 2 CPUs. > >gruel > I don't know how you did it exactly, but a few suggestions how to get at least ~30-40% speedup for 2 CPUs: 1) create threads on encoder init stage 2) in I/P VOP case enable VideoPackets, create N (N <= number of cpus) VideoPackets and encode each VideoPacket in his own thread. Under encode I mean everything: ME, DCT, bit packing. On post encode stage you'll have to join N bitstream buffers (not a problem, they'll be byte aligned). 3) in case if B VOPs are present too, try to encode each B VOP (without VideoPackets) in his own thread (as Radek Chyz proposed). Best regards, Andrew Voznytsa _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Sep 22 16:38:56 2004 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 0A63D126D8F for ; Wed, 22 Sep 2004 16:38:56 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 99E94C01F; Wed, 22 Sep 2004 16:42:47 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from weed.lut.ac.uk (weed.lut.ac.uk [158.125.1.226]) by edu.bnhof.de (Postfix) with ESMTP id BE9BEC000 for ; Wed, 22 Sep 2004 16:42:43 +0200 (CEST) Received: from [158.125.1.222] (helo=torch.lut.ac.uk) by weed.lut.ac.uk with esmtp (Exim 4.41) id 1CA8Ge-0005cD-Ju for xvid-devel@xvid.org; Wed, 22 Sep 2004 15:38:48 +0100 Received: from apache by torch.lut.ac.uk with local (Exim 4.41) id 1CA8Ge-0003GT-CV for xvid-devel@xvid.org; Wed, 22 Sep 2004 15:38:48 +0100 Received: from elvc-linux3.lut.ac.uk (elvc-linux3.lut.ac.uk [158.125.51.81]) by staff-webmail.lboro.ac.uk (IMP) with HTTP for ; Wed, 22 Sep 2004 15:38:48 +0100 Message-ID: <1095863928.41518e785775d@staff-webmail.lboro.ac.uk> Date: Wed, 22 Sep 2004 15:38:48 +0100 From: Tom Jacobs To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> <1095697712.414f05303c7cb@staff-webmail.lboro.ac.uk> <1095850151.415158a749674@staff-webmail.lboro.ac.uk> <415167AC.6000202@ihug.com.au> <1095855279.41516caf25467@staff-webmail.lboro.ac.uk> 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.5 X-Originating-IP: 158.125.51.81 X-Scan-Signature: bcec59c75427a16abb5b408c287c6bae 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 my work on mpeg2 has only been simulated in an ideal SimpleScalar simulator. so no realworld results. but it did show a 96% complexity reduction for 20 processors on a 320x240 image. im going to do a cycle actuate model of it later this year and then make me make an rtl model after that. it intended for SoC. well that the plan anyway, have got 2 more years to do something and write my thesis. to clear up a few things while im writtin this. is there a single search function (i no it sound stupid) where the subtraction takes place? if i did stop it from calcuating difference in search would i have to do it in every search method (havent looked in depth at the different searchs)? pmvs[*] and mv16 are the location for the difference MV, correct? or is it mvs[*] ? thanks for all your help Tom Quoting Christoph Lampert : > On Wed, 22 Sep 2004, Tom Jacobs wrote: > > > thanks > > > > i think i got the prediction and MV bit now, and yes i see how the > > prediction need to be correct since they are recalculated in the > decoder. > > > > so if i set it up so that the main searches are done in parallel with > the > > wrong predictions i can then, in serial, add the wrong predictions to > the > > differential MV and then subtract the correct prediction. would this > work? > > It should, yes. I guess, it would be cleanst to modify the search then, > such that it stores the vector itself (not the differential), and add a > little code that before (or while) writing the bitstream, calculates the > right predictors and subtracts them. > That's a perfectly reasonable way to do ME, and we only chose to directly > store the differential, because it saves a few CPU cycles by not having > to > calculate the predictor again. > > > thanskd for the other suggestions and i am not just ignoring them but i > am > > trying to fine grain parall xvid, ive already done it with mpeg2. > > That's interesting. What encoder, and what were your results? > > 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 Sep 22 16:48:34 2004 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 D4978126D8F for ; Wed, 22 Sep 2004 16:48:34 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 8E2B4C02E; Wed, 22 Sep 2004 16:52:26 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id 2AC1DC026 for ; Wed, 22 Sep 2004 16:52:23 +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 25DDE4136D for ; Wed, 22 Sep 2004 16:50:18 +0200 (CEST) Date: Wed, 22 Sep 2004 16:48:29 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 In-Reply-To: <41518964.8060201@polynet.lviv.ua> Message-ID: References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> <41518964.8060201@polynet.lviv.ua> 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, 22 Sep 2004, Andrew Voznytsa wrote: > I don't know how you did it exactly, but a few suggestions how to get at > least ~30-40% speedup for 2 CPUs: > 1) create threads on encoder init stage > 2) in I/P VOP case enable VideoPackets, create N (N <= number of cpus) > VideoPackets and encode each VideoPacket in his own thread. Under encode > I mean everything: ME, DCT, bit packing. On post encode stage you'll > have to join N bitstream buffers (not a problem, they'll be byte aligned). > 3) in case if B VOPs are present too, try to encode each B VOP (without > VideoPackets) in his own thread (as Radek Chyz proposed). Yes, I know, this would be more successful that my approach. What I was referring to was an early test (in 2001), to just do ME in parallel, splitting the image into N (like N=2) vertical stripes and work on each independently (but with the correct predictors, so there was some sync needed where the strips meet). Still, it turned out that there was simply too much overhead involed to be of any use, and that's one of the reason why I have been proposing coarse grain parallelism (as you suggest) instead of splitting individual routines. gruel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Sep 22 17:20:43 2004 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 1DA73126D8F for ; Wed, 22 Sep 2004 17:20:43 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 79E89C01E; Wed, 22 Sep 2004 17:24:34 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from weed.lut.ac.uk (weed.lut.ac.uk [158.125.1.226]) by edu.bnhof.de (Postfix) with ESMTP id DB12FC015 for ; Wed, 22 Sep 2004 17:24:31 +0200 (CEST) Received: from [158.125.1.222] (helo=torch.lut.ac.uk) by weed.lut.ac.uk with esmtp (Exim 4.41) id 1CA8v6-00006r-IT for xvid-devel@xvid.org; Wed, 22 Sep 2004 16:20:36 +0100 Received: from apache by torch.lut.ac.uk with local (Exim 4.41) id 1CA8v6-0005aC-BS for xvid-devel@xvid.org; Wed, 22 Sep 2004 16:20:36 +0100 Received: from elvc-linux3.lut.ac.uk (elvc-linux3.lut.ac.uk [158.125.51.81]) by staff-webmail.lboro.ac.uk (IMP) with HTTP for ; Wed, 22 Sep 2004 16:20:36 +0100 Message-ID: <1095866436.415198444f8aa@staff-webmail.lboro.ac.uk> Date: Wed, 22 Sep 2004 16:20:36 +0100 From: Tom Jacobs To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 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: 158.125.51.81 X-Scan-Signature: 1885d6b4ec7b62b9c6f9448f8871be13 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 is there any specific method or program you would use to measure the degradation of video quality / increase in bitrate. i need to show that by making this change there is a acceptable degradation. Tom Quoting Christoph Lampert : > On Wed, 22 Sep 2004, Tom Jacobs wrote: > > > thanks > > > > i think i got the prediction and MV bit now, and yes i see how the > > prediction need to be correct since they are recalculated in the > decoder. > > > > so if i set it up so that the main searches are done in parallel with > the > > wrong predictions i can then, in serial, add the wrong predictions to > the > > differential MV and then subtract the correct prediction. would this > work? > > It should, yes. I guess, it would be cleanst to modify the search then, > such that it stores the vector itself (not the differential), and add a > little code that before (or while) writing the bitstream, calculates the > right predictors and subtracts them. > That's a perfectly reasonable way to do ME, and we only chose to directly > store the differential, because it saves a few CPU cycles by not having > to > calculate the predictor again. > > > thanskd for the other suggestions and i am not just ignoring them but i > am > > trying to fine grain parall xvid, ive already done it with mpeg2. > > That's interesting. What encoder, and what were your results? > > 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 Sep 22 19:19:14 2004 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 21E2D126D8F for ; Wed, 22 Sep 2004 19:19:14 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 1A7B9C00F; Wed, 22 Sep 2004 19:23:06 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id C48F3C00C for ; Wed, 22 Sep 2004 19:23:03 +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 37D99506FF for ; Wed, 22 Sep 2004 19:20:53 +0200 (CEST) Date: Wed, 22 Sep 2004 19:19:04 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 In-Reply-To: <1095866436.415198444f8aa@staff-webmail.lboro.ac.uk> Message-ID: References: <1095866436.415198444f8aa@staff-webmail.lboro.ac.uk> 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, 22 Sep 2004, Tom Jacobs wrote: > hi > > is there any specific method or program you would use to measure the > degradation of video quality / increase in bitrate. i need to show that by > making this change there is a acceptable degradation. Typically, you plot the PSNR vs. the bitrate, e.g. using the values from the simple xvid_encraw application in the examples. PSNR is not really visual quality, but it's better than nothing. gruel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Wed Sep 22 19:27:34 2004 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 4313C126D8F for ; Wed, 22 Sep 2004 19:27:34 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 0A7D9BFF4; Wed, 22 Sep 2004 19:31:26 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from nil.math.uni-bonn.de (nil.math.uni-bonn.de [131.220.120.11]) by edu.bnhof.de (Postfix) with ESMTP id 9DCF19C24 for ; Wed, 22 Sep 2004 19:31:23 +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 8EAFB519B6 for ; Wed, 22 Sep 2004 19:29:17 +0200 (CEST) Date: Wed, 22 Sep 2004 19:27:28 +0200 (CEST) From: Christoph Lampert To: xvid-devel@xvid.org Subject: Re: [XviD-devel] Changes to get_pmv2 In-Reply-To: <1095863928.41518e785775d@staff-webmail.lboro.ac.uk> Message-ID: References: <1094136571.413732fc0321d@staff-webmail.lboro.ac.uk> <1095693130.414ef34aedd17@staff-webmail.lboro.ac.uk> <1095697712.414f05303c7cb@staff-webmail.lboro.ac.uk> <1095850151.415158a749674@staff-webmail.lboro.ac.uk> <415167AC.6000202@ihug.com.au> <1095855279.41516caf25467@staff-webmail.lboro.ac.uk> <1095863928.41518e785775d@staff-webmail.lboro.ac.uk> 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, 22 Sep 2004, Tom Jacobs wrote: > hi > > my work on mpeg2 has only been simulated in an ideal SimpleScalar simulator. The software from ftp://ftp.cs.wisc.edu/sohi/Code/simplescalar ? > so no realworld results. but it did show a 96% complexity reduction for 20 > processors on a 320x240 image. Hm, can you explain that? 96% complexity reduction means what? That 20 CPUs in parallel need only 4% of the time that 1 CPU needs? That would be a speedup factor of 25, which I supposed is impossible (well, at least very unlikely). And how did you parallelization look like? Just ME? Or everything? I'm really curious, because I did some experiments with parallel video encoding a while ago myself. If you stuff is "private", maybe we can discuss via private mail: gruel@gmx.de gruel _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Sep 23 17:03:09 2004 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 0876B126D8F for ; Thu, 23 Sep 2004 17:03:09 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 89147C02E; Thu, 23 Sep 2004 17:07:00 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from mwinf0203.wanadoo.fr (smtp2.wanadoo.fr [193.252.22.29]) by edu.bnhof.de (Postfix) with ESMTP id E00E6C028 for ; Thu, 23 Sep 2004 17:06:57 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0203.wanadoo.fr (SMTP Server) with SMTP id 741C3100017D for ; Thu, 23 Sep 2004 17:02:58 +0200 (CEST) Received: from blackbird.bzh (Mix-Rennes301-1-97.w193-250.abo.wanadoo.fr [193.250.27.97]) by mwinf0203.wanadoo.fr (SMTP Server) with ESMTP id CEFFA10001C8 for ; Thu, 23 Sep 2004 17:02:57 +0200 (CEST) Received: from Sketches.bzh (Sketches.bzh [192.168.1.66]) by blackbird.bzh (Postfix) with ESMTP id EBF0B1354E for ; Wed, 22 Sep 2004 09:57:09 +0200 (CEST) Received: by Sketches.bzh (Postfix, from userid 500) id 3F67219B1F; Thu, 23 Sep 2004 17:02:14 +0200 (CEST) Subject: Re: [XviD-devel] [FRONTEND UPDATE] mplayer modules. From: Guillaume POIRIER To: xvid-devel ML In-Reply-To: <20040831221818.GA13829@edgomez.dyndns.org> References: <20040831221818.GA13829@edgomez.dyndns.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Message-Id: <1095951734.15548.3.camel@Sketches> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 23 Sep 2004 17:02:14 +0200 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, Le mer 01/09/2004 =E0 00:18, Edouard Gomez a =E9crit : > Hey hey, >=20 > i've been working on mplayer's frontends these last two weeks > (by small touches). >=20 > Decoder updates: > - reads width and height from stream, doesn't trust container > values > - display aspect ratio support >=20 > Encoder updates: > - merged stuff from mplayer's cvs (better fps, par/dar support, > psnr gathering using the same format as lavc module). > Of course that is a "value added"(tm) merge, cleaned > the stuff, moved things where they belong to, and so on. > - added support for bvhq option if compiled with cvs head > xvidcore headers. > - what else... hell just test and give feedback >=20 > Everything up on my site until it's accepted upstream: > http://ed.gomez.free.fr/#mencoder_modules I've been using this new front-end since your released it... Would you like it to get included in MEncoder's cvs? That's likely to improve the userbase of 1.1, which can't be bad, can it? Regards, Guillaume _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Thu Sep 23 19:34:22 2004 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 2C045126D8F for ; Thu, 23 Sep 2004 19:34:22 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 5C76C9C4E; Thu, 23 Sep 2004 19:38:15 +0200 (CEST) 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 E2B309C24 for ; Thu, 23 Sep 2004 19:38:12 +0200 (CEST) Received: from edy by edgomez.kicks-ass.org with local (Exim 4.34) id 1CAXTz-0000rF-GA for xvid-devel@xvid.org; Thu, 23 Sep 2004 19:34:15 +0200 Date: Thu, 23 Sep 2004 19:34:15 +0200 From: Edouard Gomez To: xvid-devel@xvid.org Subject: Re: [XviD-devel] [FRONTEND UPDATE] mplayer modules. Message-ID: <20040923173415.GA3138@edgomez.dyndns.org> Mail-Followup-To: Edouard Gomez , xvid-devel@xvid.org References: <20040831221818.GA13829@edgomez.dyndns.org> <1095951734.15548.3.camel@Sketches> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095951734.15548.3.camel@Sketches> User-Agent: Mutt/1.5.6+20040818i 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 Guillaume POIRIER (guigui-nospam@laposte.net) wrote: > I've been using this new front-end since your released it... > Would you like it to get included in MEncoder's cvs? > That's likely to improve the userbase of 1.1, which can't be > bad, can it? I submited it to iive the day i announced it here, but he has real life stuff to deal with before he merges my changes. If you have CVS access to mplayer, or have more momentum than i have on mplayer's devs... then submit it yourself. -- 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 Sep 23 21:48:13 2004 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 EBA7B126D8F for ; Thu, 23 Sep 2004 21:48:08 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 9EE0ABFDF; Thu, 23 Sep 2004 21:52:02 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from mwinf0506.wanadoo.fr (smtp5.wanadoo.fr [193.252.22.26]) by edu.bnhof.de (Postfix) with ESMTP id E9C85BFC6 for ; Thu, 23 Sep 2004 21:51:59 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0506.wanadoo.fr (SMTP Server) with SMTP id 967B618000C8 for ; Thu, 23 Sep 2004 21:47:33 +0200 (CEST) Received: from blackbird.bzh (Mix-Rennes301-1-59.w193-250.abo.wanadoo.fr [193.250.27.59]) by mwinf0506.wanadoo.fr (SMTP Server) with ESMTP id 0A84518000BB for ; Thu, 23 Sep 2004 21:47:32 +0200 (CEST) Received: from Sketches.bzh (Sketches.bzh [192.168.1.66]) by blackbird.bzh (Postfix) with ESMTP id 112D813673 for ; Wed, 22 Sep 2004 13:40:28 +0200 (CEST) Received: by Sketches.bzh (Postfix, from userid 500) id C9BAD3DEAB; Thu, 23 Sep 2004 21:35:43 +0200 (CEST) Subject: Re: [XviD-devel] [FRONTEND UPDATE] mplayer modules. From: Guillaume POIRIER To: xvid-devel ML In-Reply-To: <20040923173415.GA3138@edgomez.dyndns.org> References: <20040831221818.GA13829@edgomez.dyndns.org> <1095951734.15548.3.camel@Sketches> <20040923173415.GA3138@edgomez.dyndns.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Message-Id: <1095968143.1438.22.camel@Sketches> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 23 Sep 2004 21:35:43 +0200 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, Le jeu 23/09/2004 =E0 19:34, Edouard Gomez a =E9crit : > Guillaume POIRIER (guigui-nospam@laposte.net) wrote: > > I've been using this new front-end since your released it... > > Would you like it to get included in MEncoder's cvs? > > That's likely to improve the userbase of 1.1, which can't be > > bad, can it? >=20 > I submited it to iive the day i announced it here, but he has > real life stuff to deal with before he merges my changes. >=20 > If you have CVS access to mplayer, or have more momentum than > i have on mplayer's devs... then submit it yourself. I do have a CVS access to mplayer, but I'm not the maintainer of that piece of code. I sent it to the ML along with the documentation of bvhq. We'll see how it goes. Regards, Guillaume _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel From xvid-devel-bounces@xvid.org Sat Sep 25 15:56:55 2004 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 63D75126D91 for ; Sat, 25 Sep 2004 15:56:55 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id 32F2613F15; Sat, 25 Sep 2004 16:00:52 +0200 (CEST) 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 725BF13EF3 for ; Sat, 25 Sep 2004 16:00:42 +0200 (CEST) Received: from edy by edgomez.kicks-ass.org with local (Exim 4.34) id 1CBD2X-0002Nv-Fo; Sat, 25 Sep 2004 15:56:41 +0200 Date: Sat, 25 Sep 2004 15:56:41 +0200 From: Edouard Gomez To: Christoph Lampert Message-ID: <20040925135641.GB3140@edgomez.dyndns.org> Mail-Followup-To: Edouard Gomez , Christoph Lampert , xvid-devel ML Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040818i Cc: xvid-devel ML Subject: [XviD-devel] Timestamp question 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 Hey christoph, (i also post to xvid-devel, in case others can help) I'm trying to debug a timestamp problem (at least it looks like it is caused by timestamps) and i' like to have your opinion. Original file: http://gigantic.ath.cx/xvid/test_huff.avi.bz2 (the directory contains the original bug report for xvid 1.0.1, i'm using to reproduce the crash on 1.1 branch, but the divide by zero is gone, the blocking problem is still there tho) Encoded file available at: http://ed.gomez.free.fr/vrac/plop.avi Options used at encoding (note that i disabled closed GOV, which you can't do because it's a flag in mencoder, so you have to disable itin the ve_xvid4.c source): mencoder -o plop.avi -nosound -ovc xvid -xvidencopts pass=2:bitrate=-905:max_bframes=1:chroma_me:vhq=4:cartoon:trellis:min_iquant=1:min_pquant=1:min_bquant=1 test_huff.avi Decoder output is as follow: mplayer -fps 2 -vc xvid -xvidopts debug=-1 test_xvid.avi -quiet 2>&1 | grep ^[IPB] (i patched vd_xvid4.c to accept debug option, and i compiled xvid with --enable-idebug option) I 0:0 P 0:1 P 0:3 B 0:2 P 0:5 B 0:4 P 0:7 B 0:6 P 0:9 B 0:8 P 0:11 B 0:10 P 0:13 B 0:12 P 0:15 B 0:14 P 0:17 B 0:16 P 0:19 B 0:18 P 0:21 B 0:20 P 0:23 B 0:22 P 1:0 B 0:24 P 0:2 B 0:1 P 0:4 B 0:3 P 0:6 B 0:5 P 0:8 B 0:7 P 0:10 B 0:9 P 0:12 B 0:11 P 0:14 B 0:13 P 0:16 B 0:15 P 0:18 B 0:17 P 0:20 B 0:19 P 0:22 B 0:21 P 0:24 B 0:23 P 1:1 B 1:0 P 0:2 P 0:4 B 0:3 P 0:6 B 0:5 P 0:8 B 0:7 P 0:10 B 0:9 P 0:12 B 0:11 P 0:14 B 0:13 P 0:16 B 0:15 P 0:18 B 0:17 P 0:20 B 0:19 P 0:22 B 0:21 P 0:24 B 0:23 P 1:1 B 1:0 P 0:2 P 0:4 B 0:3 I 0:6 B 0:5 P 0:7 P 0:9 B 0:8 P 0:11 B 0:10 P 0:13 B 0:12 P 0:14 P 0:16 B 0:15 P 0:18 B 0:17 P 0:20 B 0:19 P 0:22 <-- the visual bug is somewhere around these frames B 0:21 P 0:24 B 0:23 P 1:1 B 1:0 P 0:2 P 0:3 P 0:4 P 0:5 P 0:7 B 0:6 P 0:8 P 0:10 B 0:9 P 0:12 B 0:11 P 0:14 B 0:13 P 0:16 B 0:15 P 0:18 B 0:17 P 0:20 B 0:19 P 0:22 B 0:21 P 0:24 B 0:23 P 1:1 B 1:0 P 0:3 B 0:2 P 0:5 B 0:4 P 0:7 B 0:6 P 0:9 B 0:8 P 0:11 B 0:10 P 0:13 B 0:12 P 0:15 B 0:14 P 0:17 B 0:16 P 0:19 B 0:18 P 0:21 B 0:20 P 0:23 B 0:22 P 1:0 B 0:24 P 0:2 B 0:1 P 0:4 B 0:3 P 0:6 B 0:5 P 0:8 B 0:7 P 0:10 B 0:9 P 0:12 B 0:11 P 0:14 B 0:13 P 0:16 B 0:15 P 0:18 B 0:17 P 0:20 B 0:19 P 0:22 B 0:21 P 0:24 B 0:23 P 1:1 B 1:0 P 0:3 B 0:2 P 0:5 B 0:4 P 0:7 B 0:6 P 0:9 B 0:8 P 0:11 B 0:10 -- 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 Sep 30 13:39:58 2004 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 7AEC5126D8B for ; Thu, 30 Sep 2004 13:39:58 +0200 (CEST) Received: from edu.bnhof.de (localhost [127.0.0.1]) by edu.bnhof.de (Postfix) with ESMTP id A340B141DB; Thu, 30 Sep 2004 13:43:59 +0200 (CEST) X-Original-To: xvid-devel@xvid.org Delivered-To: xvid-devel@edu.bnhof.de Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by edu.bnhof.de (Postfix) with ESMTP id BCA39141D2 for ; Thu, 30 Sep 2004 13:43:55 +0200 (CEST) Received: from imp4-q.free.fr (imp4-q.free.fr [212.27.42.4]) by postfix3-1.free.fr (Postfix) with ESMTP id 8D1E41742C8; Thu, 30 Sep 2004 13:39:45 +0200 (CEST) Received: by imp4-q.free.fr (Postfix, from userid 33) id 89B4EF005; Thu, 30 Sep 2004 13:39:45 +0200 (MEST) Received: from 195.101.164.39 ([195.101.164.39]) by imp4-q.free.fr (IMP) with HTTP for ; Thu, 30 Sep 2004 13:39:45 +0200 Message-ID: <1096544385.415bf0817f23b@imp4-q.free.fr> Date: Thu, 30 Sep 2004 13:39:45 +0200 From: Edouard Gomez To: Christoph Lampert Subject: Re: [XviD-devel] Timestamp question References: <20040925135641.GB3140@edgomez.dyndns.org> <20040925140605.GC3140@edgomez.dyndns.org> <415BE015.5060207@gmx.de> In-Reply-To: <415BE015.5060207@gmx.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.5 X-Originating-IP: 195.101.164.39 Cc: xvid-devel@xvid.org 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 Hmm sysKin forgot to post a followup concerning this issue, it appears that the bug resides in the VFW application. It asks VFW to decode keyframes twice, so the bframe referencing both the P and I frames was using the iframe as both backward and forward reference as xvid just stacks the last two decoded reference frames. -- Edouard Gomez _______________________________________________ XviD-devel mailing list XviD-devel@xvid.org http://list.xvid.org/mailman/listinfo/xvid-devel