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

[Sagittaire]

Have you unistalled previous filters and installed the new ones?

No ... lol

I found the problem ... :devil:

[IgorC]

I have seen some pictures of beta 3 and beta 4. Beta 4 provides more details. I also noticed that there are LESS blocks with homogeneous textures . And that’s good I can see balance between sharp-smooth. The price of sharp is some blocks. But those blocks are very , VERY hard to notice. This one is the best.
Have a look
Beta 4 - http://rbf.nm.ru/Nero_b4_extra_400_2.jpg
Beta 3 - http://rbf.nm.ru/Nero_400_2.jpg

Beta 4 - http://rbf.nm.ru/Nero_b4_extra_400_4.jpg
Beta 3 - http://rbf.nm.ru/Nero_400_4.jpg

I have no codec, i found it in one of the forums

[Andrey]

>>560x336
>>encavc.exe -i sword.avs -o h264.mp4 -qual extra -rcmode 2pass -br
1002000 -psy 2 -maxb 3 -par 64:45 -ref 5 -adaptdeblock -deblock -2 -
setef wpred
Just created Swordfish encode with this params.
1. Just the same runtime error after encoding ends. I think, it might be avisync, not encavc error, because vdub get this error too when using avs source.
2. Is par correct now ? Anyway, mpc plays this file not as widescreen.
3. BSPlayer plays the file not centered when playing fullscreen.
4. Bitrate at the end of the file was 6.8Mbit/s. The difference with previous version is that it is not dropped at the end of the file.

[bobololo]

We've been warned about a crash problem with beta 4 that could occur at low bitrate. We're working on it. A hotfix will be posted soon !

[Manao]

Andrey : could you post your avisynth script ? We could then know whether it is avisynth or encavc which causes the crash.

[ziw0d0]

@bobololo
Whether it is possible to receive filters (adf_srcmp4.ax, adf_dech264.ax) And to participate in testing as the independent observer?

[IgorC]

Just personal message. I understand that it´s closed beta testing. So somebody noticed something like feedback on the one Russian forum. But there is no reason for rumors .
I respect conditions of closed beta testing. The only way to have beta was communicate to Bobololo .
So can anybody post some *. mp4 of new beta 4. (bitrate 300-400-700-1000-1500-2000 kbit/s)

[bobololo]

Originally posted by IgorC
Just personal message. I understand that it´s closed beta testing. So somebody noticed something like feedback on the one Russian forum. But there is no reason for rumors .
I respect conditions of closed beta testing. The only way to have beta was communicate to Bobololo .
So can anybody post some *. mp4 of new beta 4. (bitrate 300-400-700-1000-1500-2000 kbit/s)

I'm not sure to follow you, but the beta was not so closed. It was opened to anyone who registered *in time*.

And by the way, I take advantage of this post to announce once again that we don't need more testers now and therefore it is useless to send me PM requesting to join. Your interest is really appreciate but we are definitely not able to handle more testers. I know that some of you can't wait to play with this new codec. Please be patient we're closer and closer from the public release :)

[bobololo]

Hi there,

I just sent out beta 4a which is a hotfix for the crash some of you reported. The changelog is :

- Fix a crash when encoding at low bitrate (encavc.exe)
- RC adjust preventing some rare oversizes (encavc.exe)

[pogo stick]

Oh, my god! I didn't think that H.264 things will start moving so fast! Screenshots and feedback are very promising and impressing! :)
But I am missing all the fun. :(
So I have few "out of curiosity" questions:
Will interlaced encoding and decoding be supported in future? I think some people (including me, after I tried interlaced XviD) will be missing it.
What about editing tools for H.264/MP4 files? Are there any plans for it? It seems like this codec will be very popular and such tool will be necessary.
And I båg and entreat for mercy to those who is responsible for DShow filters in Ahead products to make filters more user-friendly. Audio and video codecs may be great, but if DS parser and muxer will cause headache it will be very very sad. And why should Nero DS filters not work with not-Nero filters? For me it's very strange.
I don't know if this thread is the right place to beg someone :), but I hope that I will be heard.
Did you noticed that I am not asking about becoming tester or asking about Planning release date?:D
Wish you success and good luck!

[IgorC]

Talking about final version of Ateme H.264 and coming until end of 2004 VP7. I think On2¨s team will investigate Ateme H.264 codec for provide better quality , so probably Ateme codec will lose popularity without be popular.
Or Ateme will present new version in the time.

[CruNcher]

was -cartoon deactivated in beta4a for normal mode, because it didn't worked and Speed droped by 5 fps ?

[JohnV]

Originally posted by IgorC
Talking about final version of Ateme H.264 and coming until end of 2004 VP7. I think On2¨s team will investigate Ateme H.264 codec for provide better quality , so probably Ateme codec will lose popularity without be popular.
Or Ateme will present new version in the time.
I don't quite understand what you are trying to say but here's few facts:
On2/VP6 has had a big set back in China: http://www.digitimes.com/news/a20040917A2003.html

H.264 has lots of industry support already compared to VP6: http://sivut.koti.soon.fi/julaak/AVC_Alliance_1.jpg

The AVC alliance includes ADB, Apple, Ateme, Broadcom, Dolby, Envivio, Fraunhofer-HHI, Fujitsu, Harmonic, Hitachi, Hewlett-Packard, JVC, LSI Logic, Mitsubishi, Moonlight, Motorola, Nokia, Packet Video, Panasonic, Philips, Polycon, Samsung, Sentivision, Sharp, Sony, ST Micro, Tandberg, Texas instruments and Thomson Broadcast, and more are joining all the time.
AVC is also part of the HD-DVD and Blue-Ray standards.

I have very much trouble believing that VP6/7 can become really popular unless VP7 is truely an unbelievable codec, otherwise it will be tough times for On2 I fear...

Btw. Here's Ateme's h.264 decoder board decoding on TI 600Mhz DSP real time h.264:
http://sivut.koti.soon.fi/julaak/AVC_Alliance_3.jpg

[RBF]

I have encoded with Ateme interlaced clip consisting of white and red fields.
Ateme encoder has correctly coded both fields not mixing them. Ateme and Nero decoders correctly without mixing colors have decoded interlaced clip.
Whether it is necessary to enter additional adjustment interlaced/not interlaced source, when now all is correctly encoded?

[Manao]

RBF :If you were encoding it with interlaced support, the filesize would be lower ( theorically ) at same PSNR. However, I don't think encavc already support interlacing as the H264 norm implements it, so no need to test it yet.

[Mr_Schizo]

heya bobo,

i encountered the green blocks again :( .This time in another part of Underworld where it wasn't present before. I encoded it also without wpred which results in a fine/bugfree encode. So i guess it's an bug in wpred(well, we already guessed that and it should be a bit more validated now). I have seen it only at longer encodes so far with beta4 and also beta4a. I'll do another whole movie encode tomorrow (Matrix) to see if it also happens there.

I've prepared a little bugreport package which contains the b0rked clip and some notes about the used settings.
I've uploaded it to your incoming ftp (it's the "greenblocks" one).

[bobololo]

Originally posted by Mr_Schizo
heya bobo,

i encountered the green blocks again :( .This time in another part of Underworld where it wasn't present before. I encoded it also without wpred which results in a fine/bugfree encode. So i guess it's an bug in wpred(well, we already guessed that and it should be a bit more validated now). I have seen it only at longer encodes so far with beta4 and also beta4a. I'll do another whole movie encode tomorrow (Matrix) to see if it also happens there.

I've prepared a little bugreport package which contains the b0rked clip and some notes about the used settings.
I've uploaded it to your incoming ftp (it's the "greenblocks" one).

Thanks for reporting back this issue. We've checked and it appears the defect comes from the decoder. We're currently working on the fix and the new filters will be released soon.

[bobololo]

Originally posted by RBF
I have encoded with Ateme interlaced clip consisting of white and red fields.
Ateme encoder has correctly coded both fields not mixing them. Ateme and Nero decoders correctly without mixing colors have decoded interlaced clip.
Whether it is necessary to enter additional adjustment interlaced/not interlaced source, when now all is correctly encoded?

Currently the encoder doesn't support interlaced encoding. So whatever you send to the encoder, it considers the input as progressive material.

[keel]

Bobololo...any chance that the encoder or decoder for your codec will work under System X on the Mac in the future? I realize most users here have PCs, but there's also a lot of video production taking place on Macs, which is what we use. Don't mean to start a platform war (I've seen and been in enough, and had enough!), I use both, and am learning linux.

Thanks,
Frank

[plonk420]

Originally posted by keel
Bobololo...any chance that the encoder or decoder for your codec will work under System X on the Mac in the future? I realize most users here have PCs, but there's also a lot of video production taking place on Macs, which is what we use. Don't mean to start a platform war (I've seen and been in enough, and had enough!), I use both, and am learning linux.

Thanks,
Frank

i doubt there's much of a chance. there's just not enough money to be made, and all the "big houses" only trust big name brands like Avid, Apple, Cleaner (gag)...

it's a pitty because i've been strugling getting webvideo even remotely as high quality as even WMV9. and Discrete wants $200-300 for a 2pass version of their underwhelmingly mediocre (or worse) Sorenson 3 codec. you'd think the thousands the place i'm interning at is shelling out for Avid systems, Avid would at LEAST have the courtesy to send Sorenson 3 Pro...

i'd LIKE to try the new apple codec that was shipped with Panther, but i don't think they're going to shell out money for a new OS just for a codec...

i could have SWORN Apple Quicktime or Compressor had 2-pass mpeg-4 ASP, but i may just be confusing it with mpeg-2

either way, i haven't been able to get HQ streaming video macside :( stupid macs >_>

[Bulletproof]

Will the B-frames cap at 3 be removed eventually or is 3 the most efficient you can get? I also noticed there is no GMC (global motion compensation) option in the encoder, has this become obsolete?

[akupenguin]

GMC is not included in the H.264 spec. It never made a whole lot of difference in MPEG4 ASP, and I suppose it was made obsolete by MV prediction (replaces much of GMC's function) and multiple reference frames (would reduce GMC's efficiency).

I can't comment on Ateme's plans for B-frames.

[bobololo]

Originally posted by Bulletproof
Will the B-frames cap at 3 be removed eventually or is 3 the most efficient you can get? I also noticed there is no GMC (global motion compensation) option in the encoder, has this become obsolete?
Yes max 3 consecutive bframes is the optimal setting we've observed so far and we didn't have reports saying that having more involves much better results. Plus except the issue we have with bframes in the first beta, nobody really complained about them. Therefore we'll set the default to 3 and probably don't let the user to change this setting. Do you think we should let the users change this ?

Regarding the GMC, akupenguin provided a very good reply :)

[SeeMoreDigital]

Originally posted by Bulletproof
Will the B-frames cap at 3 be removed eventually or is 3 the most efficient you can get? I also noticed there is no GMC (global motion compensation) option in the encoder, has this become obsolete? Has anybody read bonds AVC Information (http://forum.doom9.org/showthread.php?s=&threadid=73022#post461589) recently. Aside from it being a useful read, are there any points that require revising?

There's also a useful, "Mpeg2, Mpeg4 ASP & Mpeg4 AVC Comp Table" that might also require updating: -

http://img55.exs.cx/img55/293/h264_features_matrix.gif


Cheers

[Bulletproof]

Originally posted by bobololo
Yes max 3 consecutive bframes is the optimal setting we've observed so far and we didn't have reports saying that having more involves much better results. Plus except the issue we have with bframes in the first beta, nobody really complained about them. Therefore we'll set the default to 3 and probably don't let the user to change this setting. Do you think we should let the users change this ?

Regarding the GMC, akupenguin provided a very good reply :)

I actually thought 3 was coded to be the max in the beta encoder because in the encavc.txt file it says [1 ; 3] but I just realized the encoder allows above 3 if you specify :eek: . Alot of people probably assumed the same thing and only tested with 3 b-frames which is why we probably haven't heard much about it. I will test some more B-frames and get back to you.

[akupenguin]

Originally posted by SeeMoreDigital
There's also a useful, "Mpeg2, Mpeg4 ASP & Mpeg4 AVC Comp Table" that might also require updatingSuggestions:
Either remove Rate/Distortion Optimization from the comparison, or add a check in the MPEG-2 and ASP columns: As stated in the AVC thread, RDO is really a function of the encoder, not the format. And while this feature was introduced by the H.264 reference codec, it is now available at least in libavcodec and XviD, so that includes MPEG-4 ASP and MPEG-2.
MPEG-4 ASP also allows 8x8 block size (a.k.a. 4MV).

[Bulletproof]

Ok it does seem 3 b-frames is the most efficient you can get, after 3 the quality just degrades.

In that chart it says that the standard allows 4x4 blocksize, was this implemented into the encoder? The encavc.txt file says the part option goes down to 8x8.

[bobololo]

Originally posted by Bulletproof
Ok it does seem 3 b-frames is the most efficient you can get, after 3 the quality just degrades.

In that chart it says that the standard allows 4x4 blocksize, was this implemented into the encoder? The encavc.txt file says the part option goes down to 8x8.
Yes it is implemented in the encoder but we haven't find a efficient way to exploit them. 4x4 sub partitions give too small gains compared to the extra computation they require. They've consequently been disabled.

[IgorC]

Seems to be good news http://www.dvd-software.info/blog/archives/industry_news/

[Bulletproof]

How is the custom deblocker activated, im using v1.0.1.28 of the encoder and trying: encavc.exe -i test.avs -o test.mp4 -customdeblock deblock.txt but the encoder doesn't say anything about using it and it still says and looks -2 for deblocking strength.

[bobololo]

Originally posted by Bulletproof
How is the custom deblocker activated, im using v1.0.1.28 of the encoder and trying: encavc.exe -i test.avs -o test.mp4 -customdeblock deblock.txt but the encoder doesn't say anything about using it and it still says and looks -2 for deblocking strength.

Even the application doesn't display anything to tell you're using custom deblocking, it is actually using it if you specify a custom file with the -customdeblock flag.

[Bulletproof]

I did a test by changing all the values in the deblock.txt to 6 and enabling the customdeblock option and I encoded another file but this time I just specified -deblock 6 to it. The files do not look identical however.

[bobololo]

Dear Testers,

And here comes the end of the beta test ! Since we didn't find any critical issues nor received alarming reports lately, we can consider that the encoder, with our latest bugfixes and sligh improvments, is now stable enough to be released.

This beta test was very successful and of course we would like to thank you so much for the very good feedback you all testers provided to us. They were very valuable for the improvements of the encoder. And we hope you'll appreciate the level it has reached thanks to your help.

Beside, to show our gratefulness to your contributions, we'll try to reward all involved testers. So keep an eye to your mailbox you'll receive further instructions soon.

Now watch out for the final public release and be prepared for the next beta round of the next major version of the encoder (which could maybe come soon, who knows ? ;)).

-- bobololo.

[LostMP4]

Originally posted by bobololo

Beside, to show our gratefulness to your contributions, we'll try to reward all involved testers. So keep an eye to your mailbox you'll receive further instructions soon.

Now watch out for the final public release and be prepared for the next beta round of the next major version of the encoder (which could maybe come soon, who knows ? ;)).

-- bobololo.

I sign for the next beta :D
(and wait for the bobololo's poster as reward :p)