Is wavelet encoding the future?

Archived from groups: rec.video.desktop (More info?)

"Jan Panteltje" <pNaonStaemltje@yahoo.com> wrote in message
news:1110028017.cd14d868fed89ddaea1cb5e7bc1e973e@teranews...
>I am experimenting a little now that wavelet encoding in becoming
>avaiilable for
> the desktop.
> The latest version of ffmpeg has support fro the 'snpow' wavelet codec,
> and so has
> the latest version of Linux mplayer. (pre06 beta)
> MPlayer-1.0pre6a.tar.bz2
> ffmpeg and some version of fdshow will do in in win too I think.
>
>
> Last night I started this on a mpeg2 from satellite, 720x576 @25fps.
> Source about < 4000kbps.
> nice -n 19 mencoder q2.mpv -o out.avi -ovc lavc -lavcopts
> vcodec=snow:vstrict=-1:vqscale=3:qpel:v4mv:cmp=1:subcmp=1:mbcmp=1 red=1
>
> This encodes from original size
> 467209047
> to new size
> 140453178
> about a factor 3.3.
>
> Apart from the fact tha ton a Duron 950 mplayer plays it slow... the
> quality
> looking at different sorts of material is very good.
> The encoding time on this same PC is bad 1 to 2 frame / second.
> Given the fact tha tthe original mpeg2 is far from perfect, I can see
> no degradation at this low bitrate.
> The whole clip is 27.5 minutes, so 140453178 bytes in 1650 seconds makes
> 85123 bytes / seconds or 680 kbps.
> So with say 280 MB/ hour we can get 4700 / 280 = 16.7 Hours on a DVD, or >
> 2.5
> hours on a CD-R (not counting audio, but that could be mp3 or AC3).
>
> Now the ONLY issue seems to be one of speed.
> Fron the software point of view, we need for real time encoding a factor
> 25 improvement, with Moore's law
> ( http://www.webopedia.com/TERM/M/Moores_Law.html )
> we can expect doubling evey 18 month of densisty, throw in
> multiprocessing,
> ahum, maybe it works for speed too, 5 x 18 = 90 month = 7.5 years, before
> we
> can do that.
> But IF hardware solutions become available, it could be done today!
> As for the playback, I think it will be OK in 720x576 @ 25fps on a current
> high end
> (highest end ahum) PC today.
>
> I have merely run one experiment, on a limited data set (one program) now.
> Still I like what I see.
> Maybe if we asked for it, some chip manufacturers would make some chips,
> just
> like we now have mpeg2 encoder chips?
>
> References to read (search for keyword 'snow':
> http://ffmpeg.sourceforge.net/ffmpeg-doc.html
> http://forum.doom9.org/showthread.php?s=&threadid=87567...
> http://www.mplayerhq.hu/homepage/design7/news.html

Your results are about the same as what I've seen going from
MPEG2 to MPEG4 and Xvid. You might want to try it at Half
D1 and only 3/4 of the bitrate you used last time.

Luck;
Ken

Archived from groups: rec.video.desktop (More info?)

On a sunny day (Sun, 6 Mar 2005 07:27:15 -0600) it happened "Ken Maltby"
<kmaltby@sbcglobal.net> wrote in <pLWdnbPn9J-PmLbfRVn-jg@giganews.com>:
>
>> References to read (search for keyword 'snow':
>> http://ffmpeg.sourceforge.net/ffmpeg-doc.html
>> http://forum.doom9.org/showthread.php?s=&threadid=87567...
>> http://www.mplayerhq.hu/homepage/design7/news.html
>
> Your results are about the same as what I've seen going from
>MPEG2 to MPEG4 and Xvid. You might want to try it at Half
>D1 and only 3/4 of the bitrate you used last time.
My impression is that the 680 kbs 'snow' wavelet is the same quality as
1000 kbps DivX4

I did an other one (left it running all night) with
nice -n 19 \
mencoder \
q2.mpv \
-o out3.avi \
-ovc lavc \
-lavcopts vcodec=snow:vstrict=-1:vqscale=3:qpel:cmp=1:subcmp=1:mbcmp=1 red=0

-rw-r--r-- 1 root root 467209047 Mar 4 16:45 q2.mpv
-rw-r--r-- 1 root root 123531424 Mar 6 01:37 out3.avi
That is a factor 3.782 compressed.
The bitrate is now 599 kbps.
I have tried lower too, but then it looks ugly really...

As for half D1, well, resizing always introduces artifacts by itself..
But indeed then you get 5 hours on a CD-R...

The thing is, I KNOW what to look for in mpeg2 as artefacts...
here I see some specific things new for me (caused by the wavelet encoding?).
I will have to run some tests on 100% accurate material, some old AVI clips
I made with Blender, the same I used to test the VP6 codec (in HD).
Need a much faster PC...
Can snow be implemented in FPGA?
This all needs more time...
I will have to look at the code of the snow codec...

Archived from groups: rec.video.desktop (More info?)

On a sunny day (Sun, 6 Mar 2005 07:27:15 -0600) it happened "Ken Maltby"
<kmaltby@sbcglobal.net> wrote in <pLWdnbPn9J-PmLbfRVn-jg@giganews.com>:

>The thing is, I KNOW what to look for in mpeg2 as artefacts...
>here I see some specific things new for me (caused by the wavelet encoding?).
>I will have to run some tests on 100% accurate material, some old AVI clips
>I made with Blender, the same I used to test the VP6 codec (in HD).
>Need a much faster PC...
>Can snow be implemented in FPGA?
Want to add to this, I just had a good look at the C code for 'snow.c' in
ffpegg.
I think this is not optimized to the full extend...
It is surprising, the code seems based on the 'lifting' scheme?
Have to read up on that too.
I played around with wavelet before, for my webcam soft,
see http://panteltje.com/panteltje/mcam/ EPIC, now it is years later.

>This all needs more time...
>I will have to look at the code of the snow codec...
And I think this could be implemented in a big FPGA...
Will I try it, I dunno...
Also I am now running some tests encoding blender AVI animation output,
different sizes too, perhaps the bitrate can be even lower ;-)
Playing around with this beats watching TV.
later.. :-)

Archived from groups: rec.video.desktop (More info?)

On a sunny day (Sun, 06 Mar 2005 14:13:01 GMT) it happened Jan Panteltje
<pNaonStpealmtje@yahoo.com> wrote in
<1110118389.396110bc77f87ee4d879eb96d09bd6c2@teranews>:

>The thing is, I KNOW what to look for in mpeg2 as artefacts...
>here I see some specific things new for me (caused by the wavelet encoding?).
>I will have to run some tests on 100% accurate material, some old AVI clips
>I made with Blender, the same I used to test the VP6 codec (in HD).
>Need a much faster PC...
I did a snasty test:
I downloaded part of the blender tutorial... kfipo.avi
http://www.ibiblio.org/bvidtute/
-rw------- 1 root root 66124414 Mar 6 16:03 kfipo.avi

and compressed it with:
nice -n 19 \
mencoder \
kfipo.avi \
-nosound \
-o out5.avi \
-ovc lavc \
-lavcopts vcodec=snow:vstrict=-1:vqscale=3:qpel:cmp=1:subcmp=1:mbcmp=1 red=0

that results in:
-rw-r--r-- 1 root root 39492554 Mar 6 18:35 out5.avi
not even a factor 2, and it looks really bad on some of the the graphics,
(look at those lines on the canvas, form 45 minutes onwards).
So much for that....

But is was a NASTY test :-)
(and I also tried with pred=1, a little betetr, but not much).
So it seems 'wavelet' - at least this snow codec - does not compress SOME
images well.
Especially in these graphics, where actually only the cursor moves (much of
the time), one would expect a very high compression (almost to zero
theoretically), but I get only 50% with bad artefacts.
Maybe 2 systems could be combined, use DCT for some frames, and wavelet
for other... and a flag in each frame sequence GOP to indicate how the decoder
should handle it.
Maybe this would be too 'visible'.
For sure there is a lot that can still be done to improve compression of
images, we should not drop the 'good' of the old system...
Mpeg2 IS really good.
Anyways, I learned some more about wavelet codecs, give it a try :-).
Nothing like hands on experience.

Archived from groups: rec.video.desktop (More info?)

"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message
news:1110151507.dfae2bb34b9deb7e04cdcd39119036a3@teranews...
> On a sunny day (Sun, 06 Mar 2005 14:13:01 GMT) it happened Jan Panteltje
> <pNaonStpealmtje@yahoo.com> wrote in
> <1110118389.396110bc77f87ee4d879eb96d09bd6c2@teranews>:
>
>>The thing is, I KNOW what to look for in mpeg2 as artefacts...
>>here I see some specific things new for me (caused by the wavelet
>>encoding?).
>>I will have to run some tests on 100% accurate material, some old AVI
>>clips
>>I made with Blender, the same I used to test the VP6 codec (in HD).
>>Need a much faster PC...
> I did a snasty test:
> I downloaded part of the blender tutorial... kfipo.avi
> http://www.ibiblio.org/bvidtute/
> -rw------- 1 root root 66124414 Mar 6 16:03 kfipo.avi
>
> and compressed it with:
> nice -n 19 \
> mencoder \
> kfipo.avi \
> -nosound \
> -o out5.avi \
> -ovc lavc \
> -lavcopts
> vcodec=snow:vstrict=-1:vqscale=3:qpel:cmp=1:subcmp=1:mbcmp=1 red=0
>
> that results in:
> -rw-r--r-- 1 root root 39492554 Mar 6 18:35 out5.avi
> not even a factor 2, and it looks really bad on some of the the graphics,
> (look at those lines on the canvas, form 45 minutes onwards).
> So much for that....
>
> But is was a NASTY test :-)
> (and I also tried with pred=1, a little betetr, but not much).
> So it seems 'wavelet' - at least this snow codec - does not compress SOME
> images well.
> Especially in these graphics, where actually only the cursor moves (much
> of
> the time), one would expect a very high compression (almost to zero
> theoretically), but I get only 50% with bad artefacts.
> Maybe 2 systems could be combined, use DCT for some frames, and wavelet
> for other... and a flag in each frame sequence GOP to indicate how the
> decoder
> should handle it.
> Maybe this would be too 'visible'.
> For sure there is a lot that can still be done to improve compression of
> images, we should not drop the 'good' of the old system...
> Mpeg2 IS really good.
> Anyways, I learned some more about wavelet codecs, give it a try :-).
> Nothing like hands on experience.

I'm still licking my wounds from trying the AVC/H264 codec's
that have become available, and it was so promising in the
beginning. What does "Gspot" say about your kfipo.avi test file?
There might be something odd throwing it off.

Luck;
Ken

Archived from groups: rec.video.desktop (More info?)

On Sun, 6 Mar 2005 18:39:35 -0600, in 'rec.video.desktop',
in article <Re: Is wavelet encoding the future?>,
"Ken Maltby" <kmaltby@sbcglobal.net> wrote:
> I'm still licking my wounds from trying the AVC/H264 codec's
>that have become available, and it was so promising in the
>beginning.

Ha! Not laughing at you, Ken, just your experience with a new codec.
Been there, done that. Perhaps Apple's QuickTime Pro 7 implementation
of H.264 will be more to your liking. I know I'm expecting great
things from them.

>What does "Gspot" say about your kfipo.avi test file?

GSpot, a don't leave home without it piece of software.
http://www.headbands.com/gspot/

AVIcodec can also be a useful app to have.
http://avicodec.duby.info/

> Ken

--
Frank, Independent Consultant
New York, NY

[Please remove 'nojunkmail.' from address to reply via e-mail.]

Read Frank's thoughts on HDV at http://www.humanvalues.net/hdv/

Archived from groups: rec.video.desktop (More info?)

On a sunny day (Sun, 6 Mar 2005 18:39:35 -0600) it happened "Ken Maltby"
<kmaltby@sbcglobal.net> wrote in <Uo6dnSxFfZEjP7bfRVn-gA@giganews.com>:

>What does "Gspot" say about your kfipo.avi test file?
>There might be something odd throwing it off.

Hey. I didnt know about Gspot, so I just downloaded it.
Next year? when I need to reboot my linux box (just did my tax stuff
for this year in MS windows), I will install it.
Linux (transcode) has avidump:
panteltje:/reiser# avidump -i kfipo.avi
[audio]: 22050 Hz, format=0x50, bits=0, channels=1, bitrate=32
[video]: 5.000 fps, codec=MP42, frames=17195, width=640, height=480

All I can tell you about it, but if you download it from that link,
you will see what I mean I am sure.
It is just blender user interface screenshot, with the man explaining
by voice, moving mouse cursor, and some editing, picking, rotation,
menu selection.
VERY static, only mouse moves most of the time.

Archived from groups: rec.video.desktop (More info?)

"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message
news:1110208138.4c48617592e27b0083c598dfd0639d90@teranews...
> On a sunny day (Sun, 6 Mar 2005 18:39:35 -0600) it happened "Ken Maltby"
> <kmaltby@sbcglobal.net> wrote in <Uo6dnSxFfZEjP7bfRVn-gA@giganews.com>:
>
>>What does "Gspot" say about your kfipo.avi test file?
>>There might be something odd throwing it off.
>
> Hey. I didnt know about Gspot, so I just downloaded it.
> Next year? when I need to reboot my linux box (just did my tax stuff
> for this year in MS windows), I will install it.
> Linux (transcode) has avidump:
> panteltje:/reiser# avidump -i kfipo.avi
> [audio]: 22050 Hz, format=0x50, bits=0, channels=1, bitrate=32
> [video]: 5.000 fps, codec=MP42, frames=17195, width=640, height=480
>
> All I can tell you about it, but if you download it from that link,
> you will see what I mean I am sure.
> It is just blender user interface screenshot, with the man explaining
> by voice, moving mouse cursor, and some editing, picking, rotation,
> menu selection.
> VERY static, only mouse moves most of the time.

0x50 is MPEG audio, can be 1/2/3 (with MP42 most probably MP3)

MP42 is Microsoft MPEG 4 version 2, or a clone,

If that is really 5 fps as a playback setting, I don't see how it would
be watchable, so I guess that's the rate at which your info program
rendered the video.

MP42 and Xvid produce similar results, but I prefer Xvid.

I would think you would want to do your "testing" with a less
compressed source. Is it a requirement that your wavelet encoder
have MPEG 4 as a source?

Luck;
Ken

Archived from groups: rec.video.desktop (More info?)

On a sunny day (Mon, 7 Mar 2005 10:54:43 -0600) it happened "Ken Maltby"
<kmaltby@sbcglobal.net> wrote in <rYWdncSND-XWGrHfRVn-vw@giganews.com>:

> 0x50 is MPEG audio, can be 1/2/3 (with MP42 most probably MP3)
Yes, but I used the video only.

> MP42 is Microsoft MPEG 4 version 2, or a clone,
>
> If that is really 5 fps as a playback setting, I don't see how it would
>be watchable, so I guess that's the rate at which your info program
>rendered the video.
It is watchable, because it is only mouse movement etc...
Download it!

> MP42 and Xvid produce similar results, but I prefer Xvid.
I very recently (last week) did an other latest Xvid against DivX5 compare.
DivX5 won.
almost latest xvid (I have xvidcore-1.1.0-beta1 too).
/usr/local/lib/libxvidcore.so.4.1
versus older DivX
/root/compile/divx/divx4linux-20030428/libdivxencore.so
And xvid did not want to play in xine even (intermittent).

> I would think you would want to do your "testing" with a less
>compressed source. Is it a requirement that your wavelet encoder
>have MPEG 4 as a source?
It makes the lines (grid) on the blender canvas smear out completely,
those lines are still fine in the original.
There are also other ugly artefacts on buttoareas of the same color.
One can discus this endlessly, best is to try this yourself!
It is likely a wavelet issue, and it seems to me that if you
have a static image (like a shot of a PC screen) that lasts several minutes,
a good compression system should only need to send the occasional 'full
frame' so one can start playback at (almost) any point.
That sort of mechanism does not seem to be present.
I dunno about MS codecs really... the original AVI is really good.