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.