[theora-dev] encoder discrepancy

[Dan Miller]

the files produced by windows compile vs. Linux are indeed significantly different in size (about 140K vs. 160)  However I'm not convinced all the default parameters are set the same way in the two example files.  This needs to be verified to see if there really is a bug, or can the two versions produce byte-equal output streams?

<p> ___  Dan Miller
(++,) Founder, On2 Technologies

<p>> -----Original Message-----
> From: Dan Miller [mailto:owner-theora-dev at xiph.org]On Behalf Of Dan
> Miller
> Sent: Wednesday, May 28, 2003 5:43 PM
> To: theora-dev at xiph.org
> Subject: autoconf problem
> 
> 
> ./configure: line 524: syntax error near unexpected token 
> `AM_INIT_AUTOMAKE(libtheora,0.0)'
> ./configure: line 524: `AM_INIT_AUTOMAKE(libtheora,0.0)'
> 
> I'm sure I'm doing something pro-stupid, but ---
> my setup works fine for ogg & vorbis.
> autoconf ver 2.13
> automake (GNU automake) 1.4-p4 if that matters
> 
> hey let's put tool version numbers into the README
> 
> -dan
> 
> 
> -----Original Message-----
> From:	Dan Miller on behalf of Dan Miller
> Sent:	Wed 5/28/2003 1:20 PM
> To:	theora-dev at xiph.org
> Cc:	
> Subject:	new patch
> [standard disclaimer about my mail format]
>  
> in ftp.vp3.com/theora
> user: vp3
> pass: vp3dev
> theora_dbm_5-28.zip
>  
> this implements a bitstream change; the header now contains a 
> compressed huffman tree rather than the frequency counts (as 
> discussed)
>  
> pardon my inability to use diff correctly.  The change in 
> toplevel.c is trivial (new function names & params)
> huffman.c is the important one.  I doubt anyone has touched 
> it in a while so I suggest you use this (pulled out of CVS in 
> the last couple days)
>  
> -dan
>  
> 
> -----Original Message----- 
> From: Mike Melanson [mailto:melanson at pcisys.net] 
> Sent: Tue 5/27/2003 2:55 PM 
> To: theora-dev at xiph.org 
> Cc: 
> Subject: Re: [theora-dev] resolution issues
> 
> 
> 
> On Tue, 27 May 2003, Henry Mason  wrote:
> 
> > On a somewhat related note, is there any reason to
> > encode at dimensions which are multiples of 32 in
> > order to have full superblocks? How much do VP3
> > superblocks play a part in the video compression
> > efficiency?
> 
>         Well, a good reason to encode at superblock 
> boundaries is that it
> makes an encoder's life (and source code) much simpler...:) 
> Actually, to
> make it *really* easy, with no corner cases, the dimensions need to be
> divisible by 64 (so the U & V planes line up on 32-sample boundaries).
> 
>         I understand that the point of the superblocks and 
> the associated
> Hilbert coding scan is to maximize proximate similarities 
> (based on the
> principle that pixels close to each other tend to be 
> similar). This will
> be true for most of the image frame; only the outlying areas 
> (right and
> bottom) will not have the benefit of as many neighboring pixels.
> 
> --
>         -Mike Melanson
> 
> --- >8 ----
> List archives:  http://www.xiph.org/archives/
> Ogg project homepage: http://www.xiph.org/ogg/
> To unsubscribe from this list, send a message to 
> 'theora-dev-request at xiph.org'
> containing only the word 'unsubscribe' in the body.  No 
> subject is needed.
> Unsubscribe messages sent to the list will be ignored/filtered.
> 
> 
> 
> 
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'theora-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.