Re: YUV format

Ed Okerson wrote:
> On Thu, 26 Dec 2002, Holger Waechtler wrote:
> 
> 
>>Ed Okerson wrote:
>>
>>>I thought 3D wavelets included the temporal domain as the 3rd dimension.
>>
>>You can enable this by defining N_FRAMES in tarkin.c to anything > 1.
>>IIRC it was hardcoded to 1 because the time domain transform did not
>>gained much - we saw that a 'real' motion compensation would be needed.
> 
> 
> Any value here above 4 causes the encoder to seg fault.  And any value

sounds like a bug introduced while the bitstream format was oggetized...
should not be too hard to find if you want to play with 3d-wavelets 
again. Or you check out a really old w3d version from CVS, I remember in 
the early days the time domain transform worked fine.


> above 1 causes the sdl player to crash before displaying anything.

I never used the SDL player, so I can't say much about this.


>>>I switch to a different source file, and it is more obvious what is
>>>happening.  It appears first as some random noise on the picture and then
>>>the noise level goes up exponentially until it is nothing but random noise
>>>over the entire image.
>>
>>Hmm, I just was running a few frames from the venuscubes test sequence
>>again, I had about the same results as I remembered:
> 
> 
> I am using actual video clips that we use to test other codecs with.
> Video shorts, movie trailers and movie scenes, etc.

As mentioned before, you must not compare to any video codec, you have 
to compare to e.g. JPEG, JPEG2000, MPEG I-Frame compression or other 
still image codecs.


>>First: you want to modify the CFLAGS in the Makefile to enable
>>optimisations (-O3 instead of -O0) and disable debug checks and
>>assertions. Then I was running something like this:
>>
>>$  ./tarkin_enc <path>/AnimSpace0000%01d.ppm 3000 4 4
>>
>>which means that we encode the first 10 frames from venuscube sequence
>>at about 3kBytes per encoded frame using (4,4)-wavelets. When I piped
>>the status messages to /dev/null it needed about 2 seconds on my old
>>vaio at ~500MHz.
> 
> 
> Hmm, this may be a clue.  The video degradation only becomes obvious
> around frame 12, but by frame 30 the original image is indistiguishable.

Again, for still images you only have to compress a few frames.

The bug you describe sounds like one that was fixed once, it was caused 
by incomplete initialisation. Please tell me what sequence you use - 
then I'll take a look on this again.


> If you are only running 10 frame, you would probably never see it.  Also,
> image quality is very poor at anything less than about 80000.

80kBytes per frame? Then your image is either really large or you messed 
something up.

Holger

--- >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 '[email protected]'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.