Ateme H.264 HP Beta Test : Bugs & Issues

[bobololo]

Hi there,

So here we are, the new round of our new encoder is about to start and we all hope it will have as much success as the previous one.

We're currently testing internally the latest builds in order to smash out the latest obvious bugs and just before unveilling the beta to the testers. We should put it online on tomorrow night or at most on wednesday night. By that time, testers will receive by email the instructions and the url to get the beta package. They will need their personal login and password they should have received by postal mail.

We'll keep the same scheme for collecting your feedback as previous. We'll have this current thread which is intended to discuss about the bugs and issues you may meet (encoder crash, filters that don't work, etc.) while another thread "Quality feedback" will deal with quality feedback and discussions.

We're very excited to show you our latest improvements and we hope you'll enjoy them !

-- bobo

[LigH]

That's fine. "Fun and success!"
__

Can you tell us a bit about the range of systems you already own for tests? Which are the most/least powerful, or "most exotic" systems?

[acidsex]

Did my login information arrive in postal or email? I have yet to receive either as I have been away on a business trip.

Thanks

[chilledoutuk]

it will be snail mail well mine was.
Wating patiently for the beta test to start.

[Zarxrax]

I just recieved my login info in the mail today, so it might still be a little while before you get yours.

[bobololo]

A little high profile clip encoded with the latest pre-beta build:

ftp://mood.ateme.com/beta/cinderella-ateme-3000k-hp.mp4

with 8x8 transform, custom scale matrix (flat) and 4 slices (encoded on a bi-xeon).

Enjoy :)

[peteag]

enjoy? i'm on your knees guys. this codec is a world-wonder!

[jfehr]

Tease!

Very nice though. Can't wait for the beta to start. :)

A little high profile clip encoded with the latest pre-beta build:

ftp://mood.ateme.com/beta/cinderella-ateme-3000k-hp.mp4

with 8x8 transform, custom scale matrix (flat) and 4 slices (encoded on a bi-xeon).

Enjoy :)

[Sergejack]

Is that codec the property of ahead ?

EDIT : I'm wondering how much MB does that sample do.

[jfehr]

Its a 1280x720 HP encoded video stream, encoded at 3000Kbits/second. The file is 53 MB for 2 minutes, 28 seconds. The codec is Ateme/Ahead's (I imagine its joint, anyway)...

I can't play it without dropped frames on my P4-3Ghz though. I hope the DVD players that'll be capable of playing these kinds of streams come out soon. :)

[ChronoCross]

A little high profile clip encoded with the latest pre-beta build:

ftp://mood.ateme.com/beta/cinderella-ateme-3000k-hp.mp4

with 8x8 transform, custom scale matrix (flat) and 4 slices (encoded on a bi-xeon).

Enjoy :)

too many people seem to be requesting this file and/or other files.....any chance of getting the FTP to accept more than 10 connections total?

[R] 530 Sorry, the maximum number of allowed clients (10) are already connected.
[R] Connection failed

[plonk420]

patience, young padawan ;)

[eb]

A little high profile clip encoded with the latest pre-beta build:

ftp://mood.ateme.com/beta/cinderella-ateme-3000k-hp.mp4

with 8x8 transform, custom scale matrix (flat) and 4 slices (encoded on a bi-xeon).

Enjoy :)
It could be interesting comparison with CinderellaMan_HD trailer from DivX, resolution 1280x720, (but with mp3 128kb/s audio)

eb

[LigH]

Mplayer and ffdshow can not yet play this file:
[h264 @ 00A3A468]custom scaling matrix not implemented
[h264 @ 00A3A468]non existing SPS referenced
Error while decoding frame!
But this is not your fault - seems that your encoder already uses features which are not yet implemented in libavcodec.

It plays well with the Nero Video Decoder in MPC (through Haalis splitter).

[Sharktooth]

It could be interesting comparison with CinderellaMan_HD trailer from DivX, resolution 1280x720, (but with mp3 128kb/s audio)

eb
I think the source is the divx trailer.

[LigH]

Indeed, looks a bit "upscaled", somehow...

[hpn]

ftp://mood.ateme.com/beta/cinderella-ateme-3000k-hp.mp4

Pretty detailed and sharp-looking clip. I want to take some "full resolution" screenshots. How can I make Nero Showtime show the real 1280 pixels by cropping the extra 256 that do not fit in my 1024 LCD screen? I could force such HD playback with some players, but couldn't find a way to do it with Nero Showtime.

Here is the 4'000k DivX version of the same trailer so people could compare: http://trailers.divx.com/Universal/CinderellaMan_HD.zip
Is this the sourse or Bobololo has used some higher quality version?

[bobololo]

Dear testers,

I've just sent to you all the instructions email to retrieve the beta package. You should receive it shortly. Don't forget to use your personal login and password (sent by postal mail) when prompted.

The new beta round officially starts now ! Gentlemen, please start your CPU ;)

-- bobo

[bobololo]

Here is the 4'000k DivX version of the same trailer so people could compare: http://trailers.divx.com/Universal/CinderellaMan_HD.zip
Is this the sourse or Bobololo has used some higher quality version?

I confirm, this clip was encoded using DivX's one as source.

[LigH]

(Pushing my thumbs that it will work on my old soap-box...)

Received, downloaded, starting...
__

First problem:

It was a little hard to get the H.264 decoder filter used for playback. Although I disabled ffdshow's decoder for H.264, Media Player Classic 6.4.8.4 reported that the Ateme Splitter 1.2.5.2 is used, but as decoder it reports the "AVI Decompressor". Reason: ffdshow's VfW interface was still enabled for H.264. After disabling, the previous Nero decoder filter still had a higher merit (0x00600000) than the new Ateme H.264 decoder (0x005fffff). So I used GSpot 2.52 to raise its merit to "preferred" (0x00800000).

[acidsex]

I cant download it yet because I have not received my login information in the mail yet ( I am in the USA). When were they sent out and how long does it take to get international mail?

Bobolo, is there any way to get my login info or a temp login until mine arrive in the mail?

edit: I did receive my email with the url link just not the postal login information.

[bobololo]

(Pushing my thumbs that it will work on my old soap-box...)

Received, downloaded, starting...
__

First problem:

It was a little hard to get the H.264 decoder filter used for playback. Although I disabled ffdshow's decoder for H.264, Media Player Classic 6.4.8.4 reported that the Ateme Splitter 1.2.5.2 is used, but as decoder it reports the "AVI Decompressor". Reason: ffdshow's VfW interface was still enabled for H.264. After disabling, the previous Nero decoder filter still had a higher merit (0x00600000) than the new Ateme H.264 decoder (0x005fffff). So I used GSpot 2.52 to raise its merit to "preferred" (0x00800000).

I don't know which player you're using, but mpc has a very convenient feature for dealing with such issues : in the filters override options, put can ateme's filters to the top and set them as prefered. If this isn't enough you can ultimately block nero and ffdshow filter.

[bobololo]

I cant download it yet because I have not received my login information in the mail yet ( I am in the USA). When were they sent out and how long does it take to get international mail?

Bobolo, is there any way to get my login info or a temp login until mine arrive in the mail?

edit: I did receive my email with the url link just not the postal login information.

You should receive it very soon (probably tomorrow). Many of US residents as well as Australian testers just received it.

[acidsex]

Okay, Ill hold off until tomorrow. Ill let you know when/if it arrives and then we can go from there. :) Much thanks and tons of excitement to get started testing.

[Sagittaire]

encavc is "little more complex" than for first round beta test ... lol
Well we can have little more detail for this test ... please

- CBR rate control mode (HRD compliant)
HDR compliant?

- psychovisual improvement
find best psy mode test? find best adaptative deblocking matrix? find best custom scaling matrix?

- full interlaced support (field only, paff, mbaff)
paff? mbaff? interlacing with HDTV resolution?

- 8x8 transform
quality with/without 8x8?

- 4x4 and 8x8 custom scale matrix
find best custom scaling matrix?

- monochrome encoding


- lossless encoding
resolution or compatibility with other function (interlaced+lossless for example)?

- multi-threaded encoding support
Not for my Sempron 1.75@2.10 ...

- sse2 and sse3 instructions support
Not for my Sempron 1.75@2.10 ...

- quality and performance improvement


- source denoiser / film grain preservation
Film grain is Post-Process artificial grain? Find best setting for fgboost?

http://jfl1974.free.fr/forum/smileys/F9.gif ... more details ... please

[babayaga]

encavc is "little more complex" than for first round beta test ... lol
Well we can have little more detail for this test ... please

- CBR rate control mode (HRD compliant)
HDR compliant?
...
- full interlaced support (field only, paff, mbaff)
paff? mbaff? interlacing with HDTV resolution?
http://jfl1974.free.fr/forum/smileys/F9.gif ... more details ... please

The encoder is not designed only for movie backups. It is a full featured encoder that can be used for various applications. That's why for instance it can output a TS file that can be fed to a standard set-top-box.

Just for 2 points out of those many features:

The (CBR) Constant BitRate mode is compliant with what is expected out of an encoder for pro streaming applications (Digital Terrestrial TV for instance). This rate-control mode could be surprising to some since the quality is much lower for the same overall size than the 2 pass mode for instance. But on the other hand, the output bitrate is strictly constant over a buffer (called the CPB or Coded Picture Buffer set by default at 224kB). This means that the generated stream can be broadcasted over a fixed bitrate link without risks of overflow or underflow of the receive buffer located on the decoder's side.
It is HRD (Hypothetical Reference Decoder) compliant which means that it produces the kind of streams a decoder shall expect regarding the bitrate variations over time. Furthermore, the state of the decoding buffer the encoder expects is signalled in the stream. This enables low buffering delays or fast channel switching.


AVC/H.264 proposes several encoding modes for interlaced contents :
fixed field encoding: the video is assumed to be fully interlaced all the times
PAFF (Picture Adpative Frame Field): the video contains progressive and interlaced frames. The encoder chooses the best mode for each frame
MBAFF (Macroblock Adaptive Frame Field): the video contains progressive and interlaced frames but the interlaced or progressive parts can be limited to several macroblocks in each frame. This is the most efficient way of dealing with interlaced content. As with PAFF, the encoder chooses the best mode, but this time at the macroblock level
Regarding the resolution, there is a limitation but its very high: at least 36864 macroblocks per frame (for instance 4096x2304)

[bobololo]

@Sagittaire: you anticipated my test guideline post ;) Actually, for you particularly, you should test this :

-rcmode 2pass -br xxx -qual full -ref 8 -bref 4 -enhchrp -deblock 0 -setef xf8x8,csm -psy 3

If you're patient enough, that should give you the highest ssim score you've ever seen ;)

@Testers: here are a few hints helping you to getting started with this test.

First it would be interesting to check the stability of the encoder, ie. does it crash under some conditions ? (clips, hardware config, tools used, etc).

Then we have added many encoding tools : interlaced support, 8x8 transform, custom scale matrix, etc. Does those tools bring good improvement ? Are there some cases where they are inefficient or perform poorly ? Which matrix are optimal for different type of contents ?

New features were added : CBR rate control mode, lossless & monochrome encoding. Do those new features working fine and make you happy with them ?

Others were improved : how do you find our new psy3 model ? And what about the performance ? Does it run fast enough compared to other codecs ? Check out multi-thread support for HT/dual core CPU owners and evaluate the speed boost it gives !

We have also new stuff : the film grain modeling. Even it's still very preliminary, we wanted to show the abilities to filter out some film grain making the clip easier to encode and restituting this grain on the decoder side. It's very slow and under huge development but your feedback are welcome to help us improving it.

Finally and not the least, what about the overall quality, which settings give you the best results according your eyes :)

-- bobo

[Razorblade2000]

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

[bobololo]

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

It's certainly due to a dll dependency problem. Can you check with depends.exe if all required dll are installed on your system ?

you can find it here : http://www.dependencywalker.com/

[Zarxrax]

I just made an encode with only the -lossless option... and my output certainly does not look lossless. The output looks ok on some frames but is blocky as hell on other frames. I did not experience anything like this on encodes where I did not use the -lossless parameter.

Edit: Upon further inspection, it seems the old nero decoder was being used... if i set mpc to block that decoder though, there is nothing to decode these files. It seems the ateme decoder isnt being registered, although the ateme splitter is working just fine.

[Tommy Carrot]

You can use mplayer to play it back too, it can decode everything if you don't use custom matrices.

BTW, i'm a bit disappointed in the lossless mode, so far i couldn't get it close to the efficiency of snow and msu codecs. I'm still experimenting with the settings to get the best result, so far it seems to me that disabling b-frames can help a bit.

[Zarxrax]

Well mplayer isnt playing it back properly either. (edit: using MPlayer-mingw32-dev-CVS-050514.zip) Lots of blocking artifacts there too. It makes me wonder if its an error in the encode itself, because the compression on it looks too good to be true. Its 71mb, compressed from a 120mb yv12 lagarith file.

[Tommy Carrot]

Use the latest build (http://www.aziendeassociate.it/cd.asp?dir=/mplayer) from mplayer.

[Zarxrax]

I'm still getting blocks with the build you linked.

[CyberGuy]

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.

[Tommy Carrot]

I'm still getting blocks with the build you linked.
Well, it works flawlessly with the videos i encoded...

[Zarxrax]

Well, like i said, i think it might be an error in the encoding itself. I'll be able to verify once I get this darned ateme decoder to register @_@

[*.mp4 guy]

I just made a lossless encode from a huffyuv file, I got nearly a 50% reduction in size, and everything looks to be in order as far as blocks are concerned. The one problem I had is that the lossless encode looks slightly darker then the source file, its prolly just my overlay mixer, but I'm going to look into it.

[edit] Confirmed as overlay mixer discrepency. I'm going to make some other lossless encodes with snow et all to see how good the compression is.

[jfehr]

Did a couple quick tests with lossless tonight:

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

-qual full -lossless:
00:50, 53,639 KB

-qual full -lossless -rcmode 2pass
01:38 54,728 KB


Since the quality should be the same (since its lossless) I'm surprised the 2pass encodes both increase the size of the output file.

Also, while it looks like the lossless encoder did ok with -qual full and interlaced, it seems the filter is actually deinterlacing? (When I view the video there is no interlacing, and it seems blocky, like occurs with some deinterlacers.)

[babayaga]

Did a couple quick tests with lossless tonight:
Source was test.avi, 30,726 KB, DV interlaced, pretty shaky. Here's what I got with a few different lossless settings:
....
-qual full -setef interlaced -lossless -rcmode 2pass
01:12, 31,646 KB
...
Since the quality should be the same (since its lossless) I'm surprised the 2pass encodes both increase the size of the output file.

Also, while it looks like the lossless encoder did ok with -qual full and interlaced, it seems the filter is actually deinterlacing? (When I view the video there is no interlacing, and it seems blocky, like occurs with some deinterlacers.)
We did not think one second at using lossless in 2 pass mode since to achieve lossless, the quantiser is fixed at 0 (lossless is in fact VBR at q=0) :o There might eventually be a bug in the application that should not authorize this.

Regarding the aspect of interlaced content, it looks like an issue with the video renderer that de-interlaces (badly). The decoder filter does not de-interlace the video, but signals to the renderer that the content is indeed interlaced. It's then up to the renderer to act correctly.
There is an option in the decoder filter to force signalling the interlace content for the MBAFF case.

[Sharktooth]

Just downloaded. I'll start testing tomorrow.

[jfehr]

I didn't think it would make a difference either, but that's what beta testing is about, right?

I put up the video in question at http://www.altbits.com/test.avi if you want a look. This was my avs script (that resulted in incorrect looking lossless video):

# start of script
AviSource("d:\test.avi")
ConvertToYV12()
# end of script

and this was my command line:
encavc.exe -i d:\test_avi.avs -o d:\test.mp4 -qual fastest -setef interlaced

Let me know if you need anything else.


We did not think one second at using lossless in 2 pass mode since to achieve lossless, the quantiser is fixed at 0 (lossless is in fact VBR at q=0) :o There might eventually be a bug in the application that should not authorize this.

Regarding the aspect of interlaced content, it looks like an issue with the video renderer that de-interlaces (badly). The decoder filter does not de-interlace the video, but signals to the renderer that the content is indeed interlaced. It's then up to the renderer to act correctly.
There is an option in the decoder filter to force signalling the interlace content for the MBAFF case.

[*.mp4 guy]

FFV1 compressed the same sample from my previous post 24% better then Ateme avc HP and was 5 times faster. So I suppose that indicates avc probably wont be able to beat codecs specifically designed to be lossless. More complex sources might change things a bit.

[CyberGuy]

@Sagittaire: you anticipated my test guideline post ;) Actually, for you particularly, you should test this :

-rcmode 2pass -br xxx -qual full -ref 8 -bref 4 -enhchrp -deblock 0 -setef xf8x8,csm -psy 3

If you're patient enough, that should give you the highest ssim score you've ever seen ;)

@Testers: here are a few hints helping you to getting started with this test.

First it would be interesting to check the stability of the encoder, ie. does it crash under some conditions ? (clips, hardware config, tools used, etc).

Then we have added many encoding tools : interlaced support, 8x8 transform, custom scale matrix, etc. Does those tools bring good improvement ? Are there some cases where they are inefficient or perform poorly ? Which matrix are optimal for different type of contents ?

New features were added : CBR rate control mode, lossless & monochrome encoding. Do those new features working fine and make you happy with them ?

Others were improved : how do you find our new psy3 model ? And what about the performance ? Does it run fast enough compared to other codecs ? Check out multi-thread support for HT/dual core CPU owners and evaluate the speed boost it gives !

We have also new stuff : the film grain modeling. Even it's still very preliminary, we wanted to show the abilities to filter out some film grain making the clip easier to encode and restituting this grain on the decoder side. It's very slow and under huge development but your feedback are welcome to help us improving it.

Finally and not the least, what about the overall quality, which settings give you the best results according your eyes :)

-- bobo
These settings only gave me a SSIM 1 value of 69.43 compared to the 71.68 achieved from hp2-ateme-450k-hp.mp4 in post http://forum.doom9.org/showthread.php?p=659098#post659098. What settings did you use there? Reply should probably be posed in http://forum.doom9.org/showthread.php?t=95890.

[Razorblade2000]

It's certainly due to a dll dependency problem. Can you check with depends.exe if all required dll are installed on your system ?

you can find it here : http://www.dependencywalker.com/


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

[Manao]

Guys, don't forget that there's a quality feedback thread, and that this one is dedicated to bugs & issues.

[Selur]

seems like thread support is not working atm,..
(on WinXPpro, 512MB, Dual Athlon MP 1800+)
I set the thread option to two, but the text during 1st pass only mentions 1 thread and CPU usage also suggests that only one thread is used.
(around 70-80%, x264 thread support uses 88-98%)

Cu Selur

[Manao]

Selur : what's your commandline ?

[Selur]

encavc.exe -i "atemeTest.avs" -o atemeTest.mp4 -qual full -rcmode 2pass -br 2553000 -psy 3 -deblock -2 -adaptdbk -maxb 3 -enhchrp -thread 2 -setef ipred,ppred,bpred,wpred,cabac,deblock,part,hpel,qpel,xf8x8

Cu Selur

ps.: CPU usage in second pass drops to 50% :(

[bobololo]

Well, like i said, i think it might be an error in the encoding itself. I'll be able to verify once I get this darned ateme decoder to register @_@

Maybe you've the same issue as RazorBlade2000 ? Can you check your dll dependencies ?

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

[Manao]

jfehr : DV often have a yV12 sampling issue, check that out for explanation on the avisynth forum

[couscous]

I have a problem with the ateme decoder/parser
It seems that this is a conflict between ateme decoder/parser and nero digital decoder/parser
When I register ateme decoder/parser and I disabled Nero decoder/parser in MPC, all is OK.
But if I unregister Nero suite, MPC doesn t recognise Ateme decoder/parser anymore nor graphedit (but I can build a graph with Ateme decoder/parser filter and play the clip)
The same thing arrives when I install Nero stuff : I have to register again the ateme decoder/parser... strange...

couscous

[LigH]

That's basically the same as the first issue I posted in this thread...

[IgorC]

the same problem here MPC doesnt recoginize Ateme decoder, but graphedit
plays fine : Ateme Parcer -> Ateme Decoder -> Render

[couscous]

That's basically the same as the first issue I posted in this thread...

ok sorry then :rolleyes:

couscous

Update : Finally no that is not the same issue you talked about...!
Here it's a conflict between filters and not a decoding problem.

[IgorC]

But here problem is persist. I already put low merrit to Nero decoder and even block it and put high merrit to Ateme Decoder but it changes nothing. How to change prior for decoder in Gspot 2.52 b1?
Windows XP SP2

[CyberGuy]

But here problem is persist. I already put low merrit to Nero decoder and even block it and put high merrit to Ateme Decoder but it changes nothing.
Windows XP SP2
Try un-registering the Nero codec.

Un-registers Nero Codec:
REGSVR32.EXE /U "C:\Program Files\Common Files\Ahead\DSFilter\NeVideo.ax"

Registers Nero Codec:
REGSVR32.EXE "C:\Program Files\Common Files\Ahead\DSFilter\NeVideo.ax"

[LigH]

This probably even works from GSpot:

System - List Codecs and Other Filters - (Select desired filter) - Rightclick - ...

[couscous]

Regarding the aspect of interlaced content, it looks like an issue with the video renderer that de-interlaces (badly). The decoder filter does not de-interlace the video, but signals to the renderer that the content is indeed interlaced. It's then up to the renderer to act correctly.
There is an option in the decoder filter to force signalling the interlace content for the MBAFF case.

yep, with my interlaced encoded clip with interlaced,mbaff tool enable, the clip is jerky when it's decoded with ateme decoder/paser but the clip seems to be desentrelaced. When it's decoded with nero decoder/parser, it's not jerky but interlaced.

[IgorC]

This probably even works from GSpot:

System - List Codecs and Other Filters - (Select desired filter) - Rightclick - ...


It was another problem. My windows didn´t accept spacebars or '-' in the name of the *.dll . When the name of *.dll was changed it was registered without problems. Starting to test :). I noticed Ateme Decoder requeires more CPU. On my Cel 2ghz CPU usage 70-95% on resolution 720x304 23.976

[LigH]

The Ateme decoder seems to be very slow on my system, compared to ffdshow 2005-06-11, even when I try to disable deblocking in the Ateme codec. ffdshow is able to play a 1000x540 px video at almost realtime, and - in my opinion - with smoother images (concerning the H.264 special deblocking) than the output of Atemes decoder.

Furthermore, it seems that the decoder forces to use hardware overlay for display, although I prefer the VMR9 renderer in MPC. My graphics card does not support YV12 overlays well, I see some kind of chrominance blocking/shifting in this case. Screenshots by MPC 6.4.8.4 as BMPs do not show this shift, it is only visible on-screen while playing for me. In ffdshow, I disabled YV12 overlay, the next similar mode is YUY2 overlay which works well.


AMD Duron 800 MHz, ABIT KT7-RAID (VIA 686 KT133), 256 MB RAM PC-100 (Durons don't support more on KT133), ELSA Gladiac GeForce2 GTS 32 MB
__

@ IgorC:

In that case, the filename variable at the end of the FOR loop line in your batch file might not have double quotes around it. With double quotes it shall work well even for filenames with spaces:
FOR %%x IN (*.dll *.ax) DO regsvr32 /s "%%x"

[spyder]

I found what appears to me to be a bug in the interlaced output of the decoder filter. I encoded a TFF clip here with xf8x8,interlaced,paff,mbaff at 800kbps 2pass normal quality... When i play this backthere is a horrible jerkiness in the video that can only be corrected by either disabling the "Interlaced material" option or checking the reverse field order one. I can provide the encoded sample if you need it. It's as if the decoder ignores the field order or the encoder specified it wrong.

PS: I'm going out for the night but i am leaving this encoding the same clip with different combinations of interlaced options to see what effect it has.

[ChronoCross]

I don't know what to classify this as so I'll just put it out there. I had the encoding window open and it froze at the same percentage for about 30 mins or so, but when I minimized it and then brought it back up it actually unfroze and continued along it's merry way.

[IgorC]

Source DVD 25 fps, 720x576 resized to 720x544
Codec crashed with the following settings :
encavc.exe -i original.avs -o qu.mp4 -qual extra -rcmode 2pass -br 1500000 -psy 2 -deblock -2 -enhchrp -ref 16 -mvrange +512 -maxb 2 -setef xf8x8,interlaced -mbaff -bref 3

Codec doesn´t crash whithout -setef interlaced

[Manao]

Igorc : your command line is invalid, instead of -setef xf8x8,interlaced -mbaff, you should use -setef xf8x8,interlaced,mbaff. It might only be a bug in the input parameter parser.

ChronoCross : at which priority were you encoding ?

Spyder : can you try with another video renderer ( which if possible doesn't deinterlace )

[LigH]

@ Manao - to Spyder:

I wonder if the Ateme decoder forces a specific renderer (e.g. YV12 Overlay), because with this decoder I see video distorsions I don't see when using ffdshow (see above). To me, it appears as if it was not possible to chose another renderer in the player.
__

@ IgorC:

A "codec" is part of the operating system. You instead are working with a (standalone) "encoder". ;)

[spyder]

@Manao:

I just tried opening the file via avisynth directshowsource and it appears fine there. It must be something in the renderer but it makes little sense to me that it can't simply deinterlace a normal top field first interlaced video. I noticed some strange rendering issues also with VMR9.

Also, just a quality note, it seems mbaff may be the cause of my crappy encodes. I only did one so far with just paff but it's much better. May also depend on the content so I will check some commercials or something tomorrow.

@LigH:

I tried ffdshow(June 11) but it just crashes.

[Manao]

spyder : from our test, MBaff has always been constitantly better than paff ( by a fair margin ). And there's no reason for it to be worse, in fact. So if the quality drop is confirmed, it's a bug

FFDShow ( ffmpeg ) doesn't support interlaced at all ( well, no in fact it might supports i frames, but that's all )

[Blue_MiSfit]

Question - has anyone created or considered creating a simple GUI for us beta testers? some little frontend that will make a bat file to control the encoder? If only I knew some visual basic! :)

[berrinam]

@Blue_MiSfit: A list of options? I don't have the beta.

[LigH]

Considered ... yes. But I'd expect changing command sets during the development, so I wonder if it's really that necessary. Instead, I use a few batch files in the meantime. But maybe tonight or tomorrow... No promises.

[kwtc]

About playing interlaced content.

The Ateme H264 decoder DirectShow filter signals to the downstream filter whether or not the sequence is interlaced, through the VIDEOINFOHEADER2 structure.

Downstream filters (usually a video renderer or a color space converter followed by a video renderer) may ignore this flag or not. The default video renderer will deinterlace, but very badly. For better output, this renderer must be put in video mixing mode (which I don't know how to do with MPC).

The filter has an option to disable usage of this interlaced flag. Open the filter property page and unchek the relevant checkbox. Thus the video renderer will never try to deinterlace.

Otherwise, the filter does not force any particular renderer. It can be connected to anyone that accept YUV 4:2:0 planar. If there is no renderer that accept this format, an intermediate filter must be used to make a conversion to RGB.

Note also that there should be no conflicts between this filter and the Nero ones, apart from the fact that they both can decode H264...

[kwtc]

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


We will look about this one. Thanks for your bug report !

[LigH]

While playing with form designers, thinking about option dependencies ...

"-clref ipred" cannot make sense, IMHO; I won't even think about implementing that into a GUI.

[spyder]

@Manao : regarding the mbaff/paff thing... I haven't made a sample yet using only mbaff so i'm doing that now. I can calc some PSNR or something on each also.

PS: I still don't understand why reversing the field order in the filter properties corrects the playback.

[ChronoCross]

ChronoCross : at which priority were you encoding ?


Normal 1 thread

[babayaga]

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
...
As you can see in the second clip, the size is no good (560.39 kb/s instead of 900 kb/s)

As you pointed it out, there is an issue with interlaced or paff and 2 pass rate-control. :mad:
This explains why the final size is not correct. It will be fixed in the next version.

[LigH]

A Taste Of Things To Come


http://www.ligh.de/pics/Atemaker.png


Will take som time. Probably won't be finished ever...

Sorry for the probably crazy layout, but I won't spend too much efforts in it.

What I'm still missing, e.g.:

- What means which psy option? (You are so proud of mode 3 - why?)
- Will it make much sense to specify the CPB?
- Which MV ranges are possible/useful?
- Forgot interlacing... :o Why as bitflags? Does it make sense to e.g. use "-setef interlaced,paff,mbaff", or maybe even "-setef paff,mbaff -clref interlaced"? Can those options be combined, or will one supercede another?

[acidsex]

Ligh, that looks tight. I, for one, thank you for the work you put in to it and hope to have a chance to use it to help speed up my tests by eliminating a lot of the key strokes.

[Andrey]

Finished Die Hard 3 encode, investigating the results :)

1.
FYI: Interesting "percent complete" behavier on my machine when doing first pass
It goes in such a way
1.23%
1.24%
1.25%
1.72%
1.73%
1.74%
2.41%
2.42%
regulary jumping for an about a .5% after some steps...

2.
After going from full to extra quality second pass became 5x faster.

3.
Still do not understand, on what speed of first pass is based.
608x304 clip with br 110000 and length 1000 frames has speed of about 23fps, while 672x336 br 950 and full length was almost twice faster: about 41fps in average...

[Manao]

LigH :
* psy 0 -> no psychovisual heuristics
* psy 1 -> psychovisual heuristics on a frame level
* psy 2 -> psychovisual heuristics on a macroblock level
* psy 3 -> enhanced psychovisual heuristics on a macroblock level

* CBP has its main interest when the CBR rate control is used. It amounts to the VBV buffer in ASP. The larger, the more the bitrate can vary. In ABR / VBR / 2pass, it is also used to define the min / max allowed bitrates.

* though the norm allows unconstrained motion vectors length, level might restrict them to something like 128 or 256 ( which is enough ).

* interlacing : why flags ? well, mbaff and paff can be used together ( and that's not pretty to handle... ), so they need independant flags. Interlaced is more subtile. It can be used alone ( the whole video is encoded as if it were only made of fields ), and it is automatically set by encavc if mbaff or paff is enabled. So, to sum up : interlacied handling has five levels : progressive ( none ), interlaced ( interlaced alone ), paff ( interlaced + paff, or paff alone ), mbaff ( interlaced + mbaff, or... ) and paff + mbaff ( the three of them ).

Apart from that, you forgot 'open gop'

[Mr_Schizo]

Still do not understand, on what speed of first pass is based. 608x304 clip with br 110000 and length 1000 frames has speed of about 23fps, while 672x336 br 950 and full length was almost twice faster: about 41fps in average...
Search in the thread from the first beta test for it, it is explained there. You'll get higher speeds if you're encoding more than 10000 frames cause the encoder uses some special (even patented afaik) techniques.

[LigH]

For CBP, which dimension is usual? 100 KB? 1 MB? 10 MB? Will most probably depend on the frame dimensions and the reference counts, at least.

Interlacing: Well, I guessed so, but had to be sure; so I'll have to restructure my GUI to reflect these dependencies.

Open GOP - sorry, cannot find any option in the documentation regarding the GOP structure, beyond min/max sizes.

[babayaga]

For CBP, which dimension is usual? 100 KB? 1 MB? 10 MB? Will most probably depend on the frame dimensions and the reference counts, at least.

It's very dependant on the applications.
Some use 224kB wich is a standard value in MPEG-2 and very customary AVC/H.264. The default value in encavc is 1MB (it will hopefully default back to 224kB in the next version).

Some express it in seconds (because this buffer size is introduces a delay for the decoder), thus depending on the bitrate. Standard values are 1s to 5s.

[LigH]

Well - so it seems to be best to leave this decision to the encoder, unless you know why not. ;)
__

Uploaded an updated version to the FTP incoming. I hope bobololo will then make it available for the testers. ^ Screenhot updated on my server, too.

[bond]

i stumbled over the foreman-ateme-lossless.mp4 encode and noticed that it shows wierd colors when played with latest ffmpeg

when i extracted the stream to raw and ran mpeg4ip's h264_parse over it i only got the SPS, PPS and first SEI

the used encoder version was 1.2.0.9. is that a known bug?

[IgorC]

Interlace mbaff doesn't work at all here(enocoder 1.2.0.14) . Ouput is horrible and doesn't matter what settings of decoder were used. I also try ffdshow (without deinterlace) to decode it to see if it's problem of decoder. The same result. Waiting for a new beta. Gui for CLI is welcome for comfortable and fast test :)

[CyberGuy]

For CBP, which dimension is usual? 100 KB? 1 MB? 10 MB? Will most probably depend on the frame dimensions and the reference counts, at least.

Interlacing: Well, I guessed so, but had to be sure; so I'll have to restructure my GUI to reflect these dependencies.

Open GOP - sorry, cannot find any option in the documentation regarding the GOP structure, beyond min/max sizes.
-opengop

[CyberGuy]

I had doing some peeking and found some other command line options. Some I know like 1st, 2nd, subpart, pcm, -maxbr, and –opengop, but what is –spmvp, -log, debug and analysis used for?

[acidsex]

Ok, ran some more tests using some of the Lynda.com training files I have. The source files are 880x660 5fps, encoded with Sorenson 3 Pro. I loaded them into Vegas and output to HuffYUV using the same resolution.

I used the following command :" encavc.exe -i clip.avs -o clip.mp4 -qual extra -rcmode 2pass -br 1100000 -psy 2 -deblock -2 -adaptdbk"

Quality is quite well but file size is almost 2 1/2 times the original file size. If I lessen the bit rate, I do get a smaller file size but poor quality when compared to the source. Which leads to my big question. Is Sorenson 3 Pro that much more efficient at encoding video than Ateme's AVC? I would think not but right now, the tests I've done show differently.

Using Sorenson 3 Pro, I can archive 6-8 hours of video at 5fps on one 700MB CD. In order for me to encode the same amount of video using H.264 AVC at 5fps it takes almost 3.8GB to store the same video where text is legibile and not fuzzy.

Can anyone help explain this or is this just a limitation of the H.264 codec? I can make a copy of the source file I am using available to test this if needed.

[Manao]

IgorC : ffdshow CAN'T decode mbaff. If you want to test it, try with nero's decoder.

acidsex : your source is already compressed a lot, you can't compare the codec like that

CyberGuy : they are mostly useless remnant of the first beta, or debugging options. debug is a quality level, analysis isn't a command line parameter, and i think spmvp means spatial mv prediction in bframe ( instead of temporal ).

[*.mp4 guy]

I'm not sure if this is an error, but it looks a little off that the bitrate for the first pass is so low.
http://x2.putfile.com/6/16902095997.png

[ChronoCross]

seems pretty much insignificant in terms of total accuracy. it wouldn't even have a noticeable quality loss/gain. now if it was off by like 30-100 then I would be worried as that can produce a pretty severe difference in the quality of it.

[Manao]

*.mp4 guy : the first bitrate reported is the bitrate achieved on the last 32 frames of your clip, while the last one is the overall bitrate of the second pass. Encavc doesn't give you the bitrate of the first pass.

[plonk420]

my encode missed the bitrate by a LONG shot
http://plonkmedia.temp.powweb.com/bigmiss.png
on the other hand it IS interlaced...

[Manao]

When compressing interlaced content, since paff and interlaced are buggy, if you want to hit the bitrate xxx, you have to ask for the bitrate xxx * 3 / 2 .

[plonk420]

When compressing interlaced content, since paff and interlaced are buggy, if you want to hit the bitrate xxx, you have to ask for the bitrate xxx * 3 / 2 .

hrm, a) did i miss that somewhere in the thread? :eek: and b) will this likely be fixed soon or should i just count on using bitrate * 3 / 2 for a while?

[*.mp4 guy]

*.mp4 guy : the first bitrate reported is the bitrate achieved on the last 32 frames of your clip, while the last one is the overall bitrate of the second pass. Encavc doesn't give you the bitrate of the first pass.
Ahh, that explains it ;) I was a bit baffled by that first number for a while.

[Manao]

plonk420 : it will surely be solved for the next beta release. But have a look at the ratio bitrate wanted / bitrate obtained in this thread when paff / interlaced was used, it will always be 3 / 2 ( 900 -> 560, 1600 -> 1068, and i tried 1000 which gave we 666.68 and hinted me more obviously what had to be done to 'solve' temporarily the issue )

[IgorC]

IgorC : ffdshow CAN'T decode mbaff. If you want to test it, try with nero's decoder.


Yes, I tried to decoded it with Ateme decoder 2.0.1.0 ( with Interlaced material on and off) with this settings

encavc 1.2.0.14

encavc.exe -i corto.avs -o qu.mp4 -qual extra -rcmode 2pass -br 1500000 -psy 2 -deblock -2 -enhchrp -ref 16 -mvrange +512 -maxb 2 -setef xf8x8,interlaced,mbaff -bref 3

When I tried to do screenshots the image of output was good. But during playback all objects have not normal curve borders.

Windows XP SP2. Celeron 2ghz. Source : DVD PAL 720x576 (4:3) resized to 720x544

[JasonFly]

It has already been reported but I confirm that the lossless mode isn't perfectly losslesss. I hadn't any problem with blocks such as someone reported but ssim results clearly show that the encode isn't lossless. I get a ssim=99.64 on a DV source with the following command line:

encavc.exe -i "I:\DVD\Tests\Samples\07\sample-lossless.avs" -o DV-lossless.mp4 -lossless

I even get lower ssim results with other samples. The same sample with ffv1, CorePNG or x264 lossless were really lossless with ssim=100

Filesize:
Filesize is higher than ffv1, a bit higher than CorePNG, but lower than x264.
For a sample of 500 frames, fps=50, here are the fielsizes:
ffv1: 69 082 ko (avi container)
CorePNG: 76 650 ko (avi container)
Ateme's h264: 77 620 ko (mp4 container)
x264: 87 835 ko (mp4 container)

Decoding:
The decoding isn't perfect with three codecs. ffv1, ateme h264 and x264(with ateme's decoder or ffdshow decoder) play the file really slowly(more than 2x realtime) whereas CorePNG play the file in realtime. Not so important as I think it's just a CPU limitation(CPU load=100%).

[Manao]

IgorC : reread the issues encountered previously by other users with VMR9 automatically deinterlacing ( badly ) the output of the decoder. Furthermore, :DVD PAL 720x576 (4:3) resized to 720x544I hoped you meant 'cropped' instead of 'resized'

JasonFly : lossless mode is buggy at the moment ( cf previous posts ), than can explain your results. I find it strange that x264 yields worse results than our encoder, because it has constitantly being better than EncAvc. I guess, looking at the filesize your getting, than your testing sequence got a lot of motion, that may be the reason.

[JasonFly]

You guessed rigth. The sequence was shot in a forest with ligth/shadows with a lot of movement( very bad from a filmmaking point of view, but I'm not a filmaker so I don't bother with such details :D )

I was also surprised with the filsize as someone said x264 compressed better than ateme.

I'll come back on lossless when these problems will be solve. Let's keep on testing other fetures.

[IgorC]

IgorC : reread the issues encountered previously by other users with VMR9 automatically deinterlacing ( badly ) the output of the decoder. Furthermore, :I hoped you meant 'cropped' instead of 'resized'

LanczosResize(720,544). I've choosed VMR9 and image was looking more stable, but ateme decoder didn't deinterlaced video. It doesn't matter if 'interlaced material' in the decoder settings was enabled or not

[Manao]

LanczosResize(720,544)That's what i was afraid of. When you handle interlaced content, never resize it vertically, because you'll destroy the interlaced content ( interlacing is already bad enough, don't make it worse )

Moreover, the decoder isn't meant to deinterlace. 'Interlaced material' is only meant to say directshow whether or not the video is interlaced. It's the video renderer that is deinterlacing.

[LigH]

@ IgorC:

If you are interested in a little demonstration:

I quickly made two images and created a very obviously interlaced example clip:

rg = ImageSource("R-G.bmp",0,0,25) # http://www.ligh.de/images/Resize/R-G.png
gb = ImageSource("G-B.bmp",0,0,25) # http://www.ligh.de/images/Resize/G-B.png
UnalignedSplice(rg, gb)
AssumeFieldBased()
Weave() # http://www.ligh.de/images/Resize/R-G_G-B.png

So far for just creating an example...
___

The following kind of resizing is obviously wrong for interlaced material, it shall only be used for really progressive video:

LanczosResize(720,544) # http://www.ligh.de/images/Resize/p-resize.png

Instead, you shall use this kind of "interlaced resizing" (notice: fields have half the height of frames!):

SeparateFields()
LanczosResize(720,272)
Weave() # http://www.ligh.de/images/Resize/i-resize.png
__

Apart from that, I still wonder why you resized vertically (means: the height) at all; to get square pixels, better resize horizontally (means: the width) only.
___

P.S.:

scharfis_brain recommends even another kind of "high quality field-oriented interlaced resizing", as follows below (for "Assume?FF" use TFF or BFF depending on your source):

Assume?FF()
Bob(0,1)
LanczosResize(720,544)
Assume?FF()
SeparateFields()
SelectEvery(4,0,3)
Weave() # http://www.ligh.de/images/Resize/iqresize.png

[JasonFly]

I have a problem with the parser or directshow filter. That could be similar to what Sagitairre, *.mp4 guy or couscous reported. This occurs when I load an encode done with the beta in VirtualDub via avisynth's DirectShowSource(xxxxx.mp4). If I play/navigate from frame to frame since the beginning of the clip, ther is no problem. But if I take the slider and jump forward and backward, the preview don't display the correct frame.(it display the last frame before moving the slider and some frame seen during movement of the slider).

An other interesting thing:
First, I open a clip via avisynth and the directshowsource command.
Then, I use the "Jump to frame xxx" in VirtualDub and after that, I move further in the clip using keyboard's arrows. The displayed frames are the ones that should have been displayed If I hadn't moved.

[Manao]

The bug with avisynth is customary when using use DirectShowSource. Our parser isn't the only directshow filter that has this issue. DirectShowSource isn't meant for seeking, but rather for a straightforward reading of the source. On the same level, encavc 2pass with DirectShowSource in the avs script might cause issue if you can't seek back properly to the first frame.

[JasonFly]

Thanks for the tip. It was the first time I encounter this issue with DirectShowSource.

[IgorC]

Is is normal that for 2st pass number of procesed frames is less?
http://img126.echo.cx/my.php?image=dibujo9zv.jpg

[Manao]

It processes as many frames as the first pass, it's the second number (1136 in both cases ) that interests you.

[LigH]

Since I found some JVT custom quantization matrices in the sources of x264 rev. 266, I wonder if I understood them correctly and made some useful file out of it:

csm-jvt.txt# custom scaling matrix

# 4x4 intra luma
6, 13, 20, 28,
13, 20, 28, 32,
20, 28, 32, 37,
28, 32, 37, 42

# 4x4 intra chroma
6, 13, 20, 28,
13, 20, 28, 32,
20, 28, 32, 37,
28, 32, 37, 42

# 4x4 inter luma
10, 14, 20, 24,
14, 20, 24, 27,
20, 24, 27, 30,
24, 27, 30, 34

# 4x4 inter chroma
10, 14, 20, 24,
14, 20, 24, 27,
20, 24, 27, 30,
24, 27, 30, 34

# 8x8 intra luma
6, 10, 13, 16, 18, 23, 25, 27,
10, 11, 16, 18, 23, 25, 27, 29,
13, 16, 18, 23, 25, 27, 29, 31,
16, 18, 23, 25, 27, 29, 31, 33,
18, 23, 25, 27, 29, 31, 33, 36,
23, 25, 27, 29, 31, 33, 36, 38,
25, 27, 29, 31, 33, 36, 38, 40,
27, 29, 31, 33, 36, 38, 40, 42

# 8x8 inter luma
9, 13, 15, 17, 19, 21, 22, 24,
13, 13, 17, 19, 21, 22, 24, 25,
15, 17, 19, 21, 22, 24, 25, 27,
17, 19, 21, 22, 24, 25, 27, 28,
19, 21, 22, 24, 25, 27, 28, 30,
21, 22, 24, 25, 27, 28, 30, 32,
22, 24, 25, 27, 28, 30, 32, 33,
24, 25, 27, 28, 30, 32, 33, 35


{ 8x8 inter luma edited, copy&paste missed the right part... }

[thegeby]

Another small bug, encoding a scene form a dvd with basic settings (apart from -monochrome), the resolution came out as 704x576, while the original was 720x576. The PAR or DAR remained unchanged, so the result was a pillarbox picture with black bars on the side.

[Sergei_Esenin]

Another small bug, encoding a scene form a dvd with basic settings (apart from -monochrome), the resolution came out as 704x576, while the original was 720x576. The PAR or DAR remained unchanged, so the result was a pillarbox picture with black bars on the side.

The black bars were probably on the source--many DVDs use a 704x576 image area with a 16 pixel pillarbox. This comes from ITU recommendations to compensate for overscan. Most people don't even notice them on playback, since they're so thin; they are usually cropped out be re-encoders to improve compressibility.

BTW, I just started testing yesterday (I was out of town until then). The few small test encodes so far have come out fine, but hopefully I'll have some real feedback to contribute after my first long encodes are finished today--whole DVD of the film *Go* processed to 976x416 with Didee's IIP script, and a 1080i HDTV transport stream of the very very grainy (shot on 16mm film with deliberate grain enhancement) TV show *Veronica Mars*. I love beating on codecs hard. :D

[dragongodz]

found undersizing and oversizing with ABR and CBR 1 pass with a small clip.

while testing i found a good part that shows the difference with ABR and CBR during a scene change so wanted to just use that small section if people wanted to look at it. however when encoding that small section(141 frames) the target bitrate for these 2 modes were missed by quite a bit.

* Encoding summary

Input file : g:\pooh.avs
Output file : p-abr.mp4
Resolution : 720x576 @ 25.00 fps
Length : 141 Frames
Quality : Best
Rate Control : Abr
Target Bit Rate : 500 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:fixed)

-- Start processing pass 1 / 1
* 00140: encoding @ 11.16 fps - bitrate 423.11 kb/s - 100.00% completed
* 141 frames encoded @ 10.30 fps - average bitrate 529.47 kb/s

Encoding complete (time elapsed 00:00:16)

G:\dev>encavc.exe -i g:\pooh.avs -o p-cbr.mp4 -rcmode cbr -br 500000
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 : g:\pooh.avs
Output file : p-cbr.mp4
Resolution : 720x576 @ 25.00 fps
Length : 141 Frames
Quality : Best
Rate Control : Cbr
Target Bit Rate : 500 kb/s (cbp size 224 kB)
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:fixed)

-- Start processing pass 1 / 1
* 00140: encoding @ 10.95 fps - bitrate 488.23 kb/s - 100.00% completed
* 141 frames encoded @ 10.28 fps - average bitrate 416.96 kb/s

Encoding complete (time elapsed 00:00:16)

[thegeby]

The black bars were probably on the source--many DVDs use a 704x576 image area with a 16 pixel pillarbox. This comes from ITU recommendations to compensate for overscan. Most people don't even notice them on playback, since they're so thin; they are usually cropped out be re-encoders to improve compressibility.

No, that's not it. Looking more carefully the black bars are about 7 % of the width, that's more like 50 pixels. The commandline was:
encavc.exe. -i input.avs -o output.mp4 -rcmode cbr -br 1000000 -monochrome

[LigH]

Please make a screenshot from an obvious frame of the DVD source using DGIndex (File - Save BMP [B]).

Then make a screenshot from the same frame of the H.264 movie using e.g. AviSynth with DirectShowSource in VirtualDubMod ([Shift]+[1]).

Convert both to JPEG and attach or upload them where we can watch both.

[Manao]

dragongodz : CBR mode respects the CPB. That means that the overall size will be between ( bitrate * duration - CPB initial ) and ( bitrate * duration + CPB total - CPB initial ). The default CPB is 224 KB large, you encoded 5.64 seconds of video with a bitrate of 500 kbits, so you aimed at a final size of 352.5 KB. There lies the explanation of the 'unaccuracy' you encountered.

So, try on longer sequences in order to test the CBR mode. For the ABR, well, i guess it only means that its reaction time is around the length of your clip, so there again, you won't be able to get the requested bitrate on so short a sequence.

thegeby : where do you read that 704x576 resolution ? what did encavc printed for width & height when it showed the encoding summarize ?

[708145]

Well, I'm sorry I didn't give feedback in a while.

I did 46 encodes so far and everything worked flawlessly. But I should mention that I didn't use the advanced stuff like CQM and noise modelling yet.

If I find the time to evaluate all those clips there will be some report in the Quality thread. It's so easy to write lengthy .bat files and let your CPU sweat but watching all this takes "real" time :p

bis besser,
Tobias

[Sharktooth]

Ligh the JVT matrix is not that good.
However it's a bit hard to make good AVC custom matrices coz as you can see there are separate matrices for both chroma and luma and for inter and intra frame quantization.
The results are not always predictable and it requires hours and hours of testing...
Not to say ateme encoder supports also adaptive deblocking offset matrices (eh...) and that's also another pain in the ... ehr... :)
combining CQMs with DOMs is really hard.
However after hours of testing i've made some simple conclusions:
my eyes are more sensitive to low luma.
my eyes are less sensitive to chroma variations at highest and lowest frequencies.
4x4 matrices can be less "conservative" than 8x8 ones.
deblocking offsets need some fine adjustment and all DOMs (I, P and B) can be grouped to a single DOM.

[LigH]

Regarding JVT: Well, I just needed at least one example apart from the "flat" defaults. But in contrast to me, you might have the CPU power for developing a few "EQM AVC" matrices... :D

I checked several of the options which are supported in my (probably soon available) GUI - bobo got it and hopefully has a bit time to look at the last version, while I enhance it to a next one. All the options I checked worked without any error message. BTW, I made my GUI so that (in my opinion) senseless option combinations are avoided.

[thegeby]

Ligh:Then make a screenshot from the same frame of the H.264 movie using e.g. AviSynth with DirectShowSource in VirtualDubMod ([Shift]+[1]).

Manao:where do you read that 704x576 resolution

I am afraid that i cannot move pictures from my laptop to my work internet, but here goes: Showtime (which is the only player that can play the files) shows 720x576 on the on-screen display for the original VOB. The screen capture is however 704x576, as you may have suspected.

The Directshowsource VDubMod screenshot method on the mp4 file did not work (I will disect my dependencies later), but there Showtime displays 704x576 for the running clip. The picture is horizontally compressed with black vertical bars

Could this be a DAR issue in the decoder?

[Sharktooth]

well i started workin on AVC CQMs as soon as JM encoder made them available.
however as i said it's a real pain and the addition of DOMs made it even more painfull...
However lets talk about matrices in this thread: http://forum.doom9.org/showthread.php?t=96131
or this: http://forum.doom9.org/showthread.php?t=96127

[dragongodz]

try on longer sequences in order to test the CBR mode
i did and the end reported bitrate is practically right(0.x variance) while as i said these small clips were just done to put online for people to see the part i wanted to point out.
however the display also shows the bitrate jumping up and down like crazy, up to 700 kb/s and down to under 400 kb/s encoding a longer clip. sorry but that clearly is not CBR.

For the ABR, well, i guess it only means that its reaction time is around the length of your clip, so there again, you won't be able to get the requested bitrate on so short a sequence.
possibly so. i still thought it was worth mentioning since nobody had. :)

[Manao]

dragongodz : I'll quote a previous post in this very thread :The (CBR) Constant BitRate mode is compliant with what is expected out of an encoder for pro streaming applications (Digital Terrestrial TV for instance). This rate-control mode could be surprising to some since the quality is much lower for the same overall size than the 2 pass mode for instance. But on the other hand, the output bitrate is strictly constant over a buffer (called the CPB or Coded Picture Buffer set by default at 224kB). This means that the generated stream can be broadcasted over a fixed bitrate link without risks of overflow or underflow of the receive buffer located on the decoder's side.
It is HRD (Hypothetical Reference Decoder) compliant which means that it produces the kind of streams a decoder shall expect regarding the bitrate variations over time. Furthermore, the state of the decoding buffer the encoder expects is signalled in the stream. This enables low buffering delays or fast channel switching.And i'll add that, in fact, the default CPB size is 1 MB, and not 224 KB as I said previously and as it is said in this quote.

[LigH]

@ Sharktooth:

Whoops - this second thread was split off (but the subscription was not split)...
__

Still, I hope for more detailed documentation before I can finish my GUI, even for beta1. The fact that a few "undocumented" options were found, makes me ... hmm ... wonder at least, which of them are used and working at all.

-opengop (seems to create open GOPs, at least the encoder reports it)
-spmvp (I guess towards "special/spatial motion vector prediction"?!)
-log (maybe to specify a file where report or the 2-pass stats are stored; no effect seen)
-debug / -analysis (not yet tested, suspect "very internal" developer effects)
-maxbr (not yet tested - shall clamp bitrates?)

[Manao]

LigH : i repeat the answer i made to CyberGuy :
* opengop opens the gop
* spmvp enables spatial prediction ( temporal by default, because it's far more pleasing to the eye, even if it reduces the psnr )
* log works only if -rcmode 1st / 2nd is enabled ( 1st -> write into the file, 2nd -> read from the file )
* debug is a quality level ( -qual debug ) intended for debugging purposes only. Don't enable it in the GUI, it isn't meant to be used by anybody else than us ( results can be funny though )
* analysis doesn't exist
* maxbr is indeed the max bitrate, according to the CPB logic.

[LigH]

Fine! On the way to my next upload this evening... ;)

[dragongodz]

I'll quote a previous post in this very thread
ah i missed that. ok then it should be made clear in the final/retail version that CBR mode is not the traditional CBR as used with mpeg 1/2 or codecs such as xvid and dix etc. thanks.

[Soulhunter]

Hmm, is there a problem with huge files (above 4GB) ???

Coz I cant play this encode...

* Encoding summary

Input file : C:\Tests\Reloaded720p.avs
Output file : C:\Results\Reloaded720p.mp4
Resolution : 1280x720 @ 23.98 fps
Length : 183162 Frames
Quality : Best
Rate Control : 2pass
Target Bit Rate : 4700 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 250 (closed)
Process Priority : Idle [1 thread(s)]

* Encoding Features

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

-- Start processing pass 1 / 2
* 100.00% completed
* 183162 frames processed @ 15.16 fps
-- Start processing pass 2 / 2
* 183161: encoding @ 7.37 fps - bitrate 7.20 kb/s - 100.00% completed
* 183162 frames encoded @ 2.32 fps - average bitrate 4700.07 kb/s
* mean psnr 47.51 dB [46.44|50.92|51.74], overall psnr 46.83 dB

Encoding complete (time elapsed 02:49:22)
Bye

[Manao]

Most of the CBR rate control work the way ours work. You can't have a 'truly' CBR video in which all the frames have all the same size, because it would make I-frame and P-frame the same size, whereas Iframes must be bigger than Ps.

So, once you agreed that some frames must be bigger than others, you've got to define a number of frame on which you'll compute an average bitrate which shall be the wanted bitrate. That's (roughly) how the CPB / VBV model works. And it's the same for XviD ( since it respects the VBV buffer ), and for MPEG-2 codecs.

[CyberGuy]

LigH : i repeat the answer i made to CyberGuy :
* opengop opens the gop
* spmvp enables spatial prediction ( temporal by default, because it's far more pleasing to the eye, even if it reduces the psnr )
* log works only if -rcmode 1st / 2nd is enabled ( 1st -> write into the file, 2nd -> read from the file )
* debug is a quality level ( -qual debug ) intended for debugging purposes only. Don't enable it in the GUI, it isn't meant to be used by anybody else than us ( results can be funny though )
* analysis doesn't exist
* maxbr is indeed the max bitrate, according to the CPB logic.
I realize that these command line parameters were probably left out of the documentation for a good reason, but I was a little surprised when I discovered that –opengop yielded a lower SSIM value. I thought that open GOP was supposed the allow referencing frames outside of a GOP, therefore unusually reducing the size, from my experience with the Reference encoder. Also -spmvp also reduced the SSIM value, but this is what I expected since temporal prediction yields a better result in the Harry Potter II clip from my experience.

[LigH]

Beta 1 of my GUI looks ready now; just waiting for bobololo's opinion.

Please note the blue texted checkboxed:

checked (green) - added to "-setef"
unchecked (red) - added to "-clref"
grayed (blue) - assumes encoder defaults

Furthermore, I moved "lossless" option into the "Rate control mode" combobox. Only reasonable options are enabled depending on the selected rate control mode. Similar actions are applied to other (in my opinion) dependent options...

Screenshot: See reply #128 (http://forum.doom9.org/showpost.php?p=674506&postcount=128)

(BTW: No one yet mentioned the "funny" title of this reply?! ;))

[bond]

Since I found some JVT custom quantization matrices in the sources of x264 rev. 266, I wonder if I understood them correctly and made some useful file out of it:

csm-jvt.txt LigH, the values for the 8x8 inter luma matrix are wrong!
they should be:
INTER8X8_LUMA =
9,13,15,17,19,21,22,24,
13,13,17,19,21,22,24,25,
15,17,19,21,22,24,25,27,
17,19,21,22,24,25,27,28,
19,21,22,24,25,27,28,30,
21,22,24,25,27,28,30,32,
22,24,25,27,28,30,32,33,
24,25,27,28,30,32,33,35

[bobololo]

Ok i've made it publicly available:

ftp://mood.ateme.com/beta/Atemaker_b1.zip

Thanks for your contribution, great job :)

Beta 1 of my GUI looks ready now; just waiting for bobololo's opinion.

Please note the blue texted checkboxed:

checked (green) - added to "-setef"
unchecked (red) - added to "-clref"
grayed (blue) - assumes encoder defaults

Furthermore, I moved "lossless" option into the "Rate control mode" combobox. Only reasonable options are enabled depending on the selected rate control mode. Similar actions are applied to other (in my opinion) dependent options...

Screenshot: See reply #128 (http://forum.doom9.org/showpost.php?p=674506&postcount=128)

(BTW: No one yet mentioned the "funny" title of this reply?! ;))

[bobololo]

Hmm, is there a problem with huge files (above 4GB) ???

We may have an issue with file larger than 4 GB. We've to check. Thanks for the report.

[LigH]

@ bond:

Sometimes, copying into the clipboard seems to be not reliable on my system?! Thanks.

[bobololo]

Another small bug, encoding a scene form a dvd with basic settings (apart from -monochrome), the resolution came out as 704x576, while the original was 720x576. The PAR or DAR remained unchanged, so the result was a pillarbox picture with black bars on the side.

I just did a quick test in monochrome, and it worked for me using that resolution (720x576). Can you open you avs script with vdub and check the clip resolution ?

Actually, encavc is very dub regarding the input clip, it merely uses the parameters returned by the system (resolution, frame rate, etc) without any alteration.

[bobololo]

I realize that these command line parameters were probably left out of the documentation for a good reason, but I was a little surprised when I discovered that –opengop yielded a lower SSIM value. I thought that open GOP was supposed the allow referencing frames outside of a GOP, therefore unusually reducing the size, from my experience with the Reference encoder. Also -spmvp also reduced the SSIM value, but this is what I expected since temporal prediction yields a better result in the Harry Potter II clip from my experience.

The -opengop is bugged in beta2-1. That could explained why you get such results :)

[ChronoCross]

minor error. IDK once again if it really even matters. but

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 : 704x396 @ 23.98 fps
Length : 33491 Frames
Quality : Best
Rate Control : 2pass
Target Bit Rate : 1122 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 12:12 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.66 fps
-- Start processing pass 2 / 2
* 33490: encoding @ 1.86 fps - bitrate 66.07 kb/s - 100.00% completed
* 33491 frames encoded @ 0.53 fps - average bitrate 1121.94 kb/s

Encoding complete (time elapsed 00:04:01)

I'm pretty sure it took more than 4 minutes for me to encode this. it was actually 1 day 51 minutes. but it hit the bitrate very well. .06 off. and the quality was very very very nice.

[bill_baroud]

Just a though : Is it possible to have a page somewhere, or even a post here that will track the potentials bugs reported ? I mean, it can be quite hard to follow this post thoroughly, and yesterday i tried a little the encoder, it missed by a fair amount (5000 instead of 3000kb/s) the bitrate in abr mode...
well perhaps it already has been reported, perhaps it's my fault (the source is quite hard too encode), so i don't want to report a false alert or something already spotted.

[LigH]

Agree - best would probably be: Constantly updating the thread opening (http://forum.doom9.org/showpost.php?p=671920&postcount=1) with "known / fixed issues".

[Sharktooth]

Ligh your gui has a bug in the film grain modelling boost option. it produces "1,xx" instead of "1.xx".

[LigH]

Ah - sure, encavc expects english format, not locale dependent... should have expected that, but other details seemed more important.

[Sharktooth]

also this: http://forum.doom9.org/showpost.php?p=675777&postcount=51

[TEB]

Hi. Ive finally found some time to do some tests.. Anyone know if the codec support 4:2:2 mode? especially in lossless mode..
And whats the best way of testing that the lossless mode is infact lossless? SSIM?

Used a RGB32 file taken from a Digibeta (DPS Velocity), scaled down to yv12, and encoded on my p4 3,6 ghz in HT mode:

-- Start processing pass 1 / 2
* 100.00% completed
* 1400 frames processed @ 11.27 fps
-- Start processing pass 2 / 2
* 01399: encoding @ 13.67 fps - bitrate 28804.88 kb/s - 100.00% completed
* 1400 frames encoded @ 11.27 fps - average bitrate 34663.23 kb/s

Encoding complete (time elapsed 00:04:24)
Not bad at all.. Gonna test on a Dual Opteron i have here later..

teb

[Manao]

The codec only support 4:2:0 input at the moment. PSNR is the best way to test that the result is lossless.

[TEB]

Hi. Any good links on how to do some comparison with SSIM and PSNR? Cant get the msu tool to work on my avi files.. and it doesnt support the mp4 container..
All info would be apriciated, links, urls and the like!

teb

[LigH]

I try this using an AviSynth script. Unfortunately, the Ateme decoder has a temporal 1-frame shift, so the frames don't match -- I have to use ffdshow as decoder.

But for quality tests, we have another thread in this forum:

http://forum.doom9.org/showthread.php?t=95890

[bobololo]

@all testers,

We've created a sticky post for collecting the issues you're reporting and their current status.

You're strongly invited to check it before posting a new issue report.

http://forum.doom9.org/showthread.php?t=96203

[bill_baroud]

hmm, so i'll ask anyway, but that must be irrevelant : in ABR mode, on a hard-to-compress source (720p, high details, moving water), i got 5Mbit/s instead of the 3Mbit/s I requested... Other options where almost at defaults. It quite missed the bitrate, because of a bug or because it will have look like crap anyway (:D) ?

[bobololo]

hmm, so i'll ask anyway, but that must be irrevelant : in ABR mode, on a hard-to-compress source (720p, high details, moving water), i got 5Mbit/s instead of the 3Mbit/s I requested... Other options where almost at defaults. It quite missed the bitrate, because of a bug or because it will have look like crap anyway (:D) ?

Can you upload your clip and your encoding settings ?

[JasonFly]

I try this using an AviSynth script. Unfortunately, the Ateme decoder has a temporal 1-frame shift, so the frames don't match -- I have to use ffdshow as decoder.


How did you notice that?
From what I have done from the beginning of this beta, my avisynth's psnr scripts gave me what I'll call "correct" results. I mean I get a 38/40db psnr for 1000kbps clips(720x288 not very easy clip). I know that's a bit low for 1000kbits, but If ateme's encode were delayed the psnr should be a lot lower(20-30db).

Besides, I get very close psnr results with ffdshow decoder(0.04db higher for ffdshow without post processing).

When I load an ateme's encoded clip in vdub via DirectShowSource and go with the keyboard arrows to a frame(that's the only mean as is we move with the slider, vdub is lost, manao pointed this as an avisynth directshowsource problem), I get exactly the same frame as in my initial avs script(the source of the encoding).

All these facts convince me that I don't have this 1 frame shift you're talking about. That's strange that you get this problem.

As I'm finishing this post, i'm wondering if I understood correctly the meaning of the expression "1 frame shift". Do you mean 1 frame delay?

[LigH]

I used the following script:LoadPlugin("CompareYV12.dll")
LoadPlugin("SSIM.dll")
orig = AviSource("original.avi/avs",false,"YV12")
copy = DirectShowSource("encoded.mp4")
ssim = SSIM(orig,copy,"SSIM-Tab.csv","SSIM-Val.txt",lumimask=true)
comp = CompareYV12(orig,copy,"YUV","Compare.cmp")
diff = Subtract(orig,copy)
comp.Overlay(ssim).Overlay(diff)
The last step this script outputs, is a "difference video". And when you see some kind of "embossing" in motion there, you know that frame n in one clip was compared to frame n+1 in the other.

So yes, "1 frame delay" would sound better.

[Sharktooth]

I also experienced a rate control issue with ABR.
1400kbps was requested and it produced 1100.
It happened with Sagittaire's HP2 trailer.

CLI:
encavc.exe -i "C:\Trailers\SD-DVD\HP2\hp2.avs" -o "C:\Trailers\SD-DVD\hp2-ateme-1400.mp4" -qual extra -psy 3 -mvrange 256 -spmvp -enhchrp -rcmode abr -br 1400000 -fgm -fgboost 1.2 -priority idle -threads 2 -psnr -mingop 10 -maxgop 250 -setef ppred,bpred,wpred,cabac,deblock,part,hpel,deblock,xf8x8 -ref 2 -bref 2 -maxb 2 -deblock -2 -adaptdbk

AVS:
Mpeg2Source("hp2.d2v", idct=2)
Crop(0,74,0,-74)
LanczosResize(720,288)

[ateme]

LigH : can you post the original script that allowed you to create the mp4 in the first place ? Because i can't reproduce the issue.

[LigH]

My original script wasImageSource("HDTV%04d.bmp",1,400,25,true)
ConvertToYV12()
The images were rendered using Terragen, as described in this thread (http://forum.doom9.org/showthread.php?t=95732).

I forgot: For the AVS file as reference, I needed a SwapUV(), too...

Then I also compressed the video losslessly with FFV1 (using ffdshow's VfW interface) and compared the MP4 against this AVI, too. Except for SwapUV(): Same result - 1 frame delay with Ateme decoders, no delay with ffdshow.

The FFV1 video is around 150 MB, uploading will take some time (I might do it later, if you like).

[calinb]

Re: Large files

I've always had trouble with large Nero files too. The parser behavior seems to have changed since the first Nero AVC releases. With the early Nero AVC filters you can't seek past ~ 4GB. With the beta encoder and the newest Nero filters, the file won't render at all!

If I still have the old Nero AVC filters, I may try to confirm this, but I'm sure I remember them partially working on files > 4GB--they just couldn't seek past 4GB.

[Manao]

LigH : are you sure that your avi file doesn't begin by a dummy frame or something alike ? Because i sure don't have the issue with an avisynth script with only mpeg2source as source, and then the same script with Interleave(source, directshowsource).

[Manao]

Sharktooth : i tried your commandline on the hp2 trailer. I got a bitrate of 1316 kbps. However, something disturbs me : you put twice deblock into the setef flags ? Is it a mistake ?

Just to be sure, your computer is an X2 ? Or something more conventionnal ?

[LigH]

@ Manao:

Sorry, sorry, sorry - my fault:

In MPC, I blocked the Nero Video Decoder. But in other DirectShow applications (or DirectShowFilter), it still superceded Ateme's H264 Decoder.

I (once again) changed the merits - Nero to "unlikely", Ateme to "preferred"; if ffdshow is used, it has a much higher merit, anyway.

The double "deblock" might be an already reported bug of my GUI.

[Sharktooth]

uhm... it's a mistake...
however yep, it's a X2.

[IgorC]

Sharktooth : i tried your commandline on the hp2 trailer. I got a bitrate of 1316 kbps. However, something disturbs me : you put twice deblock into the setef flags ? Is it a mistake ?


It´s Ateme GUI bug. When you click it twice it put into CLI two times -deblock. I´ve already said that on other thread.

[Sharktooth]

yes, i checked it twice but i didnt spot the duplicate deblock

[Manao]

OK, then I guess it's a bug. However we'll have to check tomorrow on a bi-xeon to see if, hopefully, we can reproduce it.

Meanwhile, can you make sure that there's no mistake on your part by trying again the command line you gave to us, if you've got time of course. We never experienced such discrepancies between mono and multiprocessor ( at least, not since we crushed the last bugs concerning the multithreaded encoding ), so we're rather astonished.

[acidsex]

Will the .TS transport stream option be enabled in the next beta? I see its currently disabled for at least beta 1.

Would be nice to not have to pay major $$$ for TS muxing.

[LigH]

To summarize the found bugs in the first GUI:

- Film grain boost value must be formatted in english numerical format (decimal dot).
- Deblock appeared twice in "-setef".
- ref/bref options have a different meaning.

That's it so far? Then the next version shall be available very soon.

The FGBoost SpinEdit will still show localized numbers, but the command line shall contain the english format now. Deblock was a piece of copy&paste&paste. B-frame prediction value range will be clamped to the maximum prediction value.

[Sharktooth]

OK, then I guess it's a bug. However we'll have to check tomorrow on a bi-xeon to see if, hopefully, we can reproduce it.

Meanwhile, can you make sure that there's no mistake on your part by trying again the command line you gave to us, if you've got time of course. We never experienced such discrepancies between mono and multiprocessor ( at least, not since we crushed the last bugs concerning the multithreaded encoding ), so we're rather astonished.
I'll re-encode it asap and see if it goes nuts again :)
oh, btw 2pass ratecontrol hit the filesize almost perfectly.

[bill_baroud]

Can you upload your clip and your encoding settings ?

i hope i still have it, but i fear i trashed it because it looked like crap... well i'll try to reproduce the problem.

Btw, why the denoiser and/or the film grain modeling disable the PSNR switch ?
I was playing with -fgm yesterday and noticed that i never got any psnr information at the end of the encoding.

[Manao]

bill_baround : Because due to the application framework, the source picture isn't available for doing psnr computation when the denoiser is used, and the denoiser is used when fgm is.

Sharktooth : we tested on our bi-xeon, and got bit identical results to the ones I got at home on a A64 3200+ ( achieved bitrate : 1315, instead of 1400, which means an overall error on the filesize of 1.2 MB, a bit higher than expected, but since the clip ends by black frame, it's normal )

[LigH]

Until bobololo releases my new upload:

http://www.ligh.de/software/Atemaker_b1a.zip

[Sharktooth]

Sharktooth : we tested on our bi-xeon, and got bit identical results to the ones I got at home on a A64 3200+ ( achieved bitrate : 1315, instead of 1400, which means an overall error on the filesize of 1.2 MB, a bit higher than expected, but since the clip ends by black frame, it's normal )
I dont know what happened but today i cant replicate the problem (yesterday i could... but i never rebooted though...). I tested the same command line again and again and got only a slight undersize (the same you experienced), so im sorry, it seems the problem was my system... :(

@ligh: could you save some options in a configuration file? i mean selecting the encavc executable everytime you close the gui is irritating.
Maybe a more elegant solution would be to save the last settings and add a "reset to default" button but i leave it up to you:)

[bobololo]

Until bobololo releases my new upload:

http://www.ligh.de/software/Atemaker_b1a.zip

I've also made it available here :

ftp://mood.ateme.com/beta/Atemaker_b1a.zip

[LigH]

@ Sharktooth:

This will take some time ... until beta2, okay, bobo/Manao/ateme?! ;)

[bobololo]

I dont know what happened but today i cant replicate the problem (yesterday i could... but i never rebooted though...). I tested the same command line again and again and got only a slight undersize (the same you experienced), so im sorry, it seems the problem was my system... :(

Maybe you mis-read the bitrate value ? I mean instead of reading the average bitrate reported at the end of the whole encoding, you read the real time bitrate indicator showing the mean bitrate for the last frames.

[Sharktooth]

no, the filesize was much smaller. it's weird coz a simple reboot cant make it work... but i can no longer reproduce the problem.

[thegeby]

Re: my aspect ratio problems yesterday.

Sorry gentlemen, it was all due to the old beta "ax" files being present in my ateme directory. Problem solved. :thanks:

[Valeron]

A little high profile clip encoded with the latest pre-beta build:

ftp://mood.ateme.com/beta/cinderella-ateme-3000k-hp.mp4

with 8x8 transform, custom scale matrix (flat) and 4 slices (encoded on a bi-xeon).

Enjoy :)

The ffdshow 0619 seems not to decode this high profile encode AVC stream with Haali's splitter, MPC recognized the Video as "MPEG2 Video 1x4013".
Anyone can help?
I've got no NeroAVC decoder installed.

[Sharktooth]

You simply cant use ffdshow to decode that stream coz it has features ffdshow dont supports (yet).

[Valeron]

Thanks
but I see LigH had ever mentioned the "0611" build ffdshow already support decoding AVC high profile.

That confuse me a lot.

And another question maybe out of topic: do MP4 container use the same idea as AVI to recognize stream type? Just 4CC or other methods?
If 4CC is used, maybe I should mod the MP4 with UltraEdit then throw it to the ffdshow.
If not, I have to give up watch the clip this moment.

[Sharktooth]

Well it doesnt support "all" high profile features, only 8x8dct and i8x8.
It doesnt support custom matrices and seems to not like noise shaping.
FourCC is not used in MP4, coz it's supposed to contain MPEG-4 streams only.
Non MPEG-4 streams could be stored as private streams though.
So nothing will make the actual ffdshow decode that file...

[Manao]

"0611" supports 8x8 transforms, which belongs indeed to the high profile. But it misses custom matrices, another feature of the high profile, that is used in this clip too, iirc.

[Valeron]

Thanks, I've got it

Wait for the next build ffdshow to support all high profile features~

[bobololo]

We're scheduling a new beta release next week. We've addressed most (if not all) of the issues reported in the sticky. If you have still some issues that aren't listed in the sticky please post them so we can try to have them fixed for the next update.

Thanks to all testers !

[acidsex]

We're scheduling a new beta release next week. We've addressed most (if not all) of the issues reported in the sticky. If you have still some issues that aren't listed in the sticky please post them so we can try to have them fixed for the next update.

Thanks to all testers !

Will the transport stream option be enabled in the next beta?

[Sharktooth]

well... the CPU usage thing in the decoder... but i know you're already working on it :D

EDIT: ok, seems to be colorspace issues.

[bobololo]

Will the transport stream option be enabled in the next beta?

I don't think so unless there's a very good reason for this ?

[acidsex]

bobololo: I assumed since the option is there though disabled in the beta that at some point we would be able to make TS streams.

So my question would be if TS is not available during any of the betas, will this be a part of the final code or will there be additional costs for that particular option/module?

[ChronoCross]

I don't think so unless there's a very good reason for this ?

wouldn't it be ideal to test everything in the beta as we have already found issues with your mp4 implementation. Perhaps we can find bugs in the ts department :devil:

[bill_baroud]

@bolobolo :
okay, i didn't delete the clip afterall, and i even saved the log. I could reproduce it (not exactly the same bitrate, but oversized too). You can find the original file in my post in the Quality Feedback thread.
http://moodub.free.fr/x264/test1_abr_3000.log
http://moodub.free.fr/x264/test1_abr_3000.mp4

I had another strange bug yesterday (see http://moodub.free.fr/x264/error.log)
As you can see, in the first encode (ignore the first error), the 2nd pass didn't start, started when i added a Trim() in the avs, and started too when i corrected the crop in the avs (408 instead of 404) and removed the PAR flag.
Or perhaps i didn't understood how the PAR works (it's quite a possibility ;)) ?

btw, is it possible to have something less cryptic than "EAVC_initEncoder() failed with code -5" when, in this case, the resolution wasn't mod8 ? I spend some times figuring what went wrong.

[JasonFly]

I have a problem with ateme encoder or DirectShowSource(again). Don't know which one is the responsible

I downloaded a 1080i sample here:
ftp://ftp.ldv.e-technik.tu-muenchen.de/dist/test_sequences/
I took the 1080i25_parkrun_ter.yuv sample. The sample is 252 frames long with fps=25
Then I converted it to avi with yutoavi(RGB because it seems to be the only output color format supported?).
Then, i made my avisynth script(and here is the error):
DirectShowSource("I:\Telechargement\1080i25-parkrun-ter.avi").ConvertToYV12(interlaced=true)

Then I tried to test the different interlaced options in ateme's encoder but the output was always black and filesize was really small(approx 250ko instead of 2500ko). It looks like the fisrt frame of the source clip which is black too. I tried to encode it as progressive content but the result was the same. Here is my .bat file:

encavc.exe -priority below -i "I:\Telechargement\1080i.avs" -o 1080i-interlaced.mp4 -qual extra -rcmode 2pass -br 2000000 -enhchrp -deblock 0 -setef xf8x8,interlaced -maxb 3 -ref 16 -bref 8
encavc.exe -priority below -i "I:\Telechargement\1080i.avs" -o 1080i-paff.mp4 -qual extra -rcmode 2pass -br 2000000 -enhchrp -deblock 0 -setef xf8x8,paff -maxb 3 -ref 16 -bref 8
encavc.exe -priority below -i "I:\Telechargement\1080i.avs" -o 1080i-mbaff.mp4 -qual extra -rcmode 2pass -br 2000000 -enhchrp -deblock 0 -setef xf8x8,mbaff -maxb 3 -ref 16 -bref 8
encavc.exe -priority below -i "I:\Telechargement\1080i.avs" -o 1080i-paff-interlaced.mp4 -qual extra -rcmode 2pass -br 2000000 -enhchrp -deblock 0 -setef xf8x8,interlaced,paff -maxb 3 -ref 16 -bref 8
encavc.exe -priority below -i "I:\Telechargement\1080i.avs" -o 1080i-mbaff-interlaced.mp4 -qual extra -rcmode 2pass -br 2000000 -enhchrp -deblock 0 -setef xf8x8,interlaced,mbaff -maxb 3 -ref 16 -bref 8
encavc.exe -priority below -i "I:\Telechargement\1080i.avs" -o 1080i-mbaff-paff.mp4 -qual extra -rcmode 2pass -br 2000000 -enhchrp -deblock 0 -setef xf8x8,mbaff,paff -maxb 3 -ref 16 -bref 8
encavc.exe -priority below -i "I:\Telechargement\1080i.avs" -o 1080i-mbaff-paff-interlaced.mp4 -qual extra -rcmode 2pass -br 2000000 -enhchrp -deblock 0 -setef xf8x8,interlaced,mbaff,paff -maxb 3 -ref 16 -bref 8
encavc.exe -priority below -i "I:\Telechargement\1080i.avs" -o 1080i-progressive.mp4 -qual extra -rcmode 2pass -br 2000000 -enhchrp -deblock 0 -setef xf8x8 -maxb 3 -ref 16 -bref 8
pause


Here is a log:
I:\DVD\Ateme>encavc.exe -priority below -i "I:\Telechargement\1080i.avs" -o 1080
i-interlaced.mp4 -qual extra -rcmode 2pass -br 2000000 -enhchrp -deblock 0 -set
ef xf8x8,interlaced -maxb 3 -ref 16 -bref 8
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 : I:\Telechargement\1080i.avs
Output file : 1080i-interlaced.mp4
Resolution : 1920x1080 @ 25.00 fps
Length : 252 Frames
Quality : Extra
Rate Control : 2pass
Target Bit Rate : 2000 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Process Priority : Below [1 thread(s)]


* Encoding Features

- prediction : ipred ppred bpred(3) wpred : using 16:8 ref(s)
- entropy : cabac
- subsampling : hpel qpel
- mb partition : 16x16/16x8/8x16/8x8
- interlaced : field only (tff)
- misc : deblock(0:fixed) xf8x8 enhchrp

-- Start processing pass 1 / 2
* 100.00% completed
* 252 frames processed @ 0.57 fps
-- Start processing pass 2 / 2
* 00251: encoding @ 1.46 fps - bitrate 1442.91 kb/s - 100.00% completed
* 252 frames encoded @ 1.60 fps - average bitrate 200.42 kb/s

Encoding complete (time elapsed 00:10:39)

As you can see the second pass was faster than the first one, and that's the thing that convinced me that there was a problem during the second pass and that this should be related to DirectShowSource.

Here are a result:
http://perso.wanadoo.fr/paille/mp4/1080i-interlaced.mp4

To verify that hypothesis, I tried the following command lines in encavc.exe:
encavc.exe -priority below -i "I:\Telechargement\1080i.avs" -o 1080i-interlaced-2.mp4 -qual extra -rcmode 1st -log 1pass.log -br 2000000 -enhchrp -deblock 0 -setef xf8x8,interlaced -maxb 3 -ref 16 -bref 8
encavc.exe -priority below -i "I:\Telechargement\1080i.avs" -o 1080i-interlaced-2.mp4 -qual extra -rcmode 2nd -log 1pass.log -br 2000000 -enhchrp -deblock 0 -setef xf8x8,interlaced -maxb 3 -ref 16 -bref 8

And this time, the result was good(crappy because of the bitrate but the screen wasn't black). I tried 2pass encding with the same .avs with x264, and the output was correct. When I open the .avs in VirtualDub and move the slider forward and backward, I don't lost the frames. I mean I don't have any problems as those I had when I loaded .mp4 with DirectShowsource in VirtualDub.

So I don't really know who is the responsible of this strange behaviour:
Does -rcmode 2pass from encavc.exe do some strange thing to go back to the beginning of the file at the end of the first pass?
Should DirectShowSource have to be blamed one more time?

Firstly, I would have said that this should be due to encavc.exe, but I did another test:
I wrote this command line:
encavc.exe -priority below -i "I:\Telechargement\1080i-avisource.avs" -o 1080i-mbaff-avisource.mp4 -qual extra -rcmode 2pass -br 5000000 -enhchrp -deblock 0 -setef xf8x8,mbaff -maxb 3 -ref 16 -bref 8
with this .avs
AviSource("I:\Telechargement\1080i25-parkrun-ter.avi").ConvertToYV12(interlaced=true)
and this time, the result was good.

So in the end I don't know who is to "blame".

[Manao]

The fault lies in directshowsource : it can't seek properly. But when you do two passes in encavc, the file isn't closed / reopened, it is seeked to the beginning. Hence the issue.

[JasonFly]

Ok, That's what I thougth. But is the seeking done is a special way in encavc? Because as I said I my previous post, I can seek in the clip when I open it in virtualDub. Maybe it not done is the same way in encavc.

The important thing to remember from this is that we always have to take care when using DirectShowSource.

[Manao]

There's nothing special with the seeking in encavc. However, I did have issue with directshowsource even in virtualdub when seeking : the synchronization was lost, and sometimes the clip was stuck. I guess it depends on the video you're trying to open.

Anyway, when using directshowsource, and when you want to do a two passes encoding, do it in two steps, using rcmode fst, rcmode snd, and -log stats.log. That way you'll avoid any seeking issue.

[plonk420]

what kind of power does a 720p HP encode take to play back? i'm having problems playing 1280x720/24fps progressive @ 3200kbps on an athlon 64 3200, using the ateme decoder. i was trying to block it last night and use the FFDShow filter, but wasn't having much luck blocking. it was playing around 20fps. i'll try to upload the clip as soon as i get back... (after trying ffdshow)

[Manao]

Our decoder only outputs I420. It often isn't handle well by video renderers which seems to lead to a massive slowdown because the video overlay isn't correctly used.

Try the following in directshow : make the following graph :

ateme parser -> ateme decoder -> ffdshow -> video renderer

With ffdshow set up to to decode raw video ( I420 )

It should play faster. If it works, you can thank Sharktooth, who found that workaround.

[plonk420]

i get "these filters cannot agree on a connection. verify compatibility with with input pin and output pin..." with FFDshow MPEG-4 Decoder, FFDShow raw decoder, FFDShow VFW Decoder Helper

edit: i got it working. turns out graphedit was using the Nero decoder. with video > ateme decoder > ffdshow mpeg-4 decoder > video renderer, it's even slower. in a very active sequence, it dropped to about 2-4 fps.

[ChronoCross]

I decided to give it a try on my low end machine and I got a 1-2fps increase in playback on a NTSC 720x480 encode. still only amounted to 20fps on a 24fps clip but it's a definite improvement from the 18fps I was getting before. but it's too be expected for impossibility of playback on this particular machine.

[LigH]

Just a hint:
Then I converted it to avi with yutoavi(RGB because it seems to be the only output color format supported?).
Like I did for the VQEG test sequences - instead of converting YUV raw files to RGB AVIs, I would have used "RawSource()" for importing YUV files directly into AviSynth.

[JasonFly]

Didn't knew Rawsource(). Thanks, i'll try this.

[Sharktooth]

i get "these filters cannot agree on a connection. verify compatibility with with input pin and output pin..." with FFDshow MPEG-4 Decoder, FFDShow raw decoder, FFDShow VFW Decoder Helper

edit: i got it working. turns out graphedit was using the Nero decoder. with video > ateme decoder > ffdshow mpeg-4 decoder > video renderer, it's even slower. in a very active sequence, it dropped to about 2-4 fps.
ok, go to the output tab in ffdshow... remove all supported output colorspaces except YV12 or the colorspace your video card is able to decode faster (usually YV12 or YUY2) and check if overlay mixer is enabled.

[JasonFly]

I got my first "crash" with encavc. It occurs with the interlaced and paff options. That's quite strange because this problem seems to occur only with 720x576 sources. I have some 1080i samples and didn't have any problem with the same command lines.

I tried to encode some interlaced samples downloaded on the links provided by bill_baroud.
ftp://ftp.ldv.e-technik.tu-muenchen.de/dist/test_sequences/601/
Resolution is 720*576, fps=25, number of frames=252.
Samples are in .yuv so I converted them to .avi with yuv2avi12.exe (outputs YV12 directly whereas yuvtoavi.exe outputs RGB)

The following command line works fine:
encavc.exe -priority below -i "I:\DVD\Ateme\576i25_mobcal_ter.avi" -o 576-mobcal-mbaff.mp4 -qual extra -rcmode 2pass -br 1500000 -enhchrp -deblock 0 -setef xf8x8,mbaff -maxb 3 -ref 16 -bref 8
encavc.exe -priority below -i "I:\DVD\Ateme\576i25_mobcal_ter.avi" -o 576-mobcal-mbaff-paff.mp4 -qual extra -rcmode 2pass -br 1500000 -enhchrp -deblock 0 -setef xf8x8,mbaff,paff -maxb 3 -ref 16 -bref 8

The following command line lead to a crash of the encoder:
encavc.exe -priority below -i "I:\DVD\Ateme\576i25_mobcal_ter.avi" -o 576-mobcal-interlaced.mp4 -qual extra -rcmode 2pass -br 1500000 -enhchrp -deblock 0 -setef xf8x8,interlaced -maxb 3 -ref 16 -bref 8
encavc.exe -priority below -i "I:\DVD\Ateme\576i25_mobcal_ter.avi" -o 576-mobcal-paff.mp4 -qual extra -rcmode 2pass -br 1500000 -enhchrp -deblock 0 -setef xf8x8,paff -maxb 3 -ref 16 -bref 8
cbr rcmode produce the same result.

Example of Ateme's debug log, always the same except the hour:
[15:14:17] foooooo

I tried to encode via avisynth's AVIsource() but the result was the same.
I also tried to use yuvtoavi(which ouput RGB) and open it via avisynth's AVISource().ConvertToYV12(interlaced=true) but again, the encoder crashed.
I tried using Rawsource() plugin for avisynth (thanks LigH ;-)), but I still get a crash.
I was fisrt suspecting the samples because they were downloaded at the same place. But I've got the same problem with an interlaced source from a Pal DVD(720x576, 25fps, 4658 frames). I tested the same command line on two different 1080i samples and didn't have any crash.

ref and bref:
Removing the option xf8x8 from the command line didn't help but lowering the ref frames seems to solve the problem:
The following cmomand line doesn't crash the encoder:
encavc.exe -priority below -i "I:\DVD\Ateme\576i25_mobcal_ter.avi" -o 576-mobcal-interlaced-ref8-4.mp4 -qual extra -rcmode 2pass -br 1500000 -enhchrp -deblock 0 -setef xf8x8,interlaced -maxb 3 -ref 8 -bref 4
Setting higher -ref crashed the encoder:-ref 9, ..., -ref 16
Setting higher -bref (even if that doesn't make much sense) didn't crashed the encoder: -ref 8 -bref 5, -ref 8 -bref 6,..., -ref 8 -bref 8

bframes:
bframe seems to play a part in this because changing the number of bframe change the moment when the crash occurs in the first pass:
For the sample "576i25_mobcal_ter":
without bframes(-clref bpred) --> 4.37%
-maxbf 1 --> Crash at 7.94%
-maxbf 2 --> Crash at 11.11%
-maxbf 3 --> Crash at 12.70%
-maxbf 4 --> Crash at 12.70%
-maxbf 5 --> Crash at 12.70%

[Manao]

JasonFly : nice one. I added it to the bug list.

[dragongodz]

from the beta test sticky
10. Conflict with Nero
Description : Nero's decoder takes priority over Ateme's.
Status : not yet solved

solution.

first go here
http://www.free-codecs.com/download/DirectShow_Filter_Manager.htm
and download "directshow filter manager".

run it. see if it lists "Ateme H264 Decoder" and "Ateme MPEG-4 Parser". if it doent then you can use the "register new filter" button and point to the dll's. they may not show in the list right away so you may have to quit it and restart to see them.

lets assume you you see them. select one of them and click the "show filter properties" button. increase the merit value in the lower right corner, normally its 00600000 so make it 00600001 and press the "set merit" button. do the same for the other filter and then quit the manager. now try playing an MP4 in MediaPlayerClassic or whatever and you should see the Ateme decoder is used.

if not you may want to rerun the manager and see what merit whatever filter that was used is set at and change either it lower or the Ateme filters higher.

hope that helps. :)

[LigH]

Is there any reason to wrap an URL inside a CODE block to make it non-clickable?

Furthermore, there are useful alternative applications, e.g. the "Radlight Filter Manager" (hint: click directly on the Merit leaf in the tree!), or GSpot 2.52 beta (as described near the beginning of this thread).

[dragongodz]

Is there any reason to wrap an URL inside a CODE block to make it non-clickable?
is there any reason why i shouldnt ? has copying and pasting become that hard now ?

Furthermore, there are useful alternative applications, e.g. the "Radlight Filter Manager" (hint: click directly on the Merit leaf in the tree!), or GSpot 2.52 beta (as described near the beginning of this thread).
yes i know Radlight is also an alternative where you can do the same thing, including registering the filters. as for GSpot, correct me if i am wrong but the last time i looked you could not register new filters(as in ones missing from the list) with it, just reregister ones in the list and change the merit.

you know its funny but i kind of thought i may have got a little thank you or something since this is marked as still not solved. silly me, what ever was i thinking. :rolleyes:

[LigH]

Okay - "Thank you for pointing out another way to a temporary solution". But: I think that the Ateme guys search rather for wisely chosen values than for the technology to set them.

The reason is that the Ateme filters register themselves with a merit below "normal" (0x005FFFFF, AFAIR), so they get easily superceded. Instead, they should probably register themselves with a merit above "normal" (just as we correct it manually). But who knows if raising the merit may have side effects later, with other tools...

[dragongodz]

Instead, they should probably register themselves with a merit above "normal" (just as we correct it manually). But who knows if raising the merit may have side effects later, with other tools...
they registered as "normal" here using the manager. the simplest solution i can think of would be to do as FFDShow does. that is have a setting for merit in its configuration. then have the configuration callable from the start menu just as you can with x264, Divx, Xvid and FFDShow. that way it would be easy for people to set it higher if not used and easy to set lower if it causes any problems.

[JasonFly]

I bring some news about interlaced encoding and more precisely on interlaced decoding.
I get some crashes of Media Player Classic when I seek forward and backward within a clip encoded with the paff setting:
Clip: 720x576, 4658 frames, fps=25

Those command line don't produce a crash of the player:
encavc.exe -priority below -i "I:\DVD\Tests\Samples\08\08.avs" -o 08-interlaced-ref8-4-3bf.mp4 -bff -qual extra -rcmode 2pass -br 4000000 -enhchrp -deblock 0 -setef interlaced -maxb 3 -ref 8 -bref 4
encavc.exe -priority below -i "I:\DVD\Tests\Samples\08\08.avs" -o 08-mbaff-ref8-4-3bf.mp4 -bff -qual extra -rcmode 2pass -br 4000000 -enhchrp -deblock 0 -setef mbaff -maxb 3 -ref 8 -bref 4

This command line crash le player randomly when making something llike this:
Let the video start, then go forward with your slider, wait the video restart(on my computer this could take more than a second), go backward with your slider and wait the video start again. Repeat this process until the crash of the player.
encavc.exe -priority below -i "I:\DVD\Tests\Samples\08\08.avs" -o 08-paff-ref8-4-3bf.mp4 -bff -qual extra -rcmode 2pass -br 4000000 -enhchrp -deblock 0 -setef paff -maxb 3 -ref 8 -bref 4

Ateme Debug log:
[20:07:15] foooooo
[20:07:16] AtemeH264Decoder::NewInterlacing() => Changing interlaced flags

This was tested with another clip:
720x576, 252 frames, fps25 with the same result.

Disabling option such as bframes(3bf, 2bf, 1bf, 0bf), -enhchrp didn't helped.
Lowering the number of ref frames didn't helped

I wanted to try with other players but Windows Media player 6.4 doesn't allow me to seek into the file. The Core Media Player seems not to like .mp4 or h264 since playback doesn't start with interlaced content, and it only palyback a few frames with defaut settings of ateme's encoder. But that seems to be related to the player that cannot choose the right parser/renderer.

I also tested this command line on 1080i samples and cannot reproduce any crash within the player. But 1080i playback is really jerky on my system. Maybe the latency of my system could help the player not to crash? Stupid idea?



Sidenote about the 5/6 bitrate issue
Doing these tests, I was quite surprised when I saw that I didn't get the 5/6 ratio between the requested bitrate and the given one using the paff setting. This 5/6 issue has been reported previously and for now this "rule" has always been respected for me. For example, this happenned for the 1080i sample:

I:\DVD\Ateme>encavc.exe -priority below -i "I:\DVD\Ateme\LoadRawSource-mobcal-10
80.avs" -o 576-mobcal-paff-ref8-4-bf3.mp4 -rcmode 2pass -br 4000000 -enhchrp -d
eblock 0 -setef paff -maxb 3 -ref 8 -bref 4
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 : I:\DVD\Ateme\LoadRawSource-mobcal-1080.avs
Output file : 576-mobcal-paff-ref8-4-bf3.mp4
Resolution : 1920x1080 @ 25.00 fps
Length : 252 Frames
Quality : Best
Rate Control : 2pass
Target Bit Rate : 4000 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Process Priority : Below [1 thread(s)]


* Encoding Features

- prediction : ipred ppred bpred(3) wpred : using 8:4 ref(s)
- entropy : cabac
- subsampling : hpel qpel
- mb partition : 16x16/16x8/8x16/8x8
- interlaced : paff (tff)
- misc : deblock(0:fixed) enhchrp

-- Start processing pass 1 / 2
* 100.00% completed
* 252 frames processed @ 0.99 fps
-- Start processing pass 2 / 2
* 00251: encoding @ 1.33 fps - bitrate 607.51 kb/s - 100.00% completed
* 252 frames encoded @ 0.75 fps - average bitrate 3996.08 kb/s

Encoding complete (time elapsed 00:10:01)


I didn't noticed that until now but this happened for previous samples. I askezd for a 8000kbps sample and I get 7986.16 kb/s or 7992.66 kb/s.

With my 576i samples, I asked for 4000kbps and I get between 3240kbps/3260kbps according to the encoding settings. That more or less respect the 5/6 bitrate ratio issue found previously.

[*.mp4 guy]

A recent X.264 rev 270 build encode I did plays upside-down in media player classic with the Ateme filters installed, but plays right-side-up in virtualdub when FFdshow is used for decoding, see the screenshot for an example. I have verified that this is not an overlay issue aswell. I will upload the clip via ftp, but it might take a while because it is long.

Screenshot (http://img161.echo.cx/img161/9286/upsidedown0ni.png)

[edit] I tried to cut the clip in Vdub, but after I cut the clip it plays back corectly, so I will have to upload the whole thing.

[edit] Forgot to direct stream copy the video, its working now, I will upload the short clip.

[Manao]

*.mp4 guy : check if a filter hasn't inserted itself between our decoder and the video renderer during the playback.

JasonFly : the bug is solved, thanks for your report.

[Andrey]

Still wonder, why new filters doesn't work with bsplayer, while with mpc they works perfectly. Any ideas ? I prefer bsplayer to mpc for regular use...

[*.mp4 guy]

*.mp4 guy : check if a filter hasn't inserted itself between our decoder and the video renderer during the playback.

I just checked the directshow filtergraph and aperently the avi decompressor is used, it must be a problem with something else.

[Manao]

*.mp4 guy : well, it seems that :
- your graphic card doesn't support YV12 / I420 overlays
- either avi decompressor does a poor job at converting YV12 to RGB, or your graphic card doesn't support well the RGB output by the avi decompressor

[LigH]

Not necessarily - I had the AVI Decompressor as well when I lowered the merits of all Nero decoder filters, so that finally the ffdshow VfW decoder got preferred.

If you want to ensure that ffdshow is not used, disable H.264 support in both "Video decoder" and "VfW interface" codec lists.

[LigH]

23rd June 2005, 23:24
We're scheduling a new beta release next week.
Any more details about the release date? Most issues fixed?

[IgorC]

They are smashing the last misc. bugs :)

[Sharktooth]

yup, and hope they'll implement JM compatible custom scale matrices too... so i dont have to "work" twice... :)

[LigH]

Just another question about details:

- If I understood well, the "GOP size range" defines the allowed distance between IDR frames; is that right?

- What exactly would be the result of "-clref ipred"? Does this eliminate non-IDR I-frames?

[acidsex]

Has the second part of beta 2 been sent out yet? I thought we were supposed to have had a new beta last week and its 2 weeks later :)

[Sirber]

Sorry I'm late, I'll post a comparaison between x264 and ateme h264 in few days at 400kbps on my usual anime tests.

[LigH]

@ acidsex:

Not that I knew...

[bobololo]

Has the second part of beta 2 been sent out yet? I thought we were supposed to have had a new beta last week and its 2 weeks later :)

We've been rather busy here and weren't able to update as fast as we would. But hopefully a new build should be ready today or tomorrow.

[LigH]

Dear bobo,

please don't mind us, we don't want to urge you. We prefer a good product over a fast one.

It would just have beed better to drop a note if it takes longer than expected. ;)

Fun and success!

[Sirber]

Hi

my source was 23,976 FPS and result is 25 FPS

-qual extra -rcmode 2pass -br 400000 -psy 1 -deblock 3 -adaptdbk -setef ipred,ppred,bpred,wpred,cabac,deblock,part,hpel,qpel,xf8x8 -maxb 3 -enhchrp -ref 8 -bref 8 -priority idle

[bond]

with the new beta?

[Sharktooth]

OT: what NEW beta?

[Sirber]

beta 2 :(

[ChronoCross]

Edit: hmm I was thinking second beta as in second release for public testing. I think shaktooth was thinking the same. So it's actually the version from a month ago.

[Sirber]

that beta: http://forum.doom9.org/showthread.php?t=96203
is second beta test, so beta 2 :rolleyes:

[Sharktooth]

i got only 1 beta from ateme... and that was on 2005.06.15... is it the same as you're talking about?

[Sirber]

the current ateme h264 beta test
This beta test is my second (other one was last year)

[Sharktooth]

ok...

[bill_baroud]

phew...
i was starting to wonder how i could have miss a mail from Ateme :scared:

[bond]

that beta: http://forum.doom9.org/showthread.php?t=96203
is second beta test, so beta 2 :rolleyes:ok, such issues belong to the bug thread of the beta test

merged

[bobololo]

After some delays here is at last the 2nd beta build with many fixes and improvements. You can find the changelog here:

http://forum.doom9.org/showthread.php?p=685510#post685510

The packages are currently being uploaded and you'll receive your notification mail with the url within a few hours.

Thanks to all testers for the feedback you provided so far and keep on your wonderful contribution !

[LigH]

Update:

http://www.ligh.de/software/Atemaker_b2.zip

- Fixed a few mentioned and yet unreported details
- Added {S|P}AR presets and the new "no progress" option, and presets

Default preset may be saved on exit, if desired.

[IgorC]

@Ligh
When I close the window of the Atememaker it asking me in german - Ja , Nein ...
But that's ok. Danke :)

[LigH]

German? Strange: It shall use the system's values for the button captions (mbYesNoCancel), I did not code the strings on them! Does a german compiler use german captions?

[JasonFly]

Am I the only one that still have a lossy result using the lossless parameter with the beta2-2 encoder? :confused:
Tested on two differente clips.
Overall PSNR(reported from the encoder) 62.06 dB and SSIM 99.35(lower than with beta2-1 SSIM)
Overall PSNR(reported from the encoder) 62.08 dB and SSIM 99.71 (equal to the beta2-1 SSIM)

First log:

I:\DVD\Ateme>encavc.exe -priority below -i "I:\DVD\Tests\Samples\07\sample-lossl
ess.avs" -o DV-lossless.mp4 -lossless -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.17


* Encoding summary (lossless)

Input file : I:\DVD\Tests\Samples\07\sample-lossless.avs
Output file : DV-lossless.mp4
Resolution : 720x384 @ 50.00 fps
Length : 500 Frames
Quality : Normal
Gop Size Min - Max : 1 - 300 (closed)
Process Priority : Below [1 thread(s)]
CPU Extension : mmx sse


* 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:fixed)

-- Start processing pass 1 / 1
* 00499: encoding @ 8.84 fps - bitrate 55573.33 kb/s - 100.00% completed
* 500 frames encoded @ 8.12 fps - average bitrate 63633.77 kb/s
* mean psnr 62.27 dB [61.58|65.36|63.30], overall psnr 62.06 dB

Encoding complete (time elapsed 00:00:01:09)


Second log:

I:\DVD\Ateme>encavc.exe -priority below -i "I:\DVD\Tests\Samples\02\02_cut.avs"
-o 02-lossless.mp4 -lossless -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.17


* Encoding summary (lossless)

Input file : I:\DVD\Tests\Samples\02\02_cut.avs
Output file : 02-lossless.mp4
Resolution : 720x288 @ 25.00 fps
Length : 562 Frames
Quality : Normal
Gop Size Min - Max : 1 - 300 (closed)
Process Priority : Below [1 thread(s)]
CPU Extension : mmx sse


* 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:fixed)

-- Start processing pass 1 / 1
* 00561: encoding @ 12.95 fps - bitrate 13504.43 kb/s - 100.00% completed
* 562 frames encoded @ 11.16 fps - average bitrate 21069.37 kb/s
* mean psnr 62.24 dB [61.79|63.15|63.63], overall psnr 62.08 dB

Encoding complete (time elapsed 00:00:01:00)

[bobololo]

Am I the only one that still have a lossy result using the lossless parameter with the beta2-2 encoder? :confused:
Tested on two differente clips.
Overall PSNR(reported from the encoder) 62.06 dB and SSIM 99.35(lower than with beta2-1 SSIM)
Overall PSNR(reported from the encoder) 62.08 dB and SSIM 99.71 (equal to the beta2-1 SSIM)

Arggg it may come from the level compliance check that enforces the stream to become lossy in order to respect the level constraints :( We're checking this point.

[Sharktooth]

After some delays here is at last the 2nd beta build with many fixes and improvements. You can find the changelog here:

http://forum.doom9.org/showthread.php?p=685510#post685510

The packages are currently being uploaded and you'll receive your notification mail with the url within a few hours.

Thanks to all testers for the feedback you provided so far and keep on your wonderful contribution !
thanks for adding JM style custom scale matrices ;)

[Sirber]

Gonna update my comp with ateme beta 2-2 and with x264 fixed (now with bframes!!!)

[kwtc]

Am I the only one that still have a lossy result using the lossless parameter with the beta2-2 encoder? :confused:
Tested on two differente clips.
Overall PSNR(reported from the encoder) 62.06 dB and SSIM 99.35(lower than with beta2-1 SSIM)
Overall PSNR(reported from the encoder) 62.08 dB and SSIM 99.71 (equal to the beta2-1 SSIM)


There is a glitch in encavc. Use command line
encavc -lossless -setef lossless
to enforce lossless encoding.

[acidsex]

Just a question that I was wondering about. If we currently have Recode installed and then register the beta dlls, does Recode then use though for decoding or are the new dlls only for the command line encoder?

Also, I meant to ask this is the first round of beta2, but why wasnt the mux tool that was included with beta1 included with this beta2?

Thanks.

[Manao]

Beta's directshow filters only consist of a H264 decoder and a MP4 parser, so Recode won't use them for encoding. Encavc.exe isn't directshow based, so Recode can't use it for encoding either.

[LigH]

Thinking about adding kwtc's hint into my GUI...

[IgorC]

New beta2 is a bit faster and hit a target bitrate better

Beta 1

C:\dvd1>encavc.exe -i p.avs -o beta1.mp4 -qual extra -rcmode 2pass -br 700000 -
mvrange +256 -psy 3 -deblock -2 -enhchrp -ref 5 -bref 3 -setef xf8x8 -cpb 122937
6 -maxb 3
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 : p.avs
Output file : beta1.mp4
Resolution : 720x304 @ 23.98 fps
Length : 1081 Frames
Quality : Extra
Rate Control : 2pass
Target Bit Rate : 700 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Max Motion Range : 256
Process Priority : Normal [1 thread(s)]


* Encoding Features

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

-- Start processing pass 1 / 2
* 100.00% completed
* 1081 frames processed @ 3.28 fps
-- Start processing pass 2 / 2
* 01080: encoding @ 2.20 fps - bitrate 529.68 kb/s - 100.00% completed
* 1081 frames encoded @ 2.18 fps - average bitrate 699.86 kb/s

Encoding complete (time elapsed 00:14:35)


Beta 2

C:\dvd1>encavc.exe -i p.avs -o beta2.mp4 -qual extra -rcmode 2pass -br 700000 -m
vrange +256 -psy 3 -deblock -2 -enhchrp -ref 5 -bref 3 -setef xf8x8 -cpb 1229376
-maxb 3
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.17


* Encoding summary

Input file : p.avs
Output file : beta2.mp4
Resolution : 720x304 @ 23.98 fps
Length : 1081 Frames
Quality : Extra
Rate Control : 2pass
Target Bit Rate : 700 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Max Motion Range : 256
Process Priority : Normal [1 thread(s)]
CPU Extension : mmx sse sse2


* Encoding Features

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

-- Start processing pass 1 / 2
* 100.00% completed
* 1081 frames processed @ 3.40 fps
-- Start processing pass 2 / 2
* 01080: encoding @ 2.30 fps - bitrate 541.48 kb/s - 100.00% completed
* 1081 frames encoded @ 2.27 fps - average bitrate 700.01 kb/s

Encoding complete (time elapsed 00:00:14:03)

Now new line 'CPU Extension' appears

[JasonFly]

There is a glitch in encavc. Use command line
encavc -lossless -setef lossless
to enforce lossless encoding.

This works perfectly. I now have perfectly lossless outpout.

[AlexeyS]

Does somebody know when AVC high-profile will be available as Nero's software? :confused:

[Sharktooth]

there were plenty of threads made by ppl asking WHEN.
The answer is: WHEN IT'S READY.
... and guess what? it's not ready ...

[Sigmatador]

Here is some results about the feature i wished to test, the lossless mode ^^, theses results are 2 weeks old, sorry i was very² busy

first: 25 min (37685 frames) from 'Le pacte des loups'. Within those 25 minutes, you have high motion scenes, low motion scense with textures, dark and light scenes, rains, etc... everything you need to stress a codec

VBLE: 4255 MO
FFV1: 3347 MO
CPNG: 3629 MO
H264: 3717 MO
X264: 4092 MO

second: Ai Yori Aoshi Enishi Miyuki (the whole episode ~15min), an anime of course, a very very clean DVD, high contrast, not many high motion scenes, many scene changes, not very detailled, maybe not the best choice in order to test anime, but well, it was the only anime DVD i got at this moment ^^

VBLE: 1564 MO
FFV1: 1433 MO
CPNG: 1802 MO
H264: 1478 MO
X264: 1742 MO

I didn't notice any problems, the file size was my main target (sorry i forgot to note the encoding time ^^)

I just got my hand on 'Coral Reef Adventure' (the whole 1080p DVD), i'll use it to test H264 vs X264 vs XVID ^^ as soon as possible (in lossy mode of course, 2-PASS, with PSNR, duration and options)

Regards.

[Soulhunter]

Ok, it seems the parser has still a problem with huge (4GB+) files !!!

After the first 6 minutes my encode re-starts at the beginning...


Bye

[Sharktooth]

Seeking in WMP doesnt still work.
Also when seeking in MPC (didnt test other players) the video frames are decoded faster to get in sync with the audio for about 1 second.

[Manao]

Soulhunter : (big) files created with the old encoder weren't valid, so if it's one of the old files you're trying to play, it's normal.

[Soulhunter]

@ Manao

No, of course Ive redone this encode with the new (1.2.0.17) version... ;)

Bobololo told me that the file should be ok n' its probably a bug in the parser !!!


Bye

[IgorC]

Interlace doesn't work here ( version 1.2.0.17). The picture is jumping when
Interlace enable(decoder option). Whatever I use interlace and/or paff and/or mbaff.
Paff,mbaff even reduce PSNR.
Source : 720x480 NTSC 29.9 fps , no resize, no crop.

Paff,mbaff, inerlace
C:\DVDVolume>"C:\dvd1\encavc.exe" -i "C:\DVDVolume\catu.avs" -o "C:\DVDVolu
terlaced.mp4" -qual best -psy 3 -mvrange 256 -enhchrp -cpb 1048576 -par 10:
cmode 2pass -br 1000000 -psnr -setef deblock,interlaced,paff,mbaff -ref 3 -
3 -maxb 3 -deblock -2 -adaptdbk
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.17


* Encoding summary

Input file : C:\DVDVolume\catu.avs
Output file : C:\DVDVolume\interlaced.mp4
Resolution : 720x480 @ 29.97 fps
Length : 201 Frames
Quality : Best
Rate Control : 2pass
Target Bit Rate : 1000 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Max Motion Range : 256
Process Priority : Normal [1 thread(s)]
CPU Extension : mmx sse sse2


* Encoding Features

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

-- Start processing pass 1 / 2
* 100.00% completed
* 201 frames processed @ 2.43 fps
-- Start processing pass 2 / 2
* 00200: encoding @ 2.57 fps - bitrate 752.63 kb/s - 100.00% completed
* 201 frames encoded @ 2.06 fps - average bitrate 999.10 kb/s
* mean psnr 41.08 dB [39.81|45.67|47.06], overall psnr 40.48 dB

Encoding complete (time elapsed 00:00:03:12)


Interlace +mbaff
C:\DVDVolume>"C:\dvd1\encavc.exe" -i "C:\DVDVolume\catu.avs" -o "C:\DVDVolume\i
terlacedM.mp4" -qual best -psy 3 -mvrange 256 -enhchrp -cpb 1048576 -par 10:11
rcmode 2pass -br 1000000 -psnr -setef deblock,interlaced,mbaff -ref 3 -bref 3 -
axb 3 -deblock -2 -adaptdbk -priority idle
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.17


* Encoding summary

Input file : C:\DVDVolume\catu.avs
Output file : C:\DVDVolume\interlacedM.mp4
Resolution : 720x480 @ 29.97 fps
Length : 201 Frames
Quality : Best
Rate Control : 2pass
Target Bit Rate : 1000 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Max Motion Range : 256
Process Priority : Idle [1 thread(s)]
CPU Extension : mmx sse sse2


* Encoding Features

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

-- Start processing pass 1 / 2
* 100.00% completed
* 201 frames processed @ 1.97 fps
-- Start processing pass 2 / 2
* 00200: encoding @ 2.46 fps - bitrate 752.63 kb/s - 100.00% completed
* 201 frames encoded @ 1.94 fps - average bitrate 999.10 kb/s
* mean psnr 41.08 dB [39.81|45.67|47.06], overall psnr 40.48 dB

Encoding complete (time elapsed 00:00:03:36)

Inerlace only

C:\DVDVolume>"C:\dvd1\encavc.exe" -i "C:\DVDVolume\catu.avs" -o "C:\DVDVolume\in
terlaced.mp4" -qual best -psy 3 -mvrange 256 -enhchrp -cpb 1048576 -par 10:11 -r
cmode 2pass -br 1000000 -psnr -setef deblock,interlaced -ref 3 -bref 3 -maxb 3 -
deblock -2 -adaptdbk -priority idle
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.17


* Encoding summary

Input file : C:\DVDVolume\catu.avs
Output file : C:\DVDVolume\interlaced.mp4
Resolution : 720x480 @ 29.97 fps
Length : 201 Frames
Quality : Best
Rate Control : 2pass
Target Bit Rate : 1000 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Max Motion Range : 256
Process Priority : Idle [1 thread(s)]
CPU Extension : mmx sse sse2


* Encoding Features

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

-- Start processing pass 1 / 2
* 100.00% completed
* 201 frames processed @ 1.92 fps
-- Start processing pass 2 / 2
* 00200: encoding @ 4.28 fps - bitrate 615.51 kb/s - 100.00% completed
* 201 frames encoded @ 1.62 fps - average bitrate 998.30 kb/s
* mean psnr 41.51 dB [40.30|45.61|47.04], overall psnr 40.86 dB
Encoding complete (time elapsed 00:00:04:00)

[Andrey]

Hi, guys !
Was on vacation, now downloaded beta2.
BSPlayer still do not work (but it isn't in change log either :( ).
Other things working as expected, period...

[kwtc]

About playing interlaced content.

The Ateme H264 decoder DirectShow filter signals to the downstream filter whether or not the sequence is interlaced, through the VIDEOINFOHEADER2 structure.

Downstream filters (usually a video renderer or a color space converter followed by a video renderer) may ignore this flag or not. The default video renderer will deinterlace, but very badly. For better output, this renderer must be put in video mixing mode (which I don't know how to do with MPC).


Very badly may be translated by jumping image.

[LigH]

Still undocumented are these encoding tools:

- subpart
- pcm

And may there be even some more yet undocumented options?

I'd like to know if they are important, before I release Atemaker 2a (which will include the "double lossless option" and the CPU extension option).

Furthermore, I'd like to know a bit more about "realtime encoding". Seems to be only important for state-of-the-art machines, which are able to encode fair quality by using only as much time for encoding as the movie frame rate?!

[Manao]

* subpart is the equivalent of p4x4 in x264 : it enables ( virtually ) 4x4, 8x4 and 4x8 partition block size. Virtually only, however, since you won't get any of these block sizes. It's there for future use
* pcm is a special coding mode, where the macroblock is coded without any prediction / compensation / transformation / quantification / compression : the block's coefficients are simply written (almost) as such in the bitstream. In the meantime, the contexts are resetted. They are useful only in very specific cases ( context reset means better error resilience, and it very very low qps, pcm might take less bits that effectively coding the macroblock ). However, in the everyday use of the codec, you don't have to care about pcm since the codec won't use it.

* i prefer wait tomorrow for explaining 'realtime' ( better yet, wait for kwtc to explain it ), because it's behavior is a bit tricky. Correctly used, it should allow to use an encoding speed instead of a quality level ( the encoder adjusting itself the quality level to reach the wanted speed ). However, the relation between the wanted encoding speed and the 'realtime' setting isn't straightforward, so i'll stop there before saying something incorrect.

[LigH]

So I will prepare the GUI for the "subpart" option, but maybe better disable the checkbox until it might become available in the encoder. And I may write the abbrevation as "plain coding mode", except someone knows what it should mean instead. Then the next version shall be finished tomorrow...

[IgorC]

@Manao
Macroblock partition is enabled only down to 8x8. You said that 8x4,4x8, 4x4 enabled 'virtually'. What does it mean? During previos beta test of main profile it was mentioned that partition down 4x4, 4x8, 8x4 wasn't enabled yet due to hard speed impact. But is it possible to implement those patrition for -full and/or -extra quality mode.

My previos post about interlace video bug is truly only for VMR7 , not fot VMR9

[Manao]

LigH : PCM means Pulse Coded Modulation. It has exactly the same definition as PCM for audio ( ie, uncompressed numeric representation of an analogic signal )

IgorC : I said subpart are there for future use. We disabled them because we find they cost too much in comparison to what they bring, so we don't enable them, even in full quality mode ( which isn't meant to be used in the first place, except for show-off purposes ;) ). We can produce them however ( try -qual debug -setef subpart, and voilà, you've got an ugly video with 4x4 in it ), so the option is present ( an useful, but for us only ).

For the interlaced thing, if it happens only when you check interlace in the decoder, then it's the renderer once again doing its worse at deinterlacing. If it always happens, i'd say it's a field order issue, but then i'd need a more precise description of the issue.

For the unefficiency of the mbaff in comparison to interlace, you surprise me a lot. However, we didn't test thoroughly mbaff lately, perhaps we broke something down while mending the rate control / the mbaff decision, who knows. We'll dig deeper in the matter tomorrow.

@all : the decoder is buggy as hell with lossless at the moment. It's known and solved internally. The old decoder is still working with lossless, though, if you ever need to watch your lossless video.

[LigH]

PCM encoded video... sounds funny, but is true ("Klingt komisch, ist aber so"). :D

Okay - thank you for resolving this.

And ... well, I wonder if I shall add "debug" quality, or better ignore it for the GUI. (BTW: Does someone in the Ateme team use it?! I don't expect it.)

[IgorC]

subpartition down to 4x4 with extra quality is working here :). Speed wasn't too bad. Hm, going to compare quality and speed later. is subpartition really enabled now or it's like adaptive deblock in first beta 2-1?

[kwtc]

And ... well, I wonder if I shall add "debug" quality, or better ignore it for the GUI. (BTW: Does someone in the Ateme team use it?! I don't expect it.)


You really shouldn't ! In this quality mode, the encoder uses rand() for almost every decision, thus producing a very poor quality output. However, it is very useful for normative validation of the encoder and... decoder !

[kwtc]

I prefer wait tomorrow for explaining 'realtime' ( better yet, wait for kwtc to explain it ), because it's behavior is a bit tricky. Correctly used, it should allow to use an encoding speed instead of a quality level ( the encoder adjusting itself the quality level to reach the wanted speed ). However, the relation between the wanted encoding speed and the 'realtime' setting isn't straightforward, so i'll stop there before saying something incorrect.

The encoder is indeed able to run at a given fps (at least in single pass modes) rather than at a given quality level. With command line option -rt, the encoder will target 25 fps encoding speed (for content at 25 fps). Of course, the encoder may fail to reach this speed (HD can not be encoded realtime on a P3 800MHz) if the given configuration is not suitable.

Internally, this realtime option is however more complex. The encoder is given a target cpu load (which can be over 100%), a window size and a boolean flag.

The window size is the number of frames on which encoding speed statistics are collected. The smaller the window size, the quicker the encoder reacts to speed changes.

The boolean flag controls whether the target cpu load applies to the time spent by the encoder or the system cpu load. For example, you may specify that the encoder should take 75% CPU (leaving 25% for other tasks) or you may specify that the system cpu load should be 90%, whether the load is taken by the encoder or some other program.

An what about setting cpu load to 500% ? The encoder will encode a 25 fps stream at 5 fps...

[bobololo]

Ok, it seems the parser has still a problem with huge (4GB+) files !!!

After the first 6 minutes my encode re-starts at the beginning...

Does anyone can reproduce this problem also ? We've done some tests here and it appears we don't have the same issues than Soulhunter.

[bobololo]

The encoder is indeed able to run at a given fps (at least in single pass modes) rather than at a given quality level. With command line option -rt, the encoder will target 25 fps encoding speed (for content at 25 fps). Of course, the encoder may fail to reach this speed (HD can not be encoded realtime on a P3 800MHz) if the given configuration is not suitable.

Internally, this realtime option is however more complex. The encoder is given a target cpu load (which can be over 100%), a window size and a boolean flag.

The window size is the number of frames on which encoding speed statistics are collected. The smaller the window size, the quicker the encoder reacts to speed changes.

The boolean flag controls whether the target cpu load applies to the time spent by the encoder or the system cpu load. For example, you may specify that the encoder should take 75% CPU (leaving 25% for other tasks) or you may specify that the system cpu load should be 90%, whether the load is taken by the encoder or some other program.

An what about setting cpu load to 500% ? The encoder will encode a 25 fps stream at 5 fps...

encavc doesn't offer so much control over the realtime option. When using "-rt" the cpu load is forced to 100% and the window size is set to 20 frames. User can't choose the cpu load and the window size by themselve.

[Sharktooth]

Does anyone can reproduce this problem also ? We've done some tests here and it appears we don't have the same issues than Soulhunter.
Going to test it tonight.

[IgorC]

It seems like subpart doesn't work here. I got the same visual quality and OPSNR with or without subpartition. As it was mentioned it left for future.

[Manao]

IgorC : after some investigation, it seems that our MBaff decision is slightly broken with multi references. Moreover, telecined content ( i guess that's what you're encoding ), seems to be dealt quite efficiently in interlaced mode ( with at least two refs ). Could you try the same video, with 1 ref only, or with 3, but in Paff ?

[IgorC]

C:\DVDVolume>"C:\dvd1\encavc.exe" -i "C:\DVDVolume\catu.avs" -o "C:\DVDVolume\PA
FF.mp4" -qual best -psy 2 -mvrange 256 -enhchrp -cpb 1048576 -par 10:11 -rcmode
2pass -br 1000000 -psnr -setef deblock,interlaced,paff -ref 1 -bref 1 -maxb 3 -d
eblock -2 -adaptdbk -priority idle
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.17


* Encoding summary

Input file : C:\DVDVolume\catu.avs
Output file : C:\DVDVolume\PAFF.mp4
Resolution : 720x480 @ 29.97 fps
Length : 201 Frames
Quality : Best
Rate Control : 2pass
Target Bit Rate : 1000 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Max Motion Range : 256
Process Priority : Idle [1 thread(s)]
CPU Extension : mmx sse sse2


* Encoding Features

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

-- Start processing pass 1 / 2
* 100.00% completed
* 201 frames processed @ 3.70 fps
-- Start processing pass 2 / 2
* 00200: encoding @ 4.01 fps - bitrate 739.85 kb/s - 100.00% completed
* 201 frames encoded @ 3.11 fps - average bitrate 997.50 kb/s
* mean psnr 40.62 dB [39.35|45.23|46.62], overall psnr 40.04 dB

Encoding complete (time elapsed 00:00:02:08)
PSNR results :
1 ref,1bref , paff = 40.04
1 ref, mbaff,paff = 40.16
3ref,3bref ,paff,mbaf = 40.34
3ref,3bref, interlace only = 40.62
3ref,3bref, interlace,vbaff = 40.34
3ref,3bref, interlace,paff = 40.51



But OPSNR isn't always good for metrics. Visually it hard to say what was better cause of interlaced source. If you need I can upload this source.

[LigH]

Update:

http://www.ligh.de/software/Atemaker_b2a.zip

+ Quality level "debug" is available, but only after a warning dialog.
+ PAR presets changed a little; default (click on image button) resets to 1:1
+ "lossless" rate control mode adds an "encoding tool" entry as well
+ CPU extensions
+ MB sub-partitioning is available, but (as reported) not effective
+ "PCM coding mode" available, but appears to have no effect to the bitstream?! (*)

(*) http://www.ligh.de/software/PCM-test.zip contains batch file with command lines, and both results. Maybe another option supercedes the "pcm" encoding tool?

[IgorC]

Ligh. Good HDTV sample . Can you give link to this source, please.
What actually PCM is? EDIT : I already found it about PCM.

[LigH]

The video is a small version of this Terragen script:

Using Terragen to make animation for tests (http://forum.doom9.org/showthread.php?t=95732)

[Manao]

IgorC : thanks a lot, it confirms what i said previously : our interlaced vs frame decision has somehow been b0rked.

LigH : PCM are, if i'm not mistaken, always enabled. However, since they are really highly ineffective, we almost never use them ( we, that is, except in debug mode :p )

[LigH]

PCM is always enabled? Strange. So I must have misunderstood your explanation completely. I thought it is ineffective because no compression (e.g. Huffman) is used; and why would you harm your encoding efficiency?! So does "-setef pcm" mean that PCM is allowed, but not forced?

BTW: In my first command line, I even used "-clref pcm"...

[Manao]

OK, my bad, -clref pcm indeed disables PCM.

However, they are enabled by default, and they should be left enabled because :
* they don't slow down anything
* when they allow a gain, they can be used, but if not, they won't

To summarize : i should never have talk about pcm, then you'dn't have known, and it wouldn't have changed anything. Now, you know, it won't change a thing either, except making you ( and me, partly ) a bit puzzled :)

[Latexxx]

you'dn't
OMG !!!
Just write "you wouldn't".

[LigH]

Don't be afraid; although I'm not a native english speaker, I understood... ;)

[JasonFly]

I did an encode >4Gb last nigth and didn't have any problem playing it. Didn't have problems with seeking either. Is there a way Soulhunter's problem could be encountered only when using particular settings or only in the two pass mode?

I did this test using the abr mode(only for a matter of time gain ;)). Here is the full command line:

encavc.exe -priority below -i "I:\DVD\Carnet_Voyage\carnet_de_voyage_1024.avs" -o "I:\DVD\Carnet_Voyage\Carnet de voyage.mp4" -qual normal -psy 1 -deblock 0 -denomv 0 -denosp 0 -denotp 0 -rcmode abr -br 5090000 -ref 5 -bref 2 -psnr

Here is the report:

Core encoder version 1.2.0.17


* Encoding summary

Input file : I:\DVD\Carnet_Voyage\carnet_de_voyage_1024.avs
Output file : I:\DVD\Carnet_Voyage\Carnet de voyage.mp4
Resolution : 1024x544 @ 25.00 fps
Length : 181000 Frames
Quality : Normal
Rate Control : Abr
Target Bit Rate : 5090 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Process Priority : Below [1 thread(s)]
CPU Extension : mmx sse


* Encoding Features

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

-- Start processing pass 1 / 1
* 180999: encoding @ 23.86 fps - bitrate 320.32 kb/s - 100.00% completed
* 181000 frames encoded @ 4.91 fps - average bitrate 5076.44 kb/s
* mean psnr 49.00 dB [48.71|49.90|50.30], overall psnr 48.05 dB

Encoding complete (time elapsed 00:12:15:17)

[Sharktooth]

My encode (ABR too) works flawlessly and it's well beyond 4GB.

[calinb]

My encode (ABR too) works flawlessly and it's well beyond 4GB.
Same here. I've done a couple of 720p HD encodes > 4GB.

Has anyone figured out how to mux a 4GB+ file and an AC3 file to mkv? mkvmerge/mmg seems to work for my Ateme files, but only if they're < 4GB. Of course, the Ateme and Nero parsers won't connect to anything useful for muxing either.

[Soulhunter]

Im already uploading *cough* 20KB/s *cough* my 4GB+ encode... :o

So the ateme guys can check if something is wrong with the file!


Bye

[IgorC]

I have a problem with a smooth playback here. The video is stacking during playback.
The same problem occured in past year , september when showtime player didn't playback smooth.
I tried Both decoders - Ateme and Nero. It Doesn't important what settings were used. I thought it's problem of Geforce4's drivers. I've made a new installation of Windows but problem still persist. No problem with other codecs.

P.S. After playback of Ateme H.264 others videocodecs also have a playback problem for a short period. Seems like problem of the video buffer.

[skal]

Hi IgorC,
could you upload the problematic sample somewhere?
thanks,

-Skal

[IgorC]

I already test this sample with varios settings. And there was't any problem untill yesterday. Maybe something hapened with my sysytem. That's why I did a clean instalation of WindowsXP sp2. But a problem is still here. I admit it may be problem only here. http://sr1.mytempdir.com/100393

[skal]

Indeed, this bitstream is decoded ok here.
sorry not being of more help...

-Skal

[IgorC]

I'll check what it can be. I was quite sure it happens only here. Thanks.

[Sharktooth]

plays back ok here too.

[calinb]

Like Nero Digital, avcenc doesn’t seem to work with power saving modes (hibernate and sleep). Actually, I think encavvc is worse than Nero because, if I enable a low power mode and switch CPU voltage and core clock frequency on my laptop, encavc locks up.

Update to muxing large files with AC3: The Ateme parser connected to the matroska muxer—even with a 4GB+ file. Don't know why I had trouble with this before now. Still have to check the resulting mkv file though.

[vidhead]

2 days now i'm hopelessly getting the same error message from virtualdubmod 1.5.10.0 with gordian knot 0.35.0 doing x264 conversion on the 2nd pass. source is dvd.

the error reads: VirtualDub error
Cannot start video compression: An unknown error occurred (maybe corrupt data) (error code -100)

click "ok" and it 'completes' the 2nd pass in some 40 seconds. needless to say the resulting avi looks crappy.

i've tried the same without sound, with sound (ac3 to mp3). all default settings and another attempt with changes to 1000kbps and deblocking strength +6.

if i switch to xvid it worked like a charm.
(sorry if i posted inthe wrong place - i wasn't thinking :rolleyes: )

[LigH]

Indeed - you are wrong here: "Ateme H.264 beta" is not the same as "libavcodec x264".
__

But anyway:

Long time, no (real) news from the Ateme team; are the most issues cleared now, can we expect a "final" soon - or do you still miss some specific tests you would like to be done?

[kwtc]

BSPlayer still do not work (but it isn't in change log either :( ).


Sorry for taking so long to look at that. It seems to work perfectly in BSPlayer when preference "Filter Management | General | Allow Intermediate Filters" is checked.

When this option is not checked, opening a file fails with "Can't create DirectDraw surface!".

[dragongodz]

Long time, no (real) news from the Ateme team; are the most issues cleared now, can we expect a "final" soon - or do you still miss some specific tests you would like to be done?
yes i left bobololo a PM some time ago asking if there was any specific options etc he would like to see more testing done with. no reply to the PM yet either, so dont know whats happening. :confused:

[bond]

bobololo is on holiday atm

[Soulhunter]

yes i left bobololo a PM some time ago asking if there was any specific options etc he would like to see more testing done with. no reply to the PM yet either, so dont know whats happening. :confused:
Yeah, bobololo "disappeared" from IRC as well, I havent seen him for some weeks now! I hope he is just on vacation n' not dead or so... :\


Bye

[Soulhunter]

Ohw, just noticed the reply from bond !!!

Good to know bobololo is still alive... ^^


Bye

[LiFe]

Looks like things are wrapping up?

I'd love to see the new libraries added to nero digital. I've 400GB of DVD and 22GB of home made DV to encode.

: )

[LigH]

...

...

...

Hmm, must be finished now.

[acidsex]

I guess we are done with beta testing since its been ages (or so it seems like) since we received beta 2.2

[LigH]

Hereby, once again I request any signs of life from the developers.

[bobololo]

Hereby, once again I request any signs of life from the developers.

Well, we've been rather quiet lately about the beta because we haven't set a clear schedule for the next releases yet. And all we could say wouldn't bring much more compared to what you may already know.

Basically the beta isn't over and we plan several other releases with fixes and improvements. Our main matter is that with the summer break and the very busy Q3/Q4 period for ateme, we couldn't have all the required time to bring you a significant improved release. But be sure that as soon as we retrieve some bandwidth we'll be back to the beta :)

[LigH]

Thank you very much to know that you are still "in business" ;)

[dvd_maniac]

This is a little dissapointing to me. I was eagerly awaiting the release of Nero7 because I thought that the Beta was over and Recode would include it in the release.
Oh well...

[Manao]

Nero7 and ateme beta 2 are totally unrelated. Ateme's encoder is in a stable state : all the bugs found in the beta are squashed so the encoder is really to be used.

Further quality improvements in beta 2 won't ( at least shouldn't ) delay Nero7.

Basically, Ateme's encoder exists outside Nero, and Ateme's roadmap differs from Nero's.

[dvd_maniac]

Ahh, I was under the impression that the next release of Nero7 would have the HP profile in recode which is what I thought this beta was about.
I am VERY happy with the quality of the current version of Recode now, the only reason I await an upgrade is because I only get 50% CPU utilization when encoding with AVC in recode. When encoding ASP I get closer to 80% on my dual-core CPU. I was hoping to speed up AVC encoding a little...

[IgorC]

Further quality improvements in beta 2 won't ( at least shouldn't ) delay Nero7.
That's good news. Last beta was quite stable except of some bugs on interlace and multiple references. But it was 2 months ago.

[dimzon]

Does anybody know - is it possible to join to beta-testing process now?

[acidsex]

So I take the beta is over now? It has been ages and eons since the last round. Maybe Bobololo will jump in here and let us know.

[Kostarum Rex Persia]

Bobololo,hello! Can you answer us what's going on with Beta 2 test.

[Bulletproof]

It's been a long time since the last beta was released, and there are some considerable improvements in the new beta that I would like to use, but I can't since the beta is strictly for beta testing and not distribution of video. I think Doom9 is going to be doing a codec comparison soon too, and Ateme will be at a disadvantage if he is going to be forced to use the older encoder. Can John or anyone from Ateme please post an update?

[Doom9]

I think Doom9 is going to be doing a codec comparison soon too, and Ateme will be at a disadvantage if he is going to be forced to use the older encoder.What makes you think I won't get the latest and greatest build of any codec I'll be testing? ;)

[IgorC]

Ateme will be at a disadvantage if he is going to be forced to use the older encoder.

Quality of video output by last beta was best untill now.
As Doom9 won´t use full quality mode ( because of speed something like 1 fps or even less) there won´t be a big changes. During this short period 4 month there can´t be revolutional changes. Maybe +0.3.. 0.4 SSIM.
HD content encoded by Ateme was looked as a conjuction of high quality PNG pictures :p

[Guest]

How do I become a beta tester for the Ateme encoder? Thank you.

[Manao]

@all : we've been quite silent lately on the beta test. The reason is that we still want to improve things before delivering another version ( else it'd be useless ), and that we lack time and resources for that. We'll keep you informed when there'll be some updates.

neuron2 : the beta test subscription process began 6 months ago, and ended two weeks later. You're a bit late for beta testing.

[bond]

@all : we've been quite silent lately on the beta test. The reason is that we still want to improve things before delivering another version ( else it'd be useless ), and that we lack time and resources for that. We'll keep you informed when there'll be some updates.does this also influence nero releasing the high profile encoder?

does development on the high profile encoder slow down because its unsure that nero will use it?

[Kostarum Rex Persia]

No, I don't believe that. Most probably, Ateme want to maximize quality and speed of own H.264 encoder, to ensure that they codec will beat x264, in quality and speed.

[bond]

No, I don't believe that. Most probably, Ateme want to maximize quality and speed of own H.264 encoder, to ensure that they codec will beat x264, in quality and speed.well thats naive, ateme wants to make money and x264 (as using the gpl) is no competitor in the professional field

[Manao]

Ateme's beta testing scheduling is in no way related to Nero's high profile encoder release. And, once again, Ateme's encoder exists beside Nero ( since you know we're selling an encoding suite ).

When a codec is mature enough, development is bound to slow down. It happened with XviD ( OK, sysKin will try to prove me wrong on that point ), it's happening with x264. There's no reason why we should be exempted.

And as bond stated, x264 isn't a competitor on the professional field, though not as much because of the GPL than because it doesn't support interlacing.

[Guest]

neuron2 : the beta test subscription process began 6 months ago, and ended two weeks later. You're a bit late for beta testing. Maybe that should be reconsidered. As an employee of a world leader in decoding silicon, including AVC, perhaps I have something useful to offer.

[bond]

does this also influence nero releasing the high profile encoder?manao?

[guada 2]

" As an employee of a world leader in decoding silicon, including AVC, perhaps I have something useful to offer ".

Interesting :)
Who knows......

[Manao]

Bond : I don't understand what you want me to say. I don't work for Nero, and I certainly don't know when they'll release a version of recode with high profile support. We deem our encoder ready, since we have been selling it to professionnal for some times now. But the encoder isn't recode, it's only a tiny part of it.

As an employee of a world leader in decoding silicon, including AVC, perhaps I have something useful to offer.Then you should contact us professionally instead of asking on a public forum.

[bobololo]

Then you should contact us professionally instead of asking on a public forum.

They did it. Actually our companies are already in contact and they already have a old version of our encoder. Though it was another business unit or group. We just need to check if our respective agreement coverage is ok. Then we should be able to update them.

I'm taking advantage of this post to announce the release of beta2-3 which should occur by the end of next week. This beta will also be submitted to doom9 comparison so all beta testers will be able to reproduce doom9 encodes :)

[Kostarum Rex Persia]

Wow, great news, bobololo. Any new option in beta 3?

[Guest]

Then you should contact us professionally instead of asking on a public forum. Don't run a beta program on a public forum if you don't want people to ask about it.

[ChronoCross]

Don't run a beta program on a public forum if you don't want people to ask about it.

whoa calm down. The only reason he sorta yelled at you was because they ran a like 2 month signup period for the beta test on the public forums earlier this year. They stopped taking signups once the beta started. So it's kinda a common question they get about becoming a beta tester when they have already stated in the past that they aren't currently looking for more volunteers.

I'm sure you would be an exception to the rule however as it seems your company is all sorta working with them already. I'd personally like to hear your input as your probably once of the developers on this public forum who has contributed a great amount for as long as I have been a member working on a better higher quality way of dealing with DVD(mpeg2) video. Well done.

[JohnV]

does development on the high profile encoder slow down because its unsure that nero will use it?And where do you get the information that it would be unsure, I'm very interested..
Because I haven't heard that, pretty much opposite.

[bond]

And where do you get the information that it would be unsure, I'm very interested..
Because I haven't heard that, pretty much opposite.well my sentence was a question, not a statement :p

edit: well maybe you can answer why nero till now didnt release high profile?

[Sharktooth]

The answer is pretty easy, they're waiting for the final encoder.

[Bulletproof]

Are you guys going to distribute it the same way as the previous betas? Its been a long time and I lost my sheet with my login/password, am I screwed?

[bobololo]

Dear testers,

Finally it comes, the long awaited third release of Beta2 has been released a few minutes ago to testers. We're certainly reaching here the last step of the test unless major flaws suddenly appear.

As rather long time has passed since the previous release, you're certainly wondering what the hell have we done during this period and how many new features you're going to test.

Well, you'll be a little bit disapointed because our past months were mostly dedicated to video encoding fields quite far from your typical codec use : TV contents video encoding. For those who aren't familiar with such kind of application, it must be interpreted as : interlaced (mbaff), real time, CBR, 15 frames GOP, very tigh CPB (VBV) constaints, visual quality assessment, etc. As you can imagine this is very different from 2pass progressive encodes you may usually practice :)

Therefore our best efforts were spent on improving those points which give us very few breath to increase PSNR figures on trailers ;)

Anyway enough words, here is the changelog:


* decoder filter
- significant performance improvement

* encavc
- add new -chrdq parameter (chroma quantizer delta)
- add new -compcont parameter (compensate the container overhead)
- add new -minb parameter
- add udp streaming for ts output
- fix crashes with multi cores system

* core encoder
- fix rdo lambda for very low bitrate
- performance improvement
- mbaff decision fixes and improvement
- psychovisual improvement
- cbr rcmode improvement
- misc bugfixes


Have fun with this new release and thanks again for you help and don't forget to post your quality feedback here (http://forum.doom9.org/showthread.php?t=95890&highlight=Ateme+beta+quality+feedback) !

PS: This version was submitted to doom9 comparison. And also for those who lose their letter, PM me I'll give you your login info again.

[IgorC]

Wow. Thanks.
There are significant changes and new features . Already looking to it.

[acidsex]

I was a moron and lost my paper so I have to wait for my login before I get to play and have fun. Impressive list to say the least. Im excited about this beta probably more than thelast two. :)

[Bulletproof]

I was a moron and lost my paper so I have to wait for my login before I get to play and have fun. Impressive list to say the least. Im excited about this beta probably more than thelast two. :)

I lost my sheet too, who do you have to contact to get the info again?

[acidsex]

contact bobololo. He can help ya out :)

[ChronoCross]

encoding fails with adaptdbk enabled. no matter the rest of the settings tried it with all defaults with just it enabled. as well as all options enabled. 1 thread or 2 doesn't matter either.

C:\DOCUME~1\ChronoCross\MYDOCU~1\SAMURAI_X\VIDEO_TS>C:\DOCUME~1\ChronoCross\MYDO
CU~1\MYDOWN~1\ENCODI~1\Ateme\Beta_2-3\encavc.exe -i C:\DOCUME~1\ChronoCross\MYDO
CU~1\SAMURAI_X\VIDEO_TS\KenshinMovie.avs -o C:\DOCUME~1\ChronoCross\MYDOCU~1\SAM
URAI_X\VIDEO_TS\KenshinAteme.mp4 -qual best -rcmode 2pass -qp 24 -minqp 0 -maxqp
51 -mingop 1 -maxgop 300 -mvrange 256 -br 820000 -psy 0 -deblock 1 -setef ipred
,ppred,bpred,wpred,cabac,deblock,part,hpel,qpel,xf8x8 -maxb 2 -minb 0 -par 1:1 -
ref 14 -bref 14 -enhchrp -priority idle -thread 2 -cpuext auto -psnr -adaptdbk

ENCAVC - Copyright (c) 2004-2005 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.4.0.3

EAVC_initEncoder() failed with code -99
- Output file (C:\DOCUME~1\ChronoCross\MYDOCU~1\SAMURAI_X\VIDEO_TS\KenshinAteme.
mp4) closed

[acidsex]

I can confirm that adaptdbk does indeed crash.

[acidsex]

Lossless mode is horrible for me. Two seperate encodes and during play back, I get red and blue blocks, sometimes yellow all over the screen. Once I figure out how to grab the screen and find a place to host the image, Ill post it here.

"C:\Documents and Settings\patrick\Desktop\encavc\encavc.exe" -i "C:\Vegas 6 FASST\VIDEO_TS\lossless.avs" -o "C:\Vegas 6 FASST\VIDEO_TS\lossless.mp4" -qual best -psy 3 -mvrange 64 -spmvp -enhchrp -lossless -denoiser -denomv 4 -denotp 16 -denosp 16 -priority normal -mingop 1 -maxgop 300 -opengop -setef lossless,ppred,bpred,wpred,cabac,deblock,part,subpart,hpel,qpel,xf8x8,pcm,interlaced,paff,mbaff -bff -ref 1 -bref 1 -maxb 2 -deblock -2

[acidsex]

Ok, I managed to split a 10 second clip of it. Where is a place that will host large files for free? Its a 45mb file.

edit: uploading to Rapidshare now.

[acidsex]

lossless heavy blocking (http://rapidshare.de/files/9316564/lossless_2_15.mp4.html)

Check it out and see what I mean.

[ChronoCross]

Screenshot of what your seeing as well as your encoding settings. is your source interlaced? I don't see anything out of the ordinary unless it doesn't look like the source. it just looks like it was either poorly deinterlaced or you didn't set the interlacing options correctly.

[superdump]

Eeep. -adaptdbk gives me an error here too.

Commandline:
-qual extra -rcmode 2pass -br 600000 -deblock -2 -adaptdbk -setef xf8x8 -maxb 3 -enhchrp -ref 5 -bref 1 -psy 0 -psnr

Error:
EAVC_initEncoder() failed with code -99
- Output file (c:/videostuff/ateme-adaptdbk.mp4) closed

However, lossless works fine for me.

[superdump]

acidsex: Your file plays fine with Ateme's decoder but it won't decode with ffdshow.

EDIT: ***Correction. I had to use Haali Media Splitter + ffdshow to get it to decode and that is broken. I think it's an ffdshow problem though as Haali's Media Splitter + Ateme H.264 decoder beta2-3 works fine.

[molitar]

Ok I am curious from you beta testers if ateme will do what VideoSoft h.264 encoder was able to do.. so far the ONLY one out all the encoders that I have tried could accomplish.

Situation:

1. matroska file that has a bad h.264 avi file inside of it.. seems it's missing the header information.

2. Because of the bad file it will only play while inside the matroska file with nero video decoder. Used graphedit to determine this.

3. So problem how do I re-convert this bad h.264 file into a good h.264 file? Well since graphedit is the only program that would open it I tried x.264 and nothing I could do would make it work to do more than render video it just would not connect no matter what I used to the file writer.

4. So I tried the nero digital and even tho the encoder is their seems the encoder will only work with nero's recode the decoder works outside of it but not the encoder.

5. I than tried the 3ivx encoder and again incompatible with the file writer from the encoder nothing I tried to connect with would allow it to work.

6. Finally I tried VideoSoft Video Encoder and it worked BEAUTIFULLY! And with the LEAST amount of filters.. so here is how it looked in graphedit....

Haali Media Splitter --> Nero Video Decoder --> VSoft DirectShow Encoder --> AVI Mux --> file writer

It did it perfectly but since it was a trial encoder only I got about 8 minutes from it.

So my question would ateme been able to handle this problem? Would it been able to fit right where the Vsoft did and properly mux and write the file out? This bad file seems to be the ultimate test for h.264 encoding and I know now I don't like any of the others at all they are totally useless when it counts.

[Manao]

What are you talking about ? Firstly, it has nothing to do with Ateme beta test. Secondly, you don't seem to understand what happened in the processing chain that you created : you decode the video, then recode it. So :
You're losing quality
You're losing time
The hardest part was splitter -> decoder. Any other encoder / player would have worked after the nero decoder ( well, no perhaps not any, since interoperability with DirectShow isn't assured, but close ).
You don't know of avisynth and its DirectShowSource
You discard Nero because it doesn't work outside recode. Well, you don't know the renaming trick ( graphedit.exe into recode.exe iirc )
You discard 3ivX because you don't know how to use it ( because it would have worked in your case )
You speak of x264 in a DirectShow context. That's a bit astonishing since afaik there's no DirectShow implementation out there.

[molitar]

The hardest part was splitter -> decoder. Any other encoder / player would have worked after the nero decoder ( well, no perhaps not any, since interoperability with DirectShow isn't assured, but close ).
Correct so I wanted to know how interoperability with Directshow is since only the beta testers have access to this codec currently.

You don't know of avisynth and its DirectShowSource
I've used avisynth in virtdubmod to convert to xvid but this bad file threw up errors that neither virtdubmod or virtdub would open since again it has an h.264 file inside the container with NO HEADER at all.

You discard Nero because it doesn't work outside recode. Well, you don't know the renaming trick ( graphedit.exe into recode.exe iirc )
Yes I know of this trick but nero encoder pops up with codec in use. Ahead made sure that the encoder will not work with other applications so that trick does not work with encoding it seems.

You discard 3ivX because you don't know how to use it ( because it would have worked in your case )
I asked on the forums even for 3ivX and they had no solution for me either since they stated it would require a RAW h.264 parser and they had no suggestions on where to get one that would work with 3ivX.

You speak of x264 in a DirectShow context. That's a bit astonishing since afaik there's no DirectShow implementation out there.
I stated what it took to get a working conversion done from a bad file with a missing header since their seems to be no h.264 repair utilities as of yet. Videosoft encoder is called just what I stated in graphedit. VideoSoft DirectShow Encoder.

And what does it have to do with the beta. Exactly what I asked would it have worked in this situation? Since apparently 3ivX will not handle this bad file header format so it made it impossible to pass it to a file writer even with AVI Mux because the 3ivX refused to connect it's encoder to the AVI Mux. The others all had similar issues only VideoSoft has worked so far even tho I plan to test out FastVDO also.

[Manao]

It's not a DirectShow codec, as you would have known if you have read the thread. I persist for 3ivX and all other directshow encoder : once you get the decoded stream ( ie, after nero's decoder ), you should be able to do anything you want. The fact that you say 3ivX lacks a h264 parser means that you didn't explain correctly your problem to the 3ivX guys. BTW, 3ivX only allows to produce MP4 file ( which is a good thing ).

[molitar]

Manao I agree that mp4 is a good thing also. But I did state the issue with the video file missing the header information. Also that I was trying to re-encode it back to a file inside the matroska container using graphedit than posted a shot of what I had done to make it an xvid file successfully than asked what filters I would need to make it back to a h.264 or mp4. The response was that it would not parse to the avi mux because it would require a raw h.264 parser. So the only method they had suggested after seeing a portion of the hexedit of the file itself was..

if there's a way to extract h.264 streams from mkvs, mkvtoolnix is propably the only tool that might be able to do it. (There directshow filters/splitter definitly can't do it.)

Muxing the raw h.264 stream into an mp4 container should be possible with mp4box e.g. through using Yamb.

But you answered my question so thanks Ateme is not a directshow filter so no it would not handle this situation. I'm new to graphedit and still learning so please be a bit understanding of my situation I've always used virtdubmod with avisynth to accomplish conversions to xvid but graphedit is a new tool for me as well as h.264 being a new codec and I am trying to learn what ones can do what so I can find a standard one that I am satisfied with to do all my tasks.

[bill_baroud]

damnit, i didn't lose my sheet, but my motherboard died... with the time i've in my hands, it's a shame.

[bobololo]

I've just checked your clip and it works fine for me.

Lossless mode is horrible for me. Two seperate encodes and during play back, I get red and blue blocks, sometimes yellow all over the screen. Once I figure out how to grab the screen and find a place to host the image, Ill post it here.

[bobololo]

encoding fails with adaptdbk enabled. no matter the rest of the settings tried it with all defaults with just it enabled. as well as all options enabled. 1 thread or 2 doesn't matter either.

Ok it's confirmed, for some obscur reasons, the adaptive deblocking support was disabled. We're on it.

[Sharktooth]

uhm... is the decoder multithreaded?
coz i get weird results...

[Manao]

No, it isn't. What weird results ?

[Sharktooth]

Jumps in CPU2 utilization...

[bobololo]

uhm... is the decoder multithreaded?
coz i get weird results...

Yes the decoder uses slight smp optimisations.

[Sharktooth]

also ffdshow (x264.nl version) is ~30% faster at decoding on all single processor/single core configurations i tested.

@ligh: your GUI was really usefull, could you update it with the new 3 options in beta3?

[Manao]

~30% faster at decoding on all single processor/single core configurations i tested.What configurations ? And bobololo ( for once ) is incorrect, our decoder isn't multithreaded. So multicore definitely shouldn't help, hence my asking.

[Sirber]

Any way to get back my login and password? The letter is for long lost :(

[Sharktooth]

Ok, i found what was causing the CPU spikes. I was using the MPC internal mp4 splitter and for some obscure reasons it was causing those spikes.
But still the decoder is slower than ffdshow on Athlon XPs.

[Eretria-chan]

Any way to get back my login and password? The letter is for long lost :(
And also for those who lose their letter, PM me I'll give you your login info again.
:) ...

[Manao]

But still the decoder is slower than ffdshow on Athlon XPs.Unless FFDShow's speed increased a lot recently, that's a bit surprising. In the configuration panel of the decoder, what options are enabled / disabled ? And what was the encoding option of the video ? ( especially : cabac, bframes, deblocking )

[Sharktooth]

there was a libavcodec speedup recently...
hoewever, default options.

[ChronoCross]

Something else I've found. I cannot re-mux the created mp4 file using mkvtoolnix. it muxes correctly but the during playback if you skip through the file it blocks but if you leave it just play through it plays fine.

Remuxing to mp4 with sound in mp4box works perfectly. Do you think this is a bug in mkvtoolnix? or is there something missing from this version of the codec. Cause I know mkv muxing in the last version was okay.

[calinb]

Something else I've found. I cannot re-mux the created mp4 file using mkvtoolnix. it muxes correctly but the during playback if you skip through the file it blocks but if you leave it just play through it plays fine.

I'll confirm ChronoCross' findings. It muxes okay with with mkvtoolnix, but seeking is not working correctly with Haali or MPC internal matroska splitter. When I attempted to remux with avimuxgui, it failed to finish muxing successfully, which is something I never saw in beta2-2. This is unfortunate. (I want my AC3! :))

[Selur]

@ligh: your GUI was really usefull, could you update it with the new 3 options in beta3?
I second that :)

[LigH]

Oops, did I almost miss something?

Obviously, the notification went to the SPAM folder... ortunately, I was able to reconstruct the download URLs and found my password.

Okay, a new round is open. Expect a new GUI soon.

[acidsex]

sweet. LigH definitely had an awesome GUI and look forward to the new one.

[LigH]

Atemaker Test 2 Beta 3 (http://www.ligh.de/software/Atemaker_b3.zip)

Please try if it works for you; there were not many changes in the dependeny logic, but as usual, I might have missed a mistake.

[*.mp4 guy]

In the time between beta 2 and beta 3 I must have lost/thrown away the letter that was sent to me with my password, would it be possible for you to send me a replacement? I would like to help out in this round aswell, but that would be difficult without the latest beta :o.

[Sharktooth]

@*.mp4 guy: PM bobololo and ask him :)

[acidsex]

ENCAVC - Copyright (c) 2004-2005 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.4.0.3

EAVC_initEncoder() failed with code -99
- Output file (C:\encavc-beta2-3\test.mp4) closed

C:\encavc-beta2-3>C:\encavc-beta2-3\encavc.exe -i C:\DETROIT_ROCK_CI\VIDEO_TS\dr
c.avs -o C:\encavc-beta2-3\test.mp4 -qual best -psy 2 -mvrange 64 -par 40:33 -rc
mode cbr -br 1000000 -mingop 1 -maxgop 300 -setef ppred,bpred,wpred,cabac,debloc
k,part,subpart,hpel,qpel,xf8x8 -ref 1 -bref 1 -maxb 2 -deblock -2 -adaptdbk
ENCAVC - Copyright (c) 2004-2005 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.4.0.3

EAVC_initEncoder() failed with code -99
- Output file (C:\encavc-beta2-3\test.mp4) closed

C:\encavc-beta2-3>





I try running an encode using Ligh's front end and this is the error I get.

[acidsex]

Ok, its not Ligh's front end as I get the same error doing it manually with a completely seprate file.

C:\encavc-beta2-3>encavc.exe -i test.avs -o clip.mp4 -qual best -rcmode 2pass -b
r 1000000 -adaptdbk
ENCAVC - Copyright (c) 2004-2005 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.4.0.3

EAVC_initEncoder() failed with code -99
- Output file (clip.mp4) closed

[ChronoCross]

Ok, its not Ligh's front end as I get the same error doing it manually with a completely seprate file.

C:\encavc-beta2-3>encavc.exe -i test.avs -o clip.mp4 -qual best -rcmode 2pass -b
r 1000000 -adaptdbk
ENCAVC - Copyright (c) 2004-2005 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.4.0.3

EAVC_initEncoder() failed with code -99
- Output file (clip.mp4) closed

Acidsex

I reported the problem with adaptdbk about 4 days ago. bobololo confirmed the error already

[acidsex]

swet. Im a moron because I remember I didnt use that option on my initial test codes because I saw the report but forgot about it. Life is well on this end now. Thanks.

[*.mp4 guy]

I get an error with these settings:
D:\encavc-beta2-3\encavc.exe -i D:\input.avs -o D:\clip.mp4 -br 799000 -deblock -3 -ref 16 -bref 16 -mingop 48 -maxgop 240 -qual Best -mvrange 512 -enhchrp -rcmode 2pass -maxb 3 -csm D:\encavc-beta2-2\mp4_guy's_AVC_Low_Bitrate_matrix.txt -setef ipred,ppred,bpred,wpred,cabac,deblock,part,hpel,qpel,xf8x8,csm
Using ffdshow build ffdshow-20051103, 1:46 into the file the error apears as garbage blocks, with the Ateme beta 2-3 decoder and parser media player classic crashes and disapears at about the same time.

The source I encoded from was an avs script decoding a 1024*432 Huffyuv file without any processing, I've encoded the source file many times and I know its not what is at fault.

Heres the file ( http://rapidshare.de/files/9761401/clip.mp4.html)

[calinb]

I suspect this is an MPC bug and I'm not sure Ateme is even interested in mkv, but I'd like to bring it to the Ateme develpers attention, regardless:

http://forum.doom9.org/showthread.php?p=760603#post760603

[bobololo]

Ok I got the file and confirm that something is going wrong. Could you please upload the source ?

I get an error with these settings:
D:\encavc-beta2-3\encavc.exe -i D:\input.avs -o D:\clip.mp4 -br 799000 -deblock -3 -ref 16 -bref 16 -mingop 48 -maxgop 240 -qual Best -mvrange 512 -enhchrp -rcmode 2pass -maxb 3 -csm D:\encavc-beta2-2\mp4_guy's_AVC_Low_Bitrate_matrix.txt -setef ipred,ppred,bpred,wpred,cabac,deblock,part,hpel,qpel,xf8x8,csm
Using ffdshow build ffdshow-20051103, 1:46 into the file the error apears as garbage blocks, with the Ateme beta 2-3 decoder and parser media player classic crashes and disapears at about the same time.

The source I encoded from was an avs script decoding a 1024*432 Huffyuv file without any processing, I've encoded the source file many times and I know its not what is at fault.

Heres the file ( http://rapidshare.de/files/9761401/clip.mp4.html)

[*.mp4 guy]

The source was a ~600MB Huffyuv file that I deleted a while ago. I kept it for a while, but I didn't think this was going anywhere so I got rid of it a few days ago :(. I beleive I made the source by resizing Divx.com's HD Jarhead trailer to 1024*432 in virtualdub with lanczos3 resize then compressing it with FFdshows huffyuv encoder in yv12 mode, so that might reproduce the error.

[edit]

heres the matrix I used aswell.
INTRA4X4_LUMA =
12, 16, 23, 30,
16, 25, 34, 40,
23, 34, 46, 60,
30, 40, 60, 84

INTRA4X4_CHROMAU =
16, 22, 36, 46,
22, 38, 56, 67,
36, 56, 77, 102,
46, 67, 102, 166

INTRA4X4_CHROMAV =
16, 22, 36, 46,
22, 38, 56, 67,
36, 56, 77, 102,
46, 67, 102, 166

INTER4X4_LUMA =
12, 15, 20, 24,
15, 22, 27, 32,
20, 27, 35, 42,
24, 32, 42, 55

INTER4X4_CHROMAU =
18, 22, 32, 38,
22, 36, 44, 56,
32, 44, 66, 78,
38, 56, 78, 100

INTER4X4_CHROMAV =
18, 22, 32, 38,
22, 36, 44, 56,
32, 44, 66, 78,
38, 56, 78, 100

INTRA8X8_LUMA =
12, 13, 16, 18, 23, 28, 29, 32,
13, 14, 18, 22, 26, 27, 29, 33,
16, 18, 23, 27, 28, 29, 32, 35,
18, 22, 27, 30, 32, 34, 38, 39,
23, 26, 28, 32, 37, 42, 45, 47,
28, 27, 29, 34, 42, 49, 55, 57,
29, 29, 32, 38, 45, 55, 63, 69,
32, 33, 35, 39, 47, 57, 69, 84

INTER8X8_LUMA =
12, 12, 14, 15, 16, 17, 18, 20,
12, 13, 16, 17, 18, 19, 21, 22,
14, 16, 18, 19, 20, 22, 24, 25,
15, 17, 19, 21, 24, 26, 27, 28,
16, 18, 20, 24, 28, 29, 30, 32,
17, 19, 22, 26, 29, 32, 35, 38,
18, 21, 24, 27, 30, 35, 42, 46,
20, 22, 25, 28, 32, 38, 46, 55

[bobololo]

The source was a ~600MB Huffyuv file that I deleted a while ago. I kept it for a while, but I didn't think this was going anywhere so I got rid of it a few days ago :(. I beleive I made the source by resizing Divx.com's HD Jarhead trailer to 1024*432 in virtualdub with lanczos3 resize then compressing it with FFdshows huffyuv encoder in yv12 mode, so that might reproduce the error.

Ok thanks for the info, we're trying to reproduce the defect here. If you happen to encounter that again we'd be very interested to get the conditions of your encode since you seemed to spot out a very nasty issue ;(

[*.mp4 guy]

I reproduced the error on my system using this trailer (http://trailers.divx.com/Universal/Jarhead_HD.zip).

I opened the trailer virtualdub 1.6.10, set virtualdub to full processing mode and set the following filters in virtualdub.

-lanczos3 resize to 1024*576
-lanczos3 resize to 1024*432, crop the top 61 pixels and bottum 62 pixels off.

I saved the file with ffdshow's huffyuv encoder in yv12 mode. Then I made an avisynth script named input to pipe the file to the beta2-3 encoder. Then I ran the same comandline as before and got the same error.

[hubereevez]

hi,

I could be totally wrong with these settings
encavc.exe -i "F:\encodage\mamie\mamie.avs" -o "F:\encodage\mamie\mamie.mp4" -qual extra -psy 3 -spmvp -enhchrp -rcmode 2pass -br 709000 -priority above -threads 2 -psnr -cpuext auto -setef ppred,bpred,wpred,cabac,deblock,part,subpart,hpel,qpel,xf8x8 -ref 5 -bref 3 -maxb 2 -deblock 0 -adaptdbk
but returns :
EAVC_initEncoder() failed with code -99
- Output file (F:\encodage\poup\poup.mp4) closed
when using -deblock -2
encoding runs. Is there any incompatibility with -adaptdbk ?

EDIT : sorry, already previously discussed.
Ok it's confirmed, for some obscur reasons, the adaptive deblocking support was disabled. We're on it.

[Sharktooth]

Uhm, i always used -2. let me test...

EDIT: -deblock and -adaptdbk used togheter make the encoder fail with error code -99

EAVC_initEncoder() failed with code -99
- Output file (c:\temp\test.mp4) closed

[bobololo]

I reproduced the error on my system using this trailer (http://trailers.divx.com/Universal/Jarhead_HD.zip).

I opened the trailer virtualdub 1.6.10, set virtualdub to full processing mode and set the following filters in virtualdub.

-lanczos3 resize to 1024*576
-lanczos3 resize to 1024*432, crop the top 61 pixels and bottum 62 pixels off.

I saved the file with ffdshow's huffyuv encoder in yv12 mode. Then I made an avisynth script named input to pipe the file to the beta2-3 encoder. Then I ran the same comandline as before and got the same error.

Thanks for the info, we have fixed the issue now !! It was due to a nasty overflow !

[bobololo]

Uhm, i always used -2. let me test...

EDIT: -deblock and -adaptdbk used togheter make the encoder fail with error code -99

EAVC_initEncoder() failed with code -99
- Output file (c:\temp\test.mp4) closed

This has been discussed already, check the previous posts.