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.