Nero 8 Recode Changes (?)

[greggerm]

Hi all -

I'm curious if anyone has heard of any changes/improvements being made to the Recode module within Nero 8?

I'm most interested because I need to know if it will be worth my while to pay for the upgrade, or sit on v7.

Thanks!
-Greg Germ

[CruNcher]

H.264 (Quality) Core wise (1.4) i doub't there will be big changes bug fixes wise i dunno nice if JohnV could answer that if he stills on the run for Nero :P

[Romario]

I downloaded Nero 8 from one site, Russian one.

Nero 8 Ultra 8.030 Retail. But I don't install Nero 8.0, yet.

I will, tommorow. It's huge, 955 MB!!!

[ChronoCross]

I downloaded Nero 8 from one site, Russian one.

Nero 8 Ultra 8.030 Retail. But I don't install Nero 8.0, yet.

I will, tommorow. It's huge, 955 MB!!!

considering it's not released you should probably not download the illegal pirated pre-release.

[foxyshadis]

Yeah really, romario, that's pretty lame, and a major rule 6 violation.

[mediator]

At the very beginning, Nero 8 will feature an updated version of Recode 2.

Recode 3 is then scheduled for the end of this year. NeroDigital-wise it will be the biggest update since the first release of Recode 2.

[Sharktooth]

nice.

[greggerm]

Is it known if the Recode2 -> Recode3 update will be within the Nero 8 family?

(eg: If I update to Nero8, will I be entitled to the Recode update)

-Greg

[CruNcher]

wich Encoding Engine version will Recode 3 be based on (H.264) ?

[Rash]

And I was wondering how Nero Digital AVC encoder compares to x264. Has anyone ever made any tests? :)

[Dark Shikari]

And I was wondering how Nero Digital AVC encoder compares to x264. Has anyone ever made any tests? :)Due to its much weaker feature set, IIRC it generally pales in comparison. If you limited x264 to the features Nero supports, it might be more competitive.

[Sagittaire]

Due to its much weaker feature set, IIRC it generally pales in comparison. If you limited x264 to the features Nero supports, it might be more competitive.

In fact Ateme/Nero build use more advanced HVS tweak. For example the grain retention is by far better than x264.

[Rash]

Due to its much weaker feature set, IIRC it generally pales in comparison. If you limited x264 to the features Nero supports, it might be more competitive.
Whoa! :eek: Really?

[Dark Shikari]

Whoa! :eek: Really?If I recall correctly Nero's encoder is a limited version of Ateme's encoder (limited so that it can be sold for a lower price, due to the reduced feature set).

If I can get access to a copy of Nero (shouldn't be hard), I can do a test with it on best settings vs x264 on best settings, with a 1000-frame clip of Elephant's Dream (a complex scene, the running/wires scene) at 1280x720x24p, 3 megabits per second.

[Bigmango]

If I can get access to a copy of Nero (shouldn't be hard), I can do a test with it on best settings vs x264 on best settings, with a 1000-frame clip of Elephant's Dream (a complex scene, the running/wires scene) at 1280x720x24p, 3 megabits per second.

Looking forward to it :)

[Dark Shikari]

OK, I'll have a completely unfair test of x264 vs Nero up in a few hours. That is, x264 is using SATD ESA and some other batshit insane settings and Nero is using its best... which though are its best, are not nearly as intensive :p. I did disable psychovisual optimization to get the best SSIM result for comparison (since x264's psychovisual optimization, AQ, is also off).

I might also post a somewhat fair comparison with x264 having settings that give similar speed :rolleyes::cool:

[Manao]

Due to its much weaker feature setWeaker ? There's no CQM support because it's too complex for the Nero Recode basic user, and there are no B reference. Feature wise, that's the only thing missing. But in the other hand, there's weighted prediction, which x264 doesn't have.
Nero's encoder is a limited version of Ateme's encoderNot at all.

[Dark Shikari]

Weaker ? There's no CQM support because it's too complex for the Nero Recode basic user, and there are no B reference. Feature wise, that's the only thing missing. But in the other hand, there's weighted prediction, which x264 doesn't have.
Not at all.
I thought x264 has weighted prediction, in the form of --weightb?

Nero is also limited to 4 reference frames and 3 bframes.

[Dark Shikari]

And Nero, the encoder that is so clearly up to par with x264:

http://i2.tinypic.com/2i74htu.png

:p

(Y-Axis is SSIM, Insane setting isn't finished yet, it'll be another few hours. The x264 encode was approximately the same speed and bitrate as the Nero encode.)

[Thunderbolt8]

In fact Ateme/Nero build use more advanced HVS tweak. For example the grain retention is by far better than x264.
isnt the prestige CQM good as well for that with x264 ?

[mediator]

Recode 3 will be in the Nero 8-family. This implies that the update from Nero 8 Recode 2 -> Nero 8 Recode 3 will be for free (of course for legal owners of Nero 8).

[Manao]

I thought x264 has weighted prediction, in the form of --weightb?Nero does implicit and explicit weighted prediction. x264 does only implicit weighted prediction.

Nero is also limited to 4 reference frames.It's a GUI limitation, and imho, a good one. It avoid clueless users from using 16 references and complaining of the encoder being slow.

BTW, what settings did you use ?

[Dark Shikari]

Nero does implicit and explicit weighted prediction. x264 does only implicit weighted prediction.

It's a GUI limitation, and imho, a good one. It avoid clueless users from using 16 references and complaining of the encoder being slow.

BTW, what settings did you use ?In Nero? Best on the slider (twopass), with all the psychovisual optimizations disabled and all the other settings enabled (8x8dct, etc).

With x264, I used umh, subme 7, no-fast-pskip, etc.

[Sagittaire]

And Nero, the encoder that is so clearly up to par with x264:

http://i2.tinypic.com/2i74htu.png

:p

(Y-Axis is SSIM, Insane setting isn't finished yet, it'll be another few hours. The x264 encode was approximately the same speed and bitrate as the Nero encode.)

x264 and Nero AVC here have clearly not the same Rate Control strategy. In easy part x264 is by far better and for the most complex part Nero AVC produce better result.

Anyway if you compare the RC strategy there are problem (for x264 or Nero?) because these codec have symetrical opposite strategy for some part. Make comparison with constant qp encoding will be interessing here.

[Dark Shikari]

x264 and Nero AVC here have clearly not the same Rate Control strategy. In easy part x264 is by far better and for the most complex part Nero AVC produce better result.
In most of the complex parts Nero loses miserably to x264; winning in a couple frames is not "better for the most complex part," especially since the graph isn't an actual direct graph, its a B-spline, to avoid the lines going all over the place.

Going from the beginning, a list of all cases in which x264 is outperformed by Nero more than marginally:

Frames 357, 359, 361, 367, 369, 377, 381, 385: x264 and Nero's B-frame decision was out of sync (i.e. Nero had PBPB and x264 had BPBP) and so when x264 had a B-frame and Nero had a P-frame, Nero won, and vice versa. Meaningless, as if one looked at the even values one could claim that x264 completely trashed Nero (averaging P and B frames shows a great advantage for x264 overall).

Frames 425, 427: Same as above. Nero gets a small percentage better, and then in the alternate frames x264's advantage is ten times higher than Nero's advantage was.

Frames 689, 699, 703: Same as above. All nearby frames show a massive x264 advantage.

Frames 713, 715, 721, 723, 725: x264's advantage is smaller here in the alternate frames than before, but still somewhat larger than Nero's. The frames in which Nero > x264 are still meaningless for the aforementioned reasons.

Frames 747, 755, 759, 761, 763, 765: Again, small Nero advantages in between massive x264 advantages due to alternate frame type choice.

Frame 803 - 893: Filled with an overall Nero advantage, but not by that much.

The rest is pretty much solid x264 advantage.

In other words, Nero is superior in about 8% of the material, and vastly inferior in the other 92%. I don't think the ratecontrol strategy can be blamed for this; its more like a general lack of encoder capability. I'll post a blind test in a bit.

[Dark Shikari]

Insane mode test complete. Note that the "insane" test went at about 0.05 FPS on singlethreaded mode using a brute-force unoptimized ESA SATD search. As such I didn't have a chance to tweak the bitrate to exactly 3000kbps, so I interpolated using a rate-distortion curve to adjust the SSIMs appropriately (the ones displayed are the adjusted values) to make up for the roughly 2% bitrate difference. However, the results are a nice, and quite impressive, comparison.

http://i15.tinypic.com/4mhdf88.png

[Dark Shikari]

Anyways, time for the blind test.

Sample 1 (http://tjhsst.edu/~jgarrett/Sample 1.mkv)
Sample 2 (http://tjhsst.edu/~jgarrett/Sample 2.mkv)
Sample 3 (http://tjhsst.edu/~jgarrett/Sample 3.mkv)

Comment on each one's quality as compared to the others. All the bitrates are within 2% of each other, roughly.

[Kurtnoise]

Sample 2 is the Nero one...:p Quite impressive indeed. I'm not able to distinguish each other at normal playback.

[CruNcher]

Those results are also based on a older core 1.3/1.4 i think, who knows if they don't have something new by now and maybe that's gonna find it way into Recode 3 dunno exactly.
Grain retention for Atemes implementation is at low settings better then with x264 and with high subme and low qp the grain can even survive low bitrate scenarios (more or less perceptable), that's not possible in x264 yet as it over artificializes the Look & Feel of the Source (it tries to bring back the source without analog grain (creating a Digital Cinema Look & Feel) and can introduce some heavy blocks by that, when the source isn't pre-processed) for such a sample as Elepahant Dream this isn't really visualy important Ateme on the other side is trying to keep the source as true to the original input as possible the Look & Feel is sharper and more detailed that way.
At least that's my visual impression of both testing them for some time now, also somehow im pretty sure that Mainconcept/Elecard combines both of this worlds in their implementation (most probably they have found the best balance of both by now) ;)

[Sagittaire]

In other words, Nero is superior in about 8% of the material, and vastly inferior in the other 92%. I don't think the ratecontrol strategy can be blamed for this; its more like a general lack of encoder capability. I'll post a blind test in a bit.

1) Well there are major difference between x264 and Nero AVC here: IMO problem with IFrame (overquantized Iframe)
http://jfl1974.free.fr/Kase/2i74htu.png

IMO RC for Nero AVC have big problem for maintain constant "quality". Moreover Nero AVC use certainely very high space for maintain quality in the most complex part (the most complex part is the part with the lower SSIM) and Nero AVC have less bits for the other part. For your 41 sec and 15 Mo sample, Nero AVC use 5 Mo for the most complex 6 sec part: more than 33% of size for simply 15% of the time. RC is the most important part of setting for your sample (IMO really more important than insane ME search). Try to use lower qcomp for your sample and certainely that SSIM score will be very better.

2) You don't use the full search for Nero AVC (no availaible setting)

[greggerm]

Thanks for your heads up on the Recode2 -> Recode3 situation.

I really didn't want this to turn into a encoder vs. encoder discussion, ESPECIALLY considering Nero8 (w/Recode2) isn't released yet, and Nero8 (w/Recode3) doesn't EXIST yet.

Thanks again, Mediator.

And now back to your regularly scheduled graph comparisons, which really mean little to the average Recode user, considering they enjoy the operational simplicity and everyday quality of an encoder rather than squeezing the absolute best signal-to-noise ratio out of their encoders.

Speaking of signal-to-noise, I should end my participation in this thread to keep that noise level nice and high...

-Greg

[Dark Shikari]

I really didn't want this to turn into a encoder vs. encoder discussion, ESPECIALLY considering Nero8 (w/Recode2) isn't released yet, and Nero8 (w/Recode3) doesn't EXIST yet. Did Recode 2 change between 7.10 and 8?

And now back to your regularly scheduled graph comparisons, which really mean little to the average Recode user, considering they enjoy the operational simplicity and everyday quality of an encoder rather than squeezing the absolute best signal-to-noise ratio out of their encoders.

The reason I posted the graphs is because somebody asked for them. If you don't like them, don't look at them. Also note that they are not signal-to-noise ratio graphs; I would suggest you read posts before commenting on them.

(And at least IMO, the Nero interface is a buggy mess that's hard to use and annoying. Example: I tried to import my AVS script, which it listed kindly enough on the import screen. It failed... silently. I had no way of knowing if it was trying to import it or not, because nothing happened at all when I clicked import.)

[Terranigma]

This's the first time i've ever seen weighted prediction being used.
http://img517.imageshack.us/img517/1981/sample2zv8.png
(From the second sample)

x264 doesn't have this feature implemented?

[Manao]

Once again, x264 supports implicit weighted prediction. Those are used only in bframes, and implies that biprediction in bframes will not be a simple average of the previous and next reference frame, but rather a weighted average, the weight being necessarily inversely proportionnal to the distance between the bframe and its reference ( simply put : the closer the bframe is from a reference, the more important the part of this reference is in the biprediction process ).

Explicit weights, not supported by x264, can be used in P & B frames, and allows the encoder to modify the reference frame by changing its luminosity/contrast before using it as reference. That is most usefull whenever there is a fade, for example.

Fades could also correctly be encoded with implicit weighted prediction, but it would require :
- that the first & last frame of the fade are reference frames
- that all the frames inside the fades are bframes
- that the fade is perfectly linear

The third one hardly happens, and x264 doesn't specifically tries to do the first two ones, so fades in x264 aren't efficienctly handled.

Nero uses both weighted predictions ( explicit in P, implicit in B ).

To mitigate Nero's advantage, fades mostly occurs in trailers, so the tool, though extremely usefull whenever there's a fade ( you can expect up to a 40/50% bitrate reduction on that fade ), hardly matters on the overall quality of a real movie.

[Sagittaire]

Once again, x264 supports implicit weighted prediction. Those are used only in bframes, and implies that biprediction in bframes will not be a simple average of the previous and next reference frame, but rather a weighted average, the weight being necessarily inversely proportionnal to the distance between the bframe and its reference ( simply put : the closer the bframe is from a reference, the more important the part of this reference is in the biprediction process ).

Explicit weights, not supported by x264, can be used in P & B frames, and allows the encoder to modify the reference frame by changing its luminosity/contrast before using it as reference. That is most usefull whenever there is a fade, for example.

Fades could also correctly be encoded with implicit weighted prediction, but it would require :
- that the first & last frame of the fade are reference frames
- that all the frames inside the fades are bframes
- that the fade is perfectly linear

The third one hardly happens, and x264 doesn't specifically tries to do the first two ones, so fades in x264 aren't efficienctly handled.

Nero uses both weighted predictions ( explicit in P, implicit in B ).

To mitigate Nero's advantage, fades mostly occurs in trailers, so the tool, though extremely usefull whenever there's a fade ( you can expect up to a 40/50% bitrate reduction on that fade ), hardly matters on the overall quality of a real movie.

http://forum.doom9.org/showthread.php?p=1037662#post1037662

Yes and the problem for x264 is that RC don't detect correctly fade. x264 use pframe in fade scene in most case.

[Terranigma]

Dark Shikari, you're up for another task? :p

[Dark Shikari]

Dark Shikari, you're up for another task? :pI can probably fix the P-frames in fades with a kludgy hack. I already know how to do it pseudocode-wise:

a = 0
for n in Max_number_of_bframes
if(averageBrightness(currentFrameNumber+n) < averageBrightness(currentFrameNumber+n-1))
a++
else break
for all frames between currentFrameNumber and currentFrameNumber + n
frame's b-bias += (a*a)

Not sure how well it would work. I might have to implement a threshold for the brightness difference to ensure its really a fade. Also, the averageBrightness function would probably not sample every pixel, for performance reasons.

I also don't know how to do some of this stuff in the x264 codebase, such as adjust the b-bias on a per-frame level, or find the average brightness of a frame.

[sjchmura]

Has anyone tested the new recode 2 or the v3 beta? It would be nice to know before paying the upgrade cost ( I can't beleive it is $50 from 7 that was so broken) if the features are worth it.

Namely, are the directshow files INDEPENDENT of the default codecs. It is SO annyoting that with, say Halli MKV splitter installed some stuff won't load into nero.

Oh, the broken Canon HV20 camera support is great too :)

[foxyshadis]

averagePixelBrightness ≈ averageDCBrightness

Should be close enough for government work and many times faster to compute, even if the precision isn't exact.

You only get to use this trick with the already quantized frames, of course, so it might not work if you're going to be doing it in a lookahead. Might be better as a post-process filter, since fades are rare, but how to back up and redo encoded frames is beyond me. Of course you could also stick it into first pass stats.

[Sergey A. Sablin]

averagePixelBrightness ≈ averageDCBrightness

Should be close enough for government work and many times faster to compute, even if the precision isn't exact.

You only get to use this trick with the already quantized frames, of course, so it might not work if you're going to be doing it in a lookahead.

this method will work only for mpeg-1/2 I-frames. mind intra and inter prediction

[Greif]

is a future nero 7 patch introducing ac3 inside the mp4 container? or is that planned for nero 8?

[Rash]

Anyways, time for the blind test.

Sample 1 (http://tjhsst.edu/~jgarrett/Sample 1.mkv)
Sample 2 (http://tjhsst.edu/~jgarrett/Sample 2.mkv)
Sample 3 (http://tjhsst.edu/~jgarrett/Sample 3.mkv)

Comment on each one's quality as compared to the others. All the bitrates are within 2% of each other, roughly.
Wow! They look so good I can't tell which one is better. What three codecs were used? And when the test is over, could you tell me what cmd you used for x264? Thank you!

[Dark Shikari]

Wow! They look so good I can't tell which one is better. What three codecs were used? And when the test is over, could you tell me what cmd you used for x264? Thank you!
Nero: Best options without psychovisual enhancement. Twopass.
x264 1: --me umh, --b-rdo, --merange 20, --subme 7, --no-fast-pskip, --trellis 2, --bime, --bframes 16, etc--all the usual best options for reasonable speed. I used --crf for the first pass.
x264 2: --me esa --merange 24 --hadamard and max on all the other settings except --ref 8 (0.05 FPS)

Not telling which is which for now.

Also, if you think they look good, look in the background during the motion scenes: the wires are completely blocked up all over each other.

[Rash]

Thanks. ;)

I did notice the background wires were blocked, only in the "camera" motion sequences. But the overall image quality is good nonetheless. That's because the background wires have a darker shade of grey, perhaps?

Just one more thing, a bit offtopic. Why does MPC say the video size is 640x360 and ffdshow say it is 1280x720 (the real res, I guess)?

[Dark Shikari]

Thanks. ;)

I did notice the background wires were blocked, only in the "camera" motion sequences. But the overall image quality is good nonetheless. That's because the background wires have a darker shade of grey, perhaps?

Just one more thing, a bit offtopic. Why does MPC say the video size is 640x360 and ffdshow say it is 1280x720 (the real res, I guess)?
The Haali Renderer automatically resizes the video to half size if it doesn't fit in your screen resolution, I believe. You can of course set it to full size from there.

If you actually watched it at 640x360 that would explain the seemingly perfect quality :p

[Rash]

No! I watched it fullscreen. :D lol

[IgorC]

Nero: Best options without psychovisual enhancement. Twopass.
x264 1: --me umh, --b-rdo, --merange 20, --subme 7, --no-fast-pskip, --trellis 2, --bime, --bframes 16, etc--all the usual best options for reasonable speed. I used --crf for the first pass.
x264 2: --me esa --merange 24 --hadamard and max on all the other settings except --ref 8 (0.05 FPS)


Nero's "Anime/Cartoon source" optimization helps enough for both visual and metric results. The same for psychovisual enhancements.
I could see that x264's files were better than Nero for this particular video source but I failed to spot the dif between 2 x264 videos
And as it was already mentioned that was old and limited Ateme core. (no full quality mode no psy and other settings...)

[FFWD]

I wished Ahead would include an 'iPhone - AVC' Nero Digital Profile in Recode.

[Theliel]

I belive remember that in Nero 7 already exist a ipod profile, and iphone share the same h264 spect that current ipods, so no need for newer profiles.

[FFWD]

I belive remember that in Nero 7 already exist a ipod profile, and iphone share the same h264 spect that current ipods, so no need for newer profiles.The 'iPod Video - AVC' profile is limited to 768Kbps and to a maximum resolution of 320x240.

Apple recommends (http://developer.apple.com/iphone/designingcontent.html) encoding at 900Kbps and a resize that preserves the aspect ratio of the content and fits within a 480 x 360 rectangle.