Log in

View Full Version : Ateme H.264 Beta - Bug, Issues and Getting Started


Pages : 1 2 3 4 5 6 7 [8] 9

ac-chan123
9th September 2004, 14:54
http://bs.hhi.de/~wiegand/JVT.html
There is the final draft.

superdump
9th September 2004, 15:41
Originally posted by LigH
You might be interested in calculating the "bits per pixel and frame" value, as GordianKnot is calculating, for example. For DivX 5 or XviD-H.263, we usually recommend 0.25-0.30 bppf; for XviD-MPEG, we recommend 0.30-0.35 bppf. I wonder which minimum you would recommend for Ateme H.264?!Whaaaat?! I would say anything in the 0.15-0.20 range is good for most things. Maybe my aims are somewhat different to yours. I'm a 1CD kinda guy if possible, but any outputs I get certainly don't look bad. Looks like you're more interested in 1/3 of a DVD or 2 CDs. Still, 0.25 as a minimum is not right in my opinion. 0.15 maybe.

thegeby
9th September 2004, 15:47
You might be interested in calculating the "bits per pixel and frame" value, as GordianKnot is calculating, for example. For DivX 5 or XviD-H.263, we usually recommend 0.25-0.30 bppf; for XviD-MPEG, we recommend 0.30-0.35 bppf. I wonder which minimum you would recommend for Ateme H.264?!

Such a comparison would not be very useful between codecs. The whole point of a "more efficient" codec is to achieve a lower b/pf than the competition at the same quality. It could be useful, however in discussing quality settings within a codec, i.e. "at what level is individual x happy?"

bobololo
9th September 2004, 17:24
Originally posted by ac-chan123
http://bs.hhi.de/~wiegand/JVT.html
There is the final draft.

I assume the final draft you're considering is JVT-G050 ? In such case, this draft doesn't include Fidelity Range Extension.

Ok now that the server is back, here is the link to the FRExt latest draft :

ftp://ftp.imtc-files.org/jvt-experts/2004_07_Redmond/JVT-L047d9.zip

edit: Huhu my first posted url was wrong ;)

Andrey
9th September 2004, 19:00
First of all - conglaturations, beta 3 filters now allow me to save screenshot in mpc easily. Bingo, thanks :)
Still, they do not show right AR. I definded it as 235:100 - should it work ? Or I need to reencode ?
BTW, I've managed to create Equilibrium encode very close to xvid one.
See two examples here:
http://sirgrey.nm.ru/XViD.png
http://sirgrey.nm.ru/h264.png

Tommy Carrot
9th September 2004, 19:00
Originally posted by bobololo
I assume the final draft you're considering is JVT-G050 ? In such case, this draft doesn't include Fidelity Range Extension.

Ok now that the server is back, here is the link to the FRExt latest draft :

ftp://ftp.imtc-files.org/jvt-experts/2004_07_Redmond/JVT-L047d9.zip

edit: Huhu my first posted url was wrong ;)
Thanks again. :)

bobololo
9th September 2004, 19:15
Originally posted by Andrey
First of all - conglaturations, beta 3 filters now allow me to save screenshot in mpc easily. Bingo, thanks :)
Still, they do not show right AR. I definded it as 235:100 - should it work ? Or I need to reencode ?


The -par option allows you to set the pixel AR and not the display AR.

bill_baroud
9th September 2004, 19:50
hello, sorry to have still reported nothing but life catch me up (3 days searching for a new flat 800km from here etc ...) but i started to wrote a little gui to make my test easier ...
well it's not working atm, but if some guys are interested it looks like this atm
> http://moodub.free.fr/h264gui.gif

Andrey
9th September 2004, 20:28
The -par option allows you to set the pixel AR and not the display AR.
Oh. Ok :)
Always was confused with that pixel/picture AR difference...
Thanks for the info!

Soulhunter
9th September 2004, 23:21
Originally posted by Andrey

Always was confused with that pixel/picture AR difference...


Hint: Some nice info about this @ the homepage of SeeMoreDigital... ;)


Bye

LigH
10th September 2004, 08:56
Originally posted by thegeby
Such a comparison would not be very useful between codecs...
Is that the reason why attachments don't get released here? :rolleyes: (May I have to report that answer to have one released?)
__

Indeed, the personal range of acceptable quality would be very individual.

You might tell people: "At #.## bppf, most of my used material achieved a SSIM value better than ##". Would that be more objective?

Well - it was just an idea. Some people may like it, some find a drawback to criticize (BTW, that's fine for me).

plonk420
10th September 2004, 09:51
Originally posted by plonk420
yep, using DVD2AVI / MPEG2DEC3; however, it displays 100% correctly when i advance frame-by-frame in VDub. when i Save As AVI or run the AVS file thru the encoder, THAT is when it messes up... :(

oh my .. i've been overlooking DGMPEGDec all this time... :eek:

IgorC
11th September 2004, 03:03
If anyone have link fot Ateme Codec or ANY idea from where i can download it . Pliz send me email igoruso@msn.com

plonk420
11th September 2004, 07:33
Originally posted by IgorC
If anyone have link fot Ateme Codec or ANY idea from where i can download it . Pliz send me email igoruso@msn.com

sorry, you had to apply to betatest if you read the original post. that and there were only so many accepted (not sure how many or the criterea, if there was any). and if you're trying to finagle the encoder out of somebody, please don't. that's against some boards' rules, if not a warnable or even bannable offense.

based on your previous posts, i'd suggest reading FAQs/Stickies for whatever forum you're posting to. google [the technology] and FAQ (ie, rv10 faq ... or abx faq .. or lame faq). use the search command on webboards.

few people have the patience to research for you and email you what to do. webboards are there so that 1 post can be read by many in the same boat and if there's helpful replies, then you can kill multiple birds with one stone.

rules of thumb:
1. search
2. google
3. lurk and learn (see my post just above; i just now learned about DGDecode/DGIndex [previously DVD2AVI], and i hope i did so without annoying too many regulars or whoever found it to be such a stupid-seeming oversight)
4. don't act outside of webboard ettiquite: in this case, don't ask for betas unless it's the norm for the board (like a warez trading board, which this is obviously and definitely NOT). go back and read the Forum Rules: http://forum.doom9.org/forum-rules.htm

if you follow the rules, you'll be welcome at this awesome board; if not, well, you sure won't be posting here much longer...

CruNcher
11th September 2004, 14:32
Bobololo can you confirm that the Deadline now is 3 weeks ?
mentioned by Ahead on the IBC so with Nero 6.6 there will be AVC introduced in Recode 2 ?

aketon
12th September 2004, 08:02
Originally posted by CruNcher
Bobololo can you confirm that the Deadline now is 3 weeks ?
mentioned by Ahead on the IBC so with Nero 6.6 there will be AVC introduced in Recode 2 ?

Does anybody know how much this codec is going to cost???:)
I hope that ahead is not going to follow the Videosoftinc way! They sell their codec for 99$!!!:confused:

Latexxx
12th September 2004, 08:27
Originally posted by aketon
Does anybody know how much this codec is going to cost???:)
I hope that ahead is not going to follow the Videosoftinc way! They sell their codec for 99$!!!:confused:
I believe that this codec will be part of the Nero package which already includes mpeg 4 asp codec.

bobololo
12th September 2004, 22:14
Originally posted by CruNcher
Bobololo can you confirm that the Deadline now is 3 weeks ?
mentioned by Ahead on the IBC so with Nero 6.6 there will be AVC introduced in Recode 2 ?

I also heard about this but I can't really confirm, the release plan about AVC in Recode may evolve but not sure.

easyfab
13th September 2004, 18:52
bobololo,

Don't know if it is the right place but I have a question about avc and ateme. Not software but hardware question. I see on ateme pages that you have hardware solutions for avc decoding and encoding.
Will it give in (near) futur a standalone avc player? encoder ?

bobololo
14th September 2004, 08:18
Originally posted by easyfab
bobololo,

Don't know if it is the right place but I have a question about avc and ateme. Not software but hardware question. I see on ateme pages that you have hardware solutions for avc decoding and encoding.
Will it give in (near) futur a standalone avc player? encoder ?

We're offering a reference design of a platform that could address various products : ip set top box, dvd player, PVR, etc. Now it's up to OEM to adopt the reference design and to build a nice products based on it. Unfortunately this process is always very long. Btw while dealing with standalone players, accoding to some rumours ;) we may be able to see the first NeroDigital certified (MPEG-4 ASP) standalones by the end of the year.

thegeby
14th September 2004, 11:44
accoding to some rumours we may be able to see the first NeroDigital certified (MPEG-4 ASP) standalones by the end of the year

Well, considering that the required chip has been listed in the Sigma product line for several months now, the rumours might be true:scared:

LigH
14th September 2004, 13:40
Somewhere in my processing, there appears to be a 1 frame shift!
Used QuickTime 6.51 and QuickTime Alternative (mainly, its DirectShow filter) to get the video content of the Matrix trailers, e.g.

Matrix_Reloaded_Trailer_Ultra_MOV.avsDirectShowSource("trailer_final_1000_dl.mov",fps=24)
ConvertToYV12(interlaced=false)

Wrote its result into an AVI using a losslessly compressing codec (ffdshow's HuffYUV, YV12 variant, Median prediction)

Put this AVS into the encavc Encoder (beta 3) to get a Matrix_Reloaded_Trailer_Ultra.mp4 (bitrate: 1300 kbps, 0.100 bppf)

Used a similar script to get its content and save that into a losslessly compressed AVI (I had to use AVS2AVI; VirtualDubMod froze here!)

Matrix_Reloaded_Trailer_Ultra_MP4.avsDirectShowSource("Matrix_Reloaded_Trailer_Ultra.mp4",fps=24)
This worked well after setting Ateme's filters' merits a little above "normal".

Wanted to compare both lossless AVIs using this very complicated script:

MRel_Diff.avsmov = AviSource("Matrix_Reloaded_Trailer_Ultra_MOV_HFYU-YV12.avi")
mp4 = AviSource("Matrix_Reloaded_Trailer_Ultra_MP4_HFYU-YV12.avi")
comp = Compare(mov.ConvertToYUY2, mp4.ConvertToYUY2, "", "MRel_H264.log")
ssim = SSIM(mov, mp4, "MRel_H264.csv", "MRel_H264.txt", lumimask=true)
diff = Subtract(mov, mp4).Levels(96,1,160,0,255)
return comp.Overlay(ssim).Overlay(diff)
The last line is necessary to make AviSynth believe, all of the comparing results might be part of the returned video clip -- else AviSynth would optimize their calls out, and I would not get the log files.

The result was a difference clip which started to look like an "Emboss" effect.

Reason:

In the QuickTime movie, the green "rating" screen is shown up to frame 119, the tailer starts black with frame 120.

In the H.264 movie, the green "rating" screen is shown up to frame 118, the tailer starts black with frame 119.

The length of the videos was equal, though -- else the function "Compare" would have complained that the lengths were different.
__

P.S.: Saving a graph from GraphEdit's result rendering the *.mp4 file and deleting the final "Video Renderer", an AviSynth script using DirectShowSource to open this *.grf file opens well in VirtualDubMod without freezing...

Manao
14th September 2004, 13:58
LigH : I've got no shift at all when I make SSIM & PSNR measurements. However, I don't use the same protocol you're using.

* firstly, my source is either a vob/d2v ( opened through mpeg2source ) or an avi huffyuv ( opened through DirectShowSource )
* secondly, I use DirectShowSource with mp4, and I don't bother to save it to huffyuv ( which is a loss of time, imho ).
* finally, instead of using overlay ( which requires some processing ), I use Interleave, which doesn't ( hence I'm able to computes PSNR / SSIM for several codecs at the same time ).

My best guest here is an issue with DirectShowSource ( which doesn't support a lot of thing, especially not seeking ). Try to encode the huffyuv instead of the avs + directshowsource script

LigH
14th September 2004, 15:15
Originally posted by Manao
...
Try to encode the huffyuv instead of the avs + directshowsource script
Good point - I'll try that.
__

Besides that: A few results here, comparing Ateme's H.264 and Koepi's XviD 1.0.2 at the same bitrate (1300 kbps, 0.100 bppf):

C:\Programme\encavc\encavc -i "*.avs" -o "*.mp4" -qual best -rcmode 2pass -br 1300 -psy 2 -adaptdeblock -ref 5 -cartoon
SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 73.43
__

Comparing channel(s) YUV
Total frames processed: 3633

Minimum Average Maximum
Mean Absolute Deviation: 0.1142 1.2308 3.8867
Mean Deviation: -0.6448 -0.1523 +0.6153
PSNR: 32.7755 43.4412 56.9946
Overall PSNR: 41.7488
XviD 1st-pass: AS@L5, H.263, AQ, QP, GMC, 2 B-VOP *1.50 +1.00, COpt, MSP=6, VHQ=1, CM, max. 250 I, QF = 2-31/2-31/2-31, Trellis
XviD 2nd-pass: AS@L5, H.263, AQ, QP, GMC, 2 B-VOP *1.50 +1.00, COpt, MSP=6, VHQ=4, CM, max. 250 I, QF = 2-31/2-31/2-31, Trellis, BR=1300, OCS=0, Max OI=10, Max OD=10
SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 68.82
__

Comparing channel(s) YUV
Total frames processed: 3634

Minimum Average Maximum
Mean Absolute Deviation: 0.0000 1.3317 4.0590
Mean Deviation: -0.8221 -0.1164 +0.7197
PSNR: 32.5336 45.4346 108.4650
Overall PSNR: 41.0346

Teegedeck
14th September 2004, 15:33
BTW, does the -cartoon switch really do nothing else but activate chroma ME? No changed skip-block thresholds or anything?

Manao
14th September 2004, 15:33
The difference between average and overall is huge for XviD, because of some black frames I think ( a max PSNR of 108 means that the frame was perfectly reconstructed ).

You should trim those black frames before making any comparison, because they bias objective measurements.

Also, for XviD, while making objective measurements, AQ is not a good idea, because it lowers the PSNR at same filesize.

bobololo
14th September 2004, 15:54
Originally posted by Teegedeck
BTW, does the -cartoon switch really do nothing else but activate chroma ME? No changed skip-block thresholds or anything?

I'm not sure if in xvid the chroma motion mode only affects the ME, but in our case, enabling the cartoon mode includes the chroma components in the whole decision process (ME, prediction modes, etc.), not only the ME.

RBF
14th September 2004, 16:54
bobololo

Whether it is impossible to add fast first pass, just as XVID?

LostMP4
14th September 2004, 19:51
Originally posted by RBF
bobololo

Whether it is impossible to add fast first pass, just as XVID?

It is available since the first beta, but only for long clips (>10000 frames or something like that, search in this thread!)

LostMP4
14th September 2004, 20:33
Is the fourth beta on the way?

Bishep
15th September 2004, 06:28
bobololo,
I misunderstood one thing... :confused: Are sub macroblocks partitioned down to 4x4? Or they are always 8x8? If not, do you have plans to partition :devil: them?

Teegedeck
15th September 2004, 11:26
Originally posted by bobololo
I'm not sure if in xvid the chroma motion mode only affects the ME, but in our case, enabling the cartoon mode includes the chroma components in the whole decision process (ME, prediction modes, etc.), not only the ME.
I asked because testers have started using -cartoon on all their encodes. Which would be a mistake if -cartoon also affects skip-thresholds as it does in XviD.

babayaga
15th September 2004, 11:43
Originally posted by Bishep
bobololo,
I misunderstood one thing... :confused: Are sub macroblocks partitioned down to 4x4? Or they are always 8x8? If not, do you have plans to partition :devil: them?

Currently, the beta 3 does not offer the option to choose sub-partitions (4x4, 8x4 and 4x8). Some could be generated but not after evaluating all options.

The efficiency gain for sub-partitions is rather small on standard applications (MPEG-2 source transcoded) but the speed penalty is high.

babayaga
15th September 2004, 11:45
Originally posted by LostMP4
Is the fourth beta on the way?

Yes :-)
And it will include a faster 1st pass, even on short clips.

CruNcher
15th September 2004, 17:28
@babayaga
im currently uploading a rar package wich shows a b-frame problem with normal mode could you check this :(

bond
15th September 2004, 18:53
sorry if i overread it, but did anyone already do an intercodec 2pass speed comparison, like comparing atemes codec to xvid, rv or wmv (with "maximum quality-low speed settings", like qpel...) for putting things also speed-wise into perspective?

LostMP4
15th September 2004, 19:21
Originally posted by bond
sorry if i overread it, but did anyone already do an intercodec 2pass speed comparison, like comparing atemes codec to xvid, rv or wmv (with "maximum quality-low speed settings", like qpel...) for putting things also speed-wise into perspective?

According to my tests "speed" is between 2-3 fps with all slowest options at about 1200 kbps (using the PC while doing encodes)
source: 720x576, 25 fps, using AviSynth 2.55, dgmpgdec1011
PC: Athlon XP 2600+ (Barton 166x11.5) 1024MB

CruNcher
15th September 2004, 19:32
jep bond ;)
you can read glimpse about this in the Quality Feedback thread
but i will wait first for the b-frame fix before i publish the detail preservation results speedwise compared to XviD ;)

bobololo
15th September 2004, 21:53
It has just been released, check your mailbox for the updated link !

Here is the changelog :

* beta 4 - beta 3

- Better intra/inter decision that provides higher coding efficiency (sharper and more fluent motion) (encavc.exe)
- RC improvement, it's more accurate and we should have less undersize (encavc.exe)
- Strengthen the psycho level 2 (encavc.exe)
- New weighted prediction for fade transitions (-setef wpred) (encavc.exe)
- Custom deblocking matrix (-customdeblock) (encavc.exe)
- Slight speed increase (simd code optimisation) (encavc.exe)
- Faster 1st pass (encavc.exe)
- Misc bugfixes in the dshow filters (adf_srcmp4.ax, adf_dech264.ax)

Enjoy :)

IgorC
16th September 2004, 03:47
Well after such closed beta test Ateme will provide 6-months trial version like Divx Team, isnīt it? :p

bobololo
16th September 2004, 09:31
Originally posted by IgorC
Well after such closed beta test Ateme will provide 6-months trial version like Divx Team, isnīt it? :p

The codec will be available in NeroDigital products like Recode 2.

SeeMoreDigital
16th September 2004, 10:58
I've have not received an email link for beta4...

I guess I'm not worthy anymore :(


Cheers

bobololo
16th September 2004, 12:14
Originally posted by SeeMoreDigital
I've have not received an email link for beta4...
I guess I'm not worthy anymore :(


Well, the testers list has been automatically updated following feedback posted so far. Testers who didn't show much responses to previous betas or who didn't notice me about their (un)availability were switched to an idle state. They can get back to an active state and receive new beta as soon as they notice me about their willing to continue the test.

This is done in order to avoid the spread of too many copies of the beta to people who don't really participate to the test.

I know you had hardware trouble and can't encode right now, just let me know as soon as you are able to participate and I'll switch you back to an active state.

LostMP4
16th September 2004, 13:09
Core encoder version 1.0.1.26

Input file : D:\encavc\test.avs
Output file : D:\encavc\09.mp4
Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Process Priority : Idle
Rate Control : 2pass
Target Bit Rate : 1200 kb/s
Quality : Normal
Init Quantiser : 20 [0 - 51]
Max Consecutive BFrames : 3
Deblocking Strength : 0 (adaptive)
Direct Spatial MV Pred : Off
Num Reference : 1
Psychovisual : 1
Cartoon mode : On
Features : ipred ppred bpred wpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 72840 frames processed @ 36.75 fps
-- Start processing pass 2 / 2
* 72839: encoding @ 25.60 fps - bitrate 53.19 kb/s - 100.00% completed
* 72840 frames encoded @ 10.20 fps - average bitrate 1204.24 kb/s

Encoding complete

These settings provide an excellent quality AND fast encode :)

Please notice the final bitrate: just a little oversized but I guess this wouldn't cause any trouble

About fast first pass: I noticed a really fast start, then the process became slower and slower...

And a RAM related issue (maybe...): I saw in Task Manager a large portion of RAM (about 230 MB) allocated but not process-related... maybe it was used by avisynth... I'll restart the PC and try with a new encode

Sagittaire
16th September 2004, 15:47
big bug with beta4 ... with all bframes ... !!!

encavc.exe -i azerty.avs -o psy0.mp4 -qual extra -rcmode 2pass -br 800000 -deblock 0 -ref 5 -setef wpred -cartoon

http://jfl1974.free.fr/Video/Bug-beta4.JPG


no bug without wpred

encavc.exe -i azerty.avs -o psy0.mp4 -qual extra -rcmode 2pass -br 800000 -deblock 0 -ref 5 -cartoon


no bug with wpred and without bpred

encavc.exe -i azerty.avs -o psy0.mp4 -qual extra -rcmode 2pass -br 800000 -deblock 0 -ref 5 -setef wpred -cartoon -clref bpred

LostMP4
16th September 2004, 15:52
Originally posted by Sagittaire
big bug with beta4 ... with all bframes ... !!!

encavc.exe -i azerty.avs -o psy0.mp4 -qual extra -rcmode 2pass -br 800000 -deblock 0 -ref 5 -setef wpred -cartoon

http://jfl1974.free.fr/Video/Bug-beta4.JPG


no bug without wpred

encavc.exe -i azerty.avs -o psy0.mp4 -qual extra -rcmode 2pass -br 800000 -deblock 0 -ref 5 -cartoon

Have you unistalled previous filters and installed the new ones?

Sagittaire
16th September 2004, 15:59
Have you unistalled previous filters and installed the new ones?

yes ... very strange ... ???

bobololo
16th September 2004, 16:03
Originally posted by Sagittaire
[B]big bug with beta4 ... with all bframes ... !!!

Update to the newest decoder filter. The previous had a bug in the weighted prediction.

Sagittaire
16th September 2004, 16:11
adf_dech264.ax 1.1.2.0 and adf_srcmp4.ax 1.2.2.0 for beta 3 and beta 4 ... perhabs error for my pack ... ???

Nic
16th September 2004, 16:32
@bobololo: I am testing...I'll try to come up with something useful, but I'd only be re-iterating what has already been said. Mainly been trying at the 128, 512 & 768 kbps range and comparing to other codecs. Especially at 512 (two pass -qual best -adaptquant) it's very impressive...
(Been testing on a dual Xeon P4 2.4ghz...and it works very stable there (only thought i'd mention as Xeon's tend to be a bit more picky with some optimised code....))

-Nic