Ateme H.264 HP Beta Test : Bugs & Issues

[Sharktooth]

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

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

[JasonFly]

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

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

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

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

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

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

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

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

[Manao]

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

[dragongodz]

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

solution.

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

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

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

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

hope that helps. :)

[LigH]

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

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

[dragongodz]

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

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

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

[LigH]

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

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

[dragongodz]

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

[JasonFly]

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

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

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

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

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

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

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

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



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

I:\DVD\Ateme>encavc.exe -priority below -i "I:\DVD\Ateme\LoadRawSource-mobcal-10
80.avs" -o 576-mobcal-paff-ref8-4-bf3.mp4 -rcmode 2pass -br 4000000 -enhchrp -d
eblock 0 -setef paff -maxb 3 -ref 8 -bref 4
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com/)

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

Core encoder version 1.2.0.14


* Encoding summary

Input file : I:\DVD\Ateme\LoadRawSource-mobcal-1080.avs
Output file : 576-mobcal-paff-ref8-4-bf3.mp4
Resolution : 1920x1080 @ 25.00 fps
Length : 252 Frames
Quality : Best
Rate Control : 2pass
Target Bit Rate : 4000 kb/s
Init Quantiser : 24 [0 - 51]
Gop Size Min - Max : 1 - 300 (closed)
Process Priority : Below [1 thread(s)]


* Encoding Features

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

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

Encoding complete (time elapsed 00:10:01)


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

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

[*.mp4 guy]

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

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

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

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

[Manao]

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

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

[Andrey]

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

[*.mp4 guy]

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

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

[Manao]

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

[LigH]

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

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

[LigH]

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

[IgorC]

They are smashing the last misc. bugs :)

[Sharktooth]

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

[LigH]

Just another question about details:

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

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

[acidsex]

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

[Sirber]

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

[LigH]

@ acidsex:

Not that I knew...

[bobololo]

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

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

[LigH]

Dear bobo,

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

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

Fun and success!

[Sirber]

Hi

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

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

[bond]

with the new beta?

[Sharktooth]

OT: what NEW beta?

[Sirber]

beta 2 :(

[ChronoCross]

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

[Sirber]

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

[Sharktooth]

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

[Sirber]

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

[Sharktooth]

ok...

[bill_baroud]

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

[bond]

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

merged

[bobololo]

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

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

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

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

[LigH]

Update:

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

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

Default preset may be saved on exit, if desired.

[IgorC]

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

[LigH]

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

[JasonFly]

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

First log:

I:\DVD\Ateme>encavc.exe -priority below -i "I:\DVD\Tests\Samples\07\sample-lossl
ess.avs" -o DV-lossless.mp4 -lossless -psnr
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com/)

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

Core encoder version 1.2.0.17


* Encoding summary (lossless)

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


* Encoding Features

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

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

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


Second log:

I:\DVD\Ateme>encavc.exe -priority below -i "I:\DVD\Tests\Samples\02\02_cut.avs"
-o 02-lossless.mp4 -lossless -psnr
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com/)

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

Core encoder version 1.2.0.17


* Encoding summary (lossless)

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


* Encoding Features

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

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

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

[bobololo]

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

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

[Sharktooth]

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

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

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

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

[Sirber]

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

[kwtc]

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


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

[acidsex]

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

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

Thanks.

[Manao]

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

[LigH]

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

[IgorC]

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

Beta 1

C:\dvd1>encavc.exe -i p.avs -o beta1.mp4 -qual extra -rcmode 2pass -br 700000 -
mvrange +256 -psy 3 -deblock -2 -enhchrp -ref 5 -bref 3 -setef xf8x8 -cpb 122937
6 -maxb 3
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com/)

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

Core encoder version 1.2.0.14


* Encoding summary

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


* Encoding Features

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

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

Encoding complete (time elapsed 00:14:35)


Beta 2

C:\dvd1>encavc.exe -i p.avs -o beta2.mp4 -qual extra -rcmode 2pass -br 700000 -m
vrange +256 -psy 3 -deblock -2 -enhchrp -ref 5 -bref 3 -setef xf8x8 -cpb 1229376
-maxb 3
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com/)

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

Core encoder version 1.2.0.17


* Encoding summary

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


* Encoding Features

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

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

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

Now new line 'CPU Extension' appears

[JasonFly]

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

This works perfectly. I now have perfectly lossless outpout.

[AlexeyS]

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

[Sharktooth]

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

[Sigmatador]

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

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

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

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

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

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

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

Regards.

[Soulhunter]

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

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


Bye

[Sharktooth]

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

[Manao]

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

[Soulhunter]

@ Manao

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

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


Bye

[IgorC]

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

Paff,mbaff, inerlace
C:\DVDVolume>"C:\dvd1\encavc.exe" -i "C:\DVDVolume\catu.avs" -o "C:\DVDVolu
terlaced.mp4" -qual best -psy 3 -mvrange 256 -enhchrp -cpb 1048576 -par 10:
cmode 2pass -br 1000000 -psnr -setef deblock,interlaced,paff,mbaff -ref 3 -
3 -maxb 3 -deblock -2 -adaptdbk
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com/)

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

Core encoder version 1.2.0.17


* Encoding summary

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


* Encoding Features

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

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

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


Interlace +mbaff
C:\DVDVolume>"C:\dvd1\encavc.exe" -i "C:\DVDVolume\catu.avs" -o "C:\DVDVolume\i
terlacedM.mp4" -qual best -psy 3 -mvrange 256 -enhchrp -cpb 1048576 -par 10:11
rcmode 2pass -br 1000000 -psnr -setef deblock,interlaced,mbaff -ref 3 -bref 3 -
axb 3 -deblock -2 -adaptdbk -priority idle
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com/)

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

Core encoder version 1.2.0.17


* Encoding summary

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


* Encoding Features

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

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

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

Inerlace only

C:\DVDVolume>"C:\dvd1\encavc.exe" -i "C:\DVDVolume\catu.avs" -o "C:\DVDVolume\in
terlaced.mp4" -qual best -psy 3 -mvrange 256 -enhchrp -cpb 1048576 -par 10:11 -r
cmode 2pass -br 1000000 -psnr -setef deblock,interlaced -ref 3 -bref 3 -maxb 3 -
deblock -2 -adaptdbk -priority idle
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com/)

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

Core encoder version 1.2.0.17


* Encoding summary

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


* Encoding Features

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

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

[Andrey]

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

[kwtc]

About playing interlaced content.

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

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


Very badly may be translated by jumping image.

[LigH]

Still undocumented are these encoding tools:

- subpart
- pcm

And may there be even some more yet undocumented options?

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

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

[Manao]

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

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

[LigH]

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

[IgorC]

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

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

[Manao]

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

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

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

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

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

[LigH]

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

Okay - thank you for resolving this.

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

[IgorC]

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

[kwtc]

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


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

[kwtc]

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

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

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

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

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

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

[bobololo]

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

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

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

[bobololo]

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

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

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

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

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

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

[Sharktooth]

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

[IgorC]

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

[Manao]

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

[IgorC]

C:\DVDVolume>"C:\dvd1\encavc.exe" -i "C:\DVDVolume\catu.avs" -o "C:\DVDVolume\PA
FF.mp4" -qual best -psy 2 -mvrange 256 -enhchrp -cpb 1048576 -par 10:11 -rcmode
2pass -br 1000000 -psnr -setef deblock,interlaced,paff -ref 1 -bref 1 -maxb 3 -d
eblock -2 -adaptdbk -priority idle
ENCAVC - Copyright (c) 2004 ATEME (http://www.ateme.com/)

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

Core encoder version 1.2.0.17


* Encoding summary

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


* Encoding Features

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

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

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



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

[LigH]

Update:

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

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

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

[IgorC]

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

[LigH]

The video is a small version of this Terragen script:

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

[Manao]

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

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

[LigH]

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

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

[Manao]

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

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

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

[Latexxx]

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

[LigH]

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

[JasonFly]

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

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

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

Here is the report:

Core encoder version 1.2.0.17


* Encoding summary

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


* Encoding Features

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

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

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

[Sharktooth]

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

[calinb]

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

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

[Soulhunter]

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

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


Bye

[IgorC]

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

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

[skal]

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

-Skal

[IgorC]

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

[skal]

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

-Skal

[IgorC]

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

[Sharktooth]

plays back ok here too.

[calinb]

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

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

[vidhead]

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

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

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

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

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

[LigH]

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

But anyway:

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

[kwtc]

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


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

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

[dragongodz]

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

[bond]

bobololo is on holiday atm

[Soulhunter]

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


Bye

[Soulhunter]

Ohw, just noticed the reply from bond !!!

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


Bye

[LiFe]

Looks like things are wrapping up?

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

: )

[LigH]

...

...

...

Hmm, must be finished now.

[acidsex]

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

[LigH]

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

[bobololo]

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

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

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

[LigH]

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

[dvd_maniac]

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

[Manao]

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

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

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

[dvd_maniac]

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

[IgorC]

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

[dimzon]

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

[acidsex]

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

[Kostarum Rex Persia]

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

[Bulletproof]

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

[Doom9]

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

[IgorC]

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

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

[neuron2]

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

[Manao]

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

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

[bond]

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

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

[Kostarum Rex Persia]

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

[bond]

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

[Manao]

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

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

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

[neuron2]

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

[bond]

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

[guada 2]

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

Interesting :)
Who knows......

[Manao]

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

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

[bobololo]

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

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

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

[Kostarum Rex Persia]

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

[neuron2]

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

[ChronoCross]

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

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

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

[JohnV]

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

[bond]

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

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

[Sharktooth]

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

[Bulletproof]

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

[bobololo]

Dear testers,

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

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

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

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

Anyway enough words, here is the changelog:


* decoder filter
- significant performance improvement

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

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


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

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

[IgorC]

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

[acidsex]

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

[Bulletproof]

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

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

[acidsex]

contact bobololo. He can help ya out :)

[ChronoCross]

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

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

ENCAVC - Copyright (c) 2004-2005 ATEME (http://www.ateme.com/)

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

Core encoder version 1.4.0.3

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

[acidsex]

I can confirm that adaptdbk does indeed crash.

[acidsex]

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

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

[acidsex]

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

edit: uploading to Rapidshare now.

[acidsex]

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

Check it out and see what I mean.

[ChronoCross]

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

[superdump]

Eeep. -adaptdbk gives me an error here too.

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

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

However, lossless works fine for me.

[superdump]

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

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

[molitar]

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

Situation:

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

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

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

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

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

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

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

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

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

[Manao]

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

[molitar]

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

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

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

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

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

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

[Manao]

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

[molitar]

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

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

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

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

[bill_baroud]

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

[bobololo]

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

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

[bobololo]

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

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

[Sharktooth]

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

[Manao]

No, it isn't. What weird results ?

[Sharktooth]

Jumps in CPU2 utilization...

[bobololo]

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

Yes the decoder uses slight smp optimisations.

[Sharktooth]

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

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

[Manao]

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

[Sirber]

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

[Sharktooth]

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

[Eretria-chan]

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

[Manao]

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

[Sharktooth]

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

[ChronoCross]

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

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

[calinb]

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

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

[Selur]

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

[LigH]

Oops, did I almost miss something?

Obviously, the notification went to the SPAM folder... ortunately, I was able to reconstruct the download URLs and found my password.

Okay, a new round is open. Expect a new GUI soon.

[acidsex]

sweet. LigH definitely had an awesome GUI and look forward to the new one.

[LigH]

Atemaker Test 2 Beta 3 (http://www.ligh.de/software/Atemaker_b3.zip)

Please try if it works for you; there were not many changes in the dependeny logic, but as usual, I might have missed a mistake.

[*.mp4 guy]

In the time between beta 2 and beta 3 I must have lost/thrown away the letter that was sent to me with my password, would it be possible for you to send me a replacement? I would like to help out in this round aswell, but that would be difficult without the latest beta :o.

[Sharktooth]

@*.mp4 guy: PM bobololo and ask him :)

[acidsex]

ENCAVC - Copyright (c) 2004-2005 ATEME (http://www.ateme.com/)

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

Core encoder version 1.4.0.3

EAVC_initEncoder() failed with code -99
- Output file (C:\encavc-beta2-3\test.mp4) closed

C:\encavc-beta2-3>C:\encavc-beta2-3\encavc.exe -i C:\DETROIT_ROCK_CI\VIDEO_TS\dr
c.avs -o C:\encavc-beta2-3\test.mp4 -qual best -psy 2 -mvrange 64 -par 40:33 -rc
mode cbr -br 1000000 -mingop 1 -maxgop 300 -setef ppred,bpred,wpred,cabac,debloc
k,part,subpart,hpel,qpel,xf8x8 -ref 1 -bref 1 -maxb 2 -deblock -2 -adaptdbk
ENCAVC - Copyright (c) 2004-2005 ATEME (http://www.ateme.com/)

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

Core encoder version 1.4.0.3

EAVC_initEncoder() failed with code -99
- Output file (C:\encavc-beta2-3\test.mp4) closed

C:\encavc-beta2-3>





I try running an encode using Ligh's front end and this is the error I get.

[acidsex]

Ok, its not Ligh's front end as I get the same error doing it manually with a completely seprate file.

C:\encavc-beta2-3>encavc.exe -i test.avs -o clip.mp4 -qual best -rcmode 2pass -b
r 1000000 -adaptdbk
ENCAVC - Copyright (c) 2004-2005 ATEME (http://www.ateme.com/)

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

Core encoder version 1.4.0.3

EAVC_initEncoder() failed with code -99
- Output file (clip.mp4) closed

[ChronoCross]

Ok, its not Ligh's front end as I get the same error doing it manually with a completely seprate file.

C:\encavc-beta2-3>encavc.exe -i test.avs -o clip.mp4 -qual best -rcmode 2pass -b
r 1000000 -adaptdbk
ENCAVC - Copyright (c) 2004-2005 ATEME (http://www.ateme.com/)

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

Core encoder version 1.4.0.3

EAVC_initEncoder() failed with code -99
- Output file (clip.mp4) closed

Acidsex

I reported the problem with adaptdbk about 4 days ago. bobololo confirmed the error already

[acidsex]

swet. Im a moron because I remember I didnt use that option on my initial test codes because I saw the report but forgot about it. Life is well on this end now. Thanks.

[*.mp4 guy]

I get an error with these settings:
D:\encavc-beta2-3\encavc.exe -i D:\input.avs -o D:\clip.mp4 -br 799000 -deblock -3 -ref 16 -bref 16 -mingop 48 -maxgop 240 -qual Best -mvrange 512 -enhchrp -rcmode 2pass -maxb 3 -csm D:\encavc-beta2-2\mp4_guy's_AVC_Low_Bitrate_matrix.txt -setef ipred,ppred,bpred,wpred,cabac,deblock,part,hpel,qpel,xf8x8,csm
Using ffdshow build ffdshow-20051103, 1:46 into the file the error apears as garbage blocks, with the Ateme beta 2-3 decoder and parser media player classic crashes and disapears at about the same time.

The source I encoded from was an avs script decoding a 1024*432 Huffyuv file without any processing, I've encoded the source file many times and I know its not what is at fault.

Heres the file ( http://rapidshare.de/files/9761401/clip.mp4.html)

[calinb]

I suspect this is an MPC bug and I'm not sure Ateme is even interested in mkv, but I'd like to bring it to the Ateme develpers attention, regardless:

http://forum.doom9.org/showthread.php?p=760603#post760603

[bobololo]

Ok I got the file and confirm that something is going wrong. Could you please upload the source ?

I get an error with these settings:
D:\encavc-beta2-3\encavc.exe -i D:\input.avs -o D:\clip.mp4 -br 799000 -deblock -3 -ref 16 -bref 16 -mingop 48 -maxgop 240 -qual Best -mvrange 512 -enhchrp -rcmode 2pass -maxb 3 -csm D:\encavc-beta2-2\mp4_guy's_AVC_Low_Bitrate_matrix.txt -setef ipred,ppred,bpred,wpred,cabac,deblock,part,hpel,qpel,xf8x8,csm
Using ffdshow build ffdshow-20051103, 1:46 into the file the error apears as garbage blocks, with the Ateme beta 2-3 decoder and parser media player classic crashes and disapears at about the same time.

The source I encoded from was an avs script decoding a 1024*432 Huffyuv file without any processing, I've encoded the source file many times and I know its not what is at fault.

Heres the file ( http://rapidshare.de/files/9761401/clip.mp4.html)

[*.mp4 guy]

The source was a ~600MB Huffyuv file that I deleted a while ago. I kept it for a while, but I didn't think this was going anywhere so I got rid of it a few days ago :(. I beleive I made the source by resizing Divx.com's HD Jarhead trailer to 1024*432 in virtualdub with lanczos3 resize then compressing it with FFdshows huffyuv encoder in yv12 mode, so that might reproduce the error.

[edit]

heres the matrix I used aswell.
INTRA4X4_LUMA =
12, 16, 23, 30,
16, 25, 34, 40,
23, 34, 46, 60,
30, 40, 60, 84

INTRA4X4_CHROMAU =
16, 22, 36, 46,
22, 38, 56, 67,
36, 56, 77, 102,
46, 67, 102, 166

INTRA4X4_CHROMAV =
16, 22, 36, 46,
22, 38, 56, 67,
36, 56, 77, 102,
46, 67, 102, 166

INTER4X4_LUMA =
12, 15, 20, 24,
15, 22, 27, 32,
20, 27, 35, 42,
24, 32, 42, 55

INTER4X4_CHROMAU =
18, 22, 32, 38,
22, 36, 44, 56,
32, 44, 66, 78,
38, 56, 78, 100

INTER4X4_CHROMAV =
18, 22, 32, 38,
22, 36, 44, 56,
32, 44, 66, 78,
38, 56, 78, 100

INTRA8X8_LUMA =
12, 13, 16, 18, 23, 28, 29, 32,
13, 14, 18, 22, 26, 27, 29, 33,
16, 18, 23, 27, 28, 29, 32, 35,
18, 22, 27, 30, 32, 34, 38, 39,
23, 26, 28, 32, 37, 42, 45, 47,
28, 27, 29, 34, 42, 49, 55, 57,
29, 29, 32, 38, 45, 55, 63, 69,
32, 33, 35, 39, 47, 57, 69, 84

INTER8X8_LUMA =
12, 12, 14, 15, 16, 17, 18, 20,
12, 13, 16, 17, 18, 19, 21, 22,
14, 16, 18, 19, 20, 22, 24, 25,
15, 17, 19, 21, 24, 26, 27, 28,
16, 18, 20, 24, 28, 29, 30, 32,
17, 19, 22, 26, 29, 32, 35, 38,
18, 21, 24, 27, 30, 35, 42, 46,
20, 22, 25, 28, 32, 38, 46, 55

[bobololo]

The source was a ~600MB Huffyuv file that I deleted a while ago. I kept it for a while, but I didn't think this was going anywhere so I got rid of it a few days ago :(. I beleive I made the source by resizing Divx.com's HD Jarhead trailer to 1024*432 in virtualdub with lanczos3 resize then compressing it with FFdshows huffyuv encoder in yv12 mode, so that might reproduce the error.

Ok thanks for the info, we're trying to reproduce the defect here. If you happen to encounter that again we'd be very interested to get the conditions of your encode since you seemed to spot out a very nasty issue ;(

[*.mp4 guy]

I reproduced the error on my system using this trailer (http://trailers.divx.com/Universal/Jarhead_HD.zip).

I opened the trailer virtualdub 1.6.10, set virtualdub to full processing mode and set the following filters in virtualdub.

-lanczos3 resize to 1024*576
-lanczos3 resize to 1024*432, crop the top 61 pixels and bottum 62 pixels off.

I saved the file with ffdshow's huffyuv encoder in yv12 mode. Then I made an avisynth script named input to pipe the file to the beta2-3 encoder. Then I ran the same comandline as before and got the same error.

[hubereevez]

hi,

I could be totally wrong with these settings
encavc.exe -i "F:\encodage\mamie\mamie.avs" -o "F:\encodage\mamie\mamie.mp4" -qual extra -psy 3 -spmvp -enhchrp -rcmode 2pass -br 709000 -priority above -threads 2 -psnr -cpuext auto -setef ppred,bpred,wpred,cabac,deblock,part,subpart,hpel,qpel,xf8x8 -ref 5 -bref 3 -maxb 2 -deblock 0 -adaptdbk
but returns :
EAVC_initEncoder() failed with code -99
- Output file (F:\encodage\poup\poup.mp4) closed
when using -deblock -2
encoding runs. Is there any incompatibility with -adaptdbk ?

EDIT : sorry, already previously discussed.
Ok it's confirmed, for some obscur reasons, the adaptive deblocking support was disabled. We're on it.

[Sharktooth]

Uhm, i always used -2. let me test...

EDIT: -deblock and -adaptdbk used togheter make the encoder fail with error code -99

EAVC_initEncoder() failed with code -99
- Output file (c:\temp\test.mp4) closed

[bobololo]

I reproduced the error on my system using this trailer (http://trailers.divx.com/Universal/Jarhead_HD.zip).

I opened the trailer virtualdub 1.6.10, set virtualdub to full processing mode and set the following filters in virtualdub.

-lanczos3 resize to 1024*576
-lanczos3 resize to 1024*432, crop the top 61 pixels and bottum 62 pixels off.

I saved the file with ffdshow's huffyuv encoder in yv12 mode. Then I made an avisynth script named input to pipe the file to the beta2-3 encoder. Then I ran the same comandline as before and got the same error.

Thanks for the info, we have fixed the issue now !! It was due to a nasty overflow !

[bobololo]

Uhm, i always used -2. let me test...

EDIT: -deblock and -adaptdbk used togheter make the encoder fail with error code -99

EAVC_initEncoder() failed with code -99
- Output file (c:\temp\test.mp4) closed

This has been discussed already, check the previous posts.