Ateme H.264 Beta - Quality Feedback

[bobololo]

This new thread is dedicated to the quality feedback only.

Please report here everything related to quality comments about the tools, optimal settings, prefered configurations, etc. Anything that could help us to improve the encoder quality wise should come here :)

-- bobololo.

[superdump]

With the release of Beta 3, the Ateme AVC encoder is maintaining a fairly stable state and now quality tuning can really begin. As such, bobololo requested that I produce an impartial review of the preceding quality-related discussion.

Please note that in this summary I have attempted to convey the tester’s view as accurately as I could. If I have made any misinterpretations or otherwise, don’t hesitate to contact me.

Initial findings were that not only did this codec have huge potential but it has a huge advantage over all other h.264 codecs to date in that it is both fast AND maintains high quality. One user notes that Ateme AVC is more watchable than x264. Motion more fluid and natural, blocking artefacts less pronounced when in-loop deblocking not used. Link (http://forum.doom9.org/showthread.php?s=&postid=539447#post539447)

The codec appears to be very scalable coping with a full range of bit rates and resolutions in most combinations. There were many findings of high quality at HD resolutions with surprisingly low bit rates or very good quality with high bit rates.

Some people noted that an output similar to XviD with constant Q2 with something like half the file size. Link (http://forum.doom9.org/showthread.php?s=&postid=539442#post539442) Another user noted similar results with a HD source. Link (http://forum.doom9.org/showthread.php?s=&postid=540704#post540704) Notice that even when really stressing the codec at 1000kbps for this HD clip, Ateme AVC still holds its own and maintains top-rank quality. Only WMV9 can keep up at this bit rate and XviD has fallen behind.

With beta 2 a comparable looking clip to ~Q3 XviD was made with Q27 in Ateme's AVC producing a bit rate saving of ~40%. Link (http://forum.doom9.org/showthread.php?s=&postid=541323#post541323) Again with beta 2 we have some impressive quality at very high bit rates. Link (http://forum.doom9.org/showthread.php?s=&postid=541065#post541065) And yet more comparisons made, this time between XviD Q4 with the 6of9 HVS matrix and Ateme AVC revealed that Q20 was similarly transparent with a 15-30% bit rate reduction.

Constant quant isn't really recommended however as it doesn't deliver the best quality at a certain file size which partially invalidates some further tests by Teegedeck of XviD with 6of9 HVS at ~Q4-Q5 versus "-qp 23 -adaptdeblock -deblock 3 -qual extra" show similar sized files with generally similar quality aside from a few artefacts in the AVC clip. Link (http://forum.doom9.org/showthread.php?s=&postid=540808#post540808)

Moving on from this the lower resolution, low bit rate findings were also very spectacular. Two 300kbps encodes of the same clip at 640x256 with 48kbps HE AAC audio can still look good. The former clip uses -deblock adapt, the latter -cartoon -deblock -2. The update was made as the latter setting gave a more agreeable output to JohnV on his TFT. Link (http://www.hydrogenaudio.org/stuff/OutOfTime_Ateme-h264_300kbps.mp4) Link (http://www.hydrogenaudio.org/stuff/OutOfTime_Ateme-h264_300kbps_inloop2.mp4)

Across four clips RBF found that Ateme AVC gave a more detailed output with less artefacts than VP6.2/VSS h.264/XviD at 400kbps with a resolution of 720x352. RBF had only used -qual normal for these clips, so it should be noted that -qual extra would make them look even better. :) Link (http://forum.doom9.org/showthread.php?s=&postid=540704#post540704)

One user even thought that their AVC encode looked better than the original! Their source was quite blocky on some mist and as such the deblocking filter dealt with this to the users liking. In beta two we had an incredible clip at 400kbps. Link (http://nero.ateme.com/beta_encodes/cathedral-beta2-400extra-crop-avc.mp4)

There was a lot of feedback about various settings and options and a number of bugs and suggestions for improvement. Remembering that this IS a beta codec we all expected this. One of the main issues with beta 1 and 2 has been the b-frame skipping decision being too aggressive and producing an output with jumpy blocks and jerky motion. This has been fixed for beta 3 and will be very welcome among the testers. The problem only occurred at low bit rates and seemed to be compensated when using high bit rates.

There has been a large amount of discussion regarding the level of deblocking that looks good with certain resolutions/quantisers/bit rates and this discussion continues. Beta 1 had an adaptive mode but the strength of it was completely out of the user's hands. Beta 2 introduced a graded adaptive deblocking method to allow tuning to suit the individual. This gave a good improvement but some suspect that there is something wrong with the implementation and that it sometimes acts too aggressively when not needed and sometimes too weakly when needed. Hopefully this will be looked at soon.

Deblocking is certainly a very powerful feature and, when tweaked, will be a valuable asset to this codec and other h.264 codecs. Teegedeck has an adaptive deblocking behaviour suggestion, as different quants require different levels of deblocking to maintain good quality. Quoted values were - qp 19: none, qp 20: -3, qp 21: -2, qp 22: 0, qp 23: 3. Link (http://forum.doom9.org/showthread.php?s=&postid=541431#post541431)

Not surprisingly, at low bit rates, increasing quality level DOES increase quality level drastically. Sometimes the best/extra quality improvements were debatable but most often extra was clearly better. At high bit rates (704x288 @ 1200kbps) one user found that -qual normal gave a better quality suggesting that it was sharper than good/best/extra.

Cartoon mode seems to work better all round, not just in cartoons, as it takes chroma information into account for various decisions. It may well be recommended to always use it if speed is not the primary consideration.

There were various comments about the rate control, both good and bad and sometimes a mix of the two. :) Bad quality in the last 10 seconds of a clip was noticed and it was reported by babayaga that this was to prevent an oversized output. This would not normally be noticeable in a full film situation as the end is very dark with credits but this method will be removed (due to 'unpopular demand' I suppose).

I personally noticed in my clip that low motion quality was much better than high motion quality and as such suggested an adjustment to the bias. The two-pass rate control was considered to not give constant quality according to some PSNR test comparisons made against the main rival codecs. There was a surprisingly bad quality output produced from a very high motion anime clip that was handled much better by other codecs. I suspect this is due to the aforementioned b-frame skipping but would be dealt by good rate control if the entire anime episode were to be encoded rather than just the start credits. The rate control in beta 3 has been improved so I look forward to testing this.

Hardly anyone could spot any difference between using one reference or multiple references; as such it seems to be a waste of time. Comments suggest that psycho visual level 1 helps with fades and faces and psycho visual level 2 looks about the same as psy1 but possibly slightly less quality due to removed detail. Poor quality was produced from a sharp/grainy/very detailed slow motion source with unnatural contrasts. Link (http://forum.doom9.org/showthread.php?s=&postid=541189#post541189)

Soulhunter noticed some strange artefacts on an 8000kbps 'Shuttle' encode but these have been fixed for beta 3.

Sagittaire tested some settings with SSIM and gave his opinions on which looked best to him. Link (http://forum.doom9.org/showthread.php?s=&postid=541561#post541561)

Finally, some blocks noticed on still areas and backgrounds but there is reduced ringing compared to XviD and good detail preservation noted. Link (http://forum.doom9.org/showthread.php?s=&postid=541348#post541348)

All in all it's been a very busy week or so at Ateme. They seem responsive to our feedback and very helpful with any queries, also the speed of development is shocking. Most of all I would like to thank them for producing a high quality next-generation codec.

[Sagittaire]

@ superdump
waaaaouu ... good job

@ Andrey

Originally posted by Andrey
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...

SSIM for deblock adapt (beta 2)

source HPII 640*272
~1700 Kbps with XviD q2 default setting


bitrate 600 800 1000
deblock off 75.26 79.59 83.12
adapt -6 75.46 79.68 83.11
adapt -4 75.46 79.68 83.11
adapt -2 75.47* 79.68 83.11
adapt 0 75.84 79.76* 83.11
adapt 2 76.45 80.21 83.24*
adapt 4 76.96 80.75 83.57
adapt 6 76.71 80.88 83.92

* Deblock activation treshold


Deblock for H264 is "adaptative". For low bitrate (high quant) treshold activation is low and for high bitrate (low quant) treshold activation is high. I think that for very high bitrate deblock is in practice off ...

[Sirber]

On my test clip, it's still heavily squary but it's less blicking. I can say it improved :)

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

[RadicalEd]

Happy to report that the B-frame adjustments in beta-3 did the trick; they now work flawlessley with animation. Quality is excellent, surpassing XviD and, in a closer race, WMV9. Real10 is still king of the hill in my initial tests, but I'll get back to that later when the -deblock 6 encode is finished.

Current settings are: defaults + -qual extra -psy 2 -deblock 4 -adaptdeblock -ref 10 -cartoon -rcmode 2pass

[superdump]

I just tested to see what the RC was like now. It's much better.

http://www.swains.plus.com/superdump/256fix.png

Of course, the red line is beta 3.

[Sirber]

It seems to use less in the begining and lots more at the end.

[everwicked]

Originally posted by superdump
I just tested to see what the RC was like now. It's much better.

http://www.swains.plus.com/superdump/256fix.png

Of course, the red line is beta 3.

Is the filesize close to identical?

The lines are almost identical so that could mean 2 things:
- the encoder used more bits
- the coding effiency increased since beta2

[superdump]

Originally posted by everwicked
Is the filesize close to identical?

The lines are almost identical so that could mean 2 things:
- the encoder used more bits
- the coding effiency increased since beta2 Filesizes are almost identical.

1.0.1.17: 21.5 MB (22,647,187 bytes)
1.0.1.19: 21.6 MB (22,653,868 bytes)

I used identical settings for both encodes, and 1.0.1.17 had the b-frame fix.

[Sagittaire]

@ Superdump and everwicked

http://www.swains.plus.com/superdump/256fix.png

if you observe in detail H264 beta 3 is just a little below for 75% of the frames then passes largely above for the last 25%: it's simply a very better RC repartition. I think Average and Overall PSNR will be very better for beta 3 in this case. Visually the end will be also very better quality ... ;-)

[superdump]

Originally posted by Sagittaire
@ Superdump and everwicked

http://www.swains.plus.com/superdump/256fix.png

if you observe in detail H264 beta 3 is just a little below for 75% of the frames then passes largely above for the last 25%: it's simply a very better RC repartition. I think Average and Overall PSNR will be very better for beta 3 in this case. Visually the end will be also very better quality ... ;-) Yes, yes, I can see that. I was just posting it to point out that the changed RC was working properly.

[SeeMoreDigital]

It's all getting rather exciting now.

I wish I could take part more in these tests but my main "encoding" PC is not behaving it's self properly and I have not had the time to format and start again!

Still, I wonder if bobololo could confirm whether the new NVE release will include a seeking fix for H.264/AVC in NeVideo.ax filter. And if NeAudio.ax filter will be accessible via all software players.

Plus... can we see some downloadable sample encodes in this thread please?


Cheers everyone

[bobololo]

Originally posted by SeeMoreDigital
Still, I wonder if bobololo could confirm whether the new NVE release will include a seeking fix for H.264/AVC in NeVideo.ax filter. And if NeAudio.ax filter will be accessible via all software players.

Plus... can we see some downloadable sample encodes in this thread please?

This is not a official confirmation, but I don't see any reason why the seek issue with ShowTime filters wouldn't be fixed by Ahead. I don't know when but hopefuly it should be done in the next update.

Regarding the samples, well a few clips were already posted. Did you catch them ?

[SeeMoreDigital]

Originally posted by bobololo
Regarding the samples, well a few clips were already posted. Did you catch them ? I got just two.

One by your good self and another by plonk420


Cheers

[babayaga]

Originally posted by superdump
Yes, yes, I can see that. I was just posting it to point out that the changed RC was working properly.

There was a significant change in the RC that might help "unexpected clips" to be much better, especially at the end.

At the same time, the strengh of the servo loops has been reduced since some of you prefer to have a more constant quality at the expense of a slightly higher size error.
We expect that the size error wil be kept bellow something like 150kB but there was not enough time to test extensively.

On some "pathological clips" (much too low target bitrate) like the one provided by Sirber, the quantiser climbs up to 51 and the RC is very confused. In this case there is a large oversize/undersize.
Handling such situation is on the way :-)

[Bulletproof]

Originally posted by RadicalEd
Happy to report that the B-frame adjustments in beta-3 did the trick; they now work flawlessley with animation. Quality is excellent, surpassing XviD and, in a closer race, WMV9. Real10 is still king of the hill in my initial tests, but I'll get back to that later when the -deblock 6 encode is finished.

Current settings are: defaults + -qual extra -psy 2 -deblock 4 -adaptdeblock -ref 10 -cartoon -rcmode 2pass

I believe the current cap on -ref is 5, I think someone from nero/ateme said that in the main thread. That should probably be written in the next beta's encavc.txt

[Sagittaire]

At the same time, the strengh of the servo loops has been reduced since some of you prefer to have a more constant quality at the expense of a slightly higher size error.

Acceptable error for me: 0.5% for maxi error target size


Bitrate 500 Kbits/s 1000 Kbits/s 1500 Kbits/s 2000 Kbits/s
size 88 092 Ko 176 185 Ko 264 277 Ko 352 370 Ko
+/- 440 Ko 880 Ko 1 320 Ko 1 760 Ko

XviD 87 920 Ko 175 928 Ko 264 232 Ko 352 360 Ko ... :)
RV10 88 362 Ko 176 397 Ko 264 780 Ko 353 382 Ko ... :)
VP6 89 542 Ko 178 532 Ko 266 106 Ko 354 322 Ko ... :o
WMV9 88 362 Ko 176 482 Ko 264 550 Ko 352 730 Ko ... :)
DivX5 88 614 Ko 176 972 Ko 265 094 Ko 353 100 Ko ... :)
DivX3 88 518 Ko 176 516 Ko 264 516 Ko 352 520 Ko ... :)


PS: test in progress for H264 ... :devil:

[RadicalEd]

Originally posted by Bulletproof
I believe the current cap on -ref is 5, I think someone from nero/ateme said that in the main thread. That should probably be written in the next beta's encavc.txt

I recall it being said that 5 is the practical maximum and gains above that were insignificant, but as far as I know there's no actual limit.

[bobololo]

Originally posted by SeeMoreDigital
I got just two.
One by your good self and another by plonk420

JohnV also posted some good stuff, check at the first page of the initial beta feedback thread.

[bobololo]

Originally posted by RadicalEd
I recall it being said that 5 is the practical maximum and gains above that were insignificant, but as far as I know there's no actual limit.

The max value supported by the spec is 16. But actually values higher than 5 don't help very much.

[Soulhunter]

Originally posted by SeeMoreDigital
I got just two.

One by your good self and another by plonk420


Cheers

Could mail ya a encode of the Matrix lobby chapter -> " if its allowed " !!!


Bye

[Teegedeck]

Originally posted by bobololo
The max value supported by the spec is 16. But actually values higher than 5 don't help very much.
Just to support that: As I still don't have time for testing perceived quality, I've made a simple filesize comparison (again the Matrix Revolutions HD trailer). Here are the bitrate-savings compared to the encode that only used 1 reference frame:

4 reference frames: 0.12% savings
8 reference frames: 0.14% savings
16 reference frames: 0.15% savings

Maybe the overall a bit disappointing results are due to the material. Has anybody else made comparisons on the effect of the number of reference frames?

I hope to have time in order to test whether reference frames perhaps influence quality in a positive way, soon.

And as I'm at it: Has anybody encoded clips with and without the -psy switch and compared the results? I could only see that -psy blurred the picture a bit but unfortunately it didn't seem to do anything else but that.

@bobololo & babayaga: Can you tell me how -adaptdeblock calculates? I'd like to know what deblocking-strength the -adaptdeblock settings I've used actually triggered.

[708145]

Originally posted by Teegedeck
Maybe the overall a bit disappointing results are due to the material. Has anybody else made comparisons on the effect of the number of reference frames?


Maybe someone has a high quality source of a music video? Should be easy to make use of several ref. frames with fast cuts.

bis besser,
Tobias

[Tommy Carrot]

I can confirm that the b-frames are working flawlessly, the pans are as smooth as they should. :)

Btw, i wondered which method does this codec use for b-frames: overquantizing, like in the mpeg1-2-4 codecs, or using the same quantizers as in the p-frames? Seems to me the latter, because i cannot find any quality-level difference between the continous frames, which would be sign of overquantized b-frames. In this case this codec can get compression gain with b-frames without any quality loss. :eek:

Bobololo, if this is not a secret, could you clarify this?

[Teegedeck]

XviD 1.1 doesn't have a quality loss with b-frames at b-frame-quant = (p-frame-quant x 1.5) + 1 either... B-frames shouldn't necessarily trigger a quality-loss when compressed stronger than p-frames; they're supposed to be compressed stronger.

[Tommy Carrot]

Originally posted by Teegedeck
XviD XviD 1.1 doesn't have a quality loss with b-frames at b-frame-quant = (p-frame-quant x 1.5) + 1 either... B-frames shouldn't necessarily trigger a quality-loss when compressed stronger than p-frames; they're supposed to be compressed stronger.

Perhaps not visible loss, but the b-frames still have higher quantizers. With the reference h.264 encoder, i could get significantly smaller filesizes with equivalent b-frame quantizers (xvid cannot do this), and i'm curious if this is the case here too.

[Lobuz]

Maybe without postprocessing in XviD it's not so noticable but with sharp elements with postprocessing it's still visibly chenging from sharp P frame to blured Bframe etc. Or maybe I will have to make a better test with that XviD 1.1

Regards
Lobuz

[Teegedeck]

I think this would move the thread off-topic. Please come over to the XviD forum if you want to discuss this thoroughly.

[bobololo]

Originally posted by Teegedeck Maybe the overall a bit disappointing results are due to the material. Has anybody else made comparisons on the effect of the number of reference frames?

I hope to have time in order to test whether reference frames perhaps influence quality in a positive way, soon.

Your observations match with our early findings that showed that only very special clips benefit from multi-reference. For instance the foreman_cif sequence gets an huge coding efficiency improvement when we have several references. In most of the cases, it helps very slightly and requires much more cpu power. That's why in our default configuration, we recommand only 1 reference frame.

Originally posted by Teegedeck
And as I'm at it: Has anybody encoded clips with and without the -psy switch and compared the results? I could only see that -psy blurred the picture a bit but unfortunately it didn't seem to do anything else but that.

You're right the psychovisual effects are relatively weak in our current implementation and we still need to work a lot in this field. This could explain why there is no much difference with or wihtout. Basically, with -psy 1 fade transition should be better encoded than without. Btw note that when evaluating psy enhancements (which are subjective), it's very important to look at the clip normally and not doing frame by frame comparison.

Originally posted by Teegedeck
@bobololo & babayaga: Can you tell me how -adaptdeblock calculates? I'd like to know what deblocking-strength the -adaptdeblock settings I've used actually triggered.

The final strength offset used for the deblocking is computed as follow : strength = base + delta[Qp]. Where <base> is the value passed to the -deblock argument, <Qp> the quantizer and delta[] an array defined as following :


-6, -6, -6, -6, -6, -6, -6, -6, -6, -6,
-6, -6, -6, -6, -6, -6, -6, -6, -6, -6,
-6, -6, -6, -6, -6, -5, -5, -4, -4, -3,
-3, -3, -2, -2, -2, -1, -1, -1, -1, -1,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
1, 1


Those values were choosen without any tuning, and we wanted to adjust them depending on your feedback :)

Regarding the deblocking, please check at my next post.

[bobololo]

Originally posted by Tommy Carrot
I can confirm that the b-frames are working flawlessly, the pans are as smooth as they should. :)

Btw, i wondered which method does this codec use for b-frames: overquantizing, like in the mpeg1-2-4 codecs, or using the same quantizers as in the p-frames? Seems to me the latter, because i cannot find any quality-level difference between the continous frames, which would be sign of overquantized b-frames. In this case this codec can get compression gain with b-frames without any quality loss. :eek:

Bobololo, if this is not a secret, could you clarify this?

Ok without going in-depth, we quantized bframes more than other frames :)

[bobololo]

Now that the encoder has achieved a fairly stable state, we can at last discuss about quality tuning :) And I'd like to first have your feedback about the famous inloop deblocking filter and especially when the adaptive deblocking is enabled.

As it was already said, the adaptive deblocking is based on the quantizer used to encode a frame. The very simple idea behind this is to say that when the frame is highly compressed, it has more chance to show blocking, so I need to increase the delobking strength to hide the artefacts. The same applies to the opposite case.

Considering this, bframes have a higher deblocking strength. Do you feel that when watching at the encode ? Do you have the impression that there is a smoothness variation between different frame type or is it invisible for you ? The reason for this query is to know if we need to have separate strength for different frame type.

Secondly I'd like your opinion about this adapative scheme. Have you ever meet cases where the picture is higly quantized but you prefer that only a light deblocking to be applied to it ? In such case we should take into account other parameters than quantizer to compute the deblocking strength.

Last but not least, I was thinking about providing the users with the abilities to set "custom deblocking strength matrix" ;). This means that the users can choose themselves the strength to apply function of the picture quantizer. Do you think this can be useful ?

[Bulletproof]

It might be a good idea for the adaptive deblocker to test to see how dark or how bright a frame is, very dark scenes tend to handle deblocking badly and bleed/blur away into the dark background. Or maybe an option to specify when the deblocker kicks in, like an initial QP setting to set, for example I want to encode something and only want the deblocker to work if a quantizer of 32 or more is being used, and if above 32 the adaptive engine will determine how much to deblock and what deblocking cap i specified. Different deblocking settings for I,P,B frames, like -2 for I frames, -1 for P frames, 1 for B frames, this may make quality unstable however, I'm just bouncing thoughts which you may be able to improve on.

[plonk420]

Originally posted by 708145
Maybe someone has a high quality source of a music video? Should be easy to make use of several ref. frames with fast cuts.

bis besser,
Tobias

i've been working on this very thing... and it's murdering h264 ;) .. it's pretty unique for a musicvid, tho.

bobololo, i'm uploading it to the ftp now or pretty soon. be careful posting this clip; it appears to be released on an RIAA-controlled label, so posting the entire clip might not be the greatest idea (i could care less if you post the whole thing or not .. it's a freakin' sweet musicvideo and has some codec-wrecking sections). i think HydrogenAudio has found 30 seconds to be safe for any music. you could probably get away with as many 30 second clips as you want to, but i'd suggest 0:53 to 1:24 and 2:55 to 3:25

http://www.magnetbox.com/riaa/search.asp?searchtype=AsinSearch&keyword=B0000641QR

[yaz]

vow vow vow ... what's on ? just gone for some holiday and coming back for this ... how could i miss it ?
having read all threads of 'ateme' i found it quite exiting. is it possible to join in to this testing somehow ? i know i know, deadline's over but maybe ... (pls pls:-)
thx
y

[Sagittaire]

@ African Brothers ... ;-)

I have always problem with block flicking in low motion ... sniff
-qual extra -rcmode 2pass -br 1024000 -psy 2 -deblock 4 -adaptdeblock -ref 5 -priority idle

Perhabs deblock transition bframe-pframe problem ... ???

For this particular problem a capture is useless... but I can post samples if you want ... ???

[bobololo]

Originally posted by Sagittaire
@ African Brothers ... ;-)

I have always problem with block flicking in low motion ... sniff
-qual extra -rcmode 2pass -br 1024000 -psy 2 -deblock 4 -adaptdeblock -ref 5 -priority idle

Perhabs deblock transition bframe-pframe problem ... ???

For this particular problem a capture is useless... but I can post samples if you want ... ???

We've worked on the block flicking aspect and we've obtained fairly good improvement in this field. The encodes are more stable now. This will be included in the next beta !

[Teegedeck]

Originally posted by bobololo
Last but not least, I was thinking about providing the users with the abilities to set "custom deblocking strength matrix" ;). This means that the users can choose themselves the strength to apply function of the picture quantizer. Do you think this can be useful ?
Very useful indeed! That way I would feel way more comfortable, knowing that I can assign just as much deblocking as necessary/justifiable to a quantizer. Also, I'm lousy at maths and couldn't derive anything from the formula you've posted. :o

[Selur]

did some extrem clip watching the last hours and for psychvisuals I can say:

I prefer psy 1&2 over psy 0 and I can't see a difference between psy1 and psy2 unless I do a fram-to-frame comparison. So for me psy 1 is the way to go. ;)

I also prefer maxb 1 oder maxb 2&3, since they seem sometimes to be too smooth. :)

Cu Selur

[superdump]

Originally posted by bobololo
The final strength offset used for the deblocking is computed as follow : strength = base + delta[Qp]. Where <base> is the value passed to the -deblock argument, <Qp> the quantizer and delta[] an array defined as following :


-6, -6, -6, -6, -6, -6, -6, -6, -6, -6,
-6, -6, -6, -6, -6, -6, -6, -6, -6, -6,
-6, -6, -6, -6, -6, -5, -5, -4, -4, -3,
-3, -3, -2, -2, -2, -1, -1, -1, -1, -1,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
1, 1


Those values were choosen without any tuning, and we wanted to adjust them depending on your feedback :)

Originally posted by Teegedeck
Very useful indeed! That way I would feel way more comfortable, knowing that I can assign just as much deblocking as necessary/justifiable to a quantizer. Also, I'm lousy at maths and couldn't derive anything from the formula you've posted. :o

Right, say you use -deblock -4 -adaptdeblock, -4 is the base. delta[Qp] is a delta value taken from that list bobololo posted which is related to the quantiser used for the frame. The list starts from Qp 0 and should go to Qp 51. So to decide the frame deblocking strength the delta[Qp] is referenced from that quantiser-delta list and then individual frame deblocking strength = base + delta[Qp].

Originally posted by Teegedeck
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

Your deblocking as such is not adaptive as all frame in your sequences have the same quantiser. The delta[Qp]s for your suggested quants are ALL -6. As such your suggestions for the level of deblocking imply strengths of:

Qp 19 : none (I imagine you mean -clref deblocking was used)
Qp 20 : strength = -3 + (-6) = -9 = off? (or does it just clip to -6?)
Qp 21 : strength = -2 + (-6) = -8 = off?
Qp 22 : strength = 0 + (-6) = -6
Qp 23 : strength = 3 + (-6) = -3

So, if when the strength is below the defined lower bound of -6 the deblocking is disabled, deblocking only kicked in at Qp 22. However I obviously haven't considered b-frames and their overquantisation. As such it would probably kick in earlier and this would be the effect that you'd notice. I hope that helped. :) Sorry if I was at all patronising, I just intended to be thorough.

EDIT: I have been informed by bobololo that the strengths of -9 and -8 would be clipped to -6.

[Sagittaire]

@ Superdump

re-good job ... :D

@ Bobololo

with adaptdeblock
strength = base + delta[Qp]

Without adaptdeblock
strength = base ? ... if correct it's possible to make our personal matrix ... ;-)

You want that we done our personal preference for the matrix adaptdeblocking?


Considering this, bframes have a higher deblocking strength. Do you feel that when watching at the encode ? Do you have the impression that there is a smoothness variation between different frame type or is it invisible for you ? The reason for this query is to know if we need to have separate strength for different frame type.


perhaps that two custom different matrix for the I,P frame and the bframes could be a good idea

strength = base + delta-p[Qp]
strength = base + delta-b[Qb]

[CruNcher]

0-24 = -6
25-26 = -5
27-28 = -4
29-31 = -3
32-34 = -2
35-39 = -1
40-51 = 1

for all who can't read it it's simple as that :)

[plonk420]

i've been playing with
-best
-extra
-extra -psy1
-extra -psy2
i also start at a moderate bitrate and increase/decrease by 200kbps (or start at a low bitrate and increase it by either 80 or 200kbps) for each trial but i'm getting a bit bored with those...

what combination of settings are you guys playing around with and comparing? i'd like to set up a batch and let it chug away as i'd rather play with complete clips (2pass vbr because the encoder can distribute the bitrate better). i don't really understand the deblocking modes or quantizer (haven't played with them); could someone give me a set of switches that might be good with whatever bitrate would go well to test them with (high, med, low bitrates considering the clip)?

[bobololo]

A quick post to provide some fresh info :)

- We've squeezed out a little bit more coding efficiency by tuning encoder internals. As a result our latest encodes showed even more sharpness than before.

- We'll be at the IBC Show at Amsterdam for the week end. So if you have the chance to be there, don't hesitate to visit us. We'll be present on several booths including Ahead, AVC Alliance, Texas Instrument, etc...
We should demonstrate cool stuff there ;)

- The next beta is expected next week with all our latest improvements.

-- bobololo.

[Sagittaire]

Last but not least, I was thinking about providing the users with the abilities to set "custom deblocking strength matrix" . This means that the users can choose themselves the strength to apply function of the picture quantizer. Do you think this can be useful ?


Very good idea ... ;-)

and if possible integer PSNR metric command with name in output ... for exemple -PSNR "H264-500"

[RBF]

I made comparison on very difficult-coding material.
Bitrate - 700kbit/s,
At XviD almost all frames are compressed with quantizer 31
At VP6 many frames are compressed with quantizer above 31
At Ateme the majority of the frames are compressed with quantizers from 30 up to 40

Core encoder version 1.0.1.19

Input file : night.avs
Output file : night700.mp4
Resolution : 688x544 @ 25.00 fps
Length : 3002 Frames
Process Priority : Normal
Rate Control : 2pass
Target Bit Rate : 700 kb/s
Quality : Extra
Init Quantiser : 24 [0 - 51]
Max Consecutive BFrames : 3
Deblocking Strength : -2
Num Reference : 1
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 3002 frames processed @ 5.08 fps
-- Start processing pass 2 / 2
* 03001: encoding @ 5.81 fps - bitrate 917.03 kb/s - 100.00% completed
* 3002 frames encoded @ 5.19 fps - average bitrate 700.98 kb/s

Encoding complete

Xvid with the switched - off postprocessing - http://rbf.nm.ru/xvid_700.jpg
Xvid with maximum postprocessing - http://rbf.nm.ru/xvid_700_max.jpg
VP6 with the switched - off postprocessing - http://rbf.nm.ru/VP6_700.jpg
VP6 with automatic postprocessing - http://rbf.nm.ru/VP6_700_auto.jpg
Ateme - http://rbf.nm.ru/nero_700.jpg>
The original - http://rbf.nm.ru/original_700.jpg

[JohnV]

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

Here's a part of the Nero Digital team on friday 10th 2004 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 : Ahead

[SeeMoreDigital]

Nice one JohnV :D

Hey, could you amend your link so their "ugly mugs" are visible 24/7?

It's nice to link names with faces...

Does anybody have any photos like this of other forum members? Maybe we should start a new thread?

I wonder if we can get a photo of Doom9, from "over the rainbow"?


Cheers

[aketon]

Originally posted by RBF
I made comparison on very difficult-coding material.
Bitrate - 700kbit/s,
At XviD almost all frames are compressed with quantizer 31
At VP6 many frames are compressed with quantizer above 31
At Ateme the majority of the frames are compressed with quantizers from 30 up to 40

Core encoder version 1.0.1.19

Input file : night.avs
Output file : night700.mp4
Resolution : 688x544 @ 25.00 fps
Length : 3002 Frames
Process Priority : Normal
Rate Control : 2pass
Target Bit Rate : 700 kb/s
Quality : Extra
Init Quantiser : 24 [0 - 51]
Max Consecutive BFrames : 3
Deblocking Strength : -2
Num Reference : 1
Psychovisual : 0
Cartoon mode : Off
Features : ipred ppred bpred cabac deblock hpel qpel part

-- Start processing pass 1 / 2
* 100.00% completed
* 3002 frames processed @ 5.08 fps
-- Start processing pass 2 / 2
* 03001: encoding @ 5.81 fps - bitrate 917.03 kb/s - 100.00% completed
* 3002 frames encoded @ 5.19 fps - average bitrate 700.98 kb/s

Encoding complete

Xvid with the switched - off postprocessing - http://rbf.nm.ru/xvid_700.jpg
Xvid with maximum postprocessing - http://rbf.nm.ru/xvid_700_max.jpg
VP6 with the switched - off postprocessing - http://rbf.nm.ru/VP6_700.jpg
VP6 with automatic postprocessing - http://rbf.nm.ru/VP6_700_auto.jpg
Ateme - http://rbf.nm.ru/nero_700.jpg>
The original - http://rbf.nm.ru/original_700.jpg


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

[JohnV]

He has cartoon mode off which would take chroma values into account in decision making, doesn't use adaptive deblocking and maybe a bit higher offset for deblocking could be used. I'd try using these things and psy 1 for better quality.

Accoding to bobololo Beta4 will have again higher efficiency so it will be interesting. :)

[RBF]

Originally posted by aketon
VP6 is much better than the others!!!

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

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

[Andrey]

Hey it seems that you're conducting your own feedback thread over there
I wouldn't tell that it is feedback, he simply share screenshots and people can discuss them...
I hope it will not break an agreement...
Personally, I like to discuss such a things like perceptual quality in native language too...
EDIT: RBF was faster :)

[bobololo]

@RBF, Andrey: There is no problem with the thread on your Russian board. I was only frustrated to know that you're discussing about the encoder and not be able to understand what was said over there :)

[708145]

Originally posted by thegeby
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

I was not saying WMV9 and ASP are comparable. I was not expecting transparency from XVID at 3Mbps. I just stated that XVID "produces very good results at 3Mbps". BTW I'm currently watching video with an angle of 23° on a TRINITRON. :(

I'm gonna test this XVID clip on a flatscreen later today. :)
Too bad I can't play those AVC encodes there :(

I used 2pass and whole clips.

bis besser,
Tobias

[thegeby]

BTW I'm currently watching video with an angle of 23° on a TRINITRON.

I know what you mean, my best computer, and the only one that handles 1080p repectably, is hooked up to a 10-year old Sony 25" via S-Video as the HTPC monitor. My best screen is hooked up to a 1.8 Celeron:D

[Sagittaire]

HDTV bitrate with MPEG2

For calculate bitrate equivalence in HDTV resolution with DVD resolution I use two mathematical formulation:
bitrate/(pixels*fps)
bitrate/(pixel^(3/4)*fps) -> very better estimation

DVD MPEG2 720*480*30 use generaly ~5 Mbps for Average Bitrate
0.48 bit/pel
11.69 Qs

HDTV MPEG2 1280*720*30 with equivalent quality for each pixel
0.48 bit/pel -> ~13 Mbps
11.69 Qs -> ~10 Mbps

HDTV MPEG2 1920*1088*30 with equivalent quality for each pixel
0.48 bit/pel -> ~30 Mbps
11.69 Qs -> ~19 Mbps


HDTV bitrate with MPEG4

MPEG4 and clone (MPEG4 ASP, MPEG4 AVC, VP6, WMV9, RV10) are very better codec than MPEG2 especialy for high resolution. MPEG4 and clone use ~ +/- bitrate/2 for equivalent quality with MPEG2:

MPEG4 720*480*30 ~2.5 Mbps for Average Bitrate
0.24 bit/pel
5.84 Qs

HDTV MPEG4 1280*720*30 with equivalent quality for each pixel
0.24 bit/pel -> ~6.5 Mbps
5.84 Qs -> ~5 Mbps

HDTV MPEG4 1920*1088*30 with equivalent quality for each pixel
0.24 bit/pel -> ~15 Mbps
5.84 Qs -> ~9 Mbps

[thegeby]

I don't want to go off topic but this is a recent quote from AVS forum

"I took a quick sample and got the following...

HBO HD 13.9mb/s
Showtime HD 6.5mb/s (lowest I've ever recorded)
HDNet Movies 7.8mb/s (lowest for HDNet Movies I've ever recorded)

These were 5 minute samples, so I'll definitely need to collect more data, but it appears they are giving HBO more bandwidth than the other two."

Full HDTV is, as you say, 19 Mb/s, but there is no guarantee that is what you get.;)

[Sagittaire]

RE HS ... sorry Bobololo and Babayaga


HBO HD 13.9mb/s
Showtime HD 6.5mb/s (lowest I've ever recorded)
HDNet Movies 7.8mb/s (lowest for HDNet Movies I've ever recorded)


Joey on NBC HDTV 1080i 14.0 Mbps for Average Bitrate from little transport stream sample ...

little capture in High Motion start credit
http://jfl1974.free.fr/Video/Joey-NBC-HDTV.jpg

and

http://jfl1974.free.fr/Video/Capture-Joey.JPG

No Comment ...

DVD forum choose HD-DVD with "blue ray technologie" because DVD9 are unable to contain 120 min of 1080i/p MPEG2 ...

- Codec: MPEG2 HP@HL, H264 or WMV9
- Resolution Max 1080i/p with 30 fps, 720i/p with 60fps
- Capacity: HD-DVD single layer 15 GB, HD-DVD dual layer 30 GB


MPEG2 codec

MPEG2 576p ~ 5 MBps
DVD5: 120 min
DVD9: 220 min
HD-DVD15: 400 min
HD-DVD30: 800 min

MPEG2 720p ~ 10 MBps
DVD5: 60 min
DVD9: 120 min
HD-DVD15: 200 min
HD-DVD30: 400 min

MPEG2 1080p ~ 19 MBps
DVD5: 30 min
DVD9: 60 min
HD-DVD15: 100 min
HD-DVD30: 200 min


H264 or WMV9 codec

H264/WMV9 576p ~ 2.5 MBps
DVD5: 240 min
DVD9: 440 min

H264/WMV9 720p ~ 5 MBps
DVD5: 120 min
DVD9: 220 min

H264/WMV9 1080p ~ 9 MBps
DVD5: 70 min
DVD9: 130 min


HD-DVD could contain H264/WMV9 encoding in 1080i/p 30 fps or 720i/p 60 fps with ~19 Mbps for ~200 min of video: for these codec it's a low quantizer and ultra high quality preset ... it's practically a lossless quality ...

[Soulhunter]

http://jfl1974.free.fr/Video/Capture-Joey.JPG

Gah, are you sure its not LDTV... :sly:

Btw, the new beta rocks !!!


Bye

[bobololo]

Here is a nice contribution from SoulHunter :

http://nero.ateme.com/beta_encodes/TheBourneSupremacy@1000kbps.mp4

Enjoy :)

[SeeMoreDigital]

Wow, Soulhunter that's so cool.

Thanks bobololo for posting the clip and I'm so sorry I've not able to take a more proactive roll :(

As soon as my current crop of work is completed I'll format my PC and hopefully have a more stable PC to commence testing...

I'm still reading the posts and testing the clips and look forward to more releases as and when they arrive.

Keep up the good work guys....

My apologies again.

[Sagittaire]

with Bobololo authorization

Test preview: little Matrix reloaded sample 500 Kbit/s

Source from Matrix Reloaded PAL 720x576 16/9 MPG2 MP@ML 6150 Kbps chapter 20 to 26. ~2000 Kbit/s with XviD q2 default setting.

H264 sample (http://jfl1974.free.fr/Video/Sample-H264-500.mp4)
VP6 sample (http://jfl1974.free.fr/Video/Sample-VP6-500.avi)
RV10 sample (http://jfl1974.free.fr/Video/Sample-RV10-500.rmvb)
WMV9 sample (http://jfl1974.free.fr/Video/Sample-WMV9-500.avi)
XviD sample (http://jfl1974.free.fr/Video/Sample-XviD-500.avi)
DivX5 sample (http://jfl1974.free.fr/Video/Sample-DivX5-500.avi)

H264 Ateme setting:
-qual extra -rcmode 2pass -br 512000 -deblock 0 -ref 5 -setef wpred -cartoon -psy 1 -priority idle

H264: 41.9397 dB
VP6: 41.5968 dB
RV10: 41.0143 dB
WMV9: 40.7542 dB
XviD: test in progress
DivX: test in progress

http://jfl1974.free.fr/Video/H264vsVP6-500.JPG

... and here my new signature

[IgorC]

Thanks to Sagittaire. I beleive to his comparation always. There are a lot of fails comparations without any sentence. So I'm downloading.

[IgorC]

Seems like decoder of Neroshowtime doesnt support beta 4. :confused:

[Manao]

Sagittaire used "weighted prediction" which is not supported by the Nero Showtime filters.

Edit : I may be wrong, wait for bobololo's confirmation.

[SeeMoreDigital]

Originally posted by IgorC
Seems like decoder of Neroshowtime doesnt support beta 4. :confused: It should do. It works here. Except the seeking is b0rked. Which is a known problem!

Nice encode Soulhunter. I like that you decided to used an PAL DVD pixel frame size with AR signalling... very cool!

The codec copes particularly well will the "flash" transition scenes...


Cheers

[Soulhunter]

Originally posted by SeeMoreDigital

Nice encode Soulhunter. I like that you decided to used an PAL DVD pixel frame size with AR signaling... very cool!

The codec copes particularly well will the "flash" transition scenes...


Yes, considering the relative low bitrate it looks amazing !!!

XviD changed my mind about encoding, Ateme could do the same... ;)

Anyhow, for "real" backups I would aim for bitrates around 2500 kbps !!!


@ All

About the final release...

I would prefer a simple standalone (AVS2MP4 GUI) version instead of a Recode2 "inbuild" one !!!


Bye

[SeeMoreDigital]

Originally posted by Soulhunter
...Anyhow, for "real" backups I would aim for bitrates around 2500 kbps !!! Well I'm kinda hoping that we'll all be able to generate AVC encodes at lower bit-rates than this!

Obviously, when generating encodes from short sources, it's difficult to assess how well AVC will perform with an full movie back-up!

For those of us who may have 1CD back-ups of say, an 90-100min movie, generated in 2pass DivX or XviD at 720x480 or 720x576 (ie:1:1), I think it would be interesting to generate some of those movies again using Ateme's AVC in 2passes.

Personally I've never been a big fan of comparing an codecs performance using anything less than an 1:1 pixel frame size (PFS)... As it's always been my opinion that a codec should be made to work hard and look good when viewed on a big screen.... just as with an DVD.


Cheers

[LostMP4]

Originally posted by Soulhunter
About the final release...

I would prefer a simple standalone (AVS2MP4 GUI) version instead of a Recode2 "inbuild" one !!!

Would you like to pay Ateme for that?
I guess they sell their codec to Ahead, it's not a gift and on Ahead side it looks like they love to create a lot of GUIs and spread different functionalities in different programs in a random way :P

[JohnV]

Originally posted by LostMP4
Would you like to pay Ateme for that?
I guess they sell their codec to Ahead, it's not a gift and on Ahead side it looks like they love to create a lot of GUIs and spread different functionalities in different programs in a random way :P I don't think it's so simple that Ateme just sells the codec to Ahead and that's it. Nero Digital is a co-operation and co-development of both Ateme and Ahead, and Ateme is behind the Nero Digital concept as well.

[Soulhunter]

Originally posted by SeeMoreDigital

Well I'm kinda hoping that we'll all be able to generate AVC encodes at lower bit-rates than this!

Keep in mind that my usually XviD bitrates are somewhere between 3000-4000 kbps... :D

Btw, Im also not able to play Sagittaire's H264 sample via NeroShowtime player !?!

But playback through MPlayer using the Ateme filters works... :confused:


@ LostMP4

Maybe as a small bonus that comes with Recode2 then... :rolleyes:

Or someone here codes a gui (as besweet/aac) ???


Bye

[Mr_Schizo]

I encoutered some very bad issues with blue and red colours(damn heavy blocking even with strong inloopdeblocking), i know it's caused of the YV12 colourspace but it's definitely worse than it's competitors. I hope you can improve something in that area (maybe a simple and cheap converttorgb in the dshow filter or a chroma optimizer filter like in XviD).

see yah at #mpeg ;)

[CruNcher]

Sagittaire used "weighted prediction" which is not supported by the Nero Showtime filters.

jep it was added in beta4 and since then no update for the nero filters so weighted prediction is not supported in the nero filters @ the moment.

@Soulhunter
im happy with encavc :D and maybe a linux version of it *dreams*

@Mr_Schizo
chroma optimizer has nothing todo with this problem its basicly for overlayed text messages aka subtitles.

[Soulhunter]

Originally posted by Mr_Schizo

I encountered some very bad issues with blue and red colors(damn heavy blocking even with strong inloopdeblocking), i know it's caused of the YV12 colorspace but it's definitely worse than it's competitors.

If its chroma subsampling related, it shouldnt look worse than XviD !!!

As the same subsampling is used for XviD, it should look equally...

Could you maybe provide a screenshot to visualize the problem ???

You can upload it here... (http://www.imageshack.us/index.php) ;)


Originally posted by Mr_Schizo

I hope you can improve something in that area (maybe a simple and cheap converttorgb in the dshow filter...)

Yeah, would like to have this option for all decoder that deal with subsampled content !!!

Or maybe a option to choose a different renderer in the Nero Showtime player... :rolleyes:


Bye

[SeeMoreDigital]

Originally posted by Soulhunter
Btw, Im also not able to play Sagittaire's H264 sample via NeroShowtime player !?!

But playback through MPlayer using the Ateme filters works... :confused: Yes, you're right... It appears our software media players "cannot allocate memory because no size has been set" in Sagittaire's encode... ooops!


Cheers

[bill_baroud]

Originally posted by Soulhunter

Or someone here codes a gui (as besweet/aac) ???


????? (http://moodub.free.fr/h264gui.gif) :p :whistle:

although it's not (really) working (yet) and not usefull (remember that the beta software is watermarked or something ...)

[SeeMoreDigital]

I like GUI's :D

[JohnV]

Ok, now we get down to the business.. :D
Here's Jessiqa Pace from San Diego, California, a swim suit model.

Beta4 1600kbps high resolution 960x528 clip 30 fps. Encode done by plonk420.
http://www.hydrogenaudio.org/stuff/venus-beta4-1600-avc.mp4

Enjoy! :)

[plonk420]

don't forget about the comparison xvid...
http://plonkmedia.com/venus-pass2-1600-mp3audio.avi

[charact3r]

Quick question to give me some perspective to your comments as I can't find this codec for downlad: which H.264 profile is this codec closest to: baseline or main? Is it using CABAC or CAVLC?

Thanks for an answer :)

[CruNcher]

@charact3r
it supports both and all tools under that are cavlc and cabac

[SeeMoreDigital]

That's a very clean looking encode plonk420 - as is the subject matter!

There certainly appears to be more detail present, especially during the first few seconds.

Although your XviD comp file was encoded using Mp3 audio at 160Kbps compared to your AVC's encode at 128Kbps. I doubt the XviD video stream would have benefited much with an additional 32Kbps!


bobololo,

I've noticed that in the current version of the ShowTime player, when you select "Show Additional Info" under the players "Options" the bitrate for AAC audio is not displayed.

Also there does not appear to be a way of finding out the pixel frame size or PAR/DAR of an encode. Can this be incuded at some time in the future?


Cheers

[Mr_Schizo]

Originally posted by Soulhunter
If its chroma subsampling related, it shouldnt look worse than XviD !!!

As the same subsampling is used for XviD, it should look equally...

Could you maybe provide a screenshot to visualize the problem ???

You can upload it here... (http://www.imageshack.us/index.php) ;)

It doesn't have to look equally to XviD or any other codec. It's also dependend from the quantisation* and some other factors.

*(higher bitrates can improve such areas, so it's dependend from the bitspending which a codec offers to these areas)

I could provide you some screenshots but they weren't as meaningfull as some 100kb of videomaterial from atemes encoder against a few kb of XviD's output.
But that needs bobo's permission which i can't get as long as i can't find him :rolleyes: .

so stay tuned ;)

[bobololo]

Sagittaire just noticed me about his codec comparison update which now includes beta 4 :

http://jfl1974.free.fr/HTM/32_Test_Codec_Video.htm

Quite interesting since he seems to share the same opinion that most of the feedback posted here ;)

[babayaga]

Originally posted by Sagittaire

H264 Ateme setting:
-qual extra -rcmode 2pass -br 512000 -deblock 0 -ref 5 -setef wpred -cartoon -psy 1 -priority idle

H264: 41.9397 dB
VP6: 41.5968 dB
RV10: 41.0143 dB
WMV9: 40.7542 dB
XviD: test in progress
DivX: test in progress


Oh god !! It's the first time ever a codec beats VP6 on a standard PSNR/SSIM test :)
I guess they should reconsider their white paper : http://www.on2.com/pdf/vp6_white_paper.pdf

To have the best metrics, use -psy 0 (default config). This could improve the PSNR by about 0.2dB :)
Visually, I prefer -psy 2, that's the configuration for my weekly movie batch.

[SeeMoreDigital]

Originally posted by babayaga
Oh god !! It's the first time ever a codec beats VP6 on a standard PSNR/SSIM test :)
I guess they should reconsider their white paper : http://www.on2.com/pdf/vp6_white_paper.pdf

To have the best metrics, use -psy 0 (default config). This could improve the PSNR by about 0.2dB :)
Visually, I prefer -psy 2, that's the configuration for my weekly movie batch. Yep, Sagittaire certainly likes his graphs :D

Your codec is really coming up with the goods... Nice one guys.


Cheers

[Soulhunter]

@ Mr_Schizo

Maybe the difference is in the luma part then...

Anyway, with difference I meant the subsampling effect !!!


Bye

[Sagittaire]

To have the best metrics, use -psy 0 (default config). This could improve the PSNR by about 0.2dB

yes and perhabs that -psy 1 is the best compromise for PSNR and SSIM ...

little test with HPII trailer 800 Kbps ~3000 frames

-psy 0
PSNR = 45.4070
SSIM = 81.76

-psy 1
PSNR = 45.3930
SSIM = 81.96

-psy 2
PSNR = 45.2899
SSIM = 81.99




Pour les non francophones ... ;-)

visually H264 Ateme is the most powerful codec for this source (Matrix reloaded DVD Pal Chapter 20 to 26 and ~35 000 frames) particularly for low bitrates.

Sample

Compressibility 25% (/ XviD q2 H263 default setting)
Sample DivX5 500 Kbit/s (http://jfl1974.free.fr/Video/Sample-DivX5-500.avi)
Sample XviD 500 (http://jfl1974.free.fr/Video/Sample-XviD-500.avi)
Sample VP6 500 (http://jfl1974.free.fr/Video/Sample-VP6-500.avi)
Sample WMV9 500 (http://jfl1974.free.fr/Video/Sample-WMV9-500.avi)
Sample RV10 500 (http://jfl1974.free.fr/Video/Sample-RV10-500.rmvb)
Sample H264 500 (http://jfl1974.free.fr/Video/Sample-H264-500.mp4)

Compressibility 50% (/ XviD q2 H263 default setting)
Sample DivX5 1000 Kbit/s (http://jfl1974.free.fr/Video/Sample-DivX5-1000.avi)
Sample XviD 1000 (http://jfl1974.free.fr/Video/Sample-XviD-1000.avi)
Sample VP6 1000 (http://jfl1974.free.fr/Video/Sample-VP6-1000.avi)
Sample WMV9 1000 (http://jfl1974.free.fr/Video/Sample-WMV9-1000.avi)
Sample RV10 1000 (http://jfl1974.free.fr/Video/Sample-RV10-1000.rmvb)
Sample H264 1000 (http://jfl1974.free.fr/Video/Sample-H264-1000.mp4)


Metric Tests

http://jfl1974.free.fr/Test/Comparatif/PSNRAverage.gif

http://jfl1974.free.fr/Test/Comparatif/PSNROverall.gif

http://jfl1974.free.fr/Test/Comparatif/SSIM.gif

bitrate equivalence for "SSIM quality equivalence"

reference H264 500 Kbit/s
VP6: +14%
RV10: +26%
WMV9: +36%
XviD: +48%
DivX5: +52%
DivX3: +78%

reference H264 1000 Kbit/s
VP6: +9%
RV10: +12%
WMV9: +23%
XviD: +25%
DivX5: +36%
DivX3: +61%

[IgorC]

Sagittaire, there are some broken links of samples VP6.2 and other
H.264 beta 4 looks quite pretty

[SeeMoreDigital]

Originally posted by IgorC
Sagittaire, there are some broken links of samples VP6.2 and other
H.264 beta 4 looks quite pretty I can't play either of the Ateme H.264 encodes in ShowTime... and WMP10 says this: -

http://img9.exs.cx/img9/3258/SMD_Sag_AVC_Error_in_WMP10.gif


Cheers

[IgorC]

SeeMoreDigital, well try to download another time or reinstall your showtime. I have no problem with playing.
Waiting for realese

[SeeMoreDigital]

Originally posted by IgorC
SeeMoreDigital, well try to download another time or reinstall your showtime. I have no problem with playing.
Waiting for realese I weird thing is, I can play everybody else's AVC encodes but not Sagittaire's :(

But you're right, the next release of NVE should hopefully cure these ills!


Cheers

[bond]

Sagittaire, with codecs getting better and better i think it would be best to use simply no preprocessing, like convolution3d and the best resizer available: lanczosresize (i mean i dont even use your settings for my 1cd encoders :D )
that way you feed the codecs with a picture that is the closest one comparable to the dvd (no need to smooth details away prior to encoding)

also you might want to use hvs-best as mpeg-4 asp matrix, at least i think that its better than hvs-better (i also am no fan of postprocessing, but i dunno the status of the xvids decoders pp atm)

[Manao]

Since he uses both objective and subjective measurements for comparing to codec, h263 is fairer to MPEG-4. Of course, when comparing screenshots, it's slightly worse, but no custom matrix yet succeeded in combining good PSNR / SSIM and visual quality, so it's a tradeoff that has to be made.

[SeeMoreDigital]

Agreed,

In my opinion we should not be resizing our encodes either. All encodes should be generated at the same pixel frame size as the source.... why bother using an re-sizer at all.

It's also the only way you can compare the encode with the source!

All the codecs (with the exception of VP6 and WMV9VCM) can be encoded and decoded with PAR or DAR signalling!

Like I keep saying... lets make these codecs work harder!


Cheers

[Sagittaire]

@ Bond

yes but Soulhunter test

Average voting results for visual comparaison

8 points:
- Soulhunters v3
- HVS Good Picture

7 points:
- Y.A.C.Q.M
- Flat 8/16
- Soulhunters v6
- HVS Better Picture
- H.263
- Andreas 78er
- Acailas
- Selurs high datarate
- MPEG

6 points:
- HVS Best Picture
- Semi-Insane
- Jawors 1CD
- Didèes SixOfNine Max24
- Bulletproof's High Quality Matrix
- Angel BestLow
- Fox Home Entertainment
- Selurs Matrix
- 6of9 -vs- Jawors

5 points:
- EQM v2
- Bulletproof's Heavy Compression
- Soulhunters v5
- EQM v1
- AVAMAT6
- Bach1

4 points:
- mp4 guy's


Metric test with Custom matrice

Matrix: HVS Best Picture
@ Fixed Q 2 | Average PSNR = 46.51 | Overall PSNR = 46.26 | Average SSIM = 88.47
@ 2000kbps | Average PSNR = 44.90 | Overall PSNR = 44.46 | Average SSIM = 87.29

Matrix: HVS Better Picture
@ Fixed Q 2 | Average PSNR = 46.57 | Overall PSNR = 46.37 | Average SSIM = 89.11
@ 2000kbps | Average PSNR = 44.88 | Overall PSNR = 44.46 | Average SSIM = 87.35

Matrix: HVS Good Picture
@ Fixed Q 2 | Average PSNR = 46.44 | Overall PSNR = 46.22 | Average SSIM = 88.85
@ 2000kbps | Average PSNR = 44.89 | Overall PSNR = 44.46 | Average SSIM = 87.42

-> except H263 quantisation, the best compromise for MPEG4 ASP (metric, visual) is perhabs HVS-Better ... IMHO and by far the best solution is H263 + PP4. HVS matrix are very good without PP.

[IgorC]

I compared VP6 - H.264 - RV10 sample of sagitaries´s test.
It seems to me than Vp6.2 on some frames looks shaper than H.264, but H.264 doesnt have a noise, so its difficult to say what is the better.

So waiting for realse to tune myself this codec. Maybe H.264 has a matrix more smooth than VP6.2

[Tommy Carrot]

No, but h.264 uses loop-filter (similar to the postprocessing of mpeg4) by default, which masks the blocks and ringings away, but in return makes the image softer/blurrier.

If you switch off the loop-filter, h.264 is far more sharper and detailed than any other codec, but the blocks are even more annoying.

[Manao]

VP 6.2 also have in loop filtering ( though they claim it's not in loop, the results are the same : the reference frame is partially deblocked when used in the decoding loop ). There are no matrix in h264, but there's a 4x4 interger dct. In VP6, I'd bet it's an 8x8 DCT, which produces (perhaps) more details in high frequencies areas, and more ringing.

[Tommy Carrot]

It's definitely not inloop-filter in VP6, it seems to be a normal postfiltering, because inloop-filtering must be applied at both en- and decoding, and the postfilter of VP6 is selectable at decoding, independently from the encoding settings.

[bond]

ok we might not find a consensus on what matrix should be used for testing codecs, but anyone still thinking that convolution3d and another resizer than lanczos should be used?

[SeeMoreDigital]

Originally posted by bond
...but anyone still thinking that convolution3d and another resizer than lanczos should be used? You know my opinion... when testing don't resize... it just introduces another variable into the mix!


Cheers

[Manao]

Tommy Carrot : there's inloop in VP6 : have a look here : http://forum.doom9.org/showthread.php?s=&postid=527952&highlight=in+loop#post527952

I know, on2tech claims it's not in loop, but they are filtering the block used for motion compensation, so it amounts to the same. H264 could do the same at the decoder side ( they could show the frame not filtered, then filter it for using it as a reference ).

bond : I can't bear the bluriness brought by Convolution3D anymore. The only filters I can stand now are lanczos and temporalsoften ( the later because it greatly helps making walls perfectly stable with xvid - h264 doesn't need it ). Anyway, such filters make the encode easier, hurt quality at high bitrates, but make a comparison perhaps a bit fairer at low bitrate because you wouldn't encode harry potter @ 500 kbit with XviD without some prefiltering ( at least I wouldn't ).

SeeMoreDigital : resizing have two advantages though : it avoid aligning mpeg2 macroblocks with h264 one ( I never trust such alignments ), and it allows to crop more precisely and still being mod16 at the end whatever the cropping is.

[SeeMoreDigital]

Originally posted by Manao
SeeMoreDigital : resizing have two advantages though : it avoid aligning mpeg2 macroblocks with h264 one ( I never trust such alignments ), and it allows to crop more precisely and still being mod16 at the end whatever the cropping is. I guess what I should have said was: -

"You know my opinion... when testing, don't crop or resize... it just introduces other variables into the mix!"

Lets see how well all the other codecs stack up against Ateme's, with 1:1 encodes!


Cheers

[CruNcher]

HDTV transparency test

normaly im not so into HDTV and im pretty sure that mostly every next generation codec is fine with it but i wanted to test transparency @ high bitrates so i digged this up (also finding another bug ;)) im still encoding this to find the transparent bitrate for it first i tried half the bitrate from the original Source wich is 8 mbit.

8 Mbit Original VC-9 (WMV9 Professional) NO PP

http://cruncher.mufflastig.com/h264/original.png

4 Mbit H.264 Ateme

http://cruncher.mufflastig.com/h264/h264-transcoded.png

[Soulhunter]

I guess 7 Mbit would match the VC-9 encode...

Btw, what options have you used for Ateme ???


Bye

[thegeby]

Originally posted by Soulhunter
I guess 7 Mbit would match the VC-9 encode...

Btw, what options have you used for Ateme ???

I consistently got 25-30% better compression of HD with H. 264 than with VC-9, at original resolution. I would think that aiming for 5-6 would be enough.

[CruNcher]

@Soulhunter

-qual extra -rcmode 2pass -br 4000000 -clref deblock -cartoon -par 16:12

[plonk420]

@cruncher, there's some grain missing from the 4mbit h264 encode, unless it's only present when the video is in motion... i'm one for grain being present (anyone see The Cell in the theater then buy the DVD and see all the grain gone from the head-trip sequences? man, did that piss me off...)

other than that, the encode looks immaculate.

[Soulhunter]

A simple "AddGrain" function for the decoder would help...

Ateme sample with some Gaussian noise:

http://img37.exs.cx/img37/8118/Grain.png

Is there maybe some space for "sub-info" left in the stream or the container ???

Think the encoder could "measure" the grain amount/type and store it then...

This way the decoder would know which type/amount of grain to add !!!


Bye

[SeeMoreDigital]

Wow, that's cool Soulhunter!

The two images are virtually identical now...

Would your clip still be encoded at 4Mbps ie: half the bitrate of the source?


Cheers

[bobololo]

Originally posted by Soulhunter
A simple "AddGrain" function for the decoder would help...

Is there maybe some space for "sub-info" left in the stream or the container ???

Think the encoder could "measure" the grain amount/type and store it then...

This way the decoder would know which type/amount of grain to add !!!


In H.264 Fidelity Range Extension (FRExt), a new signaling message (SEI) was added to allow the encoder to send to the decoder characteristics of the film grain that could then added by the decoder as post-processing.

[Soulhunter]

Originally posted by SeeMoreDigital

Would your clip still be encoded at 4Mbps ie: half the bitrate of the source?

As Ive simply used CruNcher's PNG as source, yes... ;)


Originally posted by bobololo

In H.264 Fidelity Range Extension (FRExt), a new signaling message (SEI) was added to allow the encoder to send to the decoder characteristics of the film grain that could then added by the decoder as post-processing.

Cool, didnt know that... :eek:

Any plans to add this "SEI" to Ateme ???

Would IMO raise the codec "transcendency" even more... :cool:


Bye

[SeeMoreDigital]

Thanks for confirming that Soulhunter.

Well I guess we already know that HD video can be encoded at much lower bitrates than Miro$ofts's 8Mbps... but 4Mbps is mightly impressive all the same :)

On a slighly different note, I visited Nero's update site today.

There are new "demo" versions of Nero6 (Package 1) and Nero Media Player (Package 3)... but sadly no Nero Vision Express :(

I get the feeling though, that it wont be long before Nero Vision Express (or something like it) will be released, marketed and sold as an totally separate product soon!


Cheers

[babayaga]

Originally posted by Soulhunter
Any plans to add this "SEI" to Ateme ???
Would IMO raise the codec "transcendency" even more... :cool:


There is no plan like this in the very near future.
BTW this not standardized yet and going too fast could produce the kind of failures DivX encountered with qpel.

But the grain is a serious issue ...

[Soulhunter]

Originally posted by babayaga
There is no plan like this in the very near future.
BTW this not standardized yet and going too fast could produce the kind of failures DivX encountered with qpel.

But the grain is a serious issue ...

So a "ffdshow a'like" function to add noise (while playback) ???


Bye

[IgorC]

About HDTV. I cant said that Divx5.2 at 3.5 Mpbs Bourn Supramecy was good at resolution 1280*720. So microsoft with his 8 mpbs was better. But I think now 4 mbps Ahead H.264 or VP7 will be great

And what about block resize 4*8 8*4 . I heard that beta 4 provided this function. And what about 4*4. it will improve the quality, but will elevate the CPU usage.

What about beta testing? Is beta 4 was last?

[RadicalEd]

Originally posted by bobololo
In H.264 Fidelity Range Extension (FRExt), a new signaling message (SEI) was added to allow the encoder to send to the decoder characteristics of the film grain that could then added by the decoder as post-processing.

Sounds like HE-AVC :D

[CruNcher]

HE-AVC (AVCPLUS, AVC+) ;)
but it will be just another Profile for AVC, so no fancy new names :rolleyes:

[bobololo]

Hi,

According most of the feedback, the beta 4 seems to have reached a pretty stable state and shows rather good performance against other codecs. Therefore, except some testers report some big issues, I think we can consider that we're now very near to the end of this beta test.

If anyone has some additional comments, please don't hesitate to post them. We'll probably wait until the end of the week to definitely tag the encoder as final release :)

[SeeMoreDigital]

Hi bobololo,

Are you able to sum up what the main requests for the AVC encoder have been so far?

Also, are we able to make suggestions for the decoder?


Cheers

[Andrey]

Good point.
BTW, what about that issue Soulhunter reported first - that flat textures became "more flat" after encoding, while very good detail level maintained on small details ?
Or you think it will be solved by adding a film grain ?

[bill_baroud]

huf, so just before the end of the beta test, here my little contribution : a water/underwater test :)

Source is the introduction of the last Rip Curl surf "movie", Windows, shot in 35mm slow-motion... so a lot of high particules mouvement :)

using -qual extra -rcmode 2pass -br 2000000 -psy 1 -cartoon -adaptdeblock -maxb 5,
Ateme's H264 achieve an really impressive result at 2Mbits (the dvd source block on some scenes =)

some screenshots :
http://moodub.free.fr/390_a264.jpg

http://moodub.free.fr/1292_a264.jpg


all screenshot are here (http://moodub.free.fr/Windows%20-%20Rip%20Curl.rar)
strange things, the xvid is always brighter, i don't know why (ffdshow pp & co off, graphic card overlay settings to default).

Anyway, i think Ateme's h264 does a really good job on my little test (1500Kbits was a little too blurred for my taste.)

[thegeby]

I think you're clear to go:) You really have something there.

[bobololo]

Originally posted by Andrey
Good point.
BTW, what about that issue Soulhunter reported first - that flat textures became "more flat" after encoding, while very good detail level maintained on small details ?
Or you think it will be solved by adding a film grain ?

Well we've tried to do something by strengthening the -psy 2 effect. This may be not enough. Anyway we've some tracks to exploit but these would require some more time so we reserve them for the next major version of the encoder ;)

[JohnV]

Now all we need is that DVD-Forum does new tests comparing Nero Digital/Ateme H.264 and WMV9.
Microsoft is still advertizing WMV9's win over "H.264" in DVD-forum blind test done in 2003.
http://www.ibc.org/2002/pzone/images/2004ex7.jpg
That's a picture from IBC2004 few weeks ago.

Now if only DVD-Forum would test up-to-date h.264 quality implementations, Microsoft's WMV9 win presentations would have to end to the IBC2004.. ;)

Well, Ateme h.264 still lacks one important feature: interlace support. But after that is added WMV9 has no business on top of the test results. :D

[Andrey]

Anyway we've some tracks to exploit but these would require some more time so we reserve them for the next major version of the encoder
Ok, thank you !
I wish you good luck with this encoder - it is very promising, really :cool:
Now if only DVD-Forum would test up-to-date h.264 quality implementations, Microsoft's WMV9 win presentations would have to end to the IBC2004..
It would be GREAT. I hate a thought that approprietary standart will be used for next generation video...

[Disabled]

@bobololo
Do you know when we can expect the final product? How long does Nero need to implement this?

I'm so excited about this new codec!
Looks so promising...

[babayaga]

Originally posted by IgorC
And what about block resize 4*8 8*4 . I heard that beta 4 provided this function. And what about 4*4. it will improve the quality, but will elevate the CPU usage.


In fact, the gain of subpartitions (4x4, 8x4 and 4x8) is very small and to most eyes not noticable (including mine :p ).
The speed penalty on the other hand is very noticable : it's roughly divided by 2.
That's why we have currently decided not to release an encoder with subpartitions.


What about beta testing? Is beta 4 was last?


I guess so. Many bugs have been found and several proposed improvements were implemented. Looking at all messages, it seems to me that the codec is now fairly competitive :)

There are still some annoying bugs and internal things to manage properly. So the codec will not be officialy released tomorow...
Anyway, it has also to be integrated in a powerfull product with the great sound it deserves.

Many thanks to everybody, including Gabriel_Bouvigne who tested my rate-control in an crazy way :)

[Tommy Carrot]

Originally posted by babayaga
In fact, the gain of subpartitions (4x4, 8x4 and 4x8) is very small and to most eyes not noticable (including mine :p ).

The main advantage of the subpartitions is the elimination of ringing artifacts, isn't it? There is no problem with them when the loop-filter is activated, but when not, using subpartitions could greatly enhance the image clarity imo.

[babayaga]

Originally posted by Tommy Carrot
The main advantage of the subpartitions is the elimination of ringing artifacts, isn't it?

The transform and quantisation are always made on 4x4 blocs. That's what produces less ringing than 8x8 transform and quantisation like in MPEG-4 part 2.

With supartitions, 4x4, 4x8 and 8x4 blocs might have a specific motion vector. This could improve coding efficiency. But in fact those mode are relatively rarely selected because the cost of the vectors is very important for such small sizes.

[RadicalEd]

Originally posted by babayaga
The transform and quantisation are always made on 4x4 blocs.

Until FRExt High Profile... :O

[bond]

i assume it will take some years till some features of the standard get widely used and recognized (look at qpel in asp for example)

[Sirber]

I did a little 300kbps test:

RV10: http://www.detritus.qc.ca/300k.rmvb
H264: http://www.detritus.qc.ca/300k.mp4
VP62: http://www.detritus.qc.ca/300k.avi

Results:
RV10:
Video quality is "not too bad", except it drops lots of frames.

H264:
Video quality is bad, but it looks less bad than beta 3 at 600kbps. Also, I note no frame drops.

VP62:
Video quality is smooth. No frame are dropped.

Conclusion:
First: VP6.2
Second: RV10
Last: H264

[bobololo]

Originally posted by Sirber
I did a little 300kbps test:

RV10: http://www.detritus.qc.ca/300k.rmvb
H264: http://www.detritus.qc.ca/300k.mp4

Results:
RV10:
Video quality is "not too bad", except it drops lots of frames.

H264:
Video quality is bad, but it looks less bad than beta 3 at 600kbps. Also, I note no frame drops.

Conclusion:
(to be posted bellow :D, not by me ;))

The RV10 clip is 38% bigger (854 kB vs 620 kB) - that could explain things ;)

[Sirber]

The "Streaming" RC is not very good with filesize. I asked 300kbps for both. Going to add VP6.2 soon.

[SeeMoreDigital]

Originally posted by Sirber
The "Streaming" RC is not very good with filesize. I asked 300kbps for both. Going to add VP6.2 soon. Hi Sirber,

Can you generate the encodes again, matching the file sizes!


Cheers

[Sirber]

Hum.... no :angry:

This could be coz of container difference. AVI would be smaller in MKV. All codecs were set to 300kbps. Not my fault :o

[bobololo]

Originally posted by Sirber
Hum.... no :angry:

This could be coz of container difference. AVI would be smaller in MKV. All codecs were set to 300kbps. Not my fault :o

Hum I don't think the container could cause such an overhead, this is simply because the RC can't cope with this sequence at this bitrate. If RV10 gives 400 kb/s (854 kB for your 17s clip) when you ask 300 kb/s, then you may try to set a lower target bitrate like maybe 200 or 250 kb/s ?

The same applies to VP6 also (358 kb/s), try lower bitrate.

Or you can also increase the target bitrate of other codecs to match RV10 bitrate which is the higher.

Anyway you just demonstrated us on this sample that RV10 or VP6 RC are way less accurate than H.264's (292 kb/s) :D

[Sirber]

Note on RV: I used old Streaming RC, not the curve one (or DC alt. curve). They are acurate but less good in low bitrate.

[snacky]

Originally posted by Sirber
Hum.... no :angry:

This could be coz of container difference.

Nope. Here are the actual video bitstream sizes, NOT including container overhead:

300k.rmvb: 865354 bytes
300k.avi : 757565 byes
300k.mp4 : 629191 bytes

Sorry, this kind of test proves nothing.

[JohnV]

Originally posted by Sirber
All codecs were set to 300kbps. Not my fault :o
Hehheh, is this the way you do all your tests? :rolleyes:
Of course it's your fault if you didn't check the *real* bitrate/size. ;)

[Sirber]

This "test" was for fun. I asked 300kbps and I did not check for real output bitrate. If you're not happy, just ignore it :p

[IgorC]

http://rbf.nm.ru/b4extra28s_720_352_315kbit.mp4 - have look at this one ... very nice, men. But its only statsitic frames

bobololo, when is release of H.264?

What about test of Sirber. I think RV10 (with HFE2) is quite better than H.264 on animation.And it doesnt matter a lot with size of file
But it will be better (more truly ) if files will have iqual size

[Sagittaire]

Little test animate/cartoon low compressibility

Source: Corto Maltes Trailer. Very high quality and high complexity source MPEG2 MP@ML ~6 Mbps PAL interlaced.
Encoding: video 640*352 400 Kbit/s and audio HE-AAC 2.0 60 Kbit/s. Low compressibility 25% / XviD H263 q2.

Trailer H264 (http://jfl1974.free.fr/Video/Corto-H264.mp4)
Trailer RV10 (http://jfl1974.free.fr/Video/Corto-RV10.mkv)
Trailer WMV9 (http://jfl1974.free.fr/Video/Corto-WMV9.mkv)
Trailer VP6 (http://jfl1974.free.fr/Video/Corto-VP6.mkv)
Trailer XviD (http://jfl1974.free.fr/Video/Corto-XviD.mkv)

For animate/cartoon encoding with H264 use high deblock level: for me it's very better for visual quality:
-qual extra -rcmode 2pass -br 415000 -deblock 4 -ref 5 -setef wpred -cartoon -psy 1

IMHO visually RV10 and H264 are by far the best codecs for this trailer.

[IgorC]

[QUOTE]Originally posted by Sagittaire
[B]Little test animate/cartoon low compressibility

Source: Corto Maltes Trailer. Very high quality and high complexity source MPEG2 MP@ML ~6 Mbps PAL interlaced.
Encoding: video 640*352 400 Kbit/s and audio HE-AAC 2.0 60 Kbit/s. Low compressibility 25% / XviD H263 q2.

Sagitarie, can you do some samples of video 720x480 (without any resize or crop),600]-650 kbit/s. Untill now I´ve seen only resized or croped clips of movie ( i´m not interestin in animation)

[bobololo]

Originally posted by IgorC
http://rbf.nm.ru/b4extra28s_720_352_315kbit.mp4 - have look at this one ... very nice, men. But its only statsitic frames

bobololo, when is release of H.264?


Soon and surely before the end of the year ;) Sorry but I can't be more accurate.

What about test of Sirber. I think RV10 (with HFE2) is quite better than H.264 on animation.And it doesnt matter a lot with size of file But it will be better (more truly ) if files will have iqual size

Are you joking ;) ? If not, you should then seriously consider raw uncompressed codec, the quality is perfect, only the file size is slightly bigger ;)

[IgorC]

Originally posted by bobololo

Are you joking ;) ? If not, you should then seriously consider raw uncompressed codec, the quality is perfect, only the file size is slightly bigger ;)

It was just for fun :p

[superdump]

Hey all. I'm sorry I haven't been able to give any feedback for 2 weeks or so. Have I been removed from the beta program or has it ended? I should really read the threads but I haven't got time at this minute. I'll be back on IRC to talk to those of you that dwell there again soon.

I hope you're all well.

[SeeMoreDigital]

Yep... I'd like to "see" some more test files.

Can anyone oblige?

[LostMP4]

Originally posted by SeeMoreDigital
Yep... I'd like to "see" some more test files.

Can anyone oblige?

I heard Nero 6.6 + Vision 3 should be available in these weeks, so I guess a first release of the codec is in Ahead hands

Will have H.264 Nero Digital multiple certified profiles?

[SeeMoreDigital]

Originally posted by LostMP4
I heard Nero 6.6 + Vision 3 should be available in these weeks, so I guess a first release of the codec is in Ahead hands

Will have H.264 Nero Digital multiple certified profiles? It would be kinda cool if we could beta test NeroVision Express 3 ;)


Cheers

[LostMP4]

Originally posted by SeeMoreDigital
It would be kinda cool if we could beta test NeroVision Express 3 ;)


Cheers

If it's true that soon the new package will be available in shops it should be complete and maybe in manufactoring at this time

[bond]

Originally posted by LostMP4
Will have H.264 Nero Digital multiple certified profiles?i am pretty sure that there will be profiles for ASP, as ahead managed to get hardware manufacturers to add .mp4 support to their players, and some hardware players are still too weak to handle the original profiles defined in mpeg-4 (as advanced simple profile), mainly only 3wp GMC is left!
i assume ahead will look at the weakest player/chip existing and will create a private ASP profile which is playable on this player, to ensure as much interoperability as possible, but making the private profile pretty useless from a quality point of view (as its the case with divx's private profiles too)

perhaps they already did this in recode2?

[SeeMoreDigital]

Although adding AVC support to existing Mpeg4 stand-alone players would be nice. I would hope we don't get a confusing mass of profiles!

As far as I can see, we should only really require two versions. A "full spec" version, for use on "new" full spec hardware players. And a "low spec" version, for use on any existing players that can be converted....


EDIT: I guess some of you have already read the link Doom9 has posted on the main site... http://www.chip.de/artikel/c_artikel_12370396.html?partner=cdfreaks


Cheers

[bond]

i very much doubt that there will be any avc hardware players released soon...
and once they are here, they will be supporting the HD-DVD and/or bluray standard. the industry simply needs such a broadly accepted standard, the mess like with ASP never really made it

[IgorC]

Some news from german´s page:

German PC mag Chip has a preview of Nero 6.6. It contains an improved VisionExpress app that supports a lot of input formats (even DVD-VR and (S)VCD), but the most important information is probably what it does not contain: the 2nd generation of their MPEG-4 NeroDigital solution - the H.264 (AKA MPEG-4 AVC) codec is still missing in action.

[Sirber]

Nero's H264 is still beta :D

[SeeMoreDigital]

Originally posted by Sirber
Nero's H264 is still beta :D It ain't bad for a beta though!

[babayaga]

Originally posted by LostMP4
Will have H.264 Nero Digital multiple certified profiles?

I guess so since the profiles defined in the standard are much too difficult to implement on a relatively simple machine.

[SeeMoreDigital]

Originally posted by babayaga
I guess so since the profiles defined in the standard are much too difficult to implement on a relatively simple machine. Why bother implementing AVC on an simple machine in the first place!

The chip-set manufacturers should be designing and building chip-sets that can accommodate all of AVC's bells and whistles from the get-go!

Do we really need the same level of confusion with AVC that we currently have with Mpeg4? Thankfully though, AVC does not include GMC, so there will be no confusion here!

And one thing us consumers definitely don't need, is for a codec manufacturer (any codec manufacturer) to invent an "certification" program!

Just my 2 cents...


Cheers

[Soulhunter]

Originally posted by SeeMoreDigital

Do we really need the same level of confusion with AVC that we currently have with Mpeg4? Thankfully though, AVC does not include GMC, so there will be no confusion here!


But some AVC stuff isnt standardized yet...
Originally posted by bobololo

In H.264 Fidelity Range Extension (FRExt), a new signaling message (SEI) was added to allow the encoder to send to the decoder characteristics of the film grain that could then added by the decoder as post-processing.
Originally posted by babayaga

BTW this not standardized yet and going too fast could produce the kind of failures DivX encountered with qpel.

Bye

[bobololo]

Originally posted by SeeMoreDigital
Yep... I'd like to "see" some more test files.

Can anyone oblige?

Can't you still encode them by yourself ? Too bad you're really missing something ;)

[SeeMoreDigital]

Originally posted by bobololo
Can't you still encode them by yourself ? Too bad you're really missing something ;) Now you know I can't :(

And sadly I was not offered "beta4" to test.

While you're here. Have you had any thoughts about discussing Nero's decoder filters? They still are doing weird things!


Cheers

[bobololo]

Originally posted by SeeMoreDigital
Now you know I can't :(

And sadly I was not offered "beta4" to test.

Didn't I offer you to warn me as soon as you're able to encode ?

While you're here. Have you had any thoughts about discussing Nero's decoder filters? They still are doing weird things!
Cheers

You should post a new thread about your issues and I'll try to reply but keep in mind that I didn't developed those filters and therefore don't know everything about them (this also applies to other nero programs).