Ateme H.264 Beta - Quality Feedback

[Sagittaire]

Capture is useless and doesn't prove anythink:

- bframe imply a local heterogeneous quality for XviD or H264
- Sharpeness imply a local heterogeneous quality for VP6

IMHO (test in progress)

- VP6 little better than H264 for PSNR test
- H264 little better than VP6 for SSIM test
- for me visually H264 is better than VP6 or RV10: it's a very very powerfull codec ...

-> Good job Ateme ...

[aketon]

Originally posted by RBF
I disagree! You have not mixed a picture? Ateme keep more details than VP6.

It is a matter of taste!:) To my eyes VP6 is better in this picture! This is the way I see it! But the only thing I saw is just one picture but you have seen the video! So you might know better which one codec is the best!:cool:

[bill_baroud]

hello, any anime encoder report yet ???

my first test on this opening (http://www.irradiance.net/Animation/GroupsMPEG4/LOLI.J/Soul%20Taker%20OP%20(BSD%20D2V).avi) is very disappointing :( ... i tested some bitrate (1500/2000kbps) and played with some options so far (deblock, qpel/hpel,bframe,cartoon mode...) and it doesn't achieve the look of a classical xvid at the same bitrate. The plain color surfaces are blocky, and ... hmm... it's like it's too sharp, edges don't look good either...

i have yet to test other anime source, but on this torture test, it perform quite badly :(

/me going back to tests ....

[Bulletproof]

It worked just fine with anime for me, however all source material really depends. One thing I have kind of noticed is that denoisers sometimes hurt the picture quality with anime with this particular encoder because of the pre-encoding deblocking engine, try using no denoising at all, but like I said it all depends on the source, but my personal expierence is that it works quite good for anime.

[thegeby]

This may be a bit offtopic for this thread, but the other thread is very long and this is a quality picture anyway.

Still off topic; I just got my invitation and free ticket to last weekend's IBC conference:devil:

[bobololo]

Originally posted by aketon
VP6 is much better than the others!!! It keep more details!! I believe that ateme has a very good codec too!

Just for my understanding, I'd like to know what conducts you to have the feeling that vp6 keeps more details than others. Is it due to the noisy/grainy aspect of the picture ? Because when I look at the original and at vp6, I wouldn't say vp6 keeps more details, but actually the compression artefacts (blocking, ringing) provide to the picture with a harsh aspect and make it less smooth compare to others including the original one. If this is why vp6 picture appears more pleasant to your eyes, then it will be hard for us since our target is to prevent compression artefacts and to reproduce a result that matches the most possible with the source. Anyway we could add some noise in our decoder to render some film grain to the video and makes it even grainier than the source ?

[Manao]

bill_baround : can you provide screenshots ? Because @1.5 mbit/sec, h264 is fairly transparent for me. Also, do not forget the -cartoon flag for such contents.

[thegeby]

Some general impressions based on Beta3 (all numbers based on video stream, audio will have to be added):
720x576 (MPEG-2 original)video can be reproduced at original resolution with no discernible (by me, that is)at 1Mb/s.
1280x720 (WMV original)can be reproduced at 3-4Mb/s.

Given that these are transcoding from originally compressed sources, H.264 can probably do even better with uncompressed material. For 720p material 3-4 MB/s would put Ateme's product under the magic barrier enabling multiplexing of HDTV channels within one analogue TV channel. (Now we only need real time compression in HD into H.264. Oh well, next year...;) )

[aketon]

Originally posted by bobololo
Just for my understanding, I'd like to know what conducts you to have the feeling that vp6 keeps more details than others. Is it due to the noisy/grainy aspect of the picture ? Because when I look at the original and at vp6, I wouldn't say vp6 keeps more details, but actually the compression artefacts (blocking, ringing) provide to the picture with a harsh aspect and make it less smooth compare to others including the original one. If this is why vp6 picture appears more pleasant to your eyes, then it will be hard for us since our target is to prevent compression artefacts and to reproduce a result that matches the most possible with the source. Anyway we could add some noise in our decoder to render some film grain to the video and makes it even grainier than the source ?

This is exactly the reason I like VP6! I don't like videos that are too smooth! I prefer to have some artefacts here and there (which sometimes, when I see a full motion video (25 fps), gives me the impression that the image is more detailed!):eek:

The codec I use most often is Xvid! Xvid in very low bitrates, start to smooth the image very much (just like your codec)! Some codecs prefer to show artefacts and some others prefer to remove detail and smooth the image! The reason I like VP6 in low bitrates, is mostly because of their decoder! VP6 decoder give a very grainy picture (and it is just the way I like it)! Now, in order to prevent to see the smooth picture that Xvid give me at very low bitrates, I use ffdshow and I select the "mplayer noise" and I give a luminace strenght 20 (a lot of noise)!!!

The conclusion: I don't like smooth video!:( I like noisy video!!!:)

Adding some noise to your decoder is a very good idea!!!:D

Sorry for my bad english!!!

[IgorC]

On one half of picture Vp.62 is better, on the other half H.264 is better. Its happened in the SAME picture.

Be CAREFULL in the comparation of the NOISE-SHARP of Vp6.2 and SMOOTH-SHARP of Ateme H.264. As you can understand Vp6.2 and Ateme H.264 are difference codecs with difference matrix. I want to say in one part of picture you can noticed that Vp6.2 is better, but in the other part of the SAME picture you would say that H.264 is better. Try to analize the whole picture.
For example : Please look to picture
http://rbf.nm.ru/original_4.jpg - original
http://rbf.nm.ru/Nero_400_4.jpg - Ateme H.264
http://rbf.nm.ru/VP6_400_4.jpg - VP6.2
I noticed that the tree on the left side and forest looking more sharp in the Nero picture.
But Vp.62 is better on the part of lake. And the people on the boat looking better in the Vp6.2 file. So Vp6.2 – H.264 50%/50%.
It will be better if Ateme will find a balance between a sharp-details-smooth. I don’t think it is only question of noise. Sometimes VP6.2 is so terrible with his noise. But SHARPEST and DETAIL are most important in the quality of video.
And if the codec H.264 of Ateme will be a little slow than Vp6.2 but better than Vp.6.2 i think people won’t matter. ;-)
Waiting for Beta 4.

[aketon]

Originally posted by IgorC
On one half of picture Vp.62 is better, on the other half H.264 is better. Its happened in the SAME picture.

Be CAREFULL in the comparation of the NOISE-SHARP of Vp6.2 and SMOOTH-SHARP of Ateme H.264. As you can understand Vp6.2 and Ateme H.264 are difference codecs with difference matrix. I want to say in one part of picture you can noticed that Vp6.2 is better, but in the other part of the SAME picture you would say that H.264 is better. Try to analize the whole picture.
For example : Please look to picture
http://rbf.nm.ru/original_4.jpg - original
http://rbf.nm.ru/Nero_400_4.jpg - Ateme H.264
http://rbf.nm.ru/VP6_400_4.jpg - VP6.2
I noticed that the tree on the left side and forest looking more sharp in the Nero picture.
But Vp.62 is better on the part of lake. And the people on the boat looking better in the Vp6.2 file. So Vp6.2 – H.264 50%/50%.
It will be better if Ateme will find a balance between a sharp-details-smooth. I don’t think it is only question of noise. Sometimes VP6.2 is so terrible with his noise. But SHARPEST and DETAIL are most important in the quality of video.
And if the codec H.264 of Ateme will be a little slow than Vp6.2 but better than Vp.6.2 i think people won’t matter. ;-)
Waiting for Beta 4.

It is really difficult to decide which one is better here! I think that H.264 is a little bit better in this picture! I give H.264 55% and VP6.2 45%!:D


PS: I believe that bond should replace the MainConcept sample picture with an Ateme one in "MPEG-4 Information (including AVC/H.264)"!:)

[kwtc]

Random notes about H264's deblocking filter:

- The encoder applies the deblocking filter to an encoded picture before using this picture for reference. Hence, if a stream was encoded with deblocking on, it is not possible to decode it with deblocking off, as in that case the reference pictures used by the encoder and decoder would not match, hence introducing a drift which could cause serious visual artefacts.

- The deblocking filter can be turned on or off for each individual picture of the stream. The deblocking strength can also be modulated for each picture.

- The filter is in itself adaptive; macroblock characteristics are used to choose a filter strength (there are five possible values) for a given macroblock. Characteristics taken into account includes motion vectors, macroblock type, number of coded coefficients, etc. As this selection is normative, it can't be changed.

- The filter is also controlled by two thresholds, alpha and beta, which depend on the macroblock quantizer value. The higher these values, the stronger the deblocking. The function which maps alpha and beta to a quantizer value is normative, and thus can't be modified.

- However, it is possible to specify an alpha_offset and a beta_offset. These offsets are used as follow :
alpha = quantizer_to_alpha_function(quantizer + 2 * alpha_offset);
beta = quantizer_to_beta_function(quantizer + 2 * beta_offset);
The norm specifies that these offsets must be bound between -6 and 6.
These offsets have a constant value for a given picture but may be changed from picture to picture.

- Thus, in Ateme's encoder, setting deblocking to -2 at q=24 gives threshold values equivalent to q=20 with deblocking set to 0. The table in a previous post given by bobololo lists the offsets used when the option -adaptdeblock is used.


I hope it is now clearer what can be and can't be done with the deblocking filter. The filter is itself is already adaptive; however, it is possible to fine-tune it's usage, for example by increasing deblocking on b frames, etc.

--- kwtc

[bond]

Originally posted by JohnV
Here's a part of the Nero Digital team on friday at IBC conference in Amsterdam:
http://www.hydrogenaudio.org/stuff/NeroDigitalTeam2.jpg

From left to right:
Tchi Southivong (bobololo) : Ateme
Xavier Castellan : Ateme
Pierre Larbier (babayaga) : Ateme
Ivan Dimkovic : Ahead
Cyril Fombonne :Ateme
Menno Bakker : Ahead
Jim Corbett : Ahead
Patrick Peeters : Aheadcool :)

its always fun seeing that people look totally different than you thought they are :D

[SeeMoreDigital]

Originally posted by bond
cool :)

its always fun seeing that people look totally different than you thought they are :D http://img87.exs.cx/img87/6678/SMD_NeroDigital_Team.jpg Yep, it certainly is!


Cheers

[bill_baroud]

Originally posted by Bulletproof
try using no denoising at all

already no denoising at all, just the clip i linked with a ConvertToYV12() ...

can you provide screenshots ?

well, i don't have any here, but you can dl the original and see for yourself ;)
and i tested with and without -cartoon, with more or less no effect (taking chroma into account for motion estimation (?) won't do some magical things)
and remember this is 834x480, not 640x***, 1.5Mbits is quite light (xvid is far from perfect too, but h264 is worse)

[Manao]

I did encode it ( both with XviD and Nero ), that's why I asked for screenshots. The quality of the XviD encode is already very good at 1.5 mbit ( without resizing ), except for a slight blocking ( which disappear with deblocking postprocessing ), and a slight ringing.

The H264 clip is overall better to my eyes ( no ringing, no blocks, as sharp ), except perhaps on the part where the camera going fastly through the fog, and where perhaps XviD performs slightly better.

However, I don't use the same encoder version you're using, I don't know your exact settings, I don't know if tou're watching it on a flat screen or a CRT one ( I used a CRT, on which artifacts are far less visible ), and I may not have spotted artifacts you were seeing, hence I asked for screenshots.
remember this is 834x480, not 640x***, 1.5Mbits is quite lightI did HD ( 1280 x XXX ) encodes of the Hellboy and Kill Bill trailers at 1.5 mbit, and of the fight in Crouching Tigers, Hidden Dragon at 1.1 mbit, all three are fine :)
Edit : almost forgot taking chroma into account for motion estimation (?) won't do some magical thingsChroma represents a third of the information you want to compress, so taking it into account does improve things, especially on animes.

[RBF]

Looking at these pictures.
http://rbf.nm.ru/Nero_400_1.jpg - Ateme H.264
http://rbf.nm.ru/VP6_400_1.jpg - VP6.2
http://rbf.nm.ru/Real10_400_1.jpg - Real10
Everyone should see, that Ateme is more detailed than other codecs.
Also it is not necessary to add some noise in Ateme decoder.

[Andrey]

>>http://rbf.nm.ru/original_4.jpg - original
>>http://rbf.nm.ru/Nero_400_4.jpg - Ateme H.264
>>http://rbf.nm.ru/VP6_400_4.jpg - VP6.2
Very interesting screenshots.
I've always hate vp6 codec for it blureness and this screens prove it well.
But what is interesting, that vp6 maintain good detail level on water, where h264 fails.
Why is it so ? Any ideas ?
And the people on the boat looking better in the Vp6.2 file.
Seems that no. Colors are messed up in vp6 encode there, so it looks like it is better, but if you carefully examine, it is not, IMHO.

[Soulhunter]

- Source (http://img73.exs.cx/my.php?loc=img73&image=Sorce_300.png)

- Ateme (http://img73.exs.cx/my.php?loc=img73&image=Ateme_2500_300.png)

- XviD (http://img73.exs.cx/my.php?loc=img73&image=XviD_2500_300.png)

[Andrey]

Soulhunter, what bitrate did you used ?
Rather hard to compare.
IMHO (what I see):
1. XViD maintain more details on background (that at the right side of the face is obvious example)
2. h264 seems to be more detailed when looking at the man's face top. XViD have more details when looking at small scar? on the man's cheek...
I can not do a conclusion, what is better...

[bill_baroud]

Originally posted by Manao
I did encode it ( both with XviD and Nero ), that's why I asked for screenshots. The quality of the XviD encode is already very good at 1.5 mbit ( without resizing ), except for a slight blocking ( which disappear with deblocking postprocessing ), and a slight ringing.


wow O_o
even with full deblocking, i still see a lot of block with xvid (using like vhq4/bframe/treillis/H263)


The H264 clip is overall better to my eyes ( no ringing, no blocks, as sharp ), except perhaps on the part where the camera going fastly through the fog, and where perhaps XviD performs slightly better.

However, I don't use the same encoder version you're using, I don't know your exact settings, I don't know if tou're watching it on a flat screen or a CRT one ( I used a CRT, on which artifacts are far less visible ), and I may not have spotted artifacts you were seeing, hence I asked for screenshots.


hmm i used the beta 2 for this test, and a CRT to watch it too (dirt cheap iiyama non-diamontron).
btw, i used mpc + WMR7 (since om2 and wmr9 doesn't work) for (fullscreen) playback, what did you use ? perhaps it can change something.

for my 'best' settings, it was like : -qual extra -rcmode 2pass -br 1500000 -deblock 3 -adaptdeblock -psy 2 -cartoon -clref part,hpel,qpel (well i played with those last options, activing/desactiving things so i don't remember)

[Manao]

Do not disable any tools, especially those three one : without hpel, qpel and partition, you lose at least 3dB for the PSNR ( which is huge ).

My settings were "-cartoon -qual extra -deblock 0 -setef cabac,bpred" and I was using beta 3.5.

Edit : I doubt VMR7 was the culprit here, and I don't know which renderer I used ( it was at work, but it should be VMR9 or plain overlay ).

[Soulhunter]

@ Andrey

I used a bitrate of 2500kbps !!!

And yes, I came to the same conclusion as you...


Ateme "blurs" flat areas but keeps slightly more detail @ the rest !!!


But not only @ this picture and not only with this source, it happens nearly always...

Its something Ive noticed while comparing Ateme -vs- XviD @ "medium-high" bitrates !!!


So, is it good, or is bad...

Imo sometimes Atemes "quantization decisions" are not optimal !!!


Its the same with ya samples...

The green (trees/bushes/grass etc.) is relative much detailed but the water is quantized to much !!!


I would prefer a slight different scaling in favor of the "flat" arrears... :o


Bye

[Andrey]

To: Soulhunter
>>Ateme "blurs" flat areas but keeps slightly more detail @ the rest !!!
Oh ! I approove this conclusion :)
That is.
May be bobololo can make any comments ?

To: RBF
A bit offtopic, small question. I saw the screens of Night Watch you make - how compresable this movie is ? Can it be compressed to 1CD ?

[bobololo]

@SoulHunter: posting you screenshots is cool. It would be also great if you could give some comments about your pictures because we don't really know what is their purpose nor the encoding settings.

For instance, did you use -psy x ? These modes are intended to provide a better subjective perception that requires you to watch at the clip as it should be watched and it is not recommanded in such case to stare at the pictures and to do frame / frame comparisons.

[Soulhunter]

Originally posted by bobololo

@SoulHunter: posting you screenshots is cool. It would be also great if you could give some comments about your pictures because we don't really know what is their purpose...


IMO they fitted their purpose very well...

You know this "without any comment" pictures ???

I wanted to get a reply without affecting ppl anticipatory with my own conclusion... ;)


Originally posted by bobololo

...nor the encoding settings.

The encoding settings doesnt matter, but...

-qual extra -rcmode 2pass -br 2500000 -ref 9 -maxb 1 -clref deblock

I got the same effect with complete different setting as well !!!


Originally posted by bobololo

For instance, did you use -psy x ?

Yes, but I didn't noticed much difference !!!


Originally posted by bobololo

...it is not recommended in such case to stare at the pictures and to do frame / frame comparisons.

I can see this while normal playback as well (even @ my small 17" CRT) !!!

It was simply a "whispery" criticism, not more... ;)


Bye

[Sagittaire]

@ Soulhunter

Capture is useless and doesn't prove anything: bframe imply a local heterogeneous quality for XviD or H264. Conclusions for n frame aren't the same for n+1 frame or n+2 frame ...

2500 Kbps is a low bitrate for 720p encoding (certainely q4 for MPEG4 ASP with Bourne Trailer at 2500 Kbps and perhabs q25 for Ateme H264) ... perhabs adapt deblock must improve quality.

-qual extra -rcmode 2pass -br 2500000 -psy 2 -deblock 2 -adaptdeblock -cartoon -ref 5

[bobololo]

Originally posted by Soulhunter
IMO they fitted their purpose very well...

You know this "without any comment" pictures ???

I wanted to get a reply without affecting ppl anticipatory with my own conclusion... ;)


The encoding settings doesnt matter, but...
-qual extra -rcmode 2pass -br 2500000 -ref 9 -maxb 1 -clref deblock
I got the same effect with complete different setting as well !!!

Yes, but I didn't noticed much difference !!!

I can see this while normal playback as well (even @ my small 17" CRT) !!!

It was simply a "whispery" criticism, not more... ;)


Well, it seems I've been a little bit harsh in my previous post, sorry it wasn't an offense in anyway :) Actually I was asking for more info about the encoding that could explain what is going and try to see if there is something wrong. Obviously critics are welcomed and they're the purpose of this test since they can help us to improve the encoder. But still we need some details to be able to analyze the case :)

[Soulhunter]

Originally posted by Sagittaire

Capture is useless and doesn't prove anything: bframe imply a local heterogeneous quality for XviD or H264. Conclusions for n frame aren't the same for n+1 frame or n+2 frame...

But I wrote...
Originally posted by Soulhunter

But not only @ this picture...
Originally posted by Soulhunter

I can see this while normal playback as well...


Originally posted by Sagittaire

2500 Kbps is a low bitrate for 720p encoding...

Its only 720x576 anamorphic... ;)


Originally posted by Sagittaire

-qual extra -rcmode 2pass -br 2500000 -psy 2 -deblock 2 -adaptdeblock -cartoon -ref 5

Deblock 2 and cartoon-mode, seriously... :confused:

Ok, haven't used cartoon-mode for normal film sources yet, maybe it works !!!

But why are you suggesting deblock 2 ???


Bye

[Soulhunter]

Originally posted by bobololo

Well, it seems I've been a little bit harsh in my previous post, sorry it wasn't an offense in anyway :) Actually I was asking for more info about the encoding that could explain what is going and try to see if there is something wrong. Obviously critics are welcomed and they're the purpose of this test since they can help us to improve the encoder. But still we need some details to be able to analyze the case :)

- The source was the DivX HD trailer of the Bourne supremacy -> LanczosResize(720,576)

- Ateme settings -> -qual extra -rcmode 2pass -br 2500000 -ref 9 -maxb 1 -clref deblock

- XviD settings -> 2Pass (VHQ4) @ 2500kbps / MPEG / BVOP's 1-1-1 / Trellis / Chroma motion


But happens with different settings as well...

Wont say it looks worse than the XviD encode, only different !!!


Maybe some ppl wont agree...

But I prefer the way XviD "distributes" the detail much more than Atemes way !!!


Bye

[Sagittaire]

But why are you suggesting deblock 2 ???

-qual extra -rcmode 2pass -br 2500000 -psy 2 -deblock 2 -adaptdeblock -cartoon -ref 5

-qual: extra or best ...

-psy: psy 1 or psy 2 are very better for me ...

-deblock 2 (3 or 4 is perhabs better for me with adapt) -adaptdeblock: it's adapt deblock ... for low quant deblock is very light (for exemple with q20 deblock = -4) and stronger for high quant (for exemple with q30 deblock = -1)

-cartoon: not better for me but why not ...

-ref 5: 9 reference frame is useless ...

and read that ...


About deblocking
Random notes about H264's deblocking filter:

- The encoder applies the deblocking filter to an encoded picture before using this picture for reference. Hence, if a stream was encoded with deblocking on, it is not possible to decode it with deblocking off, as in that case the reference pictures used by the encoder and decoder would not match, hence introducing a drift which could cause serious visual artefacts.

- The deblocking filter can be turned on or off for each individual picture of the stream. The deblocking strength can also be modulated for each picture.

- The filter is in itself adaptive; macroblock characteristics are used to choose a filter strength (there are five possible values) for a given macroblock. Characteristics taken into account includes motion vectors, macroblock type, number of coded coefficients, etc. As this selection is normative, it can't be changed.

- The filter is also controlled by two thresholds, alpha and beta, which depend on the macroblock quantizer value. The higher these values, the stronger the deblocking. The function which maps alpha and beta to a quantizer value is normative, and thus can't be modified.

- However, it is possible to specify an alpha_offset and a beta_offset. These offsets are used as follow :
alpha = quantizer_to_alpha_function(quantizer + 2 * alpha_offset);
beta = quantizer_to_beta_function(quantizer + 2 * beta_offset);
The norm specifies that these offsets must be bound between -6 and 6.
These offsets have a constant value for a given picture but may be changed from picture to picture.

- Thus, in Ateme's encoder, setting deblocking to -2 at q=24 gives threshold values equivalent to q=20 with deblocking set to 0. The table in a previous post given by bobololo lists the offsets used when the option -adaptdeblock is used.


I hope it is now clearer what can be and can't be done with the deblocking filter. The filter is itself is already adaptive; however, it is possible to fine-tune it's usage, for example by increasing deblocking on b frames, etc.

--- kwtc

[Tommy Carrot]

Originally posted by Soulhunter
But I prefer the way XviD "distributes" the detail much more than Atemes way !!!

I still say that 'normal' quality mode gives a clearly more detailed result than best or extra modes (at the cost of stronger artifacts). I would advise to use it at higher bitrates, and imo it would be better in your test too.

Is it just me, or anyone else had this experience too?

[CruNcher]

@Tommy Carrot

yes im also expirience alot of prediction errors in high motion @ 700 kb/s with normal but it's hell fast 640x272 (20 fps) and gives better detail preservation then XviD with Vhq2,Qpel,Vhq B-frames and so on @ 13 fps im very impressed :) will post my results soon.

[Gabriel_Bouvigne]

-ref x test:
176x144@12.5fps, low motion content (camera café)

parameters: rcmode vbr

ref 1: 155.86kbps
ref 2: 155.14
ref 4: 154.55
ref 8: 154.19
ref 12:153.65
ref 14:153.61
ref 16:153.72

[bobololo]

Hi there,

The new beta 4 is coming with some cool stuff :

- Better intra/inter decision that provides higher coding efficiency (sharper and more fluent motion).
- RC improvement, it's more accurate and we should have less undersize.
- Strengthen the psycho level 2.
- New weighted prediction for fade transitions.
- Custom deblocking matrix.
- Slight speed increase (simd code optimisation).
- Fast 1st pass.

It should be available tonight.

[bill_baroud]

@Manao : ok, i tested with your settings (enabling part that is ;)) and i'm surprised by the quality boost ... now it's at least like xvid ... i disabled it in the first place, remembering some blocking talks in previous posts, i should have tested with the default settings first, my bad :O

waiting for the beta 4 to continue my tests now ;)

[Bulletproof]

Definite improvement with the new beta, in side-by-side comparisons I am seeing more detail in subtle areas. Darker areas do not block as much as they did in the last beta. Less ringing artifacts as well.

[Sirber]

Groovy!

Beta 4 has proven better quality than VP6 and XviD on that clip.

Beta 3: RV10, VP6, XviD, H264
Beta 4: RV10, H264, VP6, XviD

Still some little squares. RV10 is still to my eyes the winner since image Q is higher and sharper. Great effort :D

encavc.exe -i test.avs -o test.mp4 -qual extra -rcmode 2pass -br 600000 -psy 2 -maxb 3 -cartoon -ref 16 -deblock 4 -adaptdeblock

[CruNcher]

@Sirber
try -setef wpred

[Sirber]

Ouch, FPS dropped from ~8 to ~2 :eek:

About quality, it's a bit higher. I cannot say which one is better now :(

[CruNcher]

try normal mode (hell fast b-frames buggy) should give you +10 fps increase or good instead (b-frames ok) gives you arround +5 fps

[babayaga]

Originally posted by CruNcher
try normal mode (hell fast b-frames buggy) should give you +10 fps increase or good instead (b-frames ok) gives you arround +5 fps

There is an ongoing work on the b-frames decision in normal quality mode. This might help you a bit :)

[bobololo]

@RBF: Hey it seems that you're conducting your own feedback thread over there (http://forum.mediatory.ru/viewtopic.php?t=2615&start=0&postdays=0&postorder=asc&highlight=&sid=1fb1cc9b98489794266b7ce4e6537286) ;) It would be great if you could share with us the discussions established there, I definitely don't understand a word of Russian and babelfish doesn't perform very well ;)

[RadicalEd]

Impressive! The tweaks in beta 4 show a large improvement on my animated test sample. All signficiant visual defects have either been improved considerably or removed outright. Excellent work.
I'll be damned o_o after reviewing my other samples, it looks like... Ateme H.264 is just about on par with RV10. I didn't think I'd be saying that about any codec for a long time.

Also, what does "Direct Spatial MV Pred" do? It's displayed in the statistics during encoding as off and there seems to be no way to turn it on. I don't recall it being present in the previous versions.

[708145]

I encoded several HDTV trailers and compared beta3 with beta4 at 3 different bitrates (1.5, 2.0, 2.5Mbps).

Well, I must say I'm still a bit dissapointed about transparency! It was not possible for me to find settings that reduced the filesize of the original trailers (mostly WMV9, see M$ homepage) by a significant amount (say more than 30%) while still being transparent to the original. I blame this on me. Maybe someone has good suggestions for this purpose.

But I'm not complaining here: most streams look well while playing with 2Mbps (although being quite blocky at times.. but almost not noticable during playback) which is quite an achievement!

Exceptions are:
o Everquest trailer and Rules of attraction were blocky with 2.5Mbps! I will test higher adaptivequant and bitrate here.
o Robotica looks very good at 1.5Mbs even.

I'll check now if VQM reflects my subjective findings.
BTW does anybody know a tool which calculates something like "motion-VQM"? Thus taking into account that the HVS does not care about details in fast motion.

Further experiments:
o test this wpred tool
o play around with psy and test if VQM correlates with subjective feeling. Again: subjective test first, measurement later.
o play around with adaptivequant (I tend to use low values)
o compare best settings with best of what MPEG4ASP has to offer (XVID 1.1).
o test anime sources (I'm just starting with this so I might need help with suitable .avs for this). goal: "semi-perfect" 1CD 87min. anime.
...
and
o working on my DCTsmooth avisynth plugin! Which is quite an idle task unfortunately, IOW I don't have time to debug it :(

bis besser,
Tobias

[JohnV]

Originally posted by 708145
I encoded several HDTV trailers and compared beta3 with beta4 at 3 different bitrates (1.5, 2.0, 2.5Mbps).

Well, I must say I'm still a bit dissapointed about transparency! It was not possible for me to find settings that reduced the filesize of the original trailers (mostly WMV9, see M$ homepage) by a significant amount (say more than 30%) while still being transparent to the original. I blame this on me. Maybe someone has good suggestions for this purpose.

But I'm not complaining here: most streams look well while playing with 2Mbps (although being quite blocky at times.. but almost not noticable during playback) which is quite an achievement!

Exceptions are:
o Everquest trailer and Rules of attraction were blocky with 2.5Mbps! I will test higher adaptivequant and bitrate here.
o Robotica looks very good at 1.5Mbs even.

I'll check now if VQM reflects my subjective findings.
BTW does anybody know a tool which calculates something like "motion-VQM"? Thus taking into account that the HVS does not care about details in fast motion.

Further experiments:
o test this wpred tool
o play around with psy and test if VQM correlates with subjective feeling. Again: subjective test first, measurement later.
o play around with adaptivequant (I tend to use low values)
o compare best settings with best of what MPEG4ASP has to offer (XVID 1.1).
o test anime sources (I'm just starting with this so I might need help with suitable .avs for this). goal: "semi-perfect" 1CD 87min. anime.
...
and
o working on my DCTsmooth avisynth plugin! Which is quite an idle task unfortunately, IOW I don't have time to debug it :(

bis besser,
Tobias 2Mbit/s HDTV is very low. Try -rcmode 2pass -qual extra -cartoon -setef wpred -deblock 3 -adaptdeblock -psy 2 (or something, maybe add -ref 5 but it may not have effect)

[708145]

Originally posted by JohnV
2Mbit/s HDTV is very low. Try -rcmode 2pass -qual extra -cartoon -setef wpred -deblock 3 -adaptdeblock -psy 2 (or something, maybe add -ref 5 but it may not have effect)

I set up a script to test your settings.

I know that 2Mbps is quite low for HDTV but it's the same bpp as 900kbps SDTV. XVID produces very good results at 3Mbps, but we're looking for sth better here, aren't we? ;)

bis besser,
Tobias

[bobololo]

Originally posted by RadicalEd
Also, what does "Direct Spatial MV Pred" do? It's displayed in the statistics during encoding as off and there seems to be no way to turn it on. I don't recall it being present in the previous versions.

It's a way to compute mv predictor of direct mb. This one exploits spatial predictors (ie neighbour mb motion vectors). The other way is temporal prediction using motion vectors from collocated mb.

The temporal prediction gives better results than spatial prediction (less flicking/jumping blocks). However the spatial prediction has the advantage to speed up the decoder side especially on embedded device like DSPs.

For those who are curious you can enable the spatial prediction mode using the "-spmvpred" switch.

[thegeby]

I know that 2Mbps is quite low for HDTV but it's the same bpp as 900kbps SDTV. XVID produces very good results at 3Mbps, but we're looking for sth better here, aren't we?

As you might have seen, I have been looking at 720p/1080p encoding. My aim is to retain both original resolution and quality. Now a WMV 720 may be 6,5 Mb/s and I find that 4Mb/s at cbr fulfils my requirements. 3Mb/s has worked on some snips. I would not deliberately try to go much lower on cbr.

As JohnV suggests, a careful 2pass script could improve the results. In my experience Xvid can not deliver enough at 3 Mb/s. There are many resons to be annoyed at MS, but WMV is a very good codec and to expect double compression from Xvid, that is after all built on a previous generation codec (apologies to our Xvid gurus), seems a bit hopeful. Looking at comments on avsforum, original MPEG-2 HDTV seems to hover around 11-13 Mb/s for quality transmission

[RBF]

bobololo
Sorry, I not so well know English to write the big messages.
People which there discuss, have no codec. They state impressions about quality on the basis of screenshots. I post all screenshots also here.
It is forbidden?
And one more question. I can post a 30-seconds clip?