Ateme H.264 HP Beta Test : Bugs & Issues

[ChronoCross]

My initial thoughts are as follows(encoding only):

1) SOB I should have read the readme better i wasted like 3 hours before I realized the bitrate was in bits per second not kb/s bwhahaha lol. Perhaps you could change it to kb/s as I don't think anyone really does anything in bits anyway. (cosmetics)

2) There were times where the encoding seemed to stop. but picked back up several minutes later. I don't really know if this is anything to be concerned about as it may just have been CPU/memory/disk Swapping limitations.

3) I enabled pretty much everything cepts momochrome, lossless,interlaced, and custom scale matrix and I was getting 1.5-2fps of which I am extremely happy with considering my PC specs. It actually runs faster than divx 6 on insane quality. Not to mention I was using a filter happy AVS so that makes it even better(remember I deal with mainly anime sources and poor ones at that.)

I'll report back additional info once my first clip(23 minute clip) is finished encoding, but so far it's looking really good.

Regards,
ChronoCross

[Manao]

Chronocross : the speed shown during the encoding is not the overall speed, but the encoding speed, it doesn't take into account processing done outside the encoder.

Selur : the same command line here does use two threads. Can you post what encavc.exe outputs when using the command line on your computer ?

[kwtc]

Source was test.avi, 30,726 KB, DV interlaced, pretty shaky. Here's what I got with a few different lossless settings:

-qual fastest -setef interlaced -lossless:
00:34, 32,739 KB

-qual full -setef interlaced -lossless:
00:37, 30,956 KB

-qual full -setef interlaced -lossless -rcmode 2pass
01:12, 31,646 KB

-qual fastest -lossless:
00:46, 56,015 KB


I just looked at the original clip. It is "highly" interlaced; encoding it as progressive will indeed yield a much lower compression than encoding it as interlaced. You may wish to try -setef mbaff to see if result improves.

In lossless mode, the encoder encodes in VBR (variable bit rate) mode, hence doing two passes should take twice as long as a single pass and produce the same output file. We will fix the application so it does only one pass :rolleyes:

However, when I play your test.avi file and it ends, the player seeks to frame 0 and in that case what I see on screen is not frame 0 but the first field merged with the last field of the clip. This could explain why you obtain different file sizes in single pass and two pass modes.

[bobololo]

This is slightly off topic, but after I registered and verified with GSpot that I’m using the beta Ateme DirectShow filter, Ateme H264 Decoder.dll, I can't play my Reference Encoder clips. I re-registered the previous Nero filter, NeVideo.ax, and it plays correctly, except for the CABAC Initialization Table value error which causes it to freeze after about five seconds. The beta Ateme DirectShow filter does not seem to play a JM 9.6 clip with the correct or incorrect CABAC Initialization Table values. You can download the clip that I’m testing here:

http://rapidshare.de/files/2412410/HPII.MP4.html

BTW, the newest NeVideo.ax, 06/09/2005, Nero decoder still does not seem to have the correct CABAC Initialization Table values.

I've just checked your file and it has some issues with the video resolution. It is set to 32x16 and mp4box reports the same values. Once the es is demuxed and remuxed correctly, it works fine.


$ mp4box -info 1 HPII.mp4
Track # 1 Info - TrackID 1 - TimeScale 90000 - Duration 00:02:03.040
Media Type "vide" - Media Sub Type "avc1" - 3076 samples
MPEG-4 Config
Visual Stream - ObjectTypeIndication 0x21
AVC/H264 Video - Visual Size 32 x 16
Config Version 1 Profile 0x64 Level 0x28
Decoding Buffer size 0 - Average bitrate 0 kbps - Max Bitrate 0 kbps
No stream dependencies for decoding
StreamPriority 0

Computed info from media:
Total size 6390655 bytes - Total samples duration 123000 ms
Average rate 405 kbps - Max Rate 1456 kbps

[bill_baroud]

damn, couldn't download the encoder, i must have remember incorrectly my password :(

[Sagittaire]

I've got some problems getting the decoder filters to work...
If I change in Register.bat:

from
FOR %%x IN (*.dll *.ax) DO regsvr32 /s "%%x"
to
FOR %%x IN (*.dll *.ax) DO regsvr32 "%%x"


he displays an error when executing the batch file...
"LoadLibrary ("Ateme H264 Decoder.dll") fehlgeschlagen - Das angegebene Modul wurde nicht gefunden"

--> LoadLibrary ("Ateme H264 Decoder.dll") failed - The chosen module wasn't found

same for the parser


maybe I forgot something... just reinstalled XP on my Laptop and it's time to go to bed now.. zZzZzZzzzZZZzz

You must have MSVCP71.DLL and msvcr71.dll on your system

[Razorblade2000]

You must have MSVCP71.DLL and msvcr71.dll on your system

hehe

-->


You were right... The laptop I'm testing stuff on was a pretty "clean" Installation of WinXP --> msvcr71.dll, MPR.dll, msvcp71.dll and efsadu.dll were missing

Already had found out about it... but :thanks: anyway :)

[Selur]

Selur : the same command line here does use two threads. Can you post what encavc.exe outputs when using the command line on your computer ?

gave me this:
* Encoding summary

Input file : atemeTest.avs
Output file : atemeTest.mp4
Resolution : 1024x528 @ 25.00 fps
Length : 8218 Frames
Quality : Full
Rate Control : 2pass
Target Bit Rate : 2553 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Process Priority : Normal [1 thread(s)]


* Encoding Features

- prediction : ipred ppred bpred(2) wpred : using 1:1 ref(s)
- entropy : cabac
- subsampling : hpel qpel
- mb partition : 16x16/16x8/8x16/8x8
- interlaced : disabled
- misc : deblock(-2:adaptive) psy(3)

-- Start processing pass 1 / 2
* 100.00% completed
* 8218 frames processed @ 5.85 fps
-- Start processing pass 2 / 2
* 08217: encoding @ 1.51 fps - bitrate 54.25 kb/s - 100.00% completed
* 8218 frames encoded @ 0.61 fps - average bitrate 2553.01 kb/s

Encoding complete (time elapsed 04:12:23)

Cu Selur

[bobololo]

@selur, can you just try this cli: encavc.exe -i atemeTest.avs -o atemeTest.mp4 -thread 2

And check the encoding summary if it really uses 2 threads ?

@all, does anyone else experience problem with multi-threading ?

[Sagittaire]

OS: WinXP Pro SP2

Config: Sempron 2500+ O/C 1750@2100 Mhz

Day 1: Parser and decoder Test
encavc: 1.2.0.14
Ateme H264 Decoder: 2.0.1.0
Ateme MPEG-4 Parser: 1.2.5.2

to begin with the beginning ... lol

Your parser seem to have little problem (test with NDAVCMP, x264MP, x264HP)
Frame seem freeze, drop or perhabs frame order during playback (I don't know exactly but it's not fluid)
Seem not Ateme decoder problem because Nero Parser + Ateme dec work fine

# for example this command line don't play fine
encavc.exe -i Encodage.avs -o H264MP-450.mp4 -qual extra -rcmode 1st -log 1pass.log -br 447000 -deblock 0 -ref 16 -setef wpred -enhchrp -psy 1 -psnr -priority idle
encavc.exe -i Encodage.avs -o H264MP-450.mp4 -qual extra -rcmode 2nd -log 1pass.log -br 447000 -deblock 0 -ref 16 -setef wpred -enhchrp -psy 1 -psnr -priority idle

[LigH]

I would like to have an option to write a log file in addition to the console output. Currently, I have to select the console output, copy and paste it into a text file. A constantly changing output is not suitable for output redirection (app > logfile).

[Selur]

@selur, can you just try this cli: encavc.exe -i atemeTest.avs -o atemeTest.mp4 -thread 2

And check the encoding summary if it really uses 2 threads ?
=> 2 threads are used
(going to try to check which setting is causing it not to be used with my commandline)

Cu Selur

[couscous]

Your parser seem to have little problem (test with NDAVCMP, x264MP, x264HP)
Frame seem freeze, drop or perhabs frame order during playback (I don't know exactly but it's not fluid)


I have the same problem with a x264HP clip. It's not fluid, I think it's the frame order during playback (not sure). (cf my post on
http://forum.doom9.org/showthread.php?t=95890 )

couscous

[Selur]

Now, encoding goes fine,.. after using "encavc.exe -i atemeTest.avs -o atemeTest.mp4 -thread 2" my commandline too functions,.. strange,... (didn't restart my system or do anything except using the command line)
I'll report if the problem reappears,...

Cu Selur

Ps.: 98% CPU usage :D

[chilledoutuk]

is there any free playback filters that can decode avc high profile stuff yet?
Also would it not be a good idea for nero to release as a free downloadable playback filters like DIVX does if they want this codec to be used more.

[LigH]

The current ffdshow from celtic-druid (2005-06-11) can play High Profile AVC videos, as long as no custom matrices are used (limitations of x264 rev. 26x). The same for Mplayer.

[acidsex]

I am mad jealous of everyone thus far. Still havent received my login information so while others get to play and test, Ill sit here quietly awaiting that piece of paper and watch all the fun you all get to have. Someone share some samples so we can see what it offers.

[chilledoutuk]

so basically that means no csm?

acid ill post a couple in a sec ill have to not use csm otherwise you wont be able to play it with ffdshow.

[LigH]

Dear chilledoutuk,

I already have posted an issue about that topic. Would you please look at the first pages of this thread?

[chilledoutuk]

Dear chilledoutuk,

I already have posted an issue about that topic. Would you please look at the first pages of this thread?
thats nice

acidsex heres a clip i encoded
http://www.chilledoutuk.co.uk/vids/clip.mp4

[Selur]

Some feedback from other MultiCPUSystemUsers would be cool, since now 2 threads work fine in the 1st pass though, in the second pass CPUusage drops again to 50%. :(

Cu Selur

[acidsex]

@Chilled:

Much appreciated. D/Ling now. Im excited to see what Ateme has been up to.

[Zarxrax]

Ok I got the ateme decoder registered properly... and I still have blocky output on this clip that was supposed to be encoded losslessly! I thinks maybe I found a bug :D

Here is my commandline:
encavc.exe -i test.avs -o test.mp4 -lossless

The resulting file is really blocky on noisy areas, but looks fine on other parts of the file. This blockyness only happens when using the -lossless option.

Here is a 100 frame section (22MB) that is causing the problem, it is compressed with lagarith 1.3.4:
http://s48.yousendit.com/d.aspx?id=3O9I4YV1FSHFW0NPE4I6YBJRXV

[jfehr]

Not sure if you'd count it as a bug, but it is a bit of an issue for me...

Could you make the encoder return an error if any of the parameters are incorrectly set? (Ie misspellings, etc.) For example, I can call it with '-2pass' and it won't blink. (It won't do 2 pass encoding either, but that's expected.) Just a little error message (like 'Unknown parameter: -2pass') would be nice.

I know, I know, rtfm...

[babayaga]

Ok I got the ateme decoder registered properly... and I still have blocky output on this clip that was supposed to be encoded losslessly! I thinks maybe I found a bug :D
You did :mad:

[Bulletproof]

I wish there was a log feature as some people have said before, I made a batch file with 7 encodes with ">>logfile.txt" attached to the end of each command, unfortunately when I woke up in the morning it did not log correctly because of the way the percentages are written to the screen, all I saw were a bunch of music note ascii. I haven't found anything that's caused the encoder to behave wrong yet, but I have two questions, has deblocking been tuned to be more aggressive now? I've noticed that if you use -deblock 6 -adaptdbk that the picture will be considerably more blurry than the previous public release and the beta before that (using a bitrate of 900kbps), it could be my imagination or maybe the video content I'm using, but I'm not sure. My other question is how come there is a -csm option, and then there is also a csm switch for the setef command (-setef csm)? Is that so you can specify a different filename to use for the csm?

[Manao]

Bulletproof : because historically, features were enabled with the setef / clref flags, and because -setef csm alone use a default custom matrix ( which is in fact the same as the non custom one - EDIT - in fact, it's not the non custom one, it's the one defined in the h264 norm, my bad, and thanks kwtc for pointing that out )

Also, it appears that -adaptdbk does nothing now ( except the placebo effect ), hence your remark. But since for most encoding, -deblock 6 -adaptdbk amounted to -deblock 0, you get the same deblocking strength by using 0 ( or by setting a custom deblocking matrix beginning with -6 for quantizer 0 - 35, iirc )

Zarzrax : nice one ( and good torture clip, btw )

[LigH]

Please excuse this question, but... Which profile is used, if "High Profile" options are not enabled? How is it called then? In this x264 GUI proposal (http://forum.doom9.org/showthread.php?p=672631#post672631) it was called "Main Profile", is this correct?

[bobololo]

I've found another bug in the psnr computation. When 2-pass encoding, the psnr values printed at the end are wrong. It's fixed now.

[bobololo]

Please excuse this question, but... Which profile is used, if "High Profile" options are not enabled? How is it called then? In this x264 GUI proposal (http://forum.doom9.org/showthread.php?p=672631#post672631) it was called "Main Profile", is this correct?

The profile is automatically set depending on the tools you're using. So it can range from baseline up to high444 profile (lossless).

[*.mp4 guy]

I have the same problem with a x264HP clip. It's not fluid, I think it's the frame order during playback (not sure). (cf my post on
http://forum.doom9.org/showthread.php?t=95890 )

couscous

I get the same problem, It definately looks like frame ordering to me, heres a link to the clip to see if its reproduceable.

-X264.mp4 (http://sr2.mytempdir.com/54286)

[ChronoCross]

Well I've determined there is no way I can encode a 1280x720 clip on my machine with my current commandline settings. they are listed below

encavc.exe -i F:\DOT_HACK_SIGN_V6_BONUS\VIDEO_TS\HackAVCTest.avs -o F:\DOT_HACK_SIGN_V6_BONUS\VIDEO_TS\HackAVCTest.mp4 -qual full -rcmode 2pass -maxqp 1 -minqp 51 -mingop 1 -maxgop 300 -br 3944000 -psy 0 -deblock -2 -setef ipred,ppred,bpred,wpred,cabac,deblock,part,hpel,qpel,xf8x8 -adaptdbk -maxb 2 -enhchrp -par 1:1 -ref 1 -bref 1 -priority normal -thread 1 -fgboost 1.0 -psnr

here's the results from the encoding window. the first pass completed fine but after 12 hours of second pass

C:\Documents and Settings\ChronoCross\My Documents\My Downloads\Encoding Tools\A
teme>encavc.exe -i F:\DOT_HACK_SIGN_V6_BONUS\VIDEO_TS\HackAVCTest.avs -o F:\DOT_
HACK_SIGN_V6_BONUS\VIDEO_TS\HackAVCTest.mp4 -qual full -rcmode 2pass -maxqp 1 -m
inqp 51 -mingop 1 -maxgop 300 -br 3944000 -psy 0 -deblock -2 -setef ipred,ppred,
bpred,wpred,cabac,deblock,part,hpel,qpel,xf8x8 -adaptdbk -maxb 2 -enhchrp -par 1
:1 -ref 1 -bref 1 -priority normal -thread 1 -fgboost 1.0 -psnr
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.

Core encoder version 1.2.0.14


* Encoding summary

Input file : F:\DOT_HACK_SIGN_V6_BONUS\VIDEO_TS\HackAVCTest.avs
Output file : F:\DOT_HACK_SIGN_V6_BONUS\VIDEO_TS\HackAVCTest.mp4
Resolution : 1280x720 @ 23.98 fps
Length : 33491 Frames
Quality : Full
Rate Control : 2pass
Target Bit Rate : 3944 kb/s
Init Quantiser : 24 [51 - 1]
Gop Size Min - Max : 1 - 300 (closed)
Process Priority : Normal [1 thread(s)]


* Encoding Features

- prediction : ipred ppred bpred(2) wpred : using 1:1 ref(s)
- entropy : cabac
- subsampling : hpel qpel
- mb partition : 16x16/16x8/8x16/8x8
- interlaced : disabled
- misc : deblock(-2:adaptive) xf8x8 enhchrp

-- Start processing pass 1 / 2
* 100.00% completed
* 33491 frames processed @ 1.55 fps
-- Start processing pass 2 / 2
* 02854: encoding @ 0.05 fps - bitrate 4323.05 kb/s - 8.52% completed

thus ends my test of defualt for most settings+high profile+Full quality. Any suggestions to make it go faster than .000000005fps with these settings? I was just curious because the first pass finished rather normally as expected.

[*.mp4 guy]

I would set quality to best, and set refs to 2 each way to get a better qual/speed ratio. If you have slow ram or not much ram you might have to put the refs back to 1,1. Set the min GOP to the total number of refs in each direction added together, thus for 2,2 it would be 4. If speed is really important to you get rid of the psnr measurement.

[Andrey]

Hi, guys !

As a tradition, dshow filters does not work with bsplayer for me.
The picture is black and white and takes left half of the playing window...

In the WMP and mpc all is working properly.

[LigH]

@ ChronoCross:

-maxqp 1 -minqp 51

Are you really sure about that?! :D -- Try the other way round!

[kwtc]

I get the same problem, It definately looks like frame ordering to me, heres a link to the clip to see if its reproduceable.


There was indeed a frame reordering problem. Thanks for the link.

[couscous]

Hi guys,
I have a big problem with the "interlaced" tool.
I have made a test with a interlaced clip (Friends) with 500 frames.
I've just compared three encoding settings :
- no "interlaced" tool
- simply "interlaced" tool
- "interlaced" with "paff" and "mbaff" tool

1st clip
settings :

-br 900000 -qual extra -rcmode 2pass -psy 3 -adaptdbk -setef xf8x8 -maxb 3 -bref 3 -enhchrp -ref 3 -psnr -ssim -priority idle -denoiser
average bitrate : 900,94 kb/s
time elapsed : 4 min 26
http://rapidshare.de/files/2437515/Ateme-900-Friends-Test-sans_interlace.mp4.html

2nd clip
settings :

-br 900000 -qual extra -rcmode 2pass -psy 3 -adaptdbk -setef xf8x8,interlaced -maxb 3 -bref 3 -enhchrp -ref 3 -psnr -ssim -priority idle -denoiser
average bitrate : 560.39 kb/s
time elapsed : 6 min 03
http://rapidshare.de/files/2437534/Ateme-900-Friends-Test-interlaced.mp4.html

3rd clip
settings :

-br 900000 -qual extra -rcmode 2pass -psy 3 -adaptdbk -setef xf8x8,interlaced,paff,mbaff -maxb 3 -bref 3 -enhchrp -ref 3 -psnr -ssim -priority idle -denoiser
average bitrate : 899.98kb/s
time elapsed : 5 min 48
http://rapidshare.de/files/2437525/Ateme-900-Friends-Test-interlaced-paff-mbaff.mp4.html

As you can see in the second clip, the size is no good (560.39 kb/s instead of 900 kb/s)
For 2nd and 3st, I have some problem with the decoding:
when there is a lot of movement, the clip is jerky

I have a problem with the fonction "PSNR" : the result doesn't appear for this clip of 500 frames (usually, it does even if the result is false as bobololo said)

[dragongodz]

found a bug with -psnr

using line
envavc.exe -1 test.avs -o test1.mp4 -rcmode abr -br 300000 -fgm -psnr
no psnr values are given at the end. if i use other settings such as -xf8x8 and -enhchrp instead of -fgm psnr values are given.

I've found another bug in the psnr computation. When 2-pass encoding, the psnr values printed at the end are wrong. It's fixed now.
does this mean there is a new version to download ?

[JasonFly]

I get the same problem, It definately looks like frame ordering to me, heres a link to the clip to see if its reproduceable.

-X264.mp4 (http://sr2.mytempdir.com/54286)

This could be due to ateme's dshow filtert for playback. I also had some problems with x264 clips since I installed atem's beta pack. I hadn't enough time to study this issue but I will.

[Sagittaire]

no problem with ateme dec but I think that it's a parser bug (bug with ateme parser but not with nero parser)

[bobololo]

@couscous, dragongodz : the -psnr option is automatically disabled when -denoiser or -fgm options are set. When using those options, the source input is filtered before being sent to the core encoder. And therefore it doesn't make much sense to compute the psnr in such case.

[bobololo]

If you need to upload clips encoded with the beta for sharing them or for showing us some issues, you can upload here : ftp://mood.ateme.com/incoming.

This location is upload only. To make your upload public, just drop me a PM and I'll move your files to a publicly accessible directory.

[Andrey]

>> -ref 1 -bref 2
If I use non symmetric frame prediction in settings encoder outputs wpred : using 1:1 ref(s). Just FYI :)

[IgorC]

Right now I've received beta.
I have a problem with installation of decoder and parser. When I run reg.bat it said : done ! ECHO is disactivated.
But decoder and parser weren't instalated

[Tommy Carrot]

Something is not right with the lossless mode, x264 gives significantly smaller filesizes on all video so far, and i've got confirmation that x264 is really lossless, so the problem is not that.

[couscous]

Hi guys,
I have a big problem with the "interlaced" tool.
I have made a test with a interlaced clip (Friends) with 500 frames.
.....
As you can see in the second clip, the size is no good (560.39 kb/s instead of 900 kb/s)


I have made an other test with an 2000 frames interlaced DV source and the same problem with the control rate is there.

settings 1 :
-br 900000 -qual fastest -priority idle -rcmode 2pass
bitrate : 900.84 kb/s

settings 2 :
-br 900000 -qual fastest -setef interlaced -priority idle -rcmode 2pass
bitrate : 600.21 kb/s

settings 3 :
-br 900000 -qual fastest -setef interlaced,paff -priority idle -rcmode 2pass
bitrate : 744.89 kb/s

settings 4 :
-br 900000 -qual fastest -setef interlaced,paff,mbaff -priority idle -rcmode 2pass
bitrate : 899.85 kb/s

settings 5 :
-br 900000 -qual fastest -setef interlaced,mbaff -priority idle -rcmode 2pass
bitrate : 899.85 kb/s

As you can see, when the "interlaced" tool is enabled, if the tool "mbaff" is disabled, the rate control bugs...
This is the same with mode "extra" and mode "ABR"

Maybe this is normal that "interlaced" and "mbaff" have to be enabled together...and maybe this is not a bug...

couscous

[Manao]

Tommy Carrot : A wild guess would be because Ateme's encoder doesn't use 4x8 / 8x4 and 4x4 blocks.

[Tommy Carrot]

Tommy Carrot : A wild guess would be because Ateme's encoder doesn't use 4x8 / 8x4 and 4x4 blocks.
It's possible, but the difference still seems too big to me. And ateme's encoder is certainly more tuned, that should more or less compensate the lack of those features, as it's able to do in lossy mode.

[Manao]

Indeed, i just checked, it's not 4x4. But anyway, the encoder isn't that tuned for lossless ( it's not because the feature is present that it's well used ). So i don't think it's totally a bug, but definitely an issue :)

[jfehr]

I encoded a DV clip (interlaced, mbaf) and ended up with a video that had a lot of interlace bleeding. The output looks deinterlaced, but the hue remains where the 2nd field should be. When I looked at the original clip with VeeDub, it looks fine. For some reason I decided to look at that same original clip with media player, and I got the same result as when at I was getting in the AVC encoded file. I can only assume avisynth is using the same decoder that media player is using.

Anyone know how I'd get avisynth to use the same decoder veedub does, instead of the one media player uses?

Sorry for posting about a non-encoded bug here, but I thought it might help anyone else seeing strange results like this.