Compression - DCT question

Author

DCT question

Pete Fraser

2007-07-17, 9:55 pm

I want to generate a video signal that, when fed to an
MPEG encoder, will only cause one coefficient to
be active at any one time. Without thinking enough
about it I set up a source that generated 64 full-frame Cos grids
over a period of 64 seconds. Every second the horizontal frequency
would increase (running from DC to 7/8 of Nyquist in 8 steps),
and every 8 seconds the vertical frequency would increase
(running from DC to 7/8 of frame-Nyquist in 8 steps).

I had anticipated some slight "spill over" due to aliasing when
the horizontal frequency was at its highest, but when I looked
at the results things were much messier. (Of course, when
I thought about what would happen as the DCT block boundaries
ran through the phase of the grid, it became obvious why
this didn't work.)

Is there any way to do what I want? The only thing I can
think of is to generate a mosaic of identical tiled 8x8 basis
functions as the video image, ensuring that the tile boundaries
are aligned with the DCT block boundaries. This is going to
be a very strange set of images though. Particularly, there's
going to be a lot of high frequency energy when the tiles
represent odd basis functions. For example, when h is
1/8 Nyquist there is going to be a huge transition every 8
pixels. I'm worried that the energy from this is going to get
aliased down by the A/D in the encoder.

Any thoughts?

I also want to generate 10-bit video white noise. Any thoughts
on a good way to do that in hardware?

Thanks.

Pete

cr88192

2007-07-19, 6:55 pm

"Pete Fraser" <pfraser@covad.net> wrote in message
news:139qng39e97o3e@news.supernews.com...
>I want to generate a video signal that, when fed to an
> MPEG encoder, will only cause one coefficient to
> be active at any one time. Without thinking enough
> about it I set up a source that generated 64 full-frame Cos grids
> over a period of 64 seconds. Every second the horizontal frequency
> would increase (running from DC to 7/8 of Nyquist in 8 steps),
> and every 8 seconds the vertical frequency would increase
> (running from DC to 7/8 of frame-Nyquist in 8 steps).
>

deltas and motion compensation would seem to make this difficult.

> I had anticipated some slight "spill over" due to aliasing when
> the horizontal frequency was at its highest, but when I looked
> at the results things were much messier. (Of course, when
> I thought about what would happen as the DCT block boundaries
> ran through the phase of the grid, it became obvious why
> this didn't work.)
>
> Is there any way to do what I want? The only thing I can
> think of is to generate a mosaic of identical tiled 8x8 basis
> functions as the video image, ensuring that the tile boundaries
> are aligned with the DCT block boundaries. This is going to
> be a very strange set of images though. Particularly, there's
> going to be a lot of high frequency energy when the tiles
> represent odd basis functions. For example, when h is
> 1/8 Nyquist there is going to be a huge transition every 8
> pixels. I'm worried that the energy from this is going to get
> aliased down by the A/D in the encoder.
>

potentially.
with a stock encoder this could be difficult.

> Any thoughts?
>

on your question, not terribly much.

just curious:
anyone have a copy of the MPEG standard?...
I haven't been able to find this before.

ok, ok, at present I generate video as MJPG, possibly a better alternative
might make sense, and I had figured maybe MJPG->MPEG would be probably less
effort than, say, implementing an OGM/Theora encoder...

(oh well, maybe damn my NIH sometimes, but I like avoiding lib or OS
dependencies if possible...).

> I also want to generate 10-bit video white noise. Any thoughts
> on a good way to do that in hardware?
>

not sure...

noise is noise, usually the common method is a prng...

"10-bit"?...

> Thanks.
>
> Pete
>

Pete Fraser

2007-07-19, 6:55 pm

"cr88192" <cr88192@hotmail.com> wrote in message
news:a22a1$469f6cd7$ca83a8d6$27682@saipa
n.com...

>
> deltas and motion compensation would seem to make this difficult.

I should have mentioned that I only care about I frames.

>
> just curious:
> anyone have a copy of the MPEG standard?...

Yes. You can now get it free from ITU (ITU-T H.262-2000)

> noise is noise, usually the common method is a prng...

I'm currently testing a Mersenne Twister.
It looks like this will work for me.
http://www.ht-lab.com/freecores/mt32/mersenne.html
All the table initialization and VHDL code has been written
already, so it should be efortless.

> "10-bit"?...
My hardware has ten bits out for each component.

cr88192

2007-07-22, 3:55 am

"Pete Fraser" <pfraser@covad.net> wrote in message
news:139uscel8rnip51@news.supernews.com...
> "cr88192" <cr88192@hotmail.com> wrote in message
> news:a22a1$469f6cd7$ca83a8d6$27682@saipa
n.com...
>
>
> I should have mentioned that I only care about I frames.
>

ok.

>
> Yes. You can now get it free from ITU (ITU-T H.262-2000)
>

free is good...
may go try to find this.

>
> I'm currently testing a Mersenne Twister.
> It looks like this will work for me.
> http://www.ht-lab.com/freecores/mt32/mersenne.html
> All the table initialization and VHDL code has been written
> already, so it should be efortless.
>
> My hardware has ten bits out for each component.

ok.

on an unrelated note, it seems that the quality of encoded audio makes a
much bigger difference than expected when the audio is being ran through a
mixer (especially when effects such as doppler shifting, ... are involved).
the quality difference between a 11kHz 16bit sound and a lossy 8kHz 8bit
LPC-DPCM version were drastic (with the 11kHz version, one can hear the
effects of the shifting, but at 8kHz one can't).

note, I don't use mp3s or similar, because IME the spectral effects are much
worse (mp3 is only really good if there is no real intention to further
distort the sounds).

may demand either using raw wav files, or implementing a higher-quality
codec (for example, a lossless LPC-DPCM codec).

current possible idea:
predictive filters are used, as before;
samples are encoded using a bytewise VLC scheme;
the output is taken and run through deflate (lazy and works fairly well...).

oh well, good enough...

>

Sponsored Links