.mp4 oddity - Nero Decoder incompatibility?

[charleski]

I did a few test encodes using Sharktooth's profiles and have noticed that the files encoded with HQ-Slowest and HQ-Insane 'vibrate' at certain parts when playing them back in Nero Showtime or another player that uses the Nero Video Decoder. The skipping doesn't occur with the HQ-Slow or HQ-Slower profiles. Could people try them out to see if this happens on their systems as well? The big change from HQ-Slower to HQ-Slowest seems to be changing sub-pixel refinement from 6 to 7, is this the cause?

HQ-Slow (http://homepages.nildram.co.uk/~cajking/test-HQ-Slow.mp4) - MeGUI job file (http://homepages.nildram.co.uk/~cajking/job1.xml)
HQ-Slower (http://homepages.nildram.co.uk/~cajking/test-HQ-Slower.mp4) - MeGUI job file (http://homepages.nildram.co.uk/~cajking/job2.xml)
HQ-Slowest (http://homepages.nildram.co.uk/~cajking/test-HQ-Slowest.mp4) - MeGUI job file (http://homepages.nildram.co.uk/~cajking/job3.xml)
HQ-Insane (http://homepages.nildram.co.uk/~cajking/test-HQ-Insane.mp4) - MeGUI job file (http://homepages.nildram.co.uk/~cajking/job4.xml)

(As you might notice, I was trying to work out how to deal with the blocking on the wall in the background, I probably just need to twiddle the deblocking parameters to deal with this - it's a noisy source because the cinematographer used some ******* arty grain in the picture, grr).

My Nero installation is the latest version of 6.6 BTW

[bond]

I did a few test encodes using Sharktooth's profiles and have noticed that the files encoded with HQ-Slowest and HQ-Insane 'vibrate' at certain parts when playing them back in Nero Showtime or another player that uses the Nero Video Decoder. The skipping doesn't occur with the HQ-Slow or HQ-Slower profiles. Could people try them out to see if this happens on their systems as well? The big change from HQ-Slower to HQ-Slowest seems to be changing sub-pixel refinement from 6 to 7, is this the cause?where exactly should this vibrating/skipping occur?

(As you might notice, I was trying to work out how to deal with the blocking on the wall in the background, I probably just need to twiddle the deblocking parameters to deal with this - it's a noisy source because the cinematographer used some ******* arty grain in the picture, grr).imho deblocking doesnt really help getting rid of blocks in walls

i recently tried myself various ways on how to get rid of these walls blocks and my conclusion is that there is no way in x264 atm (well strictly speaking it handles walls blocks very good already compared to other codecs)

nero uses adaptive quantisation for better getting rid of blocks in walls (you can enable aq in nero by setting the psychovisual enhancement to 2), but x264's current beta aq does NOT have the same effect
in fact x264s current aq seems to not influence bright walls at all

[charleski]

where exactly should this vibrating/skipping occur?It happens for me at 7 seconds into both the HQ-Slowest and HQ-Insane files. I suspect I can get rid of it by taking measures to force ffdshow to decode the content instead, but compatibility is the issue that worries me.

imho deblocking doesnt really help getting rid of blocks in walls

i recently tried myself various ways on how to get rid of these walls blocks and my conclusion is that there is no way in x264 atm (well strictly speaking it handles walls blocks very good already compared to other codecs)

nero uses adaptive quantisation for better getting rid of blocks in walls (you can enable aq in nero by setting the psychovisual enhancement to 2), but x264's current beta aq does NOT have the same effect
in fact x264s current aq seems to not influence bright walls at all
Hmm, thanks for the advice. It's better than the banding and fixed-pattern stuff I've seen in xvid, but the dirtiness still bugs me. I want to avoid resorting to pre-filtering to get rid of the grain (which I'm sure is the root cause), but I might have to.

[bond]

It happens for me at 7 seconds into both the HQ-Slowest and HQ-Insane files. I suspect I can get rid of it by taking measures to force ffdshow to decode the content instead, but compatibility is the issue that worries me.unless you can desribe me more clearly where you see a problem and how it looks like i can only say i dont see anything strange when decoding with nero

Hmm, thanks for the advice. It's better than the banding and fixed-pattern stuff I've seen in xvid, but the dirtiness still bugs me. I want to avoid resorting to pre-filtering to get rid of the grain (which I'm sure is the root cause), but I might have to. imho the cause for blocky walls is not too much grain, in contrary the "grainier" the walls the better they look like

[Sharktooth]

A new build which fixes --subme 7 is coming.

EDIT: Done.

[charleski]

Unfortunately I still see the same behaviour in Nero Showtime when the test is encoded with the r365 build. At 7 seconds into the file (and at various times past that) the video appears to be jumping back a frame so that the image appears to 'vibrate'. It seems to be going (frame no.s) n-2, n-1, n, n-1, n+1, n+2, n+1, etc. Each episode lasts for a second or so, then it carries on playing normally. Unfortunately Showtime won't single-step through the frames, so I can't check it that way.

Playback using other DirectShow players which utilise ffdshow demonstrate no such problems. If the player uses Nero Video Decoder, though, the video skips at the same point as the phenomenon in Showtime (instead of shuffling back-and-forth it will hang on a frame then jump forward).

[bond]

indeed, i now also saw it. its only there when using nero parser and decoder

its an already known problem in neros filters and has been reported twice already, no fix available till now (altough i told johnv already)

[charleski]

Ah, thanks. I was worried about compatibility issues (which was always the bane of avi), but if it's a known bug in Nero that's something I can live with.

[JohnV]

Yes it's reported.