Ateme H.264 Beta - Bug, Issues and Getting Started

[bobololo]

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]

/me is already testing. :D

[guldukat]

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]

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]

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]

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]

Preliminary results for my own testing so far is very impressive. This is the best H.264 codec hands down right now.

[SeeMoreDigital]

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]

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]

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]

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]

i was having some trouble with the playback filters opening a 800x600 clip, resized to 800x592 and testing it now :)

[JohnV]

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]

"-ref 5 is a maximum, above it's useless"
he,he okay thx :)

Cu Selur

[CruNcher]

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]

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]

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]

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]

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]

and make sure to use lanczos resize, as its the most accurate resizer + get some sleep ;)

[Bulletproof]

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]

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]

Tommy Carrot
yep im also expirience those slightly jumps

[Bulletproof]

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]

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]

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]

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]

>>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]

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 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]

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]

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]

My poor 256MB laptop is swapping in a crazy way:
130MB of memory to decode a 12.5fps QCIF H264 clip!

[Tommy Carrot]

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]

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]

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]

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]

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]

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]

how split H264/ACC/MP4 ... ?

[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?

[guldukat]

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]

Seeking seems to be broken as well using Showtime. Everytime I seek, it freezes and then crashes.

[guldukat]

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]

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]

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]

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]

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]

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]

If anyone has downloaded the VQStudio beta i posted about earlier, please re-download, there was a huge bug in it.

Sorry about that.

[CruNcher]

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


also cabac off improves picture stability in some scenes for me :)

[bobololo]

Originally posted by Tommy Carrot
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.

It's quite strange, could you please provide the source that led to that result ? I mean the source file and the avs script you gave to encavc so we can reproduce and find what is wrong.

You can upload it to ftp://nero.ateme.com/incoming.

[superdump]

Tommy Carrot: I'm conducting thorough visual tests of pretty much all the settings. I'll get round to turning b-frames off then make my choices for the "best quality" settings to my eyes and then a "performance/quality" tradeoff.

CruNcher: CABAC is some sort of lossless arithmetic coding thing, so why would that affect it?

[LostMP4]

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
* 72839: encoding @ 15.42 fps - bitrate 52.68 kb/s - 100.00% completed
* 72840 frames encoded @ 3.88 fps - average bitrate 1199.43 kb/s

Encoding complete

* for other details look my previous post
- decoding appears to be flawless (video only, no muxed, yet)
- with Ateme filters it's possible to seek in the file
- with Showtime the clip plays well but can't seek or change speed
- final bitrate is perfect
- quality is higher (of course) compared to the same clip with the same preprocessing and bitrate (and time needed to encode too...)

[CruNcher]

CruNcher: CABAC is some sort of lossless arithmetic coding thing, so why would that affect it?


yeah i watched again it comes from the source not from cabac

[Andrey]

Ok. First result.
1. Codec crashed after job completion, but file is playable.

Resolution : 704x416 at 25.00 fps
Rate Control : 2pass
Target Bit Rate : 1289 kb/s
Quality : Extra
Init Quantiser : def
Max Consecutive BFrames : 3
Deblocking Strength : def
Num Reference : 3
Psychovisual : 0

encavc.exe -i h264.avs -o h264.mp4 -qual extra -rcmode 2pass -br 1289000 - psy 0 -maxb 3 -par 235:100 -ref 3

What I can tell imidiately:
1. Codec obey bitrate settings.
2. Result is much more pleasant to the eyes, than XViD encode, but lack details sometimes. Deblocking ?
Next time I'll disable it or set to -6.
What is better ?

BTW, how to take a screenshot from this encode ?
MPC always show me a error message when taking it...

[bond]

Originally posted by superdump
CruNcher: CABAC is some sort of lossless arithmetic coding thing, so why would that affect it?its a lossless way of saving bits, so the additonal bits recieved by using cabac might make the difference cruncher saw

[CruNcher]

1. Codec crashed after job completion, but file is playable.


check your avisynth plugins folder and try to determine by removing each plugin 1 after another wich is causeing the crash most times this comes from a not clean programmed plugin.

about the sharpness thing you could try -clref deblock (disable)
or -deblock adapt (adaptive deblocking) please report wich looks better for you :)

[superdump]

OK, second batch of results from me incoming. I've updated the first batch since I very first posted it so you may want to check it again. This time round it's deblocking. I tested with the same clip with -deblock -6, -4,..., 4, 6 and disabled. Grab the results here (http://www.swains.plus.com/superdump/-deblock.txt).

[LostMP4]

No luck with the muxer :(
Did anyone managed to make a "complete" MP4 file?

[superdump]

Originally posted by LostMP4
No luck with the muxer :(
Did anyone managed to make a "complete" MP4 file? I've done it before, yes. With LC AAC and with HE AAC. What's the problem?

[LostMP4]

Originally posted by superdump
I've done it before, yes. With LC AAC and with HE AAC. What's the problem?

It seems to don't like any aac file :confused:
(and I'm not sure I'm using the correct sintax to use it :p)

[bobololo]

Hi there,

The first day of testing has just passed and I'd just like to sum up somes points and provide some replies to posted queries.

* Bugs and other malfunctions
- when installing the dshow filters, if you encounter the LoadLibrary() error message, it's because you don't have msvcr71.dll in your system. You can get it there (http://www.dll-files.com/dllindex/dll-files.shtml?msvcr71).
- Once installed, make sure your dshow player use them and instead of other ones. Most players (like mplayerc) provide some ways to assign priorities to filters (overrides options).
- a strange issue exists with mplayerc, it happens that some files locks the player at the opening stage. The preliminary investigations done didn't explain the causes of this behaviour. Other players like wm player, bsplayer, zoom player don't show this issue.
- the decoder memory usage is huge. It's a mistake in the decoding filter and will be fixed.
- there is actually a bug in the core encoder that provokes a crash on the last frame of the sequence. It's caused by a mistake in bframes management. It is fixed now. A work around is to disable the bframes.
- the rate control doesn't achieve its target for ultra low bitrate. Some improvements are on the way.
- using 16 references causes some trouble. It is fixed now. Anyway having more than 5 references is almost useless. The gains are so small.

* Encoder Settings / Quality
- Many of you reported that on low bitrate, the bframes give some jumping blocks on uniform and slow motion area. This is due to some agressive bskip blocks decision. Improvements are on the way.
- About the deblocking strength parameter which range from -6 to 6. The smaller (-6) value gives the weaker deblocking and the higher value (6) gives the stronger deblocking and also smoother picture. The "adapt" value can also be used to ask the encoder to adapt automatically the deblocking strengh to the picture quality. This means that when a picture is strongly compressed, the deblocking will have more effects to reduce the compression artefacts. In the opposite, on low compressed picture, the filter will be disable to preserve the higher sharpness as possible.
- Regarding the encoding speed, well don't expect to get the same speed as our ASP encoder. Anyway, you can reach pretty fast encoding in lower quality level. And we have still some goodies to come :)

* suggestions
- During your test, it would be very interesting to get subjective impression of different encodes which are quite different from the perception you can have when staring clips picture per picture looking at the details and blocks :) Visual Quality Studio from Everwicked is a nice tool you can use to perform subjective comparison. It is based on the widely used DSCQS. You can grab it here (http://www.everwicked.com/vqstudio/beta/index.html).
- a ftp server has been setup so you can send us your file for debugging or other purposes. Also it can be useful when people want to show us samples where 'best' quality is better than 'extra' ;). The upload directory address is ftp://nero.ateme.com/incoming (anonymous). It is for upload only (one can't download files uploaded there).

* next update
- the next update with all the fixes and improvement is scheduled for next week. But this is not 100% yet :)

* last words
- we're still waiting for the feedback of top regular users like SeeMoreDigital, Sirber, CruNcher, Nic and many others :) Did you suddenly lose your tongue ? You were so much excited to test this beta that your silence is quite surprising ;)
- and of course, thanks to all testers !

-- bobololo.

[Andrey]

about the sharpness thing you could try -clref deblock (disable) or -deblock adapt (adaptive deblocking) please report wich looks better for you
h264 already looks better than original :D
Funny. The problem was in myst - it gave a little distortion, but picture was perfectly clean after encoding :) No distortion, no myst :)
XViD shows terrible makroblocks there, only quant 2 is usable...
Seems that SW II is hard to encode.

[Teegedeck]

Originally posted by bobololo

- we're still waiting for the feedback of top regular users like SeeMoreDigital, Sirber, CruNcher, Nic and many others :) Did you suddenly lose your tongue ? You were so much excited to test this beta that your silence is quite surprising ;)
Wellll... - since I came back home on tuesday I struggled to get the last bits of mpegable avc out of my system and finally managed getting decoding to work after a Nero re-install this evening. So definitely no solid results from me before the end of the week, as I foretold in my initial PM.

edit: I plan on testing at which quantizer and settings ateme reaches transparency (or is comparable to XviD at a setting which I regard as giving transparent results).

[Sagittaire]

- we're still waiting for the feedback of top regular users like SeeMoreDigital, Sirber, CruNcher, Nic and many others Did you suddenly lose your tongue ? You were so much excited to test this beta that your silence is quite surprising


eh eh eh ... test in progress, test in progress ... but in introduction it's a very powerfull codec:

My favorite setting: higest quality but slowest
encavc.exe -i clip.avs -o H264-2000.mp4 -qual extra -rcmode 2pass -br 2048000 -psy 2 -deblock adapt -ref 5

if you are wise and if bobololo authorize it would make you a HDTV demo ... ;-)

- King Arthur trailer
- 1440*800*24 picture aspect 2.35 and pixel aspect 4:3
- LC-AAC 5.1 high quality

[virus]

Originally posted by bobololo
Did you suddenly lose your tongue?
No, but I've suddenly lost my time :)
(that means: today has been a very, very busy day, but tomorrow I think I can find time to start playing with the codec... luckily the new version is scheduled for the next week, the weekend is absolutely needed ;))

virus

[JohnV]

Originally posted by JohnV
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
Here's the same with h264 inloop deblocking strength 2.
At this low bitrate the encoder's adaptive deblocking is not quite aggressive enough for my taste at least on TFT screen ;), so I like this fixed strength a bit better.
Also enabled is the cartoon-mode, which according to bobololo "enhances decision by taking chroma into account".
Haven't really compared the effect of the cartoon mode, but thought that people might be interested in it and it is enabled in this encode:
http://www.hydrogenaudio.org/stuff/OutOfTime_Ateme-h264_300kbps_inloop2.mp4

[SeeMoreDigital]

Originally posted by bobololo
* last words
- we're still waiting for the feedback of top regular users like SeeMoreDigital, Sirber, CruNcher, Nic and many others :) Did you suddenly lose your tongue ? You were so much excited to test this beta that your silence is quite surprising ;)
- and of course, thanks to all testers !

-- bobololo. I'm sorry about this bobololo. Initially I had some problems loading the software. And then my Mpeg4 DSdec filters became unstable (I've been running lean, with just XviD 1.1.x beta, Nero and FFdshow).

Plus today I installed a new graphics card, which unfortunately also has had it's quirks. Some of which I'm yet to resolve!

All in all, it's not been a very good couple of days. But I've enjoyed reading the posts in this thread.... It would be nice to have some encodes to play though!


Cheers

[Bulletproof]

When you disable some encoding tools like bframes or qpel etc using the -clref option is the encoder still supposed to show them in the features list? Because this is what I tried:

encavc.exe -i test.avs -o test.mp4 -clref deblock bpred hpel qpel -setef ipred ppred cabac part

and the output from encavc says:

Features : ipred ppred bpred cabac hpel qpel part

[JohnV]

Originally posted by Bulletproof
When you disable some encoding tools like bframes or qpel etc using the -clref option is the encoder still supposed to show them in the features list? Because this is what I tried:

encavc.exe -i test.avs -o test.mp4 -clref deblock bpred hpel qpel -setef ipred ppred cabac part

and the output from encavc says:

Features : ipred ppred bpred cabac hpel qpel part
use -clref deblock,bpred,qpel etc.. in other words use comma between the enabled/disabled tools.

[RadicalEd]

The bskip thing wreaks havoc here :|
Bobololo, could you give a brief explanation of the -cartoon setting?
whoops, missed johnv's small quote a few posts up.
Also enabled is the cartoon-mode, which according to bobololo "enhances decision by taking chroma into account".

[plonk420]

i'm having muxing problems too.

encoded an 800kbps clip @ 720x480 (d'oh, forgot to resize to 640x480) and a 96kbps nero aac-he file and it just sits at the cli. does't even create the output file (empty or not).

used simple switches, too:
encavc -i clip.avs -o clip.mp4 -qual best -rcmode 2pass -br 800000
mp4muxer -i video.mp4 -i audio.mp4 -f:audio -o av.mp4

also what should i be using to play the audio in JohnV's video? i've created my own MP4s with graphedit using 3ivx 4.5.1's mp4 muxer and AACs (LC and HE) and had no probs with CoreAAC, but i'm getting an error related to the audio output pin. i used nero (AAC) for both the xvid mp4s i've muxed (successfully), as well as the avc clips i'm trying to mux.


could we maybe have two threads? maybe an encoder/muxer feedback thread and a video quality feedback thread?

[bobololo]

Originally posted by plonk420
i'm having muxing problems too.
used simple switches, too:
encavc -i clip.avs -o clip.mp4 -qual best -rcmode 2pass -br 800000
mp4muxer -i video.mp4 -i audio.mp4 -f:audio -o av.mp4

Your muxing command line is slightly wrong, try this instead (as mentioned in the documentation) :

mp4muxer -i video.mp4 -i audio.mp4 -f t:audio -o av.mp4

Originally posted by plonk420
could we maybe have two threads? maybe an encoder/muxer feedback thread and a video quality feedback thread?

I think the usage issues that obviously appear at the beginning will be solved quickly and be replaced by quality considerations afterward. So I'm not sure it is worth flooding the forum with several threads ;)

-- bobololo.

[Nic]

@bobololo: Hey, sorry for me losing my tongue ;) , I've got a cold so only managed to do little testing. Everythings working great, nice set of tools, I'll report more soon :)

[babayaga]

Originally posted by superdump
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.


About 10 000 frames at the end of the clip. So there is currently no speed gain for short clips (like trailers).

The last 256 frames receive a special treatment to avoid a too large bitrate error. That's why the last 10s of clips are sometimes less good-looking than they could be.
In the special case of a hard clip with a very low energy ending (near still frames), this can lead to a bad looking ending. I guess that's what you're seeing with LOTR2.

In a movie/trailer encode, it's generaly not a problem because it's in the end credit. If you take just a chapter of a movie it could be an issue.

I've seen the same kind of "problem" with XviD and DivX.

But remember that we have to avoid by all means a too large oversize since the encode could be directly burned on a CD/DVD.

[chilledoutuk]

The last 256 frames receive a special treatment to avoid a too large bitrate error. That's why the last 10s of clips are sometimes less good-looking than they could be.

this explains the problems i have been having with the new version of recode at the end of video sequences when i crop off the credits.
From now on ill leave 10s of credits on.

Is not possible to detect that your not burning to a disc and therefore not use this special treatment or at least de-activate it when a custom size is set by the user.

[plonk420]

Originally posted by bobololo
Your muxing command line is slightly wrong, try this instead (as mentioned in the documentation) :

mp4muxer -i video.mp4 -i audio.mp4 -f t:audio -o av.mp4

:eek: oops .. how embarassing -_- guess i should try to get more sleep than i have been this week...

any ideas as to the audio problem, anyone?

[babayaga]

Originally posted by chilledoutuk
this explains the problems i have been having with the new version of recode at the end of video sequences when i crop off the credits.
From now on ill leave 10s of credits on.

Is not possible to detect that your not burning to a disc and therefore not use this special treatment or at least de-activate it when a custom size is set by the user.

The exact beheaviour is very dependant on the structure of the clip. Most of the times, the very ending is better looking than the rest of the clip, but sometimes it's the opposite.

That's my own feelings, we've never received a report stating that there could be a problem at the very end, Superdump is the first one :-)

BTW, do you think that the quality is constant enough or is there too much variation ?

[Selur]

hmm,.. playing around with deblocking settings and I'm wondering is it possible to maybe lower the deblocking setting automaticly fpr low contrast areas?

Especially for water scenes deblocking, seems to smooth too much. :)
Though I really like the deblocking in general.

Cu Selur

[Gabriel_Bouvigne]

Originally posted by babayaga

BTW, do you think that the quality is constant enough or is there too much variation ?

I think that for some targets there might be too much variation.
This is the case with very low bitrate (20-30kbps) short content.

Encoding at 12.5fps, this makes a quality drop of 20seconds, which is huge for a 1min clip.

(ok, this might not be a priority as h264 decoders are not yet available for phones)

[chilledoutuk]

recently I have been backing up stargate sg1 season 7 with full anamorphic resolution to files of 560mb per a 42min episode. Also with the directors cometry included now thanks to the new version of recode :D .

in most of the episodes there is no problem at the end of the encoded video sequence.

But on a couple of episodes there is noticable blocking just before the end of the video sequence. what also concerns me is the anmount the codec undersizes this episode i set the size to 562mb and i get a video that is 552mb which is a 10mb undersize compared to a 4mb undersize of other episodes.
This episode that repeatadlty caused rate control problems for nero is episode 4 on stargate sg1 vol 35 (PAL).

you may want to check it out.

[LostMP4]

2 new encodes, same clip as before, this time without deblocking and preprocessing, using two different bitrates (the second one is just a little oversized):


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
Num Reference : 5
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred bpred cabac hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 72840 frames processed @ 15.26 fps
-- Start processing pass 2 / 2
* 72839: encoding @ 16.29 fps - bitrate 62.73 kb/s - 100.00% completed
* 72840 frames encoded @ 3.99 fps - average bitrate 1199.53 kb/s


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

-- Start processing pass 1 / 2
* 100.00% completed
* 72840 frames processed @ 19.02 fps
-- Start processing pass 2 / 2
* 72839: encoding @ 16.73 fps - bitrate 13.78 kb/s - 100.00% completed
* 72840 frames encoded @ 5.36 fps - average bitrate 600.03 kb/s


I noticed some blocking (of course, I don't use deblocking) on still parts... maybe the reference blocks are choosen with to little accuracy :confused:

PS: even with halfed bitrate the pictures are always very clean

[virus]

bobololo, please clear your PM box a bit, it's full ;)

[superdump]

Originally posted by chilledoutuk
recently I have been backing up stargate sg1 season 7 with full anamorphic resolution to files of 560mb per a 42min episode. Also with the directors cometry included now thanks to the new version of recode :D .

in most of the episodes there is no problem at the end of the encoded video sequence.

But on a couple of episodes there is noticable blocking just before the end of the video sequence. what also concerns me is the anmount the codec undersizes this episode i set the size to 562mb and i get a video that is 552mb which is a 10mb undersize compared to a 4mb undersize of other episodes.
This episode that repeatadlty caused rate control problems for nero is episode 4 on stargate sg1 vol 35 (PAL).

you may want to check it out. I'm sure these comments will be appreciated but you are commenting about the MPEG-4 ASP codec within Nero Recode which is off-topic from this thread. We are all discussing the Ateme H.264 Beta which you had to sign up for and is not part of Nero Recode yet.

[SteMa]

Hi! Can I get the ateme beta codec too? I wish to do some encoding myself if it's not a problem. Sorry if i'm late but I really like doing encodes :D

[superdump]

Originally posted by LostMP4
2 new encodes, same clip as before, this time without deblocking and preprocessing, using two different bitrates (the second one is just a little oversized):


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
Num Reference : 5
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred bpred cabac hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 72840 frames processed @ 15.26 fps
-- Start processing pass 2 / 2
* 72839: encoding @ 16.29 fps - bitrate 62.73 kb/s - 100.00% completed
* 72840 frames encoded @ 3.99 fps - average bitrate 1199.53 kb/s


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

-- Start processing pass 1 / 2
* 100.00% completed
* 72840 frames processed @ 19.02 fps
-- Start processing pass 2 / 2
* 72839: encoding @ 16.73 fps - bitrate 13.78 kb/s - 100.00% completed
* 72840 frames encoded @ 5.36 fps - average bitrate 600.03 kb/s


I noticed some blocking (of course, I don't use deblocking) on still parts... maybe the reference blocks are choosen with to little accuracy :confused:

PS: even with halfed bitrate the pictures are always very clean LostMP4: I recommend you try the deblocking. I love XviD because of the sharpness and detail of textured areas and distinct lack of blurring. (Blurring does actually make me feel sick in high motion scenes). However, very light deblocking does give a nicer output and can work wonders with some sections of videos. At least from my brief experience of it (see the results above). Try -deblock -6 / -5 and -4 and also try the adaptive method. We've suggested an adaptive method with varying aggressivenesses to bobololo so that we can all benefit from having adaptive deblocking but to the degree which suits out visual tastes. :) Keep those results coming though, you're doing a grand job.

[Selur]

"so that we can all benefit from having adaptive deblocking but to the degree which suits out visual tastes."
yup, this would be nice. :)

[LostMP4]

Originally posted by superdump
LostMP4: I recommend you try the deblocking. I love XviD because of the sharpness and detail of textured areas and distinct lack of blurring. (Blurring does actually make me feel sick in high motion scenes). However, very light deblocking does give a nicer output and can work wonders with some sections of videos. At least from my brief experience of it (see the results above). Try -deblock -6 / -5 and -4 and also try the adaptive method. We've suggested an adaptive method with varying aggressivenesses to bobololo so that we can all benefit from having adaptive deblocking but to the degree which suits out visual tastes. :) Keep those results coming though, you're doing a grand job.

I've already tried deblocking in my first encodes, I was looking for the differences with various options on/off

[superdump]

Originally posted by babayaga
About 10 000 frames at the end of the clip. So there is currently no speed gain for short clips (like trailers).

The last 256 frames receive a special treatment to avoid a too large bitrate error. That's why the last 10s of clips are sometimes less good-looking than they could be.
In the special case of a hard clip with a very low energy ending (near still frames), this can lead to a bad looking ending. I guess that's what you're seeing with LOTR2.

In a movie/trailer encode, it's generaly not a problem because it's in the end credit. If you take just a chapter of a movie it could be an issue.

I've seen the same kind of "problem" with XviD and DivX.

But remember that we have to avoid by all means a too large oversize since the encode could be directly burned on a CD/DVD. Thanks for the response babayaga. So the poor quality ending on my clip is linked with the slow first pass RC for clips of less than 10000 frames? I think that if your perceived a similar problem in XviD it wouldn't be so pronounced as I don't think there is an intended decrease in bitrate to prevent an overflow at the end. I'll have to enquire how this works in XviD, or maybe you could yourself by visiting #xvid on freenode and talking to GomGom or Foxer or another XviD dev. I think it just uses a bit reservoir and very good calculations. I've never seen any of my XviD encodes be oversized at 'normal' bitrates. As for DivX I wouldn't have a clue how that works and I don't really care. :)

[virus]

I cannot encode anything. The encoder dies with "can't create input thread" at the start of the encoding. But my AVS is ok and I can watch it regularly both under VFW and DS... since nobody is reporting such a behaviour maybe my problem is Win98SE? Nobody using the 9x kernel around?

I've emailed bobololo about the details. Now I'm stuck :(

[superdump]

Originally posted by babayaga
The exact beheaviour is very dependant on the structure of the clip. Most of the times, the very ending is better looking than the rest of the clip, but sometimes it's the opposite.

That's my own feelings, we've never received a report stating that there could be a problem at the very end, Superdump is the first one :-)

BTW, do you think that the quality is constant enough or is there too much variation ? chilledoutuk is talking about Recode's MPEG-4 ASP codec as I pointed out a couple of posts above. I've never witnessed the same problem in Recode but then I've only ever done full film encodes with it so I wouldn't have noticed the problem... in which case, if I'm only ever doing full film encodes with it then I wouldn't notice the 'problem' in normal use.

As for the degree of constant quality... throughout the rest of the clip it is fairly constant but only in the two halves. The slow motion section looks MUCH better than the high motion section. I think this bias should be altered slightly in my opinion. :)

[babayaga]

Originally posted by chilledoutuk
This episode that repeatadlty caused rate control problems for nero is episode 4 on stargate sg1 vol 35 (PAL).


In the beta you received, there is no special protection for oversize like the one that is embedded in Recode, and there is also no compensation for the container overhead or other streams.

Besides, the rate-control algorithm is brand new even if it uses old concepts that were already in place back to the first version of Recode 2.
So the visual impression could be different, and that's in what I'm interested today.

Reading this forum, I've the feeling that except some issues at the very end of some sequences (Superdump) or extremly low bitrates (Gabriel_Bouvigne), nobody complained for very serious problems like an excessive variation of quality or a large error.
Am I wrong ?

[LostMP4]

About mp4muxer: it crashed muxing h264 video stream with a AAC.
Now the file is "locked" (mp4muxer), double-clicking on it says it isn't a valid win32 program, I can't use or delete it (I tryed restarting the PC, too)
I can copy it to another folder, obtaining another locked file that I can't delete :confused:
A "new" mp4muxer exctracted from the archive works well (audio in MP4, I don't dare to try aac anymore)
What's happened?

[superdump]

Originally posted by babayaga
In the beta you received, there is no special protection for oversize like the one that is embedded in Recode, and there is also no compensation for the container overhead or other streams.

Besides, the rate-control algorithm is brand new even if it uses old concepts that were already in place back to the first version of Recode 2.
So the visual impression could be different, and that's in what I'm interested today.

Reading this forum, I've the feeling that except some issues at the very end of some sequences (Superdump) or extremly low bitrates (Gabriel_Bouvigne), nobody complained for very serious problems like an excessive variation of quality or a large error.
Am I wrong ? As stated in the post previous to yours, I think the bias between high motion scenes (which I imagine produce larger frames) and low motion scenes needs to be adjusted slightly to create a more constant quality in the two regions. Gabriel suggests less variability but I'm not sure whether he means less variability in bitrate or quality? I'd suggest more variability in bitrate or at least an adjustment to the RC such that much bits are given to high motion scenes and less to low motion. That is my opinion based on the clip I've been using.

I'm going to wait for an update now before I continue extensive testing as I'd like to test with b-frames more extensively. I can't really comment on this feature when the bskipping is too aggressive and makes it difficult to notice quality improvements.

I can't see much difference in quality in the multiref encodes I've done but these all used b-frames so it was distracting there too. I'll have to do some with only i/p-frames and test those.

Nothing else springs to mind at the moment.

[SeeMoreDigital]

Originally posted by LostMP4
...A "new" mp4muxer exctracted from the archive works well (audio in MP4, I don't dare to try aac anymore)
What's happened? I would not worry about it too much. These things happen.

At least some of the bugs are being discovered now (during beta testing) and not later!


Cheers

[RBF]

I made comparison Ateme H.264 with VSS, VP6, XVID.
400kbit/s 720x352

PIV-2800 512RAM

Core encoder version 1.0.1.14

Input file : clip.avs
Output file : clip.mp4
Resolution : 720x352 @ 23.98 fps
Length : 4316 Frames
Rate Control : 2pass
Target Bit Rate : 400 kb/s
Quality : Best
Init Quantiser : 24
Max Consecutive BFrames : 3
Deblocking Strength : -2
Num Reference : 1
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 4316 frames processed @ 11.64 fps
-- Start processing pass 2 / 2
* 04315: encoding @ 10.28 fps - bitrate 536.14 kb/s - 100.00% completed
* 4316 frames encoded @ 11.71 fps - average bitrate 400.04 kb/s

Encoding complete

VP6 best quality, Videosoft - best quality, XVID 6/4 Aq/Qp 2B H263,Real Video 10 - sharpest image. All - 2 pass

1
Ateme - http://rbf.nm.ru/Nero_400_1.jpg
VP62 - http://rbf.nm.ru/VP6_400_1.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_1.jpg
XVID - http://rbf.nm.ru/XVID_400_1.jpg
Real Video 10 - http://rbf.nm.ru/Real10_400_1.jpg

2
Ateme - http://rbf.nm.ru/Nero_400_2.jpg
VP62 - http://rbf.nm.ru/VP6_400_2.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_2.jpg XVID - http://rbf.nm.ru/XVID_400_2.jpg
Real Video 10 - http://rbf.nm.ru/Real10_400_2.jpg


3
Ateme - http://rbf.nm.ru/Nero_400_3.jpg
VP62 - http://rbf.nm.ru/VP6_400_3.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_3.jpg
XVID - http://rbf.nm.ru/XVID_400_3.jpg
Real Video 10 - http://rbf.nm.ru/Real10_400_3.jpg

4
Ateme - http://rbf.nm.ru/Nero_400_4.jpg
VP62 - http://rbf.nm.ru/VP6_400_4.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_4.jpg
XVID - http://rbf.nm.ru/XVID_400_4.jpg
Real Video 10 - http://rbf.nm.ru/Real10_400_4.jpg

Generalizing results after full viewing 5 clips - Ateme H.264 has given more detailed picture from less artefacts than other codecs on 400kbit/s 720x352.

[LostMP4]

Originally posted by SeeMoreDigital
I would not worry about it too much. These things happen.

At least some of the bugs are being discovered now (during beta testing) and not later!


Cheers

Well, I've got 3 files I can't delete in any way :rolleyes:

[JohnV]

Originally posted by RBF
I made comparison Ateme H.264 with VSS, VP6, XVID.
400kbit/s 720x352

PIV-2800 512RAM

Core encoder version 1.0.1.14

Input file : clip.avs
Output file : clip.mp4
Resolution : 720x352 @ 23.98 fps
Length : 4316 Frames
Rate Control : 2pass
Target Bit Rate : 400 kb/s
Quality : Best
Init Quantiser : 24
Max Consecutive BFrames : 3
Deblocking Strength : -2
Num Reference : 1
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 4316 frames processed @ 11.64 fps
-- Start processing pass 2 / 2
* 04315: encoding @ 10.28 fps - bitrate 536.14 kb/s - 100.00% completed
* 4316 frames encoded @ 11.71 fps - average bitrate 400.04 kb/s

Encoding complete

VP6 best quality, Videosoft - best quality, XVID 6/4 Aq/Qp 2B H263. All - 2 pass

1
Ateme - http://rbf.nm.ru/Nero_400_1.jpg
VP62 - http://rbf.nm.ru/VP6_400_1.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_1.jpg
XVID - http://rbf.nm.ru/XVID_400_1.jpg

2
Ateme - http://rbf.nm.ru/Nero_400_2.jpg
VP62 - http://rbf.nm.ru/VP6_400_2.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_2.jpg
XVID - http://rbf.nm.ru/XVID_400_2.jpg


3
Ateme - http://rbf.nm.ru/Nero_400_3.jpg
VP62 - http://rbf.nm.ru/VP6_400_3.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_3.jpg
XVID - http://rbf.nm.ru/XVID_400_3.jpg

4
Ateme - http://rbf.nm.ru/Nero_400_4.jpg
VP62 - http://rbf.nm.ru/VP6_400_4.jpg
Videosoft-H264 - http://rbf.nm.ru/VSSH_400_4.jpg
XVID - http://rbf.nm.ru/XVID_400_4.jpg

Generalizing results after full viewing 4 clips - Ateme H.264 has given more detailed picture from less artefacts than other codecs on 400kbit/s 720x352.

Any reason why you didn't use "extra" -quality mode and psychovisual 2? Those could improve quality further.

[bobololo]

Originally posted by RBF
I made comparison Ateme H.264 with VSS, VP6, XVID.
400kbit/s 720x352

[...]
Length : 4316 Frames
Rate Control : 2pass
Target Bit Rate : 400 kb/s
Quality : Best
[...]

Generalizing results after full viewing 4 clips - Ateme H.264 has given more detailed picture from less artefacts than other codecs on 400kbit/s 720x352.
Very interesting batch of encodes. Btw, you could get even better results with 'extra' quality mode !

-- bobololo.

[bobololo]

Originally posted by LostMP4
Well, I've got 3 files I can't delete in any way :rolleyes: Aren't you infected by a virus ?

-- bobololo.

[LostMP4]

Originally posted by bobololo
Aren't you infected by a virus ?

-- bobololo.

Excluding Microsoft and Norton software(now merged in the ultimate parasite, thanks to SP2 and Symantec updates), none :p
After its crash, mp4muxer.exe had this problem, I can't delete, move or rename it, but I can copy it, obtaining a new "locked" file :confused: (now I've in 4 folders 4 mp4muxers, 3 not-working and locked and 1 working freshly extracted from the archive)

[Andrey]

Generalizing results after full viewing 4 clips - Ateme H.264 has given more detailed picture from less artefacts than other codecs on 400kbit/s 720x352.
Inloop deblocking, I think.
BTW, the difference in water on last screenshot is really surprising.

One more question: if I kill codec process occasionally, the resulting file isn't playable (2nd pass, of course).
Is this the way things are ment to be ?

[Bulletproof]

Originally posted by LostMP4
About mp4muxer: it crashed muxing h264 video stream with a AAC.
Now the file is "locked" (mp4muxer), double-clicking on it says it isn't a valid win32 program, I can't use or delete it (I tryed restarting the PC, too)
I can copy it to another folder, obtaining another locked file that I can't delete :confused:
A "new" mp4muxer exctracted from the archive works well (audio in MP4, I don't dare to try aac anymore)
What's happened?

Try starting windows in safe mode and then delete the files.

[easyfab]

Originally posted by LostMP4
Excluding Microsoft and Norton software(now merged in the ultimate parasite, thanks to SP2 and Symantec updates), none :p
After its crash, mp4muxer.exe had this problem, I can't delete, move or rename it, but I can copy it, obtaining a new "locked" file :confused: (now I've in 4 folders 4 mp4muxers, 3 not-working and locked and 1 working freshly extracted from the archive)

ctrl+alt+suppr -> kill the explorer process and open a new explorer process, your files should be unlocked now.

[Andrey]

A bug, but I don't know if it is Atheme dshow filter or BSPlayer.
When playing at full screen, image is shown at the top, not centered...
EDIT:
I like how 630Kbit 512x304 encode of SW II looks in general with adaptive deblocking. Even better (subjectively) than XViD one with heavy preprocessing... (makroblocks in XViD are too ugly when dealing with myst, flying sand and so on)
When I will find how to create a screenshots, I will post them :)

[bobololo]

Finally we're going to release tonight a new beta that fixes most of the critical issues (last frame crash, mpc lock, etc.) we had so you can find out others ones ;) We hope this new one is more stable for your encodes !

In the Beta-2 you'll have :

- Last frame crash with bframes fixed (encavc.exe)
- CreateThread() error with Win98SE fixed (encavc.exe)
- new adaptive deblocking flag "-adaptdeblock" working in
association with -deblock <strength> (encavc.exe)
- 16 references issue fixed (encavc.exe)
- better RC for very low bitrate target (encavc.exe)
- Media Player Classic lock fixed (adf_srcmp4.ax)
- Insane memory usage of the decoder filter fixed (adf_dech264.ax)
- a new tool call mp4 tool box. It allows you to extract a part of
a mp4 file and save it to another one. You'll be able to upload
to us your files illustrating your observations.

About the new deblocking option, you'll be able to use the adaptive deblocking and adjust its working range depending on your preference. For instance you can set it as follow :

-deblock -2 -adaptdeblock

This will tell the encoder to adapt the deblocking strength around the -2 level.

Enjoy :)

-- bobololo.

[Sirber]

Any URL / email?

[bobololo]

Originally posted by Sirber
Any URL / email? You'll be notified by mail.

[SeeMoreDigital]

Blimey... a beta-2 already... You guys are really fast!

I'll have to get stuck in now!


Cheers

[virus]

Originally posted by bobololo
- CreateThread() error with Win98SE fixed (encavc.exe)

:D
(I managed to be useful encoding exactly 0 bytes...)

Thanks for the brand-new build bobololo, your efforts are very appreciated. The MP4 extraction tool is a great idea. :)

virus

[Soulhunter]

Ok, before getting the new version I gonna post my 1st speed results...


System: Athlon XP 3000+ / 1024MB DDR400 / Windows XP


Source: 1024x576 @ 29.97fps

Results:

~ 07.4 fps @ -qual normal

~ 05.5 fps @ -qual good

~ 04.7 fps @ -qual best

~ 04.0 fps @ -qual extra



Source: 720x576 @ 25fps

Results:

~ 14.8 fps @ -qual normal

~ 11.9 fps @ -qual good

~ 08.8 fps @ -qual best

~ 08.2 fps @ -qual extra



Source: 640x480 @ 25fps

Results:

~ 18.7 fps @ -qual normal

~ 14.4 fps @ -qual good

~ 10.7 fps @ -qual best

~ 09.5 fps @ -qual extra


For a H.264 encoder its damn fast !!!

First visual impression -> Wow... :eek:

Btw, does someone know a tool to extract "wanted" frames from this encodes ???


Bye

[superdump]

Originally posted by Soulhunter
Btw, does someone know a tool to extract "wanted" frames from this encodes ???

Originally posted by bobololo
- a new tool call mp4 tool box. It allows you to extract a part of
a mp4 file and save it to another one. You'll be able to upload
to us your files illustrating your observations.

[Soulhunter]

@ superdump

Maybe I understood this wrong, but...

Think its a mp4 splitting/cutting tool !?!

I meant a single frame -> picture tool...


Bye

[Teegedeck]

I wish I had more precise findings to contribute right now - but I'm stuck with this 19'' Trinitron today; better view tomorrow on a TFT.

Let me just say; the codec is a jolly good piece of work. Psychovisuals and deblocking still are a no-no for my type of encoding (surprise, surprise...) but generally it seems possible to reach transparency at quite a reasonable bitrate. I still have to verify that on the TFT though.

Till tomorrow.

[bill_baroud]

my computer died on me just when i got the first beta, so i'll start testing with the beta 2 .... no i'm not dead, sorry for the delay :D

[SeeMoreDigital]

Originally posted by Soulhunter
For a H.264 encoder its damn fast !!! Nice one Soulhunter!

What did your 1024x576 encodes look like compared to the other codecs you've tested?

I'm interested because I'm hoping to use AVC for full frame HighDef encoding!


Cheers

[Krismen]

I've got one question: Is there anybody who can give a link to Ateme h.264 directshow decoder?

[Sirber]

beta1 has been removed from the server.

[guldukat]

Originally posted by Krismen
I've got one question: Is there anybody who can give a link to Ateme h.264 directshow decoder?

you received this filter by mail, IF you'Re a beta tester, else you have to wait for the final release in the nero package

[chilledoutuk]

I took the DiVX Bourne supremacy HDTV trailer from DiVX networks website which had 3500kbps bitrate and rencoded it to 2000kbps h.264 and the quality was almost transparent which is impressive.

I’m going to run some more tests on some HDTV sources and see how it performs.

[Jukke]

Hi,
I got strange file sizes from the muxer. Encoded as follows:
encavc.exe -i tv4.avs -o video.mp4 -qual normal -rcmode 2pass -br 600000 -clref bpred -psy 1
mp4muxer.exe -i video.mp4 -i audio.mp4 -f t:audio -o av.mp4
The avs is:
LoadPlugin("C:\Program\av\GORDIA~1\AviSynthPlugins\dgdecode.dll")
mpeg2source("C:\Scratch\Captures\ateme\tv4.d2v")
crop(6,6,714,564)
LanczosResize(608,480)
The muxer output is:
drv_mp4: video.mp4:3 opened (video(AVC): 608x480)
drv_mp4: audio.mp4:1 opened (audio, 48000 Hz, 2 channels)
muxing stream(s): [0] AU 4519 (Video), [1] AU 4238 (Audio)
stream[0]: muxing done (4520 AUs, 180.75 s)
stream[1]: muxing done (4239 AUs, 180.81 s)
mux completed
video.mp4 is 13314kb
audio.mp4 is 1496kb
and the muxed av.mp4 is staggering 36474kb!
Anybody finds this normal?

[Soulhunter]

Originally posted by SeeMoreDigital
Nice one Soulhunter!

What did your 1024x576 encodes look like compared to the other codecs you've tested?

I'm interested because I'm hoping to use AVC for full frame HighDef encoding!


Cheers
The source for this encode was the 1080i space shuttle clip Ive linked @ the other thread !!!

Ive encoded it 12x times with bitrates between 500-10000 kbps...

Atm its too early to tell you something concrete !!!

But I will post back tomorrow... ;)


Bye

[Sagittaire]

- better RC for very low bitrate target (encavc.exe)

Yes RC 2 pass isn't very good: quality isn't constant and there are quality degradation for the end of encoding. It's a typical Rate Control problem: too much bit for the beginning and less bit for the end to respect the bitrate. It would be necessary to make the first pass with a higher quantizer to have better estimate for the second pass with high quantizer encodind (low compressibility encoding)

720*304 500 Kbps Matrix Reloaded encoding with 35 000 Frames

http://jfl1974.free.fr/Test/Comparatif/H264vsDivX5-500.JPG

http://jfl1974.free.fr/Test/Comparatif/H264vsXviD-500.jpg

http://jfl1974.free.fr/Test/Comparatif/H264vsVP6-500.JPG

http://jfl1974.free.fr/Test/Comparatif/H264vsWMV9-500.JPG

http://jfl1974.free.fr/Test/Comparatif/H264vsRV10-500.JPG

[superdump]

Originally posted by guldukat
you received this filter by mail, IF you'Re a beta tester, else you have to wait for the final release in the nero package The current NeroVision Express package will decode the files encoded here but there won't be any seeking.

[LostMP4]

Originally posted by superdump
The current NeroVision Express package will decode the files encoded here but there won't be any seeking.

Use Ateme's filters if you want to seek ;)

[Soulhunter]

Originally posted by Soulhunter

I meant a single frame -> picture tool...
Sorry, totally overlooked the easiest way... :o

Avisynth -> DirectShowSource -> VDubMod -> Snapshot source frame


Bye

[superdump]

LostMP4: Indeed, I was just making sure that that person knew they could use NVE to watch clips posted here if they weren't part of the beta test.

Originally posted by Soulhunter
Sorry, totally overlooked the easiest way... :o

Avisynth -> DirectShowSource -> VDubMod -> Snapshot source frameYou've managed to get DSSource() to work with the Ateme filters/AVC files? Interesting. As far as I know it doesn't work anywhere else bar decoding the first frame.

[Soulhunter]

Hmm, even @ 8000 kbps Ive spotted out some faults !!!


Blocks:

Source sample 1 (http://img86.exs.cx/my.php?loc=img86&image=Source_654.png)

Ateme sample 1 (http://img86.exs.cx/my.php?loc=img86&image=Ateme_654.png)


Source sample 2 (http://img86.exs.cx/my.php?loc=img86&image=Source_665.png)

Ateme sample 2 (http://img86.exs.cx/my.php?loc=img86&image=Ateme_665.png)


Source sample 3 (http://img86.exs.cx/my.php?loc=img86&image=Source_1302.png)

Ateme sample 3 (http://img86.exs.cx/my.php?loc=img86&image=Ateme_1302.png)


Gradients:

Source sample 1 (http://img86.exs.cx/my.php?loc=img86&image=Source_987.png)

Ateme sample 1 (http://img86.exs.cx/my.php?loc=img86&image=Ateme_987.png)


Source sample 2 (http://img86.exs.cx/my.php?loc=img86&image=Source_999.png)

Ateme sample 2 (http://img86.exs.cx/my.php?loc=img86&image=Ateme_999.png)


Originally posted by superdump

You've managed to get DSSource() to work with the Ateme filters/AVC files?

Uhm, yes...

DirectShowSource("C:\Ateme\2.mp4")

Made the screenshots above this way !!!


Bye

[superdump]

SoulHunter: Nice shots. Or rather, useful shots. On the first one the blocks are noticable on the smoke cloud on the left, but AVC seems to introduce to some artificial lighting on the lower left and up the right hand side. Very strange. In fact, now I've looked at the rest there seems to be an ongoing pattern of light introduction.

EDIT: What settings were you using? Did you use -psy >0?

[Tommy Carrot]

I didn't experienced any similar blocks and artifacts in my tests. Are you sure they are there during playback too? Can't be possible that the opening via avisynth causes them somehow(as most of us cannot open MP4s in avisynth)?

[Soulhunter]

Originally posted by superdump
What settings were you using? Did you use -psy >0?
Saved all command lines Ive used...

C:\Ateme\encavc.exe

-i C:\Ateme\shuttle.avs

-o C:\Ateme\2.mp4

-qual best

-rcmode 2pass

-br 10000000

-psy 0

Note: Ateme was maxed-out @ around 8000 kbps !!!


Originally posted by Tommy Carrot
I didn't experienced any similar blocks and artifacts in my tests. Are you sure they are there during playback too? Can't be possible that the opening via avisynth causes them somehow(as most of us cannot open MP4s in avisynth)?
Yes, its definitely visible while playback !!!

The two other sources Ive used are ok... :confused:

Think I gonna encode it again !!!

Need to sleep now... ;)


Bye

[bobololo]

A new beta of the encoder is ready for download. You should receive the link by mail in a few minutes. The change log was posted previsouly.

I strongly suggest you to use the new filters provided in this package as they should be more stable (just run reg.bat).

Also the jumping blocks in bframes issue isn't addressed in this version yet. So if you intend to test low bitrate encodes, it is recommanded to disable the bframes.

-- bobololo.

[bobololo]

Originally posted by Jukke
drv_mp4: video.mp4:3 opened (video(AVC): 608x480)
drv_mp4: audio.mp4:1 opened (audio, 48000 Hz, 2 channels)
muxing stream(s): [0] AU 4519 (Video), [1] AU 4238 (Audio)
stream[0]: muxing done (4520 AUs, 180.75 s)
stream[1]: muxing done (4239 AUs, 180.81 s)
mux completed
video.mp4 is 13314kb
audio.mp4 is 1496kb
and the muxed av.mp4 is staggering 36474kb!
Anybody finds this normal?

Nice, you find a little glitch in our file handling. You may have a previous file using the same name. Delete av.mp4 and try again. It should be better then. Let me know.

-- bobololo.

[virus]

:rolleyes:

this time I'm unable to render the file... I'm unable to register the filters. I run the .bat and regsrv32 does not give any error ("succeded"...). But the filters are not successfully registered and I cannot open/decode the file (the render fails, checked with GSpot, too). I've tried to build a graph manually using Graphedit but when I select the Ateme filters (both filters) from the list and hit "Insert filter" I get the following:

"The filter could not be created. Resources used by this filter may already be in use. Interface not registered (return code: 0x80040154)"

I've tried re-registering. No luck. :(
What can I do?

[superdump]

Originally posted by virus
:rolleyes:

this time I'm unable to render the file... I'm unable to register the filters. I run the .bat and regsrv32 does not give any error ("succeded"...). But the filters are not successfully registered and I cannot open/decode the file (the render fails, checked with GSpot, too). I've tried to build a graph manually using Graphedit but when I select the Ateme filters (both filters) from the list and hit "Insert filter" I get the following:

"The filter could not be created. Resources used by this filter may already be in use. Interface not registered (return code: 0x80040154)"

I've tried re-registering. No luck. :(
What can I do? I know it's the suckiest method ever, but have you tried rebooting? :)

[bobololo]

Originally posted by Andrey
One more question: if I kill codec process occasionally, the resulting file isn't playable (2nd pass, of course).
Is this the way things are ment to be ?

Yes, the mp4 file headers are written when the file is closed. If you kill the process while the encoding is running, the resulting file will miss these headers which makes it unusable.

-- bobololo.

[superdump]

You guys running beta 2 will most likely need the msvcrtd.dll (http://www.dll-files.com/dllindex/dll-files.shtml?msvcrtd) file available from that page to run the MP4 Tool Box program.

Here are a few nifty screenshots of what it can do:

http://www.swains.plus.com/superdump/MP4TB-01.png

http://www.swains.plus.com/superdump/MP4TB-02.png

http://www.swains.plus.com/superdump/MP4TB-03.png

http://www.swains.plus.com/superdump/MP4TB-04.png

http://www.swains.plus.com/superdump/MP4TB-05.png

[bobololo]

Originally posted by virus
:rolleyes:

this time I'm unable to render the file... I'm unable to register the filters. I run the .bat and regsrv32 does not give any error ("succeded"...). But the filters are not successfully registered and I cannot open/decode the file (the render fails, checked with GSpot, too). I've tried to build a graph manually using Graphedit but when I select the Ateme filters (both filters) from the list and hit "Insert filter" I get the following:

"The filter could not be created. Resources used by this filter may already be in use. Interface not registered (return code: 0x80040154)"

I've tried re-registering. No luck. :(
What can I do?

Maybe try unreg the filters from beta-1, then re-register those from beta-2. Is that still with win98se ? Maybe you could consider upgrading to 2k/xp ?

[virus]

Originally posted by bobololo
Maybe try unreg the filters from beta-1, then re-register those from beta-2. Is that still with win98se ? Maybe you could consider upgrading to 2k/xp ?
Yes, Win98SE. The filters from beta-1 have been unregistered and deleted right after you annunced the beta-2 release, I've even rebooted after deleting them. Oh, and I've also rebooted after installing the beta-2 ones. No luck.

And of course upgrading is out of question... I've got dozens of DS filters installed (some of them manually with regsrv32) and they all work pretty fine. Do you want me to buy a copy of WinXP just to beta-test a filter? ;)

[Sirber]

encavc.exe -i test.avs -o test.mp4 -qual extra -rcmode vbr -br 600000 -psy 1 -maxb 3 -cartoon -ref 2

Encoder encode at 3mbps, regardless what BR I set :confused:. Also, the output is unplayable.

http://www.detritus.qc.ca/test.mp4

[superdump]

Originally posted by bobololo
Maybe try unreg the filters from beta-1, then re-register those from beta-2. Is that still with win98se? Maybe you could consider upgrading to 2k/xp?Lol! Fantastic suggestion. :) I guess as M$ aren't supporting Win98SE anymore I guess Ateme might not need to. But still, it might be nice.

From my testing of the new adaptive deblocking with base level setting it's looking good. I would now recommend using this method over fixed and choose your level.

[bobololo]

Originally posted by Sirber
encavc.exe -i test.avs -o test.mp4 -qual extra -rcmode vbr -br 600000 -psy 1 -maxb 3 -cartoon -ref 2

Encoder encode at 3mbps, regardless what BR I set :confused:. Also, the output is unplayable.

Our VBR means constant quantizer, so the specified bitrate is just ignored. Try "-rcmode 2pass" instead.

[Sirber]

ha! encoding now at correct bitrate.

Thx!

[edit]

Output is still unplayable, with ffdshow or your filter. MPC uses 70% CPU though...

About encoding:
FPS is about 7-10 on my 2000+.

[bobololo]

Originally posted by Sirber
Output is still unplayable, with ffdshow or your filter. MPC uses 70% CPU though...

Are you using beta-2 filters ? have you try graphedit with the following graph ?

Ateme MPEG-4 Parser (your_file.mp4) -> Ateme H.264 Decoder -> Video Renderer

If this works, check at your mpc filter overrides and make ateme's prefered and block some eventual filters able to split mp4 and decode H.264.

-- bobololo.

[virus]

Originally posted by superdump
I guess as M$ aren't supporting Win98SE anymore I guess Ateme might not need to. But still, it might be nice.

Absolutely wrong. Support for the Win9x kernel has been extended until June 30, 2006 (link (http://tech-report.com/onearticle.x/6099)) due to the still relevant diffusion of this family of OSs. Also, Nero is fully Win9x-compliant (or at least, it runs well on my PC... together with XviD, VP6.2, DivX, 3ivX, ffdshow/ffvfw and many other stuff)
Do you really think that Ahead is going to buy an NT-only codec?

(but where's bond with his WinME box anyway? :))

[Sirber]

Works in GraphEdit, does not in MPC.

The only filters used are:
WMR7 (windowed)
Nero Video Decoder
my file

:confused:

Also, from what I've seen in Graphedit, Q is jumping and very squary. You can check with the file on top of this page.

[superdump]

Originally posted by Sirber
Also, from what I've seen in Graphedit, Q is jumping and very squary. You can check with the file on top of this page. This is probably almost all down to bskip being too aggressive at the moment. But a clip as stressful as that at that low a bit rate would probably look similar with any codec, no? Try disabling b-frames and maybe turn up the deblocking a bit.

[JohnV]

Originally posted by Sirber
Works in GraphEdit, does not in MPC.

The only filters used are:
WMR7 (windowed)
Nero Video Decoder
my file

:confused:

Also, from what I've seen in Graphedit, Q is jumping and very squary. You can check with the file on top of this page. Try this: Goto MPC options -> Filters -> Overrides, and make Ateme h264 decoder preferred.

[Sirber]

I did that, Ateem H264 is being used. No frames is displayed also. I know this is very stressfull for a codec, but RV10 and VP6 can manage to have good to medium quality on that test clip.

[superdump]

Originally posted by Sirber
I did that, Ateem H264 is being used. No frames is displayed also. I know this is very stressfull for a codec, but RV10 and VP6 can manage to have good to medium quality on that test clip.Did you try without b-frames and with something like '-deblock -2 -adaptdeblock'? Maybe even stronger than that. Try a few different settings and see what the best you can get is. When the b-frame problem is fixed you can make a proper comparison.

[Sirber]

At 3000kbps and at 600kbps, I can't play it. Karl seems to have played it correctly. I will check if it's bframe related, tomorrow :D

[LostMP4]

Last test (with beta-1)
This time to check ABR mode accuracy and to make a "faster" encode - quality is still very good and without B-frames

Core encoder version 1.0.1.14

Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Rate Control : Abr
Target Bit Rate : 1200 kb/s
Quality : Normal
Init Quantiser : 20
Num Reference : 0
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred hpel qpel part

-- Start processing pass 1 / 1
* 72839: encoding @ 24.34 fps - bitrate 76.19 kb/s - 100.00% completed
* 72840 frames encoded @ 5.78 fps - average bitrate 1199.27 kb/s

[Jukke]

Originally posted by bobololo
Nice, you find a little glitch in our file handling. You may have a previous file using the same name. Delete av.mp4 and try again. It should be better then. Let me know.

-- bobololo. Bingo!
After re-muxing audio/video with no av.mp4 present the file sizes are just normal.

Audio: 1496kb
Video: 13315kb
Audio/Video: 14826kb

btw, my interlaced analogue TV-sources encodes pretty well, despite what the documentation says about interlaced material.

[plonk420]

bobololo, just like LAME has certain bitrates / presets that are tested a lot, are there any bitrate targets you might want to see tested more or genres of movies/video that would be more helpful than not? ie, Finding Nemo or, say, The Cell's "trip" sequence, or 30i/25i video?

[Teegedeck]

I believe finding a lead to good presets is one of the tasks beta-testers are supposed to fulfil.

[plonk420]

Originally posted by Sirber
Output is still unplayable, with ffdshow or your filter. MPC uses 70% CPU though...
[/B]

what bitrate and resolution? and i guess what clip? i got 720x480 @ 800kbps playing just fine on a AXP 1800+ with the beta1 decoder

[Selur]

just finished my 1st full film encode: (with beta 1)

Source: Demolition Man PAL DVD

input avisynthscript:
----------------------
LoadPlugin("C:\PROGRA~1\GORDIA~1\MPEG2Dec3.dll")
mpeg2source("D:\DEMOLITIONMAN169\VIDEO_TS\demolitionman.d2v")
crop(4,66,712,438)

encodersettings:
----------------------
"D:\encavc-beta-1\encavc" -i "D:\encavc-beta-1\demolitionman.avs" -o "D:\encavc-beta-1\demolitionman_753.mp4" -qual extra -rcmode 2pass -br 753000 -psy 2 -maxb 3 -par 16:9 -setef part -ref 5 -qp 12

an ended up with this:
http://selur.privat.t-online.de/line.jpg

haven't investigated much but since my earlier encodeings all look fine I suspect the line to be cased by the resolution 712x438.

Cu Selur

[plonk420]

man i'm feeling dumb tonight... how do you disable bframes? is it
-maxb 0
or
-setef bpred
i tried -setef bpred and bpred still showed up under Features
(this line: Features : ipred ppred bpred cabac deblock hpel qpel part)

[Jukke]

Originally posted by plonk420
man i'm feeling dumb tonight... how do you disable bframes? is it
-maxb 0
or
-setef bpred
i tried -setef bpred and bpred still showed up under Features
(this line: Features : ipred ppred bpred cabac deblock hpel qpel part) Try -clref bpred

[Sagittaire]

@ Selur

exotic resize 712x438 ... perhabs
use mod16 ...

@ Bobololo

with beta-2 (low compressibility encoding)

encavc.exe -i clip.avs -o H264-2000.mp4 -qual extra -rcmode 2pass -qp 30 -br 512000 -psy 2 -deblock -2 -adaptdeblock -ref 5

and ...

http://jfl1974.free.fr/Test/Comparatif/H264vsVP6-500.JPG

always RC probleme for the end of encoding ... target bitrate control is perfect (too perfect ... ???): quality is visualy very worst for the end ...

Perhabs a RC command ...

- RC light
poor target bitrate but very constant quality

- RC normal
good target bitrate and constant quality

- RC hard
perfect taget bitrate but constant quality is not certain

[Selur]

exotic resize 712x438
No resize, just cropping
(anamorph encoding is da way to go :D)

use mod16 ...
I will, just wanted to point out, that it`s buggy if your resolution is not mod16. :)

doing a small test with beta2 (same resolution) atm, and then with a mod4/mod8/mod16 encode, to see if mod4/8/16 is enough :)

=> same resolution with beta2 gives no problem :)

Cu Selur

[Gabriel_Bouvigne]

I did an encode of a 688x560/25fps clip with: -rcmode 2pass -br 600000 -clref qpel

I am unable to decode it in real time on my PIII 1.1GHz. I understand that this type of computer has not been sold since a few years, but I would have liked to be able to play it.

The thing that immediately come to my mind would be to reduce deblocking filter based on decoding speed. I understant that deblocking is done in loop on the encoder side and is a mandatory part of the standard, but perhaps some people could prefer to have a non compliant output than not beeing able to decode in real time.

Regarding ringing: it is quite different from the "usual" ASP ringing. It looks more like noise than ringing.

[bobololo]

To users who still have troubles with basic encoding, playing muxing, etc and can't get started (hey Sirber it's for you ;)). I strongly suggest you to join #mpeg on irc.freenode.org, there you'll find some fast and efficient support helping you to get the stuff working. So if you still are unable to encode and playback your file whereas every other seems to have no problem, just go there so we can prevent transforming this thread into a "getting started support" thread :)

Thanks.

ps: perhaps if this still continue, we really should split the thread into : "getting started, trouble & functional issues support" thread and "Quality feedback" thread as one of you already suggested ? What do you think ?

-- bobololo.

[Selur]

may be splitting into:
- getting started
- quality feadback
- bug report

Cu Selur

Ps.: didn`t happen with beta1:
-does anyone besides me have problems to playback beta2 files with tcmp? works fine with graphedit and wmp. (since it works when I, open it in graphedit and then open it in tcmp without closing graphedit I suspect it is a tcmp bug.)

-adding ffdshow as postprocessor gives me a green screen

[babayaga]

Originally posted by Sagittaire

with beta-2 (low compressibility encoding)

encavc.exe -i clip.avs -o H264-2000.mp4 -qual extra -rcmode 2pass -qp 30 -br 512000 -psy 2 -deblock -2 -adaptdeblock -ref 5

always RC probleme for the end of encoding ... target bitrate control is perfect (too perfect ... ???): quality is visualy very worst for the end ...

Perhabs a RC command ...

- RC light
poor target bitrate but very constant quality

- RC normal
good target bitrate and constant quality

- RC hard
perfect taget bitrate but constant quality is not certain

Just 2 small points :
1. your encode parameters don't give the best possible PSNR (-psy 0 -deblock -0 -cartoon should be better). For instance, -psy 1 or 2 should improve fades at the expense of the PSNR.

Regarding objective metrics like SSIM, our encoder should be above everybody else (including VP6 :-), but it's not the point in this beta test. We are far more interested by testers feelings.
Beeing 1 dB above XvID does not always implies that people with eyes prefer our encoder's results.
I've still in mind an XviD encode given by Cruncher that stuned me about the details and sharpness but that had relatively low objective metrics.

2. I guess I know the exact sequence you're using :-). I've not tried it lately and I'll check it tonight. This particular sequence stresses very much the fast 1st pass algorithm...

For the end of the sequence, you (and Superdump) made your point. The beheaviour will be modified to be on par with the rest of the sequence.

About the accuracy, I don't want to change it since it's very good and it's a very important issue to "normal" users.

Finally, don't suppose the RC algorithm we're using. It's very different from XviD or ffmpeg (AFAIK).

[LostMP4]

Beta 2, low bitrate, no B-frames (some blocking noticeable...)
Maybe an Abr related "bug": about at 98% encoding i noticed bitrate to stay over 6000 kb/s for a few seconds (to reach the filesize, I guess). It's better have an undersized file than having these peaks (visually "useless" but troublesome for playback from a CD and maybe incompatible with many profiles)

Core encoder version 1.0.1.16

Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Rate Control : Abr
Target Bit Rate : 600 kb/s
Quality : Extra
Init Quantiser : 20
Deblocking Strength : -2 (adaptive)
Num Reference : 0
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred cabac deblock hpel qpel part

-- Start processing pass 1 / 1
* 72839: encoding @ 16.21 fps - bitrate 62.54 kb/s - 100.00% completed
* 72840 frames encoded @ 4.36 fps - average bitrate 599.77 kb/s

Encoding complete

[LostMP4]

A question about RAM usage in encoding: is it normal it uses about 200 MB? Is that related to the available RAM (I've 1024 MB) or a must?

[Teegedeck]

@anyone having playback problems: Do you have any other h.264 codec installed? Make sure to remove it if altering priorities in MPC or Windows' videocodec properties doesn't help. Delete the dlls if all else fails. (Make a backup copy if you're not quite sure what you are doing...)

[Selur]

takes about 110MB on my system with 512MB RAM and about 220MB on my system with 1024MB RAM.
=> no must :)

Cu Selur

Ps.: only h264 decoder I have on my system is ffdshow, but since I disabled h264 support in it, this shouldn`t be the problem.

[LigH]

Probably not much to add here (I'm a little late):

avs2mp4.bat@ECHO OFF
IF "%1" == "" GOTO NoParam
IF "%2" == "" GOTO NoParam
IF "%3" == "" GOTO NoParam

ECHO %0 %1 %2 %3
C:\Programme\encavc\encavc -i "%1" -o "%2" -qual best -rcmode 2pass -br %3 -psy 1 -adaptdeblock -ref 2
GOTO :End

:NoParam
ECHO Syntax: %0 ^<input.avs^> ^<output.mp4^> ^<bitrate^>

:End

Matrix_Reloaded_Trailer_Ultra.logavs2mp4.bat Matrix_Reloaded_Trailer_Ultra.avs Matrix_Reloaded_Trailer_Ultra.mp4 900000
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com)

This software is an experimental MPEG-4 AVC / H.264 encoder. It is intended
for evaluation purpose only and redistribution is strictly PROHIBITED.

Resulting files generated by this software can be corrupted due to the
instability of the encoder. Please report back if it occurs.

Core encoder version 1.0.1.16

Input file : Matrix_Reloaded_Trailer_Ultra.avs
Output file : Matrix_Reloaded_Trailer_Ultra.mp4
Resolution : 1000x540 @ 24.00 fps
Length : 3634 Frames
Rate Control : 2pass
Target Bit Rate : 900 kb/s
Quality : Best
Init Quantiser : 24
Max Consecutive BFrames : 3
Deblocking Strength : -2 (adaptive)
Num Reference : 2
Psychovisual : 1
Cartoon mode : Off
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 3634 frames processed @ 4.99 fps
-- Start processing pass 2 / 2
* 03633: encoding @ 10.37 fps - bitrate 4.53 kb/s - 100.00% completed
* 3634 frames encoded @ 5.05 fps - average bitrate 900.25 kb/s

Encoding complete
Summary so far:

- stable, fairly fast for H.264 (3.2 GHz P4-HT)
- plays well in: WMP 6.4, WMP 9 (no seeking, though - just linear playback, pauseable)
{ addition: WMP 6.4 (player2.exe) crashes on exit. }
- does not play in: MPC (jumps between start/end forth and back), Nero ShowTime (black output, but timeline advances)
- 900 kbps is a bit too low for 1000x540 in a few scenes, but overall: :eek: as expected frm H.264

[Gabriel_Bouvigne]

I tryed without deblocking filter, and unfortunately it doesn't help enough to make the upper clip decodable in real time.

[Selur]

@Gabriel_Bouvigne: disabling cabac might also speed things up

[Sagittaire]

@Gabriel_Bouvigne

try -clref bpred,cabac for high resolution

[LostMP4]

Originally posted by LigH
Summary so far:

- stable, fairly fast for H.264 (3.2 GHz P4-HT)
- plays well in: WMP 6.4, WMP 9 (no seeking, though - just linear playback, pauseable)
- does not play in: MPC (jumps between start/end forth and back), Nero ShowTime (black output, but timeline advances)
- 900 kbps is a bit too low for 1000x540 in a few scenes, but overall: :eek: as expected frm H.264

It should play in Showtime, maybe you haven't the latest update installed

[Sirber]

Originally posted by plonk420
what bitrate and resolution? and i guess what clip? i got 720x480 @ 800kbps playing just fine on a AXP 1800+ with the beta1 decoder 640x480. I don't think it's CPU related.

[Sirber]

Originally posted by LigH
- does not play in: MPC (jumps between start/end forth and back), Nero ShowTime (black output, but timeline advances)Same problem as me :D

[Teegedeck]

Right-click and check if it actually is the Ateme-filter which does the playback.

[Manao]

LostMP4 : your speaking of encoding ? If so, in the 200 MB, you should count the memory used by avisynth. For me ( 512 MB ), with a classic script, encavc ( ref 5, bpred, 712x438 ) uses 87 MB. If I add to the script SetMemoryMax(16), it takes only 39 MB.

[Jukke]

Originally posted by LigH
- does not play in: MPC (jumps between start/end forth and back), Nero ShowTime (black output, but timeline advances)
Beta2 encodes (3 minute clips) runs smoothly in MPC on my machine (as mentioned earlier, had to disable h264 support in ffDShow for the ateme decoder to get into action), can seek as well. Nero ShowTime locks up when trying to seek.

[Sirber]

Originally posted by Teegedeck
Right-click and check if it actually is the Ateme-filter which does the playback. It is, check page 8.

[Soulhunter]

Something about the new version...

Im no more able to open the mp4's in VDubMod via AviSynth's DirectShowSource !!!

I get this (http://img86.exs.cx/my.php?loc=img86&image=New_AtemeB2.png) here... :(

After registering the old filters, everything works !!!


Bye

[JohnV]

Originally posted by Gabriel_Bouvigne
I did an encode of a 688x560/25fps clip with: -rcmode 2pass -br 600000 -clref qpel

I am unable to decode it in real time on my PIII 1.1GHz. I understand that this type of computer has not been sold since a few years, but I would have liked to be able to play it.

The thing that immediately come to my mind would be to reduce deblocking filter based on decoding speed. I understant that deblocking is done in loop on the encoder side and is a mandatory part of the standard, but perhaps some people could prefer to have a non compliant output than not beeing able to decode in real time.

Regarding ringing: it is quite different from the "usual" ASP ringing. It looks more like noise than ringing.
I'd try -clref bpred,deblock.
Also using adaptive deblocking often uses less cpu than constant.

[Jukke]

Wouldn't it be nice if the encoder could have a mode similar to the thread priority idle in Virtualdub? Would be great if the encoder could run silently in the background, without slowing down other applications running on the machine at the same time.
I guess the supposed audience of the encoder would like to do other things with their only home computer than just encode video.

[Sirber]

I think that will be handeled by Nero once the codec is in it.

[Soulhunter]

Strange, what happened here... :confused:

- Source sample (http://img86.exs.cx/my.php?loc=img86&image=Source_5_550.png)

- Ateme sample (http://img86.exs.cx/my.php?loc=img86&image=Ateme_5_550.png)
-qual best -rcmode 2pass -br 10000000 -psy 0 -maxb 1
Note: I raised the brightness 5% to make this fault more visible !!!


Bye

[thegeby]

Report
Beta 2
Celeron 2.66 512MB
Clip from NTSC film

AVS Script:
Loadplugin(MPEGDecoder.dll)
MPEGSource(lost.vob)
ConvertToYV12

Default avcenc

Encoding freezes at +/-80%. Identical result with two different clips (from same movie)

[LigH]

Originally posted by Teegedeck
Right-click and check if it actually is the Ateme-filter which does the playback.
MPC uses the "Nero Video Decoder". I'd probably have to update NVE, the filter tells me (C) 2003; stupid me...
__

After updating to NVE 2.1.2.18:

MPC plays (pauseable), but hangs or crashes on stop. Hangs on seek.
WMP 6.4 tries hard to seek but hangs. Stoppable.
NST 1.5.0.37: Black window, but advances (reports "Video: AVC")

After un- and re-registering the Ateme beta 2 filter:

MPC jumps forth and back between start and end. Those were the same I had before updating NVE.

[JohnV]

Originally posted by LigH
MPC uses the "Nero Video Decoder". I'd probably have to update NVE, the filter tells me (C) 2003; stupid me...
__

After updating to NVE 2.1.2.18:

MPC plays (pauseable), but hangs or crashes on stop. Hangs on seek.
WMP 6.4 tries hard to seek but hangs. Stoppable.
NST 1.5.0.37: Black window, but advances (reports "Video: AVC")

After un- and re-registering the Ateme beta 2 filter:

MPC jumps forth and back between start and end. Those were the same I had before updating NVE.
In MPC try preferring the Ateme filter and disable raw video decoding from ffdshow if you have that enabled.

[LigH]

Originally posted by JohnV
In MPC try preferring the Ateme filter...
Yes, this worked!

MPC plays fine, seekable, pauseable, stoppable. :cool:

Let's see if we can prefer its merit permanetly using e.g. RadLight filter manager.

[superdump]

Originally posted by Soulhunter
Strange, what happened here... :confused:

- Source sample (http://img86.exs.cx/my.php?loc=img86&image=Source_5_550.png)

- Ateme sample (http://img86.exs.cx/my.php?loc=img86&image=Ateme_5_550.png)
-qual best -rcmode 2pass -br 10000000 -psy 0 -maxb 1
Note: I raised the brightness 5% to make this fault more visible !!!Is the brightness level the same in your reference and output snapshots?

[superdump]

Originally posted by Jukke
Wouldn't it be nice if the encoder could have a mode similar to the thread priority idle in Virtualdub? Would be great if the encoder could run silently in the background, without slowing down other applications running on the machine at the same time.
I guess the supposed audience of the encoder would like to do other things with their only home computer than just encode video. Use ctrl+alt+delete and right-click on the encavc process to set the priority to whatever level you wish. I think you're looking for "low". :)

[superdump]

Originally posted by Soulhunter
Something about the new version...

Im no more able to open the mp4's in VDubMod via AviSynth's DirectShowSource !!!

I get this (http://img86.exs.cx/my.php?loc=img86&image=New_AtemeB2.png) here... :(

After registering the old filters, everything works !!!With the old filters, for me, it would just decode the first frame and no more. With the new filters, I also get this green output. We're not sure why at the moment.

[P0l1m0rph1c]

Or use start.exe. Like:

start /IDLE encavc -i asdasd.avs -o asdasd.avs -br 123123 blah blah

[Jukke]

Originally posted by superdump
Use ctrl+alt+delete and right-click on the encavc process to set the priority to whatever level you wish. I think you're looking for "low". :) :) You're so right! Never seen that option before, I'm happy.

[Jukke]

Originally posted by P0l1m0rph1c
Or use start.exe. Like:

start /IDLE encavc -i asdasd.avs -o asdasd.avs -br 123123 blah blah Even better than Superdump's way. Great, thanks!

[Soulhunter]

Originally posted by superdump
Is the brightness level the same in your reference and output snapshots?
Should be, I raised the brightness @ both samples equally !!!

Seems there is some sort of "smoke" in the Ateme encode that shouldn't be there... :confused:

Maybe this part of the frame belongs to a different frame much later or so ???


Bye

[bobololo]

Some of you ask me for futher mp4muxer documentation. Here it is :

mp4muxer.exe -i <stream> [-f <extra_params>] [[-i <stream>] [-f <extra_params>]] [-m <interleaving in ms>] -o <output.mp4>

When <stream> is a mp4 file, you can pass extra parameters to specify which track you want to use (indeed, the mp4 file can contain several audio/video tracks). The extra parameters are :

"t:audio" to use first audio track (without the double quotes)
"t:video" to use first video track (without the double quotes)

If you want a audio or video track different from the first one, you can use :

t:audio&id=<trackid>
t:video&id=<trackid>

where <trackid> is the correct track id to use (you can get the track id using mp4 tool box). Be sure to know what you're doing when using these advanced parameters.

When <stream> is aac file (adts format), there is no extra parameter available.

Please make sure your file has .mp4 or .aac extensions. Others will be ignored.

ps: a new -priority <above|below|idle|normal|high|realtime> has just been added to encavc.exe :) To be available in the next beta release.

-- bobololo.

edit: -priority option is not in available in beta 2 yet.

[Jukke]

Originally posted by bobololo
Some of you ask me for futher mp4muxer documentation. Here it is :

mp4muxer.exe -i <stream> [-f <extra_params>] [[-i <stream>] [-f <extra_params>]] [-m <interleaving in ms>] -o <output.mp4>

ps: a new -priority <above|below|idle|normal|high|realtime> has been added to encavc.exe :)Beautiful!

When we're at it, when you wrap AAC audio in an mp4-container in FAAC, you could also add some metadata (or is it atoms?) like:
faac.exe -w -q 75 --artist "Author" --title "Title" --comment "Rating" "UsualSuspects.wav" -o "audio.mp4"
Is it possible to add similar functionality to mp4muxer?

[edit] formatting

[Selur]

okay, now I'm
1st totally lost in this thread, too much discussion :)
2nd grumpy since the dsfilters don't like me
(won't work with directshowsource in avisynth; don't like ffdshow als postprocessor; only seem to work like they should in MPC, which I don't like,...)
3rd frustrated, since I just killed my second full movie encode
(pressed the wrong batchfile :( (I wrote) )

Cu Selur

[bobololo]

Originally posted by Soulhunter
Should be, I raised the brightness @ both samples equally !!!

Seems there is some sort of "smoke" in the Ateme encode that shouldn't be there... :confused:

Maybe this part of the frame belongs to a different frame much later or so ???

I'm trying to reproduce your encode. Can you provide your avs script and the encoding settings you used please ? Thanks.

[CruNcher]

Maybe this part of the frame belongs to a different frame much later or so ???


hmm sounds like the old XviD B-frame prediction problem do you tried it without b-frames is it still visible ?

[Soulhunter]

Originally posted by bobololo
I'm trying to reproduce your encode. Can you provide your avs script and the encoding settings you used please ? Thanks.
I used this (ftp://ftp.heise.de/pub/ct/spezial/shuttle.mpg) source, and....

- De-interlaced it (blend fields)

- Centered the image (dunno the exact parameters anymore)

- Feeded it to FFVFW (IIRC I added some noise)

- Resized it to 1024x576 with Lanczos

- Encoded it to FFV1 (size around 1.05 GB)

- Feeded this via Avisyth (DirectShowSource) to the encoder (settings @ page 10)


Sounds a bit confusing, huh... :o


But maybe I already found the reason for this !!!

Atm I dunno if my premonition is right, but...

I will post back later !!!


Bye

[Soulhunter]

Originally posted by CruNcher
hmm sounds like the old XviD B-frame prediction problem do you tried it without b-frames is it still visible ?
Assumed the same thing, but...

After rising the brightness of the source even more, I realized its already there !!!

Its no smoke, its a very weak flood-light !!!


But @ the Anteme encode its much brighter and "floating" around !!!

Disabling b-frames doesn't help...
____________________________________

EDIT:

Removed, coz probably misleading !!!

Read the stuff below...
____________________________________

Btw, Ive re-done this "too bright flood-light" encode...

Got exactly the same results !!!


Bye

[Bulletproof]

Try disabling the "part" encoding option, maybe that might help.

[Teegedeck]

So here finally come my first test results; I merely tested an 81-frames-long clip from the HDTV Matrix 3 trailer (rev_theatre_0x10383910_1024_dl.mov with "trim(1431,1512)", no filtering of course) and it took me 3 hours... 31 files were encoded in the process.

The clip apparently wasn't a problem-sample as I encountered no bugs of any kind.

Aims
I value a clean test-setup very highly, so please excuse me if I tell you in detail:

Test results aren't worth anything if you aren't 100% sure how to interpret them. So the first question to ask myself before a test is: What do you want to find out?

My personal usage of codecs dictates that I want to find transparency in a codec. I don't care for internet-streaming, I want backup-copies of my stuff that I really cannot tell from the original ("transparency").

So, the first question to this new codec is: Can it deliver transparency?

If Ateme h.264 manages to reach transparency, the next question would be: Does it do that at a lower bitrate than MPEG-4 ASP (XviD)? Otherwise there would be little point in using it. From a technical viewpoint, H.264 should do so easily. Personally, I would be disappointed with anything less than 1/3 bitrate-savings.

The test procedure I've used was as follows:

Setup
Choice of sample
About the selection of the clip: My thought is such that a scene should be tested which would show the problems that arise from a bad codec configuration most visibly. As our eyes are best trained at recognizing faces (we look at faces all the time...), we spot differences here first. So I opted for two short closeups of the faces of agent Smith and 'that other guy with blood all over his chin'. An action sequence would not be my choice because the eye just doesn't manage following too much motion and I don't want to compare screenshots, it's a second-rate quality indicator.

Tested switches
What else is important to say about the test-setup? I used a fixed quantizer because I don't want to test the performance of the two-pass or ABR algo for now.

Not all switches were tested because it would make the test too complex. CABAC, b-frames, data partitioning, h-pel and q-pel were always left on because they should help and I trust the programmers knew what they were doing. I would only expect benefits from switching them off if the codec exhibited problems that point to a buggy implementation.

Switches were tested in a sensible order. As my aim is transparency, all switches that potentially blurr or alter the picture in any other undesirable way were spared till the end. These switches were -deblock and -psy.

Actual test
First I tried to find the highest quantizer that still delivered transparency for me, using the highest encoder quality and only varying the quantizer (deblocking switched off). Actually, my first guess (-qp 20) wasn't so bad (but then again I did play with quant 25 when I first received the encoder and it turned out non-transparent). My result was that "-qp 19 -qual extra -clref deblock" is the highest compression that produces a transparent encoding of this specific clip for me. The encoder quality will be tested in the end to see whether any quality is lost with it.

-qp 20 was the quantizer that was just about not transparent anymore. Now I tried using other features to find out whether I could push the limit of transparency up by one quantizer.

I tried to increase the number of reference frames, which should not alter the picture in any way. I used -ref 5 and -ref 16 but at least for this short test-clip they didn't help the quality in any way.

Next tested whether -psy or -adaptdeblock -deblock helped at quant 20 (the simple -deblock optioin didn't seem so good to handle when I first had a go at it with beta1).

After numerous tries it turned out that (to my surprise) indeed "-adaptdeblock -deblock -3 " made quant 20 look just about transparent to me. (I'm still not absolutely sure whether I would use it, though, or would rather prefer to play it safe). -psy didn't seem to do anything good for an encoding that should yield transparent results.

Now I tested whether I could get away with lowering the encoder quality. The result was that lowering it to 'normal' quite drastically increased the filesize at unchanged picture quality. I could not produce or perceive any difference between -qual best and -qual extra though.

The final step was to compare the quality and bitrate to an XviD (1.1) clip which is just about transparent to me. The clip was encoded with the SixOfNine matrix at quant=4; adaptive quantization was used, trellis, quarterpel, gmc, vhq=4 (for b-frames also), the defaults.

Results
The visual quality was indeed the same (i.e. excellent) - otherwise I would have gone wrong somewhere because transparent is transparent.

Now, if the bitrate of the Ateme clips was about 1/3 lower than that of the XviD clip I'd call it a successful showing of H.264's capabilities. If it was even lower, I'd call it a BIG success.


Filesizes:
Ateme h.264 at -qp 19: 893 kb
Ateme h.264 at -qp 20: 696 kb
XviD at quant=4: 1006 kb

Ateme at -qp 19 was 11.23% smaller than XviD.
Ateme at -qp 20 was 30.81% smaller than XviD.

Caution: These values are results of testing a virtually no-motion clip. Actual values may differ quite a lot. ATM I am encoding the complete trailer in order to find out how filesizes look on high-motion scenes. I will let you know when I'm done.

The bottom-line after testing this sample is: Ateme h.264 fulfilled my expectations for a good h.264 implementation. A competitive codec. My congratulations go out to its developers.

One also has to remember few people are nearly as geekish as I am (or watch their stuff on a 19'' Eizo TFT). Using the -adaptdeblock option in a cautious way lets you raise quantizer still a little to reach XviD SixOfNine-HVS quality for example. Most people will be perfectly sound to call a "-qp 23 -adaptdeblock -deblock 3 -qual extra" encoding transparent (which is only 315 kb in size and still comparable to XviD with SixOfNine-HVS and 978 kb - i.e. at 32.2% its filesize).

A short round-up of the settings mentioned:

TRANSPARENT (comparable to SixOfNine at quant=4):

-qp 19 -qual extra -clref deblock
-qp 20 -adaptdeblock -deblock -3 -qual extra

comparable to SixOfNine-HVS at quant=4:
-qp 21 -adaptdeblock -deblock -2 -qual extra

smallest filesize at acceptably-near-to-transparent quality (a little worse than XviD at SixOfNine-HVS):
matrix -qp 23 -adaptdeblock -deblock 3 -qual extra

(-qual extra could be replaced by -qual best)

UPDATE: I just finished encoding the whole trailer and now the results are closer:

XviD at quant=4: 105 MB;
Ateme at -qp 19: 98.4 MB (6.29% smaller)
Ateme at -qp 20: 87 MB (17.14% smaller)
[edit: The original trailer is 100 MB in size...]

It would seem XviD handles lots of motion and detail very well for a humble MPEG-4 ASP codec. :)

Edit: In the light of these last results, Ateme h.264 seems very good, its edge over XviD for high-end encodings is still small ATM though. More filesize comparisons at the above settings are to follow. I'm gonna test other clips in order to verify transparency at -qp 20, too.

[Soulhunter]

Originally posted by Bulletproof
Try disabling the "part" encoding option, maybe that might help.
Wow, you are right...

After disabling "part" the brightness of the spot-light seems to be correct !!!

- Sample without part (http://img86.exs.cx/my.php?loc=img86&image=Ateme_noPart_550.png)

But if you look close enough, you still see some blocks... :(


Bye

[Soulhunter]

Gah, I got the same symptoms* with a trailer of Terminator 3...

* Means -> Increased brightness & blocks @ parts of some frames !!!

-qual best -rcmode 2pass -br 6000000 -psy 0 -maxb 1

- Source sample (http://img86.exs.cx/my.php?loc=img86&image=T3_Source_1672.png)

- Ateme sample (http://img86.exs.cx/my.php?loc=img86&image=T3_Ateme_1672.png)

But the rest of the encode looks great... :rolleyes:

Gonna encode without "part" to see if it helps here as well !!!


Update:

Nope, disabling "part" does not help in this case... :(


Bye

[superdump]

Soulhunter: I still see the light patch personally. I'd say without part but with cabac it looks about the same as with part but without cabac, maybe sightly worse. It's still not as good as the original though and that light beam has still been enhanced.

[Teegedeck]

It doesn't take much to produce such an effect. Use Didée's semi-insane matrix and you can experience similarly interesting enhanced lighting in XviD, too. So I don't think it is a bug in any of the fancy features.

[bobololo]

Just a little note about our latest fixes/improvements :

- The AviSynth DirectShowSource() issue is fixed. With the current filters a nasty typo prevent mp4 files to be correctly sourced by DirectShowSource(). So don't waste your time tweaker your filters config, it's our fault ;)

- GraphEdit couldn't save the graph when it includes our source filter. This was also caused by another nasty typo ! It's fixed now.

- mp4muxer.exe missed to truncate an existing file. It is fixed.

- The process priority of encavc can be set by the '-priority <prio>' option.

- Last but no least, the bskip jumping blocks issue has received a solution that clearly improves the problem. But still need to be extensively tested.

All these fixes are to come in the next beta expected by the begining of next week.

-- bobololo.

[virus]

Originally posted by bobololo
All these fixes are to come in the next beta
:(

quoting from the Nero Recode 2 official page (http://www.nero.com/en/631943759476949.html):
System Requirements

Microsoft® (Windows) 98, 98SE, ME, 2000, XP, Server 2003
Pentium Celeron 800Mhz (Minimum)
128 MB RAM
Up to 4.8 GB hard disc space (for Image files)
Screen resolution at least 800 x 600 Pixel, 16 Bit colour depth or higher
DVD recorder
could some of the other beta-testers please support my request (yes, even if you run XP)? I see the devs implementing even the unneeded small options (like "-priority") ignoring that the files are completely unplayable under one of the supported platforms. This is normally considered a critical issue and usually receives a very different level of attention. Thanks in advance for your support!

virus

[bobololo]

Originally posted by virus
:(

could some of the other beta-testers please support my request (yes, even if you run XP)? I see the devs implementing even the unneeded small options (like "-priority") ignoring that the files are completely unplayable under one of the supported platforms. This is normally considered a critical issue and usually receives a very different level of attention. Thanks in advance for your support!

Yeah I'm sorry, please consider that this beta is not a recode beta. The codec itself is completely cross-platform but our tools which integrate the codec may have flaw when running on old platform like Win9x. These tools have nothing to do with the final product.

We're doing our best to try to make them work on your plateform as it was previously done following your report on encavc. But with regarding to your filter registration problem we have no hint of what could happen. Have you succeeded to register the filters that came with beta-1 ? Do other filters like ffdshow, divx, etc work fine ?

-- bobololo.

[Sirber]

I got H264 working. I'll try to get the best settings for low bitrate anime.

[virus]

Originally posted by bobololo
Do other filters like ffdshow, divx, etc work fine?
man, you have quite a dark opinion of "the life with Win98SE" :)

Let me say that in the last 2 years I've found only 3 programs (in which I'm interested in) out of ~100 that don't work under Win9x: ICL8, DRF Analyzer and your DirectShow filters... (encavc works OK now)

I have XviD, VP6.2, DivX, 3ivX, ffdshow/ffvfw. All of them run fine. The only clue I have is maybe a conflict with the 3ivX muxer/splitter (which I use for .MP4 support). But the Ateme filters (from both beta-1 and beta-2) are simply not registered, despite the "registered successfully" messages printed out. As a matter of fact, if I try to un-register them the regsrv32 application hangs because there's nothing to un-register ;)

If you want me to check my System Register and report back if all the needed keys are created correctly please let me know. (and don't be so pessimist and suspicious, life under Win98 is still very, very easy & beautiful, even in 2004! :D)

[Tommy Carrot]

Well, i was using win98se up until last month (the reason i decided to change the OS was Doom 3 :p), and i remember a few cases where win98 had problems with registering something because of the long filenames. When i renamed them to 8+3 char form, the windows didn't have issues with the registering anymore. Perhaps this might be be your case too.

[virus]

Originally posted by Tommy Carrot
When i renamed them to 8+3 char form, the windows didn't have issues with the registering anymore. Perhaps this might be be your case too.
Thanks for the suggestion Tommy, but it doesn't work :(
GSpot keeps reporting the filter as "not registered":
Src Property Value
- - ** Problem ** ** Codec not registered
DSH Friendly Name Ateme H264 Decoder
DSH DirectShow CLSID {7E68F9E8-EAFA-4C02-A9FD-BA39F2D95C4A}

[Sirber]

Maybe you're missing some DLLs.

I still haven't found a way to get my clip whitout ugly blinking blocks :(

[bobololo]

@virus: I was just thinking, have you tried latest NeroVisionExpress filters ? Even they don't seek properly, they can let you watch your encodes.

@Soulhunter: can you upload your resulting t3trailer mp4 file that shows these blocks ? It seems the bitsream is broken. It's maybe related to the cabac and we need to check the file. Thanks.

@Teegedeck: very interesting experiments you've done here. I'd like to know if you think that transparency is reached whatever the source you encode at Qp 19 or is it only valid for the clip you mentioned ? Actually, depending on the source type, the compression ratio to get transparency can change a lot.

What is also outstantind in your tests, is that you actually evaluated the raw coding efficiency of our encoder (ie without RC). Your conclusions should make people realize about the high coding efficiency potential of H.264 which is really superior to MPEG-4 ASP. And more is still to come, our codec is quite young and hasn't exploited all the possibilities yet.

Finally, I would suggest you to try regulated modes which also improve the coding efficiency by using a smart bits allocation over the whole sequence. And I wouldn't be suprised it you could get transparency at lower bitrate.

[RadicalEd]

Originally posted by Sirber
I still haven't found a way to get my clip whitout ugly blinking blocks :(

Are you using B-frames? They don't seem to like anime :/

[virus]

Originally posted by bobololo
@virus: I was just thinking, have you tried latest NeroVisionExpress filters?I've been unable to d/l the free trial version of Nero6 ("New free demo package will be available soon"...), how can I find a direct link to the latest NVE demo or something similar?

EDIT: now downloading the standalone NVE package. I have no idea if I can install it...

[bobololo]

Originally posted by virus
I've been unable to d/l the free trial version of Nero6 ("New free demo package will be available soon"...), how can I find a direct link to the latest NVE demo or something similar?

http://nero.com/fr/download_nero6.php?pak=2&serv=de

[virus]

Eureka! :)

The standalone NVE update package is sufficient, even without Nero6. Showtime refuses to start ("your demo version is expired"... LOL) but I can open, watch & pause the encodes in the other players, at least. Seeking b0rks everything, but hey, we're improving, aren't we? :D

[Sirber]

I think the motion estimation engine is too fast and have problem detecting motion in anime content. Look at the sample in page 8.

[CruNcher]

@Soulhunter

I encoded the t3trailer with your settings no problems here hmm
65,7 MB (68.921.605 bytes)

except one wich i allready reported

[thegeby]

Has anybody else had this problem?

On some of our computers the reg.bat returns with a message from regsrv32: "LoadLibrary ("adf_srcmp4.ax") failed - The specified module could not be found". They all have NET Framework 1.1 installed.

The only computer that does thes reg.bat flawlessly unfortunately runs Intel Extreme (not) Graphics. I am very frustrated as after several encodes, I still cannot verify the quality properly, due to the dodgy graphics in my system.
Help!

[Manao]

thegeby : look at the third post of that thread : you need msvcr71.dll in order to register successfully the filters.

[SeeMoreDigital]

Originally posted by Sirber
I think the motion estimation engine is too fast and have problem detecting motion in anime content. Look at the sample in page 8. Sirber... I don't seem to be able to "lock on" and download your sample!

It might be traffic... so I'll keep trying...


Cheers

[Teegedeck]

Originally posted by bobololo
I'd like to know if you think that transparency is reached whatever the source you encode at Qp 19 or is it only valid for the clip you mentioned ? Actually, depending on the source type, the compression ratio to get transparency can change a lot.
You are of course quite right. I chose a clip where non-transparency is very easy to detect, so the constant-quality setting I chose could be called the 'extreme' preset. I am going to test on other sequences.

BTW, my findings from an overnight encoding session are perhaps not so pleasing for you: I compressed an episode of Starsky & Hutch (not so perfect quality). The settings which I rated 'just a little worse than XviD & SixOfNine-HVS @quant4' (actually somewhere between quant 4 and 5), "-qp 23 -adaptdeblock -deblock 3 -qual extra" produced an output of 527 MB. XviD & SixOfNine-HVS @quant4 produced an output of 525 MB. What can I say? Good ME in XviD. ;) Or maybe MPEG-AVC is even more dependent on clean sources than MPEG-4 ASP. (On the complete Matrix 3 trailer this Ateme setting produced an output that was 37.05% smaller than XviD @q=4) - which most people will find transparent.

Yes, I would rate the quality of both files pretty much identical. Actually not quite, right now I see that Ateme produced obvious dancing blocks on the face of one actor where XviD didn't - and also on some black background. Well, I did rate this Ateme setting a little worse than the XviD setting initially. I can post screenshots if you like.

[RBF]

1.It is possible to speak early now, but adf_srcmp4.ax does not play mp4 files with two audio tracks.

2. The -qp parameter works only in vbr-mode , or it is possible to limit maximal quantiser in 2 pass-mode?

[thegeby]

Manao: Thanks.

I had thought that the fact that I had installed Net Framework would cover that, but when checking, I found that NET does not install the file to the System32 folder. A quick copy/paste solved the problem.

[Soulhunter]

Originally posted by CruNcher
@Soulhunter

I encoded the t3trailer with your settings no problems here hmm
65,7 MB (68.921.605 bytes)

except one which i already reported
My encode has a size of 68.867.500 Bytes !!!

Source was a HQ DivX files...

Originally posted by bobololo

@Soulhunter: can you upload your resulting t3trailer mp4 file that shows these blocks ? It seems the bitsream is broken. It's maybe related to the cabac and we need to check the file. Thanks.

Sure, but where to upload this file... :confused:

Maybe here (ftp://nero.ateme.com/incoming) ???


Bye

[Mr_Schizo]

Can anybody test the -par setting on a small clip? Seems to be brocken here (the dshow filter ignored it and played the clip as 1:1).

thx

[CruNcher]

@Soulhunter

Are you sure it's not in the source my was from the DVD trailer
maybe a problem in combination with the DivX filter tough hmm

[virus]

ok, it's finally time to report back some impressions. I cannot do a proper comparison without seeking capabilities nor a working DirectShowSource(), so I decided to go for a high-motion clip (1000 frames) with the sea, some close-ups on faces, a bit of superimposed text and some underwater frames, just to see how well encavc retains detail. Of course the differences in such a clip can only be spotted by a careful frame-by-frame comparison... (which is the only thing I can do right now, until either the NVE or the Ateme filters are fixed)

I used XviD (with deblocking) and VP6.2 (sharpness 7, with deblocking only) at their best settings for comparison. Clean DVD source at 560x304 @ 25fps, Lanczos resized. Commandline used for AVC:

-rcmode 2pass -qual extra -br 1781000 -ref 3 -adaptdeblock

keep in mind that this rate is roughly 70% of XviD 1stpass size (I'll try lower bitrates with the fixes in beta-3). No postprocessing at all for encavc, in perfect H.264-style ;)

Needless to say, at this rate the in-loop filter was under investigation... at a first sight, I didn't like how encavc blurred some frames. But the in-loop filter is not to blame. I simply re-encoded without B-frames and the blurring disappeared ;)
Without B-frames, encavc delivers better detail preservation than VP6.2 (which was the reigning champ on this clip and doesn't use B-frames too) and much less artifacts than XviD, which heavily needs a deringer here.
Ateme's codec managed to reach near-transparency on several frames, especially in the very difficult underwater sequence. Right now I'm going to experiment with the in-loop deblocker to see if I can get even more detail and what the effect of -adaptdeblock actually is. I will also try to find out at what bitrate encavc is roughly on par with VP6.2.

stay tuned :)
virus

[Soulhunter]

Originally posted by CruNcher
@Soulhunter

Are you sure it's not in the source my was from the DVD trailer
maybe a problem in combination with the DivX filter tough hmm

The source looks fine -> the source frames ;)


About the DivX filter...

Dont even have DivX installed atm, I use ffdshow for decoding !!!


But...

If I encode the DivX -> FFV1 and use this as source, I get the same result !!!

But ffdshow is used for FFV1 decoding as well, no... :rolleyes:


Maybe I should use uncompressed input to check if ffdshow is the culprit ???


Btw, Ive cutted this shuttle source down (750 frames / the problem part) n' encoded it again...

Surprisingly the problem is no more visible with this shorten input !!!


Bye

[bobololo]

@sirber: Currently our bframe are not very good at low bitrate, this could explain your remarks on your clip. Some improvements were done lately and will be integrated to the next beta. Meanwhile, could you upload your source so we can reproduce your encode (ftp://nero.ateme.com/incoming) ?

@Soulhunter: yes this is the right place to upload.

@Teegedeck: Your note about "Starky & Hutch" matches precisely with my previous remarks. When encoding at constant quantizer you have a high risk of wasting much bits when it's useless. For a better understanding, consider it's common to have picture size variation in a factor of 2 or 3 when changing +/- 1 quantizer step for a result being nearly transparent (~0.1 dB PSNR). In your case, for a long clip with different types of sequence, you'll need to use the lower quantizer to achieve the overall transparency which may conduct to a quantizer that happens to be too high for many other sequences.

Actually AVC size versus quantizer behaviour is quite more "nervous" than ASP especially if you use bframe.

Basically, IMHO your experiment -trying to find the Qp for transparency and then check the size- is quite valuable for short sequence where the contents is homogeneous. Although, for longer and diversified clips, if you want to see the efficiency of AVC, you really need to rely on a good RC able to correctly estimate size/Qp and to allocate bits wherever is it needed and save lots of bits transparently when it's possible. This in order to achieve optimal quality. To give you an idea, with 2pass RC we usually reach around 0.5 to 1 dB PSNR increase compared to a constant Qp encode for the same bitrate.

-- bobololo.

[Sirber]

Uploading. name: test.avi :D

[Soulhunter]

Feeding a uncompressed source...


1. - The source DivX -> Uncompressed RGB (http://img80.exs.cx/my.php?loc=img80&image=RGB_Source.png) with VDubMod

2. - Uncompressed RGB -> served via AviSynth... (http://img80.exs.cx/my.php?loc=img80&image=Source_AVS.png)
DirectShowSource("C:\Blah.avi").ConvertToYV12().KillAudio()
3. - Ateme "encodes" (http://img80.exs.cx/my.php?loc=img80&image=Encoder.png) this AVS source

4. - The result... (http://img80.exs.cx/my.php?loc=img80&image=Resulting_MP4.png)


Ehm, what happened here ???

Serving this AVS -> VDubMod -> XviD works excellent... :confused:


Bye

[Soulhunter]

Originally posted by bobololo
@Soulhunter: yes this is the right place to upload.
Ok, gonna upload "Soulhunters_T3_Clip.mp4" now !!!


Bye

[anonimitous]

@ Soulhunter
AFAIK Converting YV12->RGB24->YV12 isnt lossless with out subsampling .

[Teegedeck]

Originally posted by bobololo
@Teegedeck: Your note about "Starky & Hutch" matches precisely with my previous remarks. When encoding at constant quantizer you have a high risk of wasting much bits when it's useless. For a better understanding, consider it's common to have picture size variation in a factor of 2 or 3 when changing +/- 1 quantizer step for a result being nearly transparent (~0.1 dB PSNR). In your case, for a long clip with different types of sequence, you'll need to use the lower quantizer to achieve the overall transparency which may conduct to a quantizer that happens to be too high for many other sequences. I hope your understand that and have some patience with me.

Actually AVC size versus quantizer behaviour is quite more "nervous" than ASP especially if you use bframe.

Basically, IMHO your experiment -trying to find the Qp for transparency and then check the size- is quite valuable for short sequence where the contents is homogeneous. Although, for longer and diversified clips, if you want to see the efficiency of AVC, you really need to rely on a good RC able to correctly estimate size/Qp and to allocate bits wherever is it needed and save lots of bits transparently when it's possible. This in order to achieve optimal quality. To give you an idea, with 2pass RC we usually reach around 0.5 to 1 dB PSNR increase compared to a constant Qp encode for the same bitrate.
Certainly I'm going to test the merits of Ateme h.264's RC as well - but all in due time. Pure encoder performance is what I am curious to see now. RC or two-pass code is pretty independent of the codec itself, meaning you could probably plug XviD's RC on top of an H.264 codec with a small rewrite or vice versa. The RC hardly is the innovative part of H.264 that sparked so much interest that it made it as an amendment into the MPEG-4 specs. ATM I want to see the pure performance of its multiple reference-frames, CABAC, in-loop filtering etc.

If I would have tested two-pass with Ateme I would have tested two-pass with XviD, too, of course, so don't trust that this would have brought the Ateme encode ahead (hehehe) of the XviD encode again.

Don't worry, I, too, want to test real-life use (1-CD, 2-CD encodings) but this will be much easier to do when I have an idea which features to use at what bitrate and what quantizer for example will be just too high for certain content.

BTW; wouldn't it be a good idea to automate the strength of adaptive deblocking for two-pass in a way that links it to the current-frame quantizer?

I also was surprised that one step in quantization caused such huge differences in filesize ("nervous" alright). Isn't there any way to have finer quantization steps? This turned out very useful when insightful people created their own custom matrices for XviD.

[ac-chan123]

@ Soulhunter :
try any real uncompresed source from:
- http://www.vqeg.org (Video Quality expert group)
- http://www.cipr.rpi.edu/resource/sequences/
- http://eeweb.poly.edu/~yao/VideobookSampleData/video/
- http://www-i4.informatik.rwth-aachen.de/~imed/
- http://www.hhi.fraunhofer.de/german/bs/HiCon/downloads.htm
...

[Soulhunter]

Originally posted by anonimitous
@ Soulhunter

AFAIK Converting YV12->RGB24->YV12 isnt lossless with out subsampling .

Yes, I know... :rolleyes:

But I dont think that a color conversation is able to drop the filesize from 66MB -> 180kb !!!

Btw, I can play the resulting file, but I get only a black picture... :(


@ ac-chan123

Thanks for the links... :)

But I dont get why a "uncompressed" source should be different* than my converted one !!!

* I know that some info is lost while YV12->RGB->YV12 conversation, but...

That what the encoder gets is a raw YV12 source (IIRC YUY2 wont work) !!!


EDIT:

Found a solution for the raw YV12 -> encoder problem !!!

While DirectShowSource works not correctly with the encoder, AVISource does... :confused:

But, is this a bug in the decoder or in the encoder ???


Bye

[Soulhunter]

Update:

Ok, feeding the encoder with raw Y12 (bypassing ffdshow) does not help !!!

I still get this image distortion... :(


@ bobololo

Do you received my file ???

FileZilla told me that the transmission was completed...

But I cant see my file @ the index, its still shown as empty !!!


Bye

[ac-chan123]

The raw yuv files are better to compare with the encodet one, because ther is no decoder interpting space. Also this are sequences wich are used by most of the commercial encoder programmers and tester(like magazine). This sequences have alle somthing that is not easy to encode.

[Soulhunter]

Originally posted by ac-chan123
The raw yuv files are better to compare with the encoded one, because their is no decoder interpting space. Also this are sequences which are used by most of the commercial encoder programmers and tester(like magazine). This sequences have all something that is not easy to encode. Ok, I gonna use them later -> for my "detail" tests... :)

Thought the links where regarding my ecoding problems !!!

Btw, does someone know why raw YV12 input via DirectShowSource doesnt work ???


Bye

[ac-chan123]

this yuv file have no header, this are pictures only(multiple in one file). use the rawsource filter from warpenterprises( http://www.avisynth.org/warpenterprises/ ).

[LostMP4]

Originally posted by Mr_Schizo
Can anybody test the -par setting on a small clip? Seems to be brocken here (the dshow filter ignored it and played the clip as 1:1).

thx

Don't worry, Recode filters play the file and handle PAR correctly, but they can't seek (until next update?)

[virus]

I have a question on the deblocking strength (used together with -adaptdeblock). I've re-encoded the same test clip mentioned before with deblock strength -4 and -6 (the original clip was at the default -2). The 3 files obtained have exactly the same size, and they only differ for a few bytes near the end... here's an excerpt from the "fc /B" output:

....
0087FE68: FA E8
0087FE6B: 67 6B
0087FE6C: FA E8
008810B6: 67 6B
008810B7: FA E8
008810BA: 67 6B
....

This is the comparison between -4 and -6. Similar output happens comparing with -2. Apparently, almost nothing changed between -2 and -6, which is quite a big difference. I wonder if this is normal (shouldn't -adaptdeblock vary the filtering strength around the specified value?).

BTW I've determined on the aforementioned clip that encavc shows a comparable amount of detail with the best performing competitor (VP6.2) at roughly 200 kbit/s less... that's a ~11% saving. Impressive indeed :)