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

[virus]

Some numbers about the efficiency of the new tools... :)

Encoding at fixed quantizer: -rcmode vbr -qp 20 <other options>
(this should be roughly equivalent to a 1stpass with XviD)

-qual normal -clref bpred,cabac,part -adaptdeblock
2560.09 kbit/s

-qual best -clref bpred,cabac,part -adaptdeblock
2387.80 kbit/s

-qual extra -clref bpred,cabac,part -adaptdeblock
2385.78 kbit/s

-qual extra -clref bpred,cabac -adaptdeblock
2301.58 kbit/s

-qual extra -clref bpred -adaptdeblock
2187.28 kbit/s

-qual extra -ref 3 -clref bpred -adaptdeblock
2172.43 kbit/s

-qual extra -ref 3 -maxb 2 -adaptdeblock
2068.38 kbit/s

CABAC is not a surprise, I always rated it as the best innovation in H.264. Multiple frames references score quite badly here because this tool shines on low/mid motion scenes (and this was not our case). I wonder how many room is still left for improving the MB partitioning tool, since it doesn't use 8x4, 4x8 and 4x4 blocks. Maybe they can be supported in "extra" quality mode? (the algorithm itself is already quite time-consuming)

A further note: encavc saturates at ridiculously high bitrates. It delivered on this very same clip up to 12 mbit/s (with spikes of 20!). Is this a side-effect of the exponential quantizers used in H.264? A bitrate explosion at low QPs?

[Manao]

You should also take into account the PSNR in your figures ( or at least visual impressions ) : for exemple, between best and extra the size almost doesn't change, but the PSNR raises.

H264 indeed saturates at a very high bitrate, but even if subjective transparency is reached around a quantizer of 18, PSNR is still improved if you lower the quantizer ( for example, where XviD at quant 2 was giving a PSNR of 44.5, H264 is able to give a PSNR of 50 or more, with a higher size, of course )

[BoNz1]

Hi, first I must apologize for my slow testing :(. It took a long time to gather these results and make some hopefully useful comments about them.

Anyway, I have done some subjective testing on the Ateme beta 2 H.264 encoder and XviD 1.01. As they are subjective I have not drawn any conclusions from the results ie which codec is better etc. IF you decide to, beware! These are all reasonably hard clips and may not be representative of a real encode of a full length video. Also, how I perceive quality may be different than you. But I think some problems with both codecs were identified though.

Anyway, I do have some more clips I wanted to test. But I am very tired and it has taken me almost 5 hours to do these 4 clips. I will provide the source video clips tomorrow if that is deemed necessary.

Beware, this thing is 9 pages long. Although a lot of it is settings and other boring stuff you can skip ;). Here it is! (http://www.geocities.com/bonzi5252/Subjective_Test.zip)

[thegeby]

Just did a double testing against a 98.2MB 1280x720p WMV clip, transcoding from that clip via Avisynth and using the same bitrate (less the original audio). I am VERY impressed with the beta.

1) clip using vbr 6000000, otherwise default, resulting filesize 70.5 MB, much smoother playback than the original on a Celeron 1.8GHz, the same slight judder as noted by others. Playback rate varying from 2.8 Mb/s all the way to 20.5Mb/s. This is OK for local playback, but would cause problems during broadcasting.

2) Clip using cbr 6000000, otherwise default, resulting filesize 79.7 MB, no obvious difference in playback vs. clip 1). Playback rate, exceeding target at 7.2-7.7 Mb/s.

Given that this is made from a clip that is specifically picked for WMV quality and transcoded to H.264....Wow.

However for broadcast use, it needs to achieve these results at a lower bitrate (not to mention real time encoding:D ).

[Manao]

The flag -rcmode vbr makes the encode being done at fixed quantizer, bitrate control is then disabled, so you were lucky to reach the right size in your first attempt ( if you reached it ). It's astonishing that cbr doesn't reach the bitrate you're asking, since regulation seems accurate ( except perhaps at low bitrate, which is not the case here ).

[plonk]

Originally posted by Teegedeck
@anyone having playback problems: Do you have any other h.264 codec installed? Make sure to remove it if altering priorities in MPC or Windows' videocodec properties doesn't help. Delete the dlls if all else fails. (Make a backup copy if you're not quite sure what you are doing...)

i was having audio playback problems. solved by a combination of removing 3ivx and removing some preferred/blocked filters in MPC's Override section. pity, because i liked the ease of using 3ivx and graphedit to mux mp4s...

[Manao]

BoNz1 : I read your comments : very interesting. The first subjective measurement is however rather astonishing ( h264 being worse than XviD ) but your visual impressions seems to confirm it ( EDIT : my bad, I thought subjective measurement in VQStudio was simply a VQM measurement, but it isn't. So results aren't astonishing anymore /EDIT ). You should test without bpred ( since they have a mocing blocks issue for the moment ).

Also, since you used inloop deblocking for h264, did you postprocess XviD to make the comparison ? If not, I think it would be fair to do so, since the major issue you're raising is blocking.

[plonk]

Originally posted by Soulhunter

Do you received my file ???

FileZilla told me that the transmission was completed...

But I cant see my file @ the index, its still shown as empty !!!


yeah, one of the READMEs states that the ftp upload folder is upload only, so no downloads, and i'm assuming no LISTings

[LigH]

I did a few more encodes on a Duron 800. Stable; speed in comparable relation to my previous tests.

Direct sample:
H:\Programme\encavc\avs2mp4.bat j:MRev.avs j:MRev.mp4 900000
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.

Resulting files generated by this software can be corrupted due to the
instability of the encoder. Please report back if it occurs.

Core encoder version 1.0.1.16

Input file : j:MRev.avs
Output file : j:MRev.mp4
Resolution : 1024x532 @ 24.00 fps
Length : 3600 Frames
Rate Control : 2pass
Target Bit Rate : 900 kb/s
Quality : Best
Init Quantiser : 24
Max Consecutive BFrames : 3
Deblocking Strength : -2 (adaptive)
Num Reference : 5
Psychovisual : 2
Cartoon mode : On
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 3600 frames processed @ 1.94 fps
-- Start processing pass 2 / 2
* 03599: encoding @ 2.84 fps - bitrate 56.21 kb/s - 100.00% completed
* 3600 frames encoded @ 1.98 fps - average bitrate 900.80 kb/s

Encoding complete
Resized sample:
H:\Programme\encavc\avs2mp4.bat j:MRev'.avs j:MRev'.mp4 900000
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.

Resulting files generated by this software can be corrupted due to the
instability of the encoder. Please report back if it occurs.

Core encoder version 1.0.1.16

Input file : j:MRev'.avs
Output file : j:MRev'.mp4
Resolution : 512x272 @ 24.00 fps
Length : 3600 Frames
Rate Control : 2pass
Target Bit Rate : 900 kb/s
Quality : Best
Init Quantiser : 24
Max Consecutive BFrames : 3
Deblocking Strength : -2 (adaptive)
Num Reference : 5
Psychovisual : 2
Cartoon mode : On
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 3600 frames processed @ 4.64 fps
-- Start processing pass 2 / 2
* 03599: encoding @ 10.37 fps - bitrate 8.68 kb/s - 100.00% completed
* 3600 frames encoded @ 4.68 fps - average bitrate 900.59 kb/s

Encoding complete
Now I wanted to compare the results using AviSynth functions like Compare(), SSIM() - unfortunately:

- DirectShowSource fails (green video)
- GraphEdit fails to save a *.GRF file (Error 80004003: Invalid pointer).

Had to construct a graph manually to save the Ateme output as an AVI file:

Ateme MPEG-4 File Parser => Ateme H264 Decoder => AVI Decompressor => (a VfW encoder) => AVI Mux => File writer

But the resulting AVI file requires a SwapUV(); can I add a filter to do that in the graph?

[everwicked]

Originally posted by BoNz1
Anyway, I have done some subjective testing on the Ateme beta 2 H.264 encoder and XviD 1.01.

Congratulations, you're the first person to conduct a blind test in this thread :)

[Teegedeck]

To my shame I must admit that I didn't get Visual Quality Studio to work. :( After testing, the promised results don't pop up. So I have to rely on switching between the two clips manually.

[Selur]

btw. would be cool if the encoder could/would support/use both/all cpu's on smp systems. (got a dual athlon mp 1800+ system,.. 50-60% CPU usage during encoding :( )

Cu Selur

[lexor]

Originally posted by everwicked
Congratulations, you're the first person to conduct a blind test in this thread :)
blind test? with a video encoder? umm... I see nothing wrong with that testing methodology. :D

[thegeby]

Re: Manao
The flag -rcmode vbr makes the encode being done at fixed quantizer, bitrate control is then disabled

I realise my considerations are a bit premature, but my interest is mainly in H.264 as a possible future HDTV broadcast codec. This makes bitrate the main interesting parameter. If it does not fit in a 7 or 8 MHz broadcast channel (6 MHz if in the US) it will not do. What I am really looking for is a bitrate that would allow two HDTV channels multiplexed in one broadcast channel.

The original Ateme Matrix clip did that, but unless you are running a pure film channel, you are bound to do live segments...., i.e as quick encodes as possible. Given that this is an early public beta, I can only repeat that I am impressed.

[SeeMoreDigital]

Congratulations everyone :D

In the few days this thread began, it has taken the forum by storm!

Well done Ateme for giving us the chance to get involved in such a well organised and professional way.


Thanks bobololo

[LigH]

Unfortunately, I don't see a useful way to run an objective comparison: I tried to export the mentioned graph to an AVI file (e.g. a pure YV12 video). But the result has almost 3 times as many frames as the original one... :confused:

And which filter preference merits I tried, DirectShowSource() only returns a green picture.

Besides that, the Ateme filters are fast enough to play back the video smoothly with 512x272 or 512x288 pixels at 24 fps on a Duron 800: Well done, they are nicely fast for playback.

[virus]

Originally posted by LigH
And which filter preference merits I tried, DirectShowSource() only returns a green picture.
DirectShowSource() doesn't work with the latest NVE filters, too. It returns "unable to determine the duration of the video", even if I specify "fps=25" and "seek=false" in the call (seeking is b0rked for these filters)...

@Manao: ...that's why I didn't provide PSNR values... I simply cannot compute them with CompareYV12() and evaluate them against the values I've already calculated for the other codecs. (you should know better that I'm a PSNR freak ;))

[Mr_Schizo]

Ok, here is a little feedback from my tests so far.
* Check the stability of the encoder
No Problems here till now (with beta2). Checked with alot of smaller clips,trailers and 2 Full movie encodes.
* Check if the encoder performs well on various source types (progressive only)
The "Core Performance" (i don't count RC and deblocking as Core in this case)of the encoder is very powerfull on the most "hollywood" movies/trailer. But their is also an exception where the encoder performs very bad. It seems that the encoder has some difficulties with very sharp,grainy,detailed slow motion material with unnatural contrasts. This can lead to blocks, ugly grain removal and extreme heavy blurring (inloop deblocker)- everything in the same clip with the terrible result of a heavy fluctuating quality.
* Check the encoder performance on different computers
I've only checked it on my own computer where i like the performance. It's pretty fast for a h264 encoder even with slowest settings.

2500XP,704x288 1.pass ~37fps 2.Pass ~8fps with slowest settings
* Check the efficiency of tools with regards to the quality improvement
I can't see any gain from PSY or REF but i'll use it as long as i also can't spot out any negative effects of it. Quality is much more important than speed, at least for me. The gain from best to extra is noticeable in the most cases, so i'll use the latter. I haven't played around enough with b-frames till now to give any decent statements about it.
* Check which settings are the best suited to your eyes !
My preferred settings for 1CD encodes atm are:
Natural material:
RC: 2pass
Quality: extra
maxB-frames: 3
deblocking strength:-deblock -2/-3/-4 -adaptdeblock (can't realy spot out any differences between the three-maybe a bug or my bad eyes)
Num of Ref Frames: 5 (bobo said that it works smart, so it should not harm except of the speed decrease)
PSY: 2
Cartoon Mode: On (gives a slightly noticeable quality improvement)
Features: everything enabled (haven't tried that till now)
Cartoon/Anime Material: not testet
* Check the encoder against competitors (xvid, vp6, wm9, etc.)
Nothing to check here! ;) It's clearly superior in 9 of 10 encodes against everything i've seen so far.

What should be improved ?:
-The b-frame issue-flickering blocks (done allready afaik)
-the handling of grainy material
-RC coupled with deblocking
-PSY should be coupled with deblocking which works picture-part-based (something like higher quants in the background caused of PSY also means higher deblocking of the background and so on)
*The last 2 points are the ones where i see by far the most room for improvements.

Ok, thats it for now :) !

[everwicked]

Originally posted by Teegedeck
To my shame I must admit that I didn't get Visual Quality Studio to work. :( After testing, the promised results don't pop up. So I have to rely on switching between the two clips manually.

My sincere apologies. I fixed it shortly after I uploaded the last beta but then I forgot to update the site... That's what you get for working late.

Anyways, here (http://www.everwicked.com/vqstudio/beta/subjective-20040902.zip) 's the fixed version.

[Teegedeck]

Thanks :) a lot, will try it tomorrow.

[Tommy Carrot]

All right, guys, it's time to share my findings about the quality of this codec. :) I made a little quality comparison test against xvid. I used constant quantizer, because i think this is the most fair way to compare the raw performance of the codecs.

The settings of the xvid encoding was: mpeg quant 3, bframes(2,1.5,1), vhq 4, chroma me. I choosed these settings because these are close enough to the real life 1cd rips settings i usually use. The resulting video file is 53,662 kb.

My goal was to find the settings for the ateme h.264 codec which gives subjectively nearly identical visual result to the above one. I've used extra quality and disabled b-frames, and vbr RC mode, other than those, everything was at default.

I've started to increase the quantizer until i felt the quality of the two videos are almost perfectly matching, and this came at quant 27. At most scenes, h.264 was still better with slightly more details and cleaner pictures, while xvid was a bit better in a few cases, especially in the darker scenes (but this was the minority in the clip).

And here comes the best part of it: the resulting filesize is 32,310 kb!!! H.264 delivered similar quality at ~60% bitrate, compared to xvid. If this is not fucking impressive, i don't know what is!

[bobololo]

@RBF: regarding, our mp4 source filter is simply a helping tool for us, it's not intended to have all the features you can expect from ND products filters (support for multi audio, subtitle, chapter, etc.). And we won't support it since it is not the purpose. Also you spotted an nice idea, we could add options in encavc to limit the quantizer range. We should have them in beta 3.

@Soulhunter: your file is up, can you also post the t3 trailer source you're using ? Thanks.

@Mr_Schizo: the decode filter doesn't support AR settings for now. We'll try to do something, but it's not a high priority task since you can adjust the AR in mpc manually.

@Teegedeck: I see your point, I really suggest your then to make your tries on homogeneous sequence. About the adaptive deblocking, it's actually how it works. It's adjust the filter strength depending on the picture quantizer.

[BoNz1]

Originally posted by Manao
You should test without bpred ( since they have a mocing blocks issue for the moment ).


Well, I had considered doing this. However, I decided against it. It is a known issue so I didn't really worry about it. I didn't notice any frames like Soulhunter found. If I would have seen some frames like this I might have considered testing without bpred. I probably did have some impact on the results. But it is difficult to tell how much without doing another subjective test ;).


Also, since you used inloop deblocking for h264, did you postprocess XviD to make the comparison ? If not, I think it would be fair to do so, since the major issue you're raising is blocking.

Well that is a good point and one that I had not thought of. Usually, I watch all my XviD encodes without any postprocessing since I find this to be more pleasing to my eyes than with it on. So they settings in the XviD decoder were exactly the same.

[CruNcher]

@LigH

you could gain some extra speed without part like +2-4 fps without loseing to much.

Ok i almost finished all my testclips and overall i have to say im impressed by the Detail Preservation and Ringin prevention @ low bitrates as this are my main criterias as everyone knows :)
The only drawback are the backgrounds in low bitrate encodes short transforms do not really well with them there i would prefer ASP for but well it's a matter of how you like it anyways :P
So i soon will start with full DVD encodes with my settings and then it's time for finding enhanceing solutions :D

Here is what seems to be a prediction bug that i found lately

Source Frame (after transition)
http://cruncher.mufflastig.com/h264/source.png
Source Transition
http://cruncher.mufflastig.com/h264/sourcetransition.png
Compressed Result (after transition)
http://cruncher.mufflastig.com/h264/coloredblocks.png

[Teegedeck]

Originally posted by bobololo
About the adaptive deblocking, it's actually how it works. It's adjust the filter strength depending on the picture quantizer.
Maybe it would be good to change its adaptive behaviour a bit in the long run. For me, the same adaptive deblocking strength that was too strong for quant 20 was too weak for quant 23. I'll hopefully have the time today to do one or two more hours of testing.

ATM strengths like these seemed to preserve a maximum of detail while providing enough smoothing:

qp 19: none
qp 20: -3
qp 21: -2
qp 22: 0
qp 23: 3

Now, don't tell me that adaptive strength -3 at quant 20 will actually have no effect at all and that my eyes betrayed me - such things do happen but hopefully not to me. ;)

[babayaga]

Originally posted by virus
A further note: encavc saturates at ridiculously high bitrates. It delivered on this very same clip up to 12 mbit/s (with spikes of 20!). Is this a side-effect of the exponential quantizers used in H.264? A bitrate explosion at low QPs?

At low quantisers (below about Qp=20), the relation between the bitrate and the quantiser is close to a straight line.

For instance, the bitrate should be something like 6 times higher at Qp=0 than Qp=20

[Andrey]

Hi guys.
I was a bit off testing because of terrorist attack on school here.
:devil:
I don't know when I will be on a good mood again...

Ok, back to the codec.
One problem (I think) I noticed - seems that there are some problems with rate control. Doing Equilibrium encoding at 912Kbit I occassionally was near monitor while encoding finishing.
At 99.6% avg bitrate begin to raise constantly and reached 5.5Mbit !!!
Then at 99.8% it begin to drop and reached 190Kbit.
But when I look at the picture, I didn't see that quality is too high or too low. May be that was a concole printing bug ?

About encoding: with deblocking -4 + adaptive it is still too blurry compared to XViD + MPEG quantizer. (not h263 one!)
BTW, how to create a screenshot ? MPC still crashes when trying to do it in standard way...

[babayaga]

Originally posted by Andrey

One problem (I think) I noticed - seems that there are some problems with rate control. Doing Equilibrium encoding at 912Kbit I occassionally was near monitor while encoding finishing.
At 99.6% avg bitrate begin to raise constantly and reached 5.5Mbit !!!
Then at 99.8% it begin to drop and reached 190Kbit.
But when I look at the picture, I didn't see that quality is too high or too low. May be that was a concole printing bug ?

Was it during the first or the second pass ?

Anyway, this kind of things eventually happen and this is no bug, since you don't spot a quality modification (which is the goal) and the size is correctly achieved.
BTW the size of individual frames varies in a very large proportion, even larger than in MPEG-4.

If you fear about the ability of you CD player, there is an option to limit the maximum instaneous bitrate but it's not available in the beta.

[Andrey]

Second pass.
The bitrate was fluctuating in 600Kbit - 1200Kbit (which, I think, is normal for 912Kbit encode) as I occassionaly looked at the monitor.
But that ~6Mbit was a bit overtop, I think :)
Especially on a practically still scene - if you remeber Equilibrium end...

>>If you fear about the ability of you CD player, there is an option to limit the maximum instaneous bitrate but it's not available in the beta.
Thanks for the info...

[LostMP4]

Originally posted by Andrey
Second pass.
The bitrate was fluctuating in 600Kbit - 1200Kbit (which, I think, is normal for 912Kbit encode) as I occassionaly looked at the monitor.
But that ~6Mbit was a bit overtop, I think :)
Especially on a practically still scene - if you remeber Equilibrium end...

>>If you fear about the ability of you CD player, there is an option to limit the maximum instaneous bitrate but it's not available in the beta.
Thanks for the info...

The same happened to me, as reported some posts ago, and it looks to me a way to reach the final filesize, since it happened during static credits
I'd like to obtain an undersized file more than a beefed file

[Soulhunter]

Originally posted by bobololo

@Soulhunter: your file is up, can you also post the t3 trailer source you're using ? Thanks.Ok then, simply wasn't sure coz the index was still shown empty !!!

The source "Soulhunter_T3_Source.avi" is on the way... ;)


EDIT:

Some additional info for ya guys...

- Used decoder was ffdshow (even if VDubMod tells its XviD)

- I feeded the file via AviSynth -> AviSource to the encoder


Bye

[Sagittaire]

SSIM test: HPII 640*272 800 Kbps
*best for my eyes


options SSIM

defaut 80.53

qual normal 77.84
qual good 79.66
qual best 80.53 *
qual extra 80.65 *

psy 0 80.53
psy 1 80.79 *
psy 2 80.83 *

deblock -6 79.68
deblock -4 79.88
deblock -2 80.53 *
deblock 0 80.99
deblock 2 80.47
deblock 4 78.69
deblock 6 75.98

adapt -6 79.68
adapt -4 79.68
adapt -2 79.68
adapt 0 79.76
adapt 2 80.21
adapt 4 80.75 *
adapt 6 80.88

maxb 3 80.53 *
maxb 2 80.55 *
maxb 1 80.51 *
maxb 0 80.11

cartoon 80.55

ref 1 80.53 *
ref 2 80.62 *
ref 5 80.75 *
ref 20 80.77 *

best setting 81.59


Good quality (and good speed) for SSIM
-rcmode 2pass -br 800000 -psy 2 -deblock 0

Best quality with SSIM
-qual extra -rcmode 2pass -br 800000 -psy 2 -deblock 0 -ref 5

Good quality (and good speed) for my eyes
-rcmode 2pass -br 800000 -psy 2 -deblock 4 -adaptdeblock

Best quality for my eyes
-qual extra -rcmode 2pass -br 800000 -psy 2 -deblock 4 -adaptdeblock -ref 5

Edit error: adapt 4 for my eyes

[virus]

Originally posted by Sagittaire

adapt -6 79.68
adapt -4 79.68
adapt -2 79.68

I wonder if this is related to the "different deblock strength, ~same file"-issue I signalled some posts ago. It was exactly in the range [-6, -2] too, and with -adaptdeblock enabled.

[babayaga]

Originally posted by Sagittaire
SSIM test: HPII 640*272 800 Kbps
...
best setting 81.59


Sometimes I love your figures :-))

If I recall correctly, the closest in your SSIM test was VP6.2 at something like 76. Am I wrong ?

[CruNcher]

The same happened to me, as reported some posts ago, and it looks to me a way to reach the final filesize, since it happened during static credits
I'd like to obtain an undersized file more than a beefed file


Exactly for such things i prayed to the developers to include a OSD in the beta decoder. I hope they didn´t forget that wish of me ;)

[Sagittaire]

Sometimes I love your figures :-))

If I recall correctly, the closest in your SSIM test was VP6.2 at something like 76. Am I wrong ?


perhabs, i don't remember if i use the same avs script ... but your MPEG4 AVC is very very powerfull ... ;-)

complete test in progress with Matrix reloaded:

- metric test
- blind test
- sample for demo

[bobololo]

Here is a little contribution from plonk420 :

http://nero.ateme.com/beta_encodes/cathedral-beta2-400extra-crop-avc.mp4

No you're not dreaming, it's only 400 kb/s :)

[bobololo]

Originally posted by Sagittaire
perhabs, i don't remember if i use the same avs script ... but your MPEG4 AVC is very very powerfull ... ;-)

complete test in progress with Matrix reloaded:

- metric test
- blind test
- sample for demo

You should wait for the beta 3, it's about to be ready.

[vio_man]

Originally posted by bobololo
Here is a little contribution from plonk420 :

http://nero.ateme.com/beta_encodes/cathedral-beta2-400extra-crop-avc.mp4

No you're not dreaming, it's only 400 kb/s :)

I would like to see this encode but I don't have Ateme's filters :( I'm a AVC enthusiastic :)

[LostMP4]

Originally posted by vio_man
I would like to see this encode but I don't have Ateme's filters :( I'm a AVC enthusiastic :)
Nero Showtime is the answer

[Sagittaire]

You should wait for the beta 3, it's about to be ready.

oky ... :D

improuvement for beta 3 ???

[bobololo]

Originally posted by Sagittaire
oky ... :D
improuvement for beta 3 ???

For the core encoder, we'll have :

- quite better bframes
- improved RC
- a few speed optimizations (sse2)

I think it should be ready by tomorrow evening.

[vio_man]

Originally posted by bobololo
Here is a little contribution from plonk420 :

http://nero.ateme.com/beta_encodes/cathedral-beta2-400extra-crop-avc.mp4

No you're not dreaming, it's only 400 kb/s :)

Wow :eek: I've just watched the video and I must say I'm really impressed by the quality at such bitrate :) I think AVC/H.264 will take over MPEG-4 ASP in time.

[Sagittaire]

Little HDTV demo:

Trailer HPIII 80 sec
Video 1280*720 16/9 1280 Kbps
Audio HE-AAC 5.1 128 Kbps

Trailer King Arthur 125 sec
Video 1280*720 2.35 2000 Kbps
Audio HE-AAC 5.1 200 Kbps

configuration Intel 2.4 Ghz or Athlon XP 2400+

[bobololo]

Originally posted by Sagittaire
Little HDTV demo:

Trailer HPIII 80 sec
Video 1280*720 16/9 1280 Kbps
Audio HE-ACC 5.1 128 Kbps

Trailer King Arthur 125 sec
Video 1280*720 2.35 2000 Kbps
Audio HE-ACC 5.1 200 Kbps

configuration Intel 2.4 Ghz or Athlon XP 2400+

Nice trailers. Which settings did you use ? In the HP3 clip, sometimes I find the background a little bit too blurred to my taste and I've the feeling it was caused by a strong deblocking. Is it possible to provide the source ?

It appears here that audio and video are not sync (and I don't think it was caused by slow decoding since my cpu is loaded at 60% only).

Also next time before posting some material from the beta, please ask if you can (I don't think there is any problem with your trailers). The same apply to your test you're publishing on your website. The reasons are quite simple, the current tested betas are not always revelant of the final release and we may prefer not to spread the beta encodes even they're already very good.

This point was clearly explicited in the terms of the test you accepted, so please make your best to respect them.

[Sagittaire]

This point was clearly explicited in the terms of the test you accepted, so please make your best to respect them.

yes ... i remember that ... for this reason trailer out (auto-censured) ... sorry


In the HP3 clip, sometimes I find the background a little bit too blurred to my taste and I've the feeling it was caused by a strong deblocking.

-qual extra -rcmode vbr -qp 30 -psy 2 -deblock 6 -adaptdeblock -ref 1

it's high quant and very high compression but very good quality for 1300 Kbps and 720p i think. Personaly i like high treshold for adapt deblock ( adapt in [2-6] interval) ...


Is it possible to provide the source. It appears here that audio and video are not sync (and I don't think it was caused by slow decoding since my cpu is loaded at 60% only).

It's video.ts 12 Mbps MPEG2 1080i capture from HDTV. Sync is difficult because delay correction (DVD2AVI done not correct ac3 delay for these source) ... the problem is not mp4 muxer ... ;-)

[Andrey]

Wow I've just watched the video and I must say I'm really impressed by the quality with such bitrate I think AVC/H.264 will take over MPEG-4 ASP in time.
On low bitrates - definitely. :)
Inloop filtering produce really unexpected (in good meaning) results.

Still can not do good medium-to-high bitrate (~1Mbit) encode - too blurry. Seems that deblocking must be disabled for such a bitrates...
Will check it...

[708145]

I found some time to conduct my first experiments and I found 2 things:

a) I cannot play my produced .mp4 files but can play the .mp4 files posted by others. Maybe this is due to not muxing audio to it? But shouldn't the video stream play on itself?

b) For several HDTV 720p clips the encoder is able to produce 1000kbit encodes (+++ hit the target size _very_ well +++) but not so for 600kbit. Is this a bug? It should at least produce something <1000kbit if it's not possible to hit 600kbit exactly.

--
J:\b2>encavc -i "bourne.avs" -o "bourne_600.mp4" -qual best -rcmode 2pass -br 600000 -psy 1 -adaptdeblock -ref 2
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.

Resulting files generated by this software can be corrupted due to the
instability of the encoder. Please report back if it occurs.

Core encoder version 1.0.1.16

Input file : bourne.avs
Output file : bourne_600.mp4
Resolution : 1280x720 @ 25.00 fps
Length : 1813 Frames
Rate Control : 2pass
Target Bit Rate : 600 kb/s
Quality : Best
Init Quantiser : 24
Max Consecutive BFrames : 3
Deblocking Strength : -2 (adaptive)
Num Reference : 2
Psychovisual : 1
Cartoon mode : Off
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 1813 frames processed @ 1.51 fps
-- Start processing pass 2 / 2
* 01812: encoding @ 2.89 fps - bitrate 22.19 kb/s - 100.00% completed
* 1813 frames encoded @ 2.51 fps - average bitrate 14.86 kb/s

Encoding complete
--
fps are not valid since I was doing several (2-3) encodes at the same time.

This is on an AXP1800+/768MB-PC133/Win2kpro/radeon8500

bis besser,
Tobias

[Soulhunter]

Originally posted by 708145
...average bitrate 14.86 kb/s
Does your avs use DirectShowSource ???

When yes, try AviSource instead... ;)


Bye

[bobololo]

@SoulHunter: The problem (blocks) you reported at high bitrate should be fixed now, we have found some bugs that only occur at very low Qp (< 12) which should be your case.

@Cruncher: The transition issue you reported come from the source (snapshot from the vob file that comes with the DVD) :

http://nero.ateme.com/~tchi/t3_source.png.

[Soulhunter]

Originally posted by bobololo

@SoulHunter: The problem (blocks) you reported at high bitrate should be fixed now, we have found some bugs that only occur at very low Qp (< 12) which should be your case.

Nice, waiting for the new build... :)

Btw, some info about this other "bug" yet ???


Bye

[plonk420]

Originally posted by bobololo
Here is a little contribution from plonk420 :

http://nero.ateme.com/beta_encodes/cathedral-beta2-400extra-crop-avc.mp4

No you're not dreaming, it's only 400 kb/s :)

there was a bug (prolly the fault of the user :o ) where the incorrect framerate was used... should be 25ish... i'll reencode when the next beta comes out and hopefully we can replace this slightly embarassing file with the fixed one :eek:

[CruNcher]

@bobololo yes i apologize i was too fast with my asumption i rechecked and indeed it's allready in the source sorry for this :(

[bobololo]

After a week of intensive testing, we're happy to announce the release of the third beta package which is currently being uploaded to our public server. Testers' should receive the notification mail soon.

The changelog for this new version is the following :

- AviSynth DirectShowSource() issue fixed (adf_dech264.ax)
- Can't save graph in graphedit with source filter issue
fixed (adf_srcmp4.ax)
- Overwrite file issue fixed (mp4muxer.exe)
- New "-priority" option (encavc.exe)
- New "-maxqp" and "-minqp" options (encavc.exe)
- The extraction function could produce invalid mp4
(wrong config), it's fixed (mp4tb.exe)
- xmlparse.dll and xmltok.dll now compiled in release
- Misc bugfixes in the core encoder (encavc.exe)
- Improved bframes support (encavc.exe)
- Add AR support in the decoder filter (adf_dech264.ax)

As you can see, a bunch of bugs were fixed again thanks to your helpful reports and now the encoder is more stable than ever :)

Beside, with more than 300 posts and 12000 views in only 7 days, this feedback thread has completely exploded :) We couldn't imagine how popular this test could be ! In order to avoid your feedback to be completely overflooded, I created a new thread (http://forum.doom9.org/showthread.php?s=&threadid=82036) dedicated to quality feedback only while this one will be dedicated to bug, issues and help for starters. If a moderator is reading this, it would be really appreciated if he could rename this thread into something like "Ateme H.264 Beta - Bug, Issues and Getting Started" :)

This will hopefuly make the progress of this beta test more convenient for all !

Thanks again to all testers, your contribution is greatly welcomed.

-- bobololo.

[LostMP4]

Can I have details on the -priority option, please?
Which values are available?

[bobololo]

Originally posted by LostMP4
Can I have details on the -priority option, please?
Which values are available?

*Damned* I missed this option in the doc ...

-priority <below|above|high|idle|realtime|normal>

[LostMP4]

Originally posted by bobololo
*Damned* I missed this option in the doc ...

-priority <below|above|high|idle|realtime|normal>

You must be bugged ;)

Ok, for beta-3 this useful option is available, too:

-priority <idle|below|normal|above|high|realtime>

[virus]

ok, I've given the devs one more chance installing and testing the beta-3 filters, which don't work as always.

Now, I just want to let you know that I'm quitting the test.
I'm tired of asking (and offering help to fix the bugs) and be ignored, tired of fighting against the windmills alone, and I sincerely regret all the time I've wasted overnight to prepare some material, take PSNR figures, and so on even if I'm in a very busy period. My spare time, used for free, think about it dear Ateme devs, when you'll receive your salary at the end of the month...

I think I deserved something a bit different for my efforts, but hey, when it comes down to business you know how it's going to be... well, not a problem, 29 or 30 testers doesn't make any difference. I will continue read on your feedback guys, so please continue outputting numbers and opinions, I'm still interested in them.

have fun :)
virus

[bond]

Originally posted by bobololo
If a moderator is reading this, it would be really appreciated if he could rename this thread into something like "Ateme H.264 Beta - Bug, Issues and Getting Started"you wish we play, btw you can change the thread title by yourself too if you simply edit the title of your first post in this thread :)

[bobololo]

Originally posted by virus
ok, I've given the devs one more chance installing and testing the beta-3 filters, which don't work as always.

Now, I just want to let you know that I'm quitting the test.
I'm tired of asking (and offering help to fix the bugs) and be ignored, tired of fighting against the windmills alone, and I sincerely regret all the time I've wasted overnight to prepare some material, take PSNR figures, and so on even if I'm in a very busy period. My spare time, used for free, think about it dear Ateme devs, when you'll receive your salary at the end of the month...

I think I deserved something a bit different for my efforts, but hey, when it comes down to business you know how it's going to be... well, not a problem, 29 or 30 testers doesn't make any difference. I will continue read on your feedback guys, so please continue outputting numbers and opinions, I'm still interested in them.

have fun :)
virus

Well, I understand your disapointment and I'm sorry about it, but also consider what you were asking to us. Win9x support would involve our staff to setup a new PC, install the OS & drivers, all the development environment (just figure out how huge it is ...). And only then start investigating the issue. And all this for only 1 tester. Now imagine each tester has similar request, then I think we'd never be able to get our focus on the main topic of this test and the encoder would never be released ;)

Please keep in mind that we're not Microsoft nor Ahead. We're just compression codecs designers. Our expertise is to squeeze video data as much as possible and even we're learning and trying to do so, it is not to write software that works on every platform/os existing on this world (imagine one moment, that a single tester requests for BeOS support, what should we do then ?) ;)

BTW what's wrong with ShowTime filters ? Couldn't you continue to use them ?

[virus]

Originally posted by bobololo
BTW what's wrong with ShowTime filters ? Couldn't you continue to use them ? I can't seek nor use AVISynth. Ever tried to do an in-motion clip comparison without seeking capabilities? Or maybe compare two frames from two different encavc encodes side by side? Try without using seeking nor StackVertical() and then you can see.

Anyway, I can understand your point. But I also want to remind you that you never specified "Win2k/XP only" in your call for testers. Nor you said that 2k/XP was required at any point of this thread. Why fool me?

BTW I've already offered (4 days ago) to check the register and all the stuff you need on my own PC. And you didn't ever care to answer, as you do for the other stuff (the issue with the deblocker - thank God Sagittaire posted an answer to that some hours ago)

You know, when someone is unwanted it's better to ignore him. This I find disrespectful. Anyway, I don't care. One less tester, one less bug to resolve. Easy and simple, uh?

(ah, and even the XviD team is made up of "just compression codecs designers" who work on their spare time but their filters work flawlessly here... so I don't think I'm making such a huge request)

virus

[JohnV]

Originally posted by virus
I can't seek nor use AVISynth. Ever tried to do an in-motion clip comparison without seeking capabilities? Or maybe compare two frames from two different encavc encodes side by side? Try without using seeking nor StackVertical() and then you can see.

Anyway, I can understand your point. But I also want to remind you that you never specified "Win2k/XP only" in your call for testers. Nor you said that 2k/XP was required at any point of this thread. Why fool me?

BTW I've already offered (4 days ago) to check the register and all the stuff you need on my own PC. And you didn't ever care to answer, as you do for the other stuff (the issue with the deblocker - thank God Sagittaire posted an answer to that some hours ago)

You know, when someone is unwanted it's better to ignore him. This I find disrespectful. Anyway, I don't care. One less tester, one less bug to resolve. Easy and simple, uh?

(ah, and even the XviD team is made up of "just compression codecs designers" who work on their spare time but their filters work flawlessly here... so I don't think I'm making such a huge request)

virus For Pete's sake... At this stage it's much more important to optimize the quality than start spending lots of beta tuning time to fix some Win9x compatibility issues which affect 0.00001% of users.
I'm sure Win9X compatibility comes when it's the time, but considering how small minority this user group is, I totally understand that quality issue feedback/tuning gets much higher priority from Ateme at this point of the beta-test.

[acidsex]

For some odd reason, I never received the Beta-3 email. Dont know if it had to do with the hurricane we went through this past weekend but if bobololo could please send it to me, it would be greatly appreciated.

[virus]

Originally posted by JohnV
At this stage it's much more important to optimize the quality than start spending lots of beta tuning time to fix some Win9x compatibility issues which affect 0.00001% of users.
It's 10%, not 0.00001% :)
(I gave a link to an article about that in this very thread)

I want to remind you that Ahead (as Micro$oft) still supports Win98, 98SE, ME. And I also want to remind you that without my help, Ateme would have sold to Ahead a codec that wouldn't work at all on half of their supported platforms, since encavc-beta1 was b0rked on Win9x. I think that I deserved a different treatment for doing that... just make things clear, without making me waste time on this stuff, would have been much appreciated ;)

Anyway, it's all the same story. Why support that exotic Linux OS if everyone on Earth uses Windows? Why care about compatibility with Firefox if everyone uses IE? Why support that strange XviD-thingie when everybody in the world is happy with DivX? It's all the same. Business and software diversity are such different concepts... ;)

(and it's easy to make comments like yours when you're on the winning side. much less when you're in the minority)

virus

EDIT:
I'm sure Win9X compatibility comes when it's the time
please read again bobololo's statements... win9x compatibility will never come.

[JohnV]

Originally posted by virus


EDIT:

please read again bobololo's statements... win9x compatibility will never come. Eh.. Nero Digital uses Ahead's inhouse h.264 decoder anyway, not Ateme's decoder. So maybe complete win9x support won't come for this Ateme beta-test, but ShowTime works with Win9x, doesn't it? Furthermore according to my knowledge at least the h.264 seeking issue should be fixed in the next NVE update package.

[virus]

Originally posted by JohnV
Furthermore according to my knowledge at least the h.264 seeking issue should be fixed in the next NVE update package.
Good. (not that I need it anymore :D)
Anyway I'm not asking Ateme to support anything. But they should have simply said "dear virus, you cannot partecipate in this test with your OS, sorry, please don't waste time on it". Instead, they choose not to talk and ignore me. Had I not spoken out tonight, no more words would have been spent on the whole issue. That's disrespectful. (and I even offered to debug everything on my machine! :rolleyes: )

Ateme is free to do what they want. I'm just asking for a bit of respect for my (free) efforts ;)

virus

[everwicked]

Hi,

I don't speak for bobololo, nor I am trying to defend him but I have experienced similar problems since I have started developing for windows so I might be able to explain a few things.

Originally posted by virus
I can't seek nor use AVISynth. Ever tried to do an in-motion clip comparison without seeking capabilities? Or maybe compare two frames from two different encavc encodes side by side? Try without using seeking nor StackVertical() and then you can see.


Quite a few people like StackVertical(). I myself feel that is not used as it should. What i mean is, that you shouldn't be looking for differences, frame by frame. If you let the video play and get a generic impression then go ahead.

There are also two more things you can do:
1) Use VQStudio
2) Use GraphEdit to export the mp4 file to another, lossless or uncompressed AVI. You can then do whatever you need with it, including seeking.


Anyway, I can understand your point. But I also want to remind you that you never specified "Win2k/XP only" in your call for testers. Nor you said that 2k/XP was required at any point of this thread. Why fool me?


I am quite certain they did not know it wouldn't work on win9x. Noone was trying to fool you. That is clear, to me at least. You were just unlucky to find out in practice.


BTW I've already offered (4 days ago) to check the register and all the stuff you need on my own PC. And you didn't ever care to answer, as you do for the other stuff (the issue with the deblocker - thank God Sagittaire posted an answer to that some hours ago)


Unfortunately, it doesn't have to do with your PC at all. The state of your installation is unrelated to these issues which are clearly related to advancements not evident in Win9x. I don't know what it is, but it can be anything, varying from Unicode to threading. If you don't believe me, you can browse through msdn.microsoft.com. Check at the bottom and see that a lot of functions are not supported by Win9x.


(ah, and even the XviD team is made up of "just compression codecs designers" who work on their spare time but their filters work flawlessly here... so I don't think I'm making such a huge request)

The XviD team has quite a few people and it has some basic differences with ateme:
1) they "ship" a complete product
2) because of 1, they also have mechanisms to ensure portability.
Something that noone has pointed out is that Ateme does NOT sell a standalone encoder but rather an encoding library.


I want to remind you that Ahead (as Micro$oft) still supports Win98, 98SE, ME. And I also want to remind you that without my help, Ateme would have sold to Ahead a codec that wouldn't work at all on half of their supported platforms, since encavc-beta1 was b0rked on Win9x. I think that I deserved a different treatment for doing that... just make things clear, without making me waste time on this stuff, would have been much appreciated


As I said above, they only sell the library to ahead, not the interface. And as bobololo himself said, the core is cross-platform.


Anyway, it's all the same story. Why support that exotic Linux OS if everyone on Earth uses Windows? Why care about compatibility with Firefox if everyone uses IE? Why support that strange XviD-thingie when everybody in the world is happy with DivX? It's all the same. Business and software diversity are such different concepts...


Aside from the ateme issue, my personal opinion is that if you want to support multiple platforms then you're limited to Java or .NET if only linux/windows is target. Then you lose speed assuming it's video processing we're talking about. Let alone how many people moan about the required runtime.

If you keep the speed and work with C/C++, then let's face it. Developers will spend more time testing and adding work-arounds for broken stuff in obsolete OS's. Time that they could have used to introduce new features. In that way, the minority is hurting the majority, not themselves.


please read again bobololo's statements... win9x compatibility will never come.


It will come. Just not with Ateme's encoder/filters. Once again, someone from Ateme pointed out that they are used for in-house development. Too bad it didnt work for win9x users for this test. However, when Ahead gets it and the new Nero is out, it will support your beloved OS.

Just my 0.02 &euro;

[superdump]

virus: The AVC binary doesn't work on your Win9x machine, right? Waaaay back when you first mentioned this bobololo stated that that's an issue with their tools (i.e. encavc) NOT WITH THE CODEC ITSELF. So just sit back and wait until it's released in Nero then try it again. If it's a quick fix they'd have done it already and as you're the only tester complaining about Windows 9x incompatibility I assume everyone else running the test executable is doing fine. As far as I'm concerned that's not bad going at all really. It's not viable to spend a lot of time fixing Win9x compatibility for a couple of week long beta test. Quality development, as stated, is more important as the other 49/50 beta testers are concerned with this, as are the codec developers. Ahead can fix Win9x compatibility as that will be part of their goal, not necessarily Ateme's.

Have a nice day.

[virus]

Originally posted by superdump
virus: The AVC binary doesn't work on your Win9x machine, right? Waaaay back when you first mentioned this bobololo stated that that's an issue with their tools (i.e. encavc) NOT WITH THE CODEC ITSELF. the codec (encavc.exe, not the filters) was b0rked in beta-1 under Win9x. I resolved the issue with bobololo by email so you probably don't know about it. And again: saying "sorry you cannot test with your OS" at *that* time (and not now) would have been better. The point is that nobody ever cared to say that.

BTW It's also not viable to spend a lot of time to prepare a lot of stuff for a beta-test and not having someone warn you "hey, you're doing useless work, we're not going to support your OS right now". Can you see my point?

[plonk420]

*groans*
just update your os already, if just for the codec test...! >:| after it's done, go back to your favored 98 or whatever... i upgraded XP (from 2000) just for a LAN party and haven't been (or looked) back since

[virus]

Originally posted by everwicked
2) Use GraphEdit to export the mp4 file to another, lossless or uncompressed AVI. You can then do whatever you need with it, including seeking.As I already pointed out a couple of times before, GraphEdit won't render the graph, nor let me build it manually... ;)

I am quite certain they did not know it wouldn't work on win9x. Noone was trying to fool you. That is clear, to me at least. I disagree. bobololo stopped talking to me right after he was sure that encavc worked under my OS, because Ateme needed that (encavc is meant to be cross-platform). You can re-read the thread if you want. He answered all the questions except mines, and commented all the results except mines. He didn't ever care to state *clearly* something like "sorry, we're not going to support your OS". That would have been sufficient for me. Instead, he chose to ignore me.
Is this a correct, polite behaviour? Especially considering that I've tried to be helpful?

[JohnV]

For Pete's sake stop the crying already. :rolleyes:

Lets all praise virus from the behalf of all the two Doom9 members using Win9x and behalf of the other Win9x users out there. It's time for this thread to go back on topic instead of whining about what someone should or shouldn't have said.

[Bulletproof]

I seem to have a video that I encoded that refuses to play using the latest beta, when trying to open it in WMP it just freezes up. If I use the default encoding settings it decodes just fine but when I use this:

encavc.exe -i test.avs -o test.mp4 -qual extra -cartoon -rcmode 2pass -br 1000000

It freezes up in WMP.

[bobololo]

Originally posted by Bulletproof
I seem to have a video that I encoded that refuses to play using the latest beta, when trying to open it in WMP it just freezes up. If I use the default encoding settings it decodes just fine but when I use this:

encavc.exe -i test.avs -o test.mp4 -qual extra -cartoon -rcmode 2pass -br 1000000

It freezes up in WMP.

Can you upload the file ? Thanks.

edit:

Originally posted by virus
I disagree. bobololo stopped talking to me right after he was sure that encavc worked under my OS, because Ateme needed that (encavc is meant to be cross-platform). You can re-read the thread if you want. He answered all the questions except mines, and commented all the results except mines. He didn't ever care to state *clearly* something like "sorry, we're not going to support your OS". That would have been sufficient for me. Instead, he chose to ignore me.
Is this a correct, polite behaviour? Especially considering that I've tried to be helpful?

Ok this will be my last post here about this subject, if you can't understand my point, it's useless to continue this low discussion.

1. The fix we did with encavc.exe was related to the system call CreateThread() which has a different behaviour between win9x and win2k/xp. This function is use to create the thread that read the input source and has nothing to do with the core encoder. We didn't change even 1 line of code in the core encoder to fix this issue.

2. You reported that changing the deblocking filter settings, there were few changes in your clip. I didn't answer you because if you read all the posts before, it clearly appeared that changing deblocking filters settings does something. Plus you didn't tell which bitrate you were using, it was obvious that if you encoded at high bitrate the deblocking doesn't do anything since there is no blocks !

3. I didn't either reply to some questions posted when I considered my answer wouldn't have much interest.

I now hope you can stand back and see the reality of the facts which is quite different from your whacky interpretation. In no way we tried to exploit you in order to make our codec works with win9x (once again the core encoder is completely OS independant) and ignored you just after. I simply can't believe how you can imagine such things, this is hallucinating !

This discussion is closed for me, I won't reply anymore on this topic.

-- bobololo.

[708145]

Originally posted by plonk420
*groans*
just update your os already, if just for the codec test...! >:| after it's done, go back to your favored 98 or whatever... i upgraded XP (from 2000) just for a LAN party and haven't been (or looked) back since

XPpro is 180€! I wouldn't do that just for a codec test. Don't know about prices in italy, though.

But now let's stop this allright?

/me on Win2kpro

bis besser,
Tobias

[plonk420]

now if only i could figure out why my video is dropping frames even tho it looks perfect in Vdub... :(

edit: FINALLY figured out where the problem is..! when i frame by frame my AVISynth script in vdub all is well. however, when VDub saves the AVI (or when EncAVC encodes from the AVS script) something gets skewed and the duplicated frame gets kept and some other frame gets dropped...! :angry: w...t...f...?!?

MPEG2Source("cathedral.d2v").BiCubicResize(640,480).crop(0,64,0,-64).SelectEvery(6,0,1,2,3,4).AssumeFPS(25)

(it makes no difference if the AssumeFPS is there or not)

[Manao]

What dll are you using for decoding mpeg2 ? MPEG2DEC3 ? dgdecode ?

With DVD2AVi / MPEG2DEC3, there was sometimes some frames missing. With DGdecode ( and DGindex ), you shouldn't have this issue anymore. Perhaps it will solve your problem.

Also, perhaps the frame you need to drop isn't always the 6th of each sycle of 6 frames. You should try decimate ( from the decomb package ), it may solve your issue.

Finally, if nothing works, try to cut a small part of your vob and make it available, some gurus on the avisynth forum will surely find what is wrong with it.

[avih]

Originally posted by JohnV
For Pete's sake stop the crying already. :rolleyes:

Lets all praise virus from the behalf of all the two Doom9 members using Win9x and behalf of the other Win9x users out there. It's time for this thread to go back on topic instead of whining about what someone should or shouldn't have said.

Take it easy JohnV, and please try to stay polite.

avih.

[Sagittaire]

I seem to have a video that I encoded that refuses to play using the latest beta, when trying to open it in WMP it just freezes up. If I use the default encoding settings it decodes just fine but when I use this:

encavc.exe -i test.avs -o test.mp4 -qual extra -cartoon -rcmode 2pass -br 1000000

It freezes up in WMP.


1)For me don't work with WMP10 or QTP but work perfectly with MPC: after test only default renderer works with MPC. WMR7 and WMR9 with windowed or renderless doesn't work ...


2) this avs script works
video=DirectShowSource("G:\H264-500.mp4",fps=25)
video=trim(video,0,35237)
return video

but not this script (VD or VDM bug)
video=DirectShowSource("G:\H264-500.mp4",fps=25)
return video


3) Directshow with H264 consumes RAM enormously. The RAM is not reloaded when I open several avs consecutively: I must open and close VD to avoid depassement of virtual memory.

but it isn't important for me: it's beta test on quality. These problem are decodeur problem exclusively and will be solved later.

[virus]

Originally posted by bobololo
... and ignored you just after. I simply can't believe how you can imagine such things, this is hallucinating !

Yeah, how can I imagine such things? Well...

Originally posted by bobololo on 4th September 2004 00:17
We're doing our best to try to make them work on your plateform as it was previously done following your report on encavc.

These were the last words you've addressed to me (before I spoke out a few hours ago). You didn't even care to answer "we cannot make it to work, sorry". You didn't even care to say a single word, either accepting or rejecting my offer to debug your filters on my PC.
You can be one of the best coders in the world but still I don't think you have the right to jerk me around.

This is my point. Sorry for any further incomprehension, anyway.

Discussion closed for me, too

cheers :)
virus

[avih]

Originally posted by virus

.....

Discussion closed for me, too

cheers :)
virus

thank you :)

[plonk420]

Originally posted by Manao
What dll are you using for decoding mpeg2 ? MPEG2DEC3 ? dgdecode ?

With DVD2AVi / MPEG2DEC3, there was sometimes some frames missing. With DGdecode ( and DGindex ), you shouldn't have this issue anymore. Perhaps it will solve your problem.

Also, perhaps the frame you need to drop isn't always the 6th of each sycle of 6 frames. You should try decimate ( from the decomb package ), it may solve your issue.

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... :(

[LostMP4]

H.264 quantizer question..
If I remember correctly, increasing the quantizer by 6 should half the filesize... right :confused:
If that's right increasing the quantizer by 12 should reduce the filesize to a quarter

I made two test vbr encodes, with 21 (min and max) and 33 (min and max) quantizer but the first file it's about 6 times larger than second (1015 MB and 170 MB)

So, something is wrong (my memory, something related to my setting or maybe the codec?)

Core encoder version 1.0.1.19

Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Process Priority : Below
Rate Control : Vbr
Quality : Extra
Init Quantiser : 21 [21 - 21]
Max Consecutive BFrames : 3
Deblocking Strength : 0 (adaptive)
Num Reference : 5
Psychovisual : 2
Cartoon mode : On
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 1
* 72839: encoding @ 12.20 fps - bitrate 352.48 kb/s - 100.00% completed
* 72840 frames encoded @ 2.66 fps - average bitrate 2919.37 kb/s

Encoding complete

Core encoder version 1.0.1.19

Resolution : 720x576 @ 25.00 fps
Length : 72840 Frames
Process Priority : Below
Rate Control : Vbr
Quality : Extra
Init Quantiser : 33 [33 - 33]
Max Consecutive BFrames : 3
Deblocking Strength : 0 (adaptive)
Num Reference : 5
Psychovisual : 2
Cartoon mode : On
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 1
* 72839: encoding @ 11.20 fps - bitrate 29.63 kb/s - 100.00% completed
* 72840 frames encoded @ 4.48 fps - average bitrate 488.87 kb/s

Encoding complete

[superdump]

Originally posted by LostMP4
H.264 quantizer question..
If I remember correctly, increasing the quantizer by 6 should half the filesize... right :confused:
If that's right increasing the quantizer by 12 should reduce the filesize to a quarter

I made two test vbr encodes, with 21 (min and max) and 33 (min and max) quantizer but the first file it's about 6 times larger than second (1015 MB and 170 MB)

So, something is wrong (my memory, something related to my setting or maybe the codec?)I think bobololo said that the filesize is 'nervous' using constant quantiser mode. I don't know if increasing qp by 6 is intended to halve the filesize but even if it is it won't do that in every case, depends on the source.

[bobololo]

Originally posted by LostMP4
H.264 quantizer question..
If I remember correctly, increasing the quantizer by 6 should half the filesize... right :confused:
If that's right increasing the quantizer by 12 should reduce the filesize to a quarter

I made two test vbr encodes, with 21 (min and max) and 33 (min and max) quantizer but the first file it's about 6 times larger than second (1015 MB and 170 MB)

So, something is wrong (my memory, something related to my setting or maybe the codec?)

The bitrate variation versus quantizer is absolutely not linear. If it was the case, the RC would be quite easier ;)

[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?!

At first I'll try to upload a zipped Excel sheet here (I wonder if I'm allowed to upload - if so, it may appear soon here). Also I made a Windows EXE, but it is a but huge (due to using Delphi): ~185 KB.

[Soulhunter]

Nice, all problems with the T3 trailer are gone with the new beta... :)


Bye

[ac-chan123]

I have testet the mp4 files from this treat with the new IIS Frauenhofer mp4 Player (http://www.iis.fraunhofer.de/pub_rel/presse/2004/mpeg4/index.html). None of them are played. The Player says profile unkow.

[SeeMoreDigital]

Originally posted by ac-chan123
I have testet the mp4 files from this treat with the new IIS Frauenhofer mp4 Player (http://www.iis.fraunhofer.de/pub_rel/presse/2004/mpeg4/index.html). None of them are played. The Player says profile unkow. Can you upload a short sample?


Cheers

[LostMP4]

Originally posted by ac-chan123
I have testet the mp4 files from this treat with the new IIS Frauenhofer mp4 Player (http://www.iis.fraunhofer.de/pub_rel/presse/2004/mpeg4/index.html). None of them are played. The Player says profile unkow.
Tested my encodes, same error (AVC profile unknow)
maybe profiles aren't implemented yet...

[Bulletproof]

Originally posted by bobololo
Can you upload the file ? Thanks.


I have uploaded the file on the ftp in the incoming dir.

[bond]

Originally posted by LostMP4
maybe profiles aren't implemented yet...hm maybe the ateme encoder doesnt indicate the used profile in the .mp4 file, but the frauenhofer player needs it (might only play baseline profile streams and not main profile ones), but thats only speculation

[bobololo]

Originally posted by bond
hm maybe the ateme encoder doesnt indicate the used profile in the .mp4 file, but the frauenhofer player needs it (might only play baseline profile streams and not main profile ones), but thats only speculation

It seems that fraunhofer doesn't support main profile...

edit: FYI, streams encoded with our beta use main profile (77) and level 4.0 (40).

[bobololo]

Originally posted by Bulletproof
I seem to have a video that I encoded that refuses to play using the latest beta, when trying to open it in WMP it just freezes up. If I use the default encoding settings it decodes just fine but when I use this:

encavc.exe -i test.avs -o test.mp4 -qual extra -cartoon -rcmode 2pass -br 1000000

It freezes up in WMP.

Ok I got your file and tried to play it with mpc and wmp9 and both worked fine. Only I couldn't seek in wmp9. Which version of wmp do you use ? Does is work with other player ? Have you updated your filters with those provided in beta 3 ?

I'll try tomorrow on other PCs with different version of wmp if possible.

[Bulletproof]

I think my decoding filters were screwed up, I used unreg and reg again and it's playing fine now in WMP 6.4, thanks.

[LostMP4]

Originally posted by bobololo
streams encoded with our beta use main profile (77) and level 4.0 (40).

Will you support extended profile?

[bobololo]

Originally posted by LostMP4
Will you support extended profile?

Hum I don't think so, however FRExt tools are much more interesting :)

[Tommy Carrot]

Originally posted by bobololo
Hum I don't think so, however FRExt tools are much more interesting :)

Could anyone tell me what tools does FRExt/high profile have other than the additional colorspaces? I did a search, but everything i could find was a bunch of japanese pages, and press releases.

[bobololo]

Originally posted by Tommy Carrot
Could anyone tell me what tools does FRExt/high profile have other than the additional colorspaces? I did a search, but everything i could find was a bunch of japanese pages, and press releases.

The draft amendement is available on the jvt public ftp directory (ftp.imtc-files.org/jvt-experts). Check in the 2004/07 event at Redmond. If i remember correct, the draft is JVT-L049.doc. I'd like to check but it seems their ftp server is down now.

[Tommy Carrot]

Thx, i'll check later when the ftp is back. :)

[ac-chan123]

http://bs.hhi.de/~wiegand/JVT.html
There is the final draft.

[superdump]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

If anyone have link fot Ateme Codec or ANY idea from where i can download it . Pliz send me email igoruso@msn.com

[plonk420]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

BTW, does the -cartoon switch really do nothing else but activate chroma ME? No changed skip-block thresholds or anything?

[Manao]

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]

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]

bobololo

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

[LostMP4]

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]

Is the fourth beta on the way?

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

[Teegedeck]

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]

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]

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]

@babayaga
im currently uploading a rar package wich shows a b-frame problem with normal mode could you check this :(

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

[LostMP4]

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]

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]

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]

Well after such closed beta test Ateme will provide 6-months trial version like Divx Team, isn´t it? :p

[bobololo]

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]

I've have not received an email link for beta4...

I guess I'm not worthy anymore :(


Cheers

[bobololo]

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]

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]

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]

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]

Have you unistalled previous filters and installed the new ones?

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

[bobololo]

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]

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]

@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

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