Log in

View Full Version : Ateme H.264 Beta - Bug, Issues and Getting Started


Pages : [1] 2 3 4 5 6 7 8 9

bobololo
31st August 2004, 16:58
Ladies and Gentlemen,

And here we go, the beta packages are currently being sent out, so I really suggest you to check your mailbox :)

Please report your feedback in this thread.

-- bobololo.

superdump
31st August 2004, 17:07
/me is already testing. :D

guldukat
31st August 2004, 17:13
i'm also testing

ps: if you get the LoadLibrary() error message upon registering the directshow filters you need the following dll file msvcr71.dll (http://www.dll-files.com/dllindex/dll-files.shtml?msvcr71)

JohnV
31st August 2004, 17:32
Ok, by permission from bobololo, I post the first few clips encoded with the beta Ateme h264 encoder. For optimal playback, download and install the NeroVision Express package (seeking of h264 is broken at the moment though), or if you are a beta tester, you probably received Ateme decoder filters.

The source matrial is not quite optimal quality wise though but it's not horribly big download like most HD content. It's one of the new 1280x720 DivX High Definition clips: http://trailers.divx.com/Universal/BourneSupremacy_HD.zip (34 MB)
so in any case the result from the transcode is not as good as the source DivX.
Also the encoder switches may not be optimal since this is a very new encoder for me and everybody. No preprocessing used.

First clip is about half the filesize of the DivX clip but with the original resolution (1280x720). Video bitrate is 1900kbps
http://nero.ateme.com/beta_encodes/BourneSupremacy_HD_Ateme-h264_1900kbps.mp4

The next is the same but without B-frames, so it's playable with clearly slower computers (plays on my 1.6Ghz laptop with about 70% cpu with ND/Ateme decoder filter):
http://nero.ateme.com/beta_encodes/BourneSupremacy_HD_Ateme-h264_1900kbps_noB.mp4

Third clip is same HD resolution, but video encoded with 1000kbps:
http://nero.ateme.com/beta_encodes/BourneSupremacy_HD_Ateme-h264_1000kbps.mp4

I did some unoptimzed VP 6.2, WMV9 and Real10 encodes at 1000kbps also. Everybody can make their own comparisons, but to me these Ateme h264 clips show very competitive quality indeed.
I havent tested lower than 1000kbps yet, but at 1000kbps and over, quality is indeed very competitive. My results were that at 1000kbps Ateme h264 looked better than VP 6.2 and Real10, and was quite on par with WMV9 with a bit different type of artifacting. XviD couldn't keep up with the quality in my test. All codecs tested with 2pass vbr. But I won't post other codecs' clip because there's a chance my encodes weren't totally optimal, so test yourself and comment.

Razorblade2000
31st August 2004, 17:40
it would be cool if someone could do some low-bitrate encoding (480*X and a bitrate of 300 kbit/s)

I am really interested how h.264 performs :D

superdump
31st August 2004, 17:46
If you have problems registering (a LoadLibrary() error) the decoder filters you probably need msvcr71.dll. You can obtain it from here (http://www.dll-files.com/dllindex/dll-files.shtml?msvcr71).

Bulletproof
31st August 2004, 17:55
Preliminary results for my own testing so far is very impressive. This is the best H.264 codec hands down right now.

SeeMoreDigital
31st August 2004, 18:21
Since installing the beta software I've been unable to play ordinary Mpeg4/AAC .MP4 encodes in WMP9 - ShowTime is okay though!

I've just used system restore and all is well again. But has anybody else had problems with this, or is it just me?


Cheers

bond
31st August 2004, 18:23
Originally posted by JohnV
The source matrial is not quite optimal quality wise though but it's not horribly big download like most HD content. It's one of the new 1280x720 DivX High Definition clips: http://trailers.divx.com/Universal/BourneSupremacy_HD.zip (34 MB)
so in any case the result from the transcode is not as good as the source DivX.uhm, such sources are far from being optimal, you should use uncompressed or HDTV sources, you will find links to if you use search

JohnV
31st August 2004, 18:32
Originally posted by bond
uhm, such sources are far from being optimal, you should use uncompressed or HDTV sources, you will find links to if you use search
Sure, but not everybody can/want to download 200-800MB in order to see the source and test by themselves. This was a compromise and everybody understands that the source is not optimal, still it's relatively decent.

Selur
31st August 2004, 18:40
on my system it seems like setting "-ref 16" breaks the clips at least for playback

Anyone having the same problem?

Cu Selur

Ps.:
edit: ref 1, 2, ... (testing atm) work fine

WaryWolf
31st August 2004, 19:02
i was having some trouble with the playback filters opening a 800x600 clip, resized to 800x592 and testing it now :)

JohnV
31st August 2004, 19:05
Originally posted by Selur
on my system it seems like setting "-ref 16" breaks the clips at least for playback

Anyone having the same problem?

Cu Selur

Ps.:
edit: ref 1, 2, ... (testing atm) work fine
Ateme dev on #mpeg said:
<_babayaga> -ref 5 is a maximum, above it's useless

Selur
31st August 2004, 19:44
"-ref 5 is a maximum, above it's useless"
he,he okay thx :)

Cu Selur

CruNcher
31st August 2004, 20:28
It can happen that some of your encoded clips do not playback correct in Media Player Classc and couse 100% cpu utilization on load this problem is currently under investigation those clips will play fine via Graphedit and Directshow directly tough so they still can be evaluated stay tuned.

JohnV
31st August 2004, 22:55
Originally posted by Razorblade2000
it would be cool if someone could do some low-bitrate encoding (480*X and a bitrate of 300 kbit/s)

I am really interested how h.264 performs :D
Ok, I got permission from bobololo. Here's a low bitrate clip.
640x256 300kbps h264 video and 48kbps aac-he audio.
Length 1.31 minutes. Size: 3.82 MB
No preprocessing used. I decided to use 640x instead of 480x, maybe 512x could be ideal, but anyway this should be quite nice.

http://www.hydrogenaudio.org/stuff/OutOfTime_Ateme-h264_300kbps.mp4

bond
31st August 2004, 23:18
Originally posted by JohnV
Ok, I got permission from bobololo. Here's a low bitrate clip.what source? dvd or the hd divx stuff?

Again no other Avisynth pre-processing except undot.why do you use undot? for testing it might be better to use no preprocessing at all

I decided to use 640x instead of 480x, maybe 512x could be ideal, but anyway this should be quite niceunless its getting not very blocky its ok to use such a res and h.264 should indeed be stressed :D

JohnV
31st August 2004, 23:25
Originally posted by bond
[B]what source? dvd or the hd divx stuff?
DVD movie.
why do you use undot? for testing it might be better to use no preprocessing at allWell, simply because it comes as default with Gordian Knot 0.28.8 created avs script and I remember reading that since it removes "orphan" pixels, it's ok to be used, doesn't do harm and doesnt change the image practically at all, but can improve compression. Tell me if I'm wrong.

Edit. No undot used anymore because of complaints from bond.

bond
31st August 2004, 23:34
Originally posted by JohnV
Tell me if I'm wrong.well its indeed preprocessing, making the compressibility better by taking out small details, making it harder to spot the codecs own performance

imagine someone preprocessing an audio clip (even if only a little bit), while trying to show an audio codecs performance on hydrogenaudio...

bond
1st September 2004, 00:14
and make sure to use lanczos resize, as its the most accurate resizer + get some sleep ;)

Bulletproof
1st September 2004, 00:17
From my testing right now I think the default settings are able to make a file that looks almost like quantizer 2 in xvid at half the filesize.

Source: Spiderman 2

http://www.boomspeed.com/boya/sp2.JPG

http://www.boomspeed.com/boya/sp3.JPG

http://www.boomspeed.com/boya/sp4.JPG

Tommy Carrot
1st September 2004, 00:29
I've done a few tests, and my opinion so far is quite positive, the output is far more watchable than x264's, the motions are more fluid and natural (this is a serious problem with other h264 codecs), and the blocks are far less pronounced with disabled inloop filter.

Strangely, i got better results with disabled b-frames. Enabling the bidirectional prediction causes some kind of 'stuttering', periodical jumps in the motions (especially during pans), and vibrating blocks (not that annoying, but still...).

By the way, any idea how can i open the MP4 files in avisynth? I didn't have any success with it.

CruNcher
1st September 2004, 01:01
Tommy Carrot
yep im also expirience those slightly jumps

Bulletproof
1st September 2004, 01:01
I don't think you can right now, but I'm not 100% sure. The way I got those screenshots was to create a custom graph in graphedit that outputted a HuffYUV file and then took the screenshots from that. I remember a while back that avisynth had added support for .GRF files (graphedit), maybe its possible to create a graph and have it open in avisynth but im not sure if it will work or not.

Have not expierenced those jumps yet, but I need to do more testing to find out.

Tommy Carrot
1st September 2004, 01:19
Originally posted by Bulletproof
Have not expierenced those jumps yet, but I need to do more testing to find out.
It's more noticable at lower bitrates (i used fixed quant 27).

bobololo
1st September 2004, 01:27
Concerning the jumping blocks you may observe in uniform area at low bitrate, this probably comes from bframes skipped blocks which are too agressively decided. To reduced this effect in the current version you could try to reduce the number of consecutive bframes (-maxb) or disable the bidir prediction. We'll try to find a way to fix that in the next update.

For taking screenshots, to my knowledge the easiest way to proceed is to simply open the render filter properties and to use the snapshot function.

@bulletprof: the initial quantizer is the value used by default at the first pass for vbr and abr modes. For 2 pass encoding, it doesn't really matter since a more suited initial quantizer will be choosen automatically for the second pass using the data of the first pass.

-- bobololo.

minolta
1st September 2004, 05:07
i'm too late to request beta-testing. if okay with bobololo, can somebody post a screenshot of the encoder gui with all advanced settings? i'm just curious...but PLEASE verify with bobololo before posting.
-minolta

Andrey
1st September 2004, 06:58
>>can somebody post a screenshot of the encoder gui
It has no gui :)
BTW, 2 questions:
1. About deblocking filter settings. If I gonna to enable it, what is maximum bitrate recommended and what that -6:6 means ?
Is -6 for less inloop deblocking ?
Now I stayed with default.
2. What about psyhovisual settings ?
What is recommended by devs in this case for DVD encode ?
Leave default ?
------------------------------------------------
Now 50% of second pass of StarWars: Ep II is ready.
1st pass - 20.5fps, second pass ~4fps I think.
clip resolution is 704x416, Undot() only.
Using Celeron 2600.
Waiting... :)

bobololo
1st September 2004, 09:34
Originally posted by minolta
i'm too late to request beta-testing. if okay with bobololo, can somebody post a screenshot of the encoder gui with all advanced settings? i'm just curious...but PLEASE verify with bobololo before posting.
-minolta

Ok here it is :

http://nero.ateme.com/~tchi/gui.PNG :)

@Andrey: deblocking strength -6 means very weak deblocking, 6 means strong deblocking. And regarding the psychovisual, ie may help to have better visual quality. As of now, the effects of psychovisual are not very pronounced, but we're interested to know if you can see something better when using it.

-- bobololo.

thegeby
1st September 2004, 10:04
1st attempt: 2.6 Celeron laptop 4200 rpm HD

Clip 1080P/30fps WMV fed into default encavc. Crashed at 100%. No error messge except Windows kind offer to call home. Resulting MP4 file full size but corrupt.:(

To quote someone in NYC: "I'll be baack"

LostMP4
1st September 2004, 12:00
First encode with nearly-default settings showed no problems and nice overall look, now running a second one:

System

Athlon XP 2600+ (Barton 11.5x166 = 1919 MHz)
1024 MB Ram
Windows XP SP2 (with a lot of stuff installed and removed, really NOT CLEAN, I'll format soon)
Encoding in low priority while using the PC (net-surfing, antivirus and something else)

Input AVS

AviSynth 2.55 RC3
dgmpgdec 1.0.11
MPEG-2 source

Core encoder version 1.0.1.14

Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Rate Control : 2pass
Target Bit Rate : 1200 kb/s
Quality : Extra
Init Quantiser : 20
Max Consecutive BFrames : 3
Deblocking Strength : Adaptive
Num Reference : 5
Psychovisual : 2
Cartoon mode : Off
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 72840 frames processed @ 15.51 fps
-- Start processing pass 2 / 2

(running at about 4 fps)

I want to compare this encode with the same clip encoded with Nero Digital MPEG-4 ASP latest codec (and I'll try the muxer later)

14:30 update:
encode takes about 230 MB RAM
second pass is still running, reaching peaks of about 3600 Kb/s but it appears to be always over 1500Kb/s :rolleyes:

everwicked
1st September 2004, 12:10
Hi everyone,

I just released a VQStudio (subjective) beta (http://www.everwicked.com/vqstudio/beta/index.html) that works well with Ateme's filters (there had to be a work around).

Let me know what's broken :cool:

Cheers

Gabriel_Bouvigne
1st September 2004, 13:21
My poor 256MB laptop is swapping in a crazy way:
130MB of memory to decode a 12.5fps QCIF H264 clip!

Tommy Carrot
1st September 2004, 13:56
Originally posted by thegeby
Crashed at 100%. No error messge except Windows kind offer to call home. Resulting MP4 file full size but corrupt.:(


I experienced the same, it always crashes at the end of a clip. I suspect the b-frames again, because it doesn't happen without them. The resulting file has about the right size, but the index part (or at least i think it is, that part looks very similar to the index table of the avi container) is missing from the end of it, i guess this is why it's unplayable.

Gabriel_Bouvigne
1st September 2004, 14:05
Very low bitrate test:
a 23s QCIF 12.5fps, low motion (caméra café)
-rcmode abr -br 32000

*resulting bitrate is 44kbps, which is severly way off.
Perhaps there should be a more restricted abr mode for short clips or clips that would be streamed (32kbps video + 8kbps AMR would fit in UMTS bandwidth)

*psy 1 helps to keep a few more details on the faces

*psy2 removes too much detail on the background (which is static in my sample). It nearly removed a door from a wall.

edit: I am wondering if the bitrate difference between target and resulting file could be container overhead

edit: -br 32000 and not 32

LostMP4
1st September 2004, 14:17
Originally posted by Gabriel_Bouvigne
Very low bitrate test:
a 23s QCIF 12.5fps, low motion (caméra café)
-rcmode abr -br 32

*resulting bitrate is 44kbps, which is severly way off.
Perhaps there should be a more restricted abr mode for short clips or clips that would be streamed (32kbps video + 8kbps AMR would fit in UMTS bandwidth)

*psy 1 helps to keep a few more details on the faces

*psy2 removes too much detail on the background (which is static in my sample). It nearly removed a door from a wall.

edit: I am wondering if the bitrate difference between target and resulting file could be container overhead

What? Did you select a bitrate of 32 bits/sec? (-br 32)

Gabriel_Bouvigne
1st September 2004, 14:27
No, that is a mistake. I used -br 32000 and not 32.

Regarding my psy2 comment, you can discard it as the increased brightness came from my player.
I tryed again, and I think that the results are quite close to psy1. I perhaps like q1 better than q2.

everwicked
1st September 2004, 14:28
Originally posted by LostMP4
What? Did you select a bitrate of 32 bits/sec? (-br 32)

I guess that's really pushing it huh :D

Gabriel_Bouvigne
1st September 2004, 15:00
Same clip (QCIF, 12.5fps)

Target bitrate: abr 16kbps

At this bitrate, there are a lot of blocking effect when characters are moving, creating stairway effects on sharp diagonal transitions.

In this case, adding -deblock adapt helps a lot to reduce the stairway effect.

Sagittaire
1st September 2004, 15:09
how split H264/ACC/MP4 ... ?

acidsex
1st September 2004, 15:47
Couple questions.

Has it been optimized for speed yet? I am only getting 9fps on a P4 2.5ghz.

Next, during the first pass analysis, is it normal for it to go extremely slow unlike the first pass analysis using Nero Digital?

guldukat
1st September 2004, 15:53
Originally posted by acidsex
Couple questions.

Has it been optimized for speed yet? I am only getting 9fps on a P4 2.5ghz.

Next, during the first pass analysis, is it normal for it to go extremely slow unlike the first pass analysis using Nero Digital?

well h264 aint normal mpeg4, it's much much much more complex, and you can be grateful that it is THAT fast, dont hesitate to compare the speed to other h264 competitors (there are many)

acidsex
1st September 2004, 15:58
Seeking seems to be broken as well using Showtime. Everytime I seek, it freezes and then crashes.

guldukat
1st September 2004, 15:59
Originally posted by acidsex
Seeking seems to be broken as well using Showtime. Everytime I seek, it freezes and then crashes.


if you're a beta tester, you should've received some directshow filters, use them instead of showtime, seeking is supposed to work there

superdump
1st September 2004, 16:12
First batch of results from me: grab them here (http://www.swains.plus.com/superdump/-qual.txt).

All useful information is in the text file.

LostMP4
1st September 2004, 16:13
Originally posted by acidsex

Next, during the first pass analysis, is it normal for it to go extremely slow unlike the first pass analysis using Nero Digital?

AVC first pass is extremely slow compared to ASP, but about 3-4 times faster than AVC second pass

superdump
1st September 2004, 16:19
Originally posted by LostMP4
AVC first pass is extremely slow compared to ASP, but about 3-4 times faster than AVC second pass There's a fast first pass on long clips but not on short clips. I don't know what the cutoff number of frames is though.

Tommy Carrot
1st September 2004, 16:24
I know this might sound stupid, but i got better results with 'normal' quality mode than with 'best', at higher bitrates (720x288@1200 kbps). Somehow it's sharper and has more details. At lower bitrates, it's not true anymore, the more accurate rendition of the motions of 'best' quality overweights the little detail loss.

I don't agree with acidsex on the performance issues: i got 14-20 fps on my athlon 1700 in normal mode (and 7-10 in best mode). Anyone who played with the reference software will understand why do i find this so impressive.

edit: Superdump, i would advise you to disable the b-frames, they are the main cause of the motion issues.

babayaga
1st September 2004, 16:45
Originally posted by Gabriel_Bouvigne
Very low bitrate test:
a 23s QCIF 12.5fps, low motion (caméra café)
-rcmode abr -br 32000

*resulting bitrate is 44kbps, which is severly way off.
Perhaps there should be a more restricted abr mode for short clips or clips that would be streamed (32kbps video + 8kbps AMR would fit in UMTS bandwidth)


The rate-control is not optimised (yet) for those kind of bitrates. Currently, the ABR is perfectly ok with 32kB of over/undersize which is very consistant with standard video backup applications (if I count right you're experiencing 34kB of oversize).

Anyway, you're right and we will address this issue in the next version.

Thanks for pointing this out.

everwicked
1st September 2004, 16:55
If anyone has downloaded the VQStudio beta i posted about earlier, please re-download, there was a huge bug in it.

Sorry about that.