MV hints = more speed but even more blocks

[unplugged]

All my suspects started by recent encodes when, at same time, I have enabled MV hints and...
having to test and aiming my attentions to this pain :D of alternative curve, some strange "mass macroblock" supervention has totally confused my CC quality evaluation tests :mad:...

Thanks to Foxer (and post by others) explanations finally I have found the good curve concept and basic setup in alt-CC for videos.

After this I have aimed to solve the "mass macroblock" problem addressed in my ultimate test encodes; I found some motion frames suffering by excessive dribble too localized and a bit strange, like something related to the "motion tracking".
Meanwhile I red in some post that MV-hints data file contains motion vectors calculated with fixed quantizer 2 for all frames...
Reading more I have understood that this method is rather new and accepted as is...
I don't remember exactly -h's post but he wrote something about MV-hints saying that using all motion vectors calculations based to lower quantizer (2 quant, 1st pass), this could carry a bit more detail from frame to frame, because of the more precision (correct me :o).
An generally some few little benefits are expected...

I have made my last encode of my test-movie WITHOUT MV-hints and a lot of macroblocks (really messed up) systematically in motion areas are disappeared :).
Though in very low motion areas I have registered a very little decrease in image detail, must say (negligible).

My encode:
1h 50min, 704x424 (vertically pos. and aligned by 2 ;) to match YV12 planes)
Koepi's XviD-20020502 compile
bitrate choice ~1620 Kbit/s
Motion search 6, MPEG quant, min I-frame 5, max I-frame 1000
alt-CC Medium (linear) ;) High=350 Low=99
Bonus bias manual to 0. (100% distributed)
Max bitrate 8000 kbit/s.
the rest set to default.

Look this shot, this is just an example, in several motion sections of this movie there are macroblocks messed up and rather visible during play, because of the continuous fluctuation by MV-Hints data (sometimes dribbles on edges).
ZOOM the image to see what you can see during play.

[Koepi]

Your resolution may be way too high for that particular movie.

If you'd do "contact" on that esolution, no problem, but the matrix prolly would be a mess.

So your posting considers only an extreme situation.

do the same with divx3.11 and nandub and then tell again what wonders xvid did ;)

SCNR

[unplugged]

Last, I have an attachment with 3 images taken from an high motion section, the third image is the original MPEG2 frame.
All JPEGs are virtually identical to original bitmaps (I already checked the minimal compression loss).

For example, to see differences overlap this images with 3 sessions of your favourite image viewer... ACDSee?
then animate...
(high-tech home benchmarking of course :p)

MV-hints enabled screenshot shows a little *crazy* detail, as if the codec tries to describe detail that cannot, because of low bitrate or because of the quantizer.
The screenshot obtained from NO-MVhints encode is more uniform and rightly more soft in nuance areas.

[unplugged]

Originally posted by Koepi
Your resolution may be way too high for that particular movie.

If you'd do "contact" on that esolution, no problem, but the matrix prolly would be a mess.

So your posting considers only an extreme situation.

Yes, must say that is the-edge, but the advantage of not resizing (YV12) is more (trust me) than bitrate bonus by using 704x304 resolution.
Almost... with my ultimate fine-tune findings, the image result rocks!! :D:D

In certain sense, XviD seems don't need B-frames... :)
IMHO the first priority for this encoder is further motion engine improvement (QP), edge smart quantize, custom graphical alt-CC shape :D.

[unplugged]

Originally posted by Koepi
So your posting considers only an extreme situation.

These mass-macroblock differences are pretty visible around all the movie, and quality is almost always on favour of the NO-MVhints movie.

So, I think also 1 CD encodes are extreme (mine is for 2CD), consider that even when you resize down, much pixel detail isn't lost but "concentrated", so compressible gain isn't so as expected...
Not only, resizing down, "forces" the 2 Croma planes (that as you know have half x/y resolution: 360x288) of YV12 data to redistribute his color value with an approximation of 2 horizontal/vertical pixels in relation with Luma plane (720x576).
So, after resize, especially horiz. and vertical resize, probably a good amount of Luma pixels doesn't match exactly (or absolutely) with the *original* respective croma value.

[scorchED]

Originally posted by unplugged
Last, I have an attachment with 3 images taken from an high motion section, the third image is the original MPEG2 frame.
All JPEGs are virtually identical to original bitmaps (I already checked the minimal compression loss).


I think that the picture where is MVhints enabled looks better than the picture encoded without MVhints. it looks more like the original than the picture without MVhints - just look at the heads or the structure of the fog, for example. In my opinion it has more details like the original picture which was attached.

[MfA]

As far as pictures are concenred Id say mv hints looks better. Blockiness isnt a whole lot worse, but you can clearly see some shape changes taking place without the hints.

Of course I have not myself tested the difference in motion, so if you say its worse Ill have to take your word for it ... cant tell much from a single screenshot.

[unplugged]

Trust me, take care about motion and do some test...

Edit:
Quantize disposition, even with slight less detail, appears more uniform to me, however look the first image (soldier) posted zoomed fullscreen or more, you will find a hell of blocks with MVhints shot, blocks disposed in a manner that totally breaks the uniformity (every 8 pixels).

Of course, it's right that whe must condiser real playback conditions (not zoomed :D), but why spend so much time to optimize codec's detail fidelity and then cash that quantization garbage?

[duartix]

704x424 (vertically pos. and aligned by 2 to match YV12 planes) I'm sorry unplugged, but would you care to expand on this?

[kilg0r3]

@unplugged

yes, please. even though my athlon 700@856 might be way to slow to decode such a video. :-(

[unplugged]

Originally posted by duartix
I'm sorry unplugged, but would you care to expand on this?

The reason is a bit technical related :scared:, most of MPEG2 stuff and all MPEG4 frames are saved using the color space called YV12.
For an example of color space, the highest and most used video cards' color space is (called) RGB, you have 24 bit of color information per point (pixel), thus each pixel has 8-bit per each primary color: Red, Green ,Blue.
About "color space" should be intended the disposition scheme and the quantization range of pixel data into memory ("quantize" mean digitalize or rescale down data digitalized yet).
The YV12 color space is most used for image and videos because of the different approach to color definition (not red-green-blue), this scheme permits very aggressive quantization with low image loss... at least for human eye...

YV12 have also 3 values for pixel data, but different behavior: Y, Cr and Cb.
Y=luminance, C=chrominance.
Y data is 8-bit per 1 pixel, but both chrominance values even with 8-bit range apiece MUST represent information for 4 adjacent pixels: 2 horizontal and 2 vertical.
For example using a YV12 color space of 720x576 pixels you have "only" 360x288 8-bit chrominance data for Cr and 360x288 8-bit for Cb, so only each 2 horizonal/vertical pixels Chrominance data accomplishes Luminance data (Y fits full res 720x576).

So I'm here at your issue :p
If you crop an image from this color space (YV12) by using ODD vertical/horizonal offset, in few words NOT ALIGNED BY 2 pixels, the cropped result put in another YV12 buffer (later passed to XviD...) will have chrominance space drastically resampled: chroma values totally flatted especially in high color contrast areas.
(because resampling by 2 a color space yet sampled by 2 with NON-aligned (ODD) offset totally blurs chroma content).

Of course, this chroma RAW granularity (2x2) also suffers a bit with resize operations.


YV12 is also called YUV 4:2:0.
Space color info (http://www.cs.sfu.ca/undergrad/CourseMaterials/CMPT479/material/notes/Chap3/Chap3.4/Chap3.4.html#video_signal)

[Chibi Jasmin]

What if we crop/resize in AviSynth? Isn't YV12 converted to YUY2 (YUV 4:2:2) first, so that we only have to have even (mod 2) values horizontally?

Is there a way to process mpeg2->mpeg4 conversion entirely in YV12?

[Teegedeck]

That should be possible in Xmpeg and in the SAVE-project.

[unplugged]

Originally posted by Chibi Jasmin
What if we crop/resize in AviSynth? Isn't YV12 converted to YUY2 (YUV 4:2:2) first, so that we only have to have even (mod 2) values horizontally?

Yes, Avisynth works with YUY2 space (4:2:2), but don't worry, there are NO loss implications, at all.
YUY2 simply has FULL vertical chrominance resolution, not half.

Originally posted by Chibi Jasmin
Is there a way to process mpeg2->mpeg4 conversion entirely in YV12?

Mpeg2avi, Xmpeg and maybe some other tools less popular...
I'm using mpeg2avi because is the fastest, has by default REAL IEEE strict compilant decoder, and improved by ikerrg (Iker Rodriguez).

To be honest, the best featured method is VirtualDub(fastrepack) + Avisynth + mpeg2dec.dll (also very fast), but it seems that MPEG2 decode dll doesn't fit IEEE quality standard (as Xmpeg test says that DVD2AVI MMX/SSE decode engine fails the test just at start...) and plus with certain movies give some frames messed up to output... (by personal experience :().

[trbarry]

quote:
Originally posted by Chibi Jasmin
What if we crop/resize in AviSynth? Isn't YV12 converted to YUY2 (YUV 4:2:2) first, so that we only have to have even (mod 2) values horizontally?
--------------------------------------------------------------------------------
Yes, Avisynth works with YUY2 space (4:2:2), but don't worry, there are NO loss implications, at all.
YUY2 simply has FULL vertical chrominance resolution, not half.


I still wonder about that. In YUY2 converted from YV12 half the pixels, both horizontally and vertically, have been created by interpolation. If you crop and then convert back to YV12 in the encoder it seems there might still be problems similar to just cropping in YV12. But I can't really visualize what's happening and haven't studied the Xvid YUY2->YV12 code yet. Do repeated color conversions back and forth YV12 <-> YUY2 cause a loss of color resolution?


To be honest, the best featured method is VirtualDub(fastrepack) + Avisynth + mpeg2dec.dll (also very fast), but it seems that MPEG2 decode dll doesn't fit IEEE quality standard (as Xmpeg test says that DVD2AVI MMX/SSE decode engine fails the test just at start...)

Drat! I certified the new MPEG2DEC and DVD2AVI SSE2 IDCT code for my own puposes simply by comparing binary output with the MMX/SSE versions so it will have the same bugs, if any. Where can I find out more about this problem?

- Tom

[Nic]

@Tom: No need to Drat... :) The SSE MMX of DVD2AVI is the fastest. & although not strictly IEEE compiliant. I have never found anyone that can notice the difference between 64bit reference iDCT & SSE MMX iDCT.

If there's anyone that truly understands the differences between the iDCTs its liaor/pcdvdguy. Try contacting him if you have any doubts :)

Cheers,
-Nic

[trbarry]

Nic -

Thanks, I'll take your word for it. I just was afraid new bugs had surfaced. And I never really understood IDCT at all. I just added DmitryR's code plus some extra code that did both IDCT's for awhile and compared them.

The SSE MMX of DVD2AVI is the fastest...

Not anymore. The SSE2 MMX is the fastest now, at least on P4's. ;)

- Tom

[unplugged]

Originally posted by trbarry
both horizontally and vertically, have been created by interpolation.

Why also horizontally resampled? :confused:

[trbarry]

Why also horizontally resampled?

Oops. Only vertical. :(

But I still wonder if repeated round trip conversions between YUY2 and YV12 can soften color detail, just because of the vertical interpolations.

- Tom

[Chibi Jasmin]

Originally posted by unplugged


Yes, Avisynth works with YUY2 space (4:2:2), but don't worry, there are NO loss implications, at all.
YUY2 simply has FULL vertical chrominance resolution, not half.



That means I can resize/crop vertically with odd values in AviSynth without problems, right? Or what do you think about Tom's suggestion about loss of color resolution?
Originally posted by unplugged


Mpeg2avi, Xmpeg and maybe some other tools less popular...
I'm using mpeg2avi because is the fastest, has by default REAL IEEE strict compilant decoder, and improved by ikerrg (Iker Rodriguez).

To be honest, the best featured method is VirtualDub(fastrepack) + Avisynth + mpeg2dec.dll (also very fast), but it seems that MPEG2 decode dll doesn't fit IEEE quality standard (as Xmpeg test says that DVD2AVI MMX/SSE decode engine fails the test just at start...) and plus with certain movies give some frames messed up to output... (by personal experience :().

There was something that bugged me with mpeg2avi...ah yes, I remember, you only have a centered crop window...and can't crop let's say left 6 and right 10 pixels or something like that...

Well, for the other method we could simply use IEEE reference code, or isn't that implemented in MPEG2DEC.DLL and it uses MMX/SSE, although IEEE ref. is selected in D2V?

[Chibi Jasmin]

Originally posted by Teegedeck
That should be possible in Xmpeg and in the SAVE-project.

The SAVE-Project hasn't any of this implemented yet, or did I miss something? But I am glad, they are working on it.

[vlad59]

Nope no YV12 support......

sadly... :(

I'll try to understand that (and eventually add that) after adding the bressenham resize filter.

[unplugged]

Originally posted by Chibi Jasmin
That means I can resize/crop vertically with odd values in AviSynth without problems, right?

Yes, for vertical you feel free...

Originally posted by Chibi Jasmin
Or what do you think about Tom's suggestion about loss of color resolution?

He is rather expert coder with this matter, surely he knows behaivor better than us...

Originally posted by Chibi Jasmin
There was something that bugged me with mpeg2avi...ah yes, I remember, you only have a centered crop window...and can't crop let's say left 6 and right 10 pixels or something like that...

I know, limited crop is a nuisance, though often video are pretty centered...

I use also Xmpeg when mpeg2avi is real useless even if Xmpeg has tedious (stupid) interface behavior bugs!
And no frame numeration... ("where" are the titles??? :rolleyes: )

Originally posted by Chibi Jasmin
Well, for the other method we could simply use IEEE reference code, or isn't that implemented in MPEG2DEC.DLL and it uses MMX/SSE, although IEEE ref. is selected in D2V?

Original DVD2AVI IEEE reference (not default) iDCT HAS BUG, Haven't looked yet Onimusha PS2 video decode BUG (http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/refidct/)?
2nd I don't know if mpeg2dec.dll implement/support selection of other iDCT than default (SSE MMX)...

[trbarry]

quote:
--------------------------------------------------------------------------------
Originally posted by Chibi Jasmin
Or what do you think about Tom's suggestion about loss of color resolution?
--------------------------------------------------------------------------------
He is rather expert coder with this matter, surely he knows behaivor better than us...

Unplugged -

Whoa! I don't either claim or deserve that sort of credibility. I'm just an idea person who likes to toss things out on the table for discussion. And while I do believe there could be a small cumulative loss for converting back and forth YV12 <-> UYUY I can't claim to have sat down and worked out the math, or any concrete examples.

But it bothers me a bit because the round trip from DVD to Avisynth back to Xvid causes this to happen. And in some cases it may be converted to YUY2 a 2nd time during the decoding process. I could probably change DVD2AVI and MPEG2DEC to put out YV12 but I think trying to do the same thing for Avisynth and all its filters is more than I could tackle.

I do claim to be a professional programmer, but that just means that (on better days) I get paid for it and so lost my amateur status. ;)

- Tom

[Nic]

Thats a brilliant quote...im going to have to use that :D

I do claim to be a professional programmer, but that just means that (on better days) I get paid for it and so lost my amateur status.

Just to mention...Vidomi can do straight thru YV12 encoding...the source code is available too. Might be of some use some time....

-Nic

[unplugged]

@Tom

If you have made GreeyHMA or such video plugins...
so this is reason because can I think that...

not necessarily professional :), but quite documented in this matter...

[trbarry]

Just to mention...Vidomi can do straight thru YV12 encoding...the source code is available too. Might be of some use some time....

Nic -

Yes, that is still on my wish/todo list for DVD2AVI and Xvid. I'll take a look at that.

How is your DVD2AVI version coming? I'd sort of hoped to be able to pilfer all the nifty enhancements of your version before I attacked the Sourceforge save-oe project for Xvid. This is because modifying Avisynth to do YV12 is beyond the scope of what I'd be willing to tackle, at least by myself. So any native YV12 option would have to be one that went directly from DVD2AVI to Xvid.

But it seems a shame to me that, except for TV cap's, almost all our input data (DVD's, HDTV) is in YV12 format and our target files (Xvid, Divx) are in YV12 format but we do most of our processing in RGB or YUY2. I think this means all the chroma data has been softened by interpolation, 50% of it is redundant, and we have to process 33% more bytes of data for no real benefit.

That just seems unaesthetic somehow. ;)

- Tom

[Chibi Jasmin]

Originally posted by vlad59
Nope no YV12 support......

sadly... :(

I'll try to understand that (and eventually add that) after adding the bressenham resize filter.

Great...

[Chibi Jasmin]

Originally posted by unplugged


Yes, for vertical you feel free...



He is rather expert coder with this matter, surely he knows behaivor better than us...



I know, limited crop is a nuisance, though often video are pretty centered...

I use also Xmpeg when mpeg2avi is real useless even if Xmpeg has tedious (stupid) interface behavior bugs!
And no frame numeration... ("where" are the titles??? :rolleyes: )



Original DVD2AVI IEEE reference (not default) iDCT HAS BUG, Haven't looked yet Onimusha PS2 video decode BUG (http://arbor.ee.ntu.edu.tw/~jackei/dvd2avi/refidct/)?
2nd I don't know if mpeg2dec.dll implement/support selection of other iDCT than default (SSE MMX)...

Thanx for your answer, I understood you correctly then (about vertical cropping)...I used the ieee reference in dvd2avi a lot and never had this 'bug' in a movie...I know, it has this ps2 thing, but for me it worked fine...but I used mpeg2dec.dll, maybe it used sse mmx, although I had set dvd2avi to ieee reference? Who knows...

[Chibi Jasmin]

Originally posted by Nic
Thats a brilliant quote...im going to have to use that :D



Just to mention...Vidomi can do straight thru YV12 encoding...the source code is available too. Might be of some use some time....

-Nic

Well, there's no real reason to use Vidomi except YV12, is there? I didn't even find, where to set the codec configuration for the second pass :) And I doubt, the special 'Vidomi' encoding modes make any sense...or did I miss something? Maybe Vidomi is worth a try? Just dumped it after a short look...

But also looked a bit at XMpeg...maybe YV12 in XMpeg is worth a real test...it seems to have the most basic options needed to make a decent encode in YV12...but I had a 7 frame delay in the output avi using ntsc-source with reconstruct progressive images...strange...anyone knows about this?

[rui]

Chibi, i had a look at vidomi some time ago, but didn’t like it either.
Those vidomi encoding modes also puzzled me. But I remember that the “thing“ crashed in my system, so I gave up. But I think they have a Pentium4 special version, maybe Pentium4 users find it useful.

About xmpeg, it was my starting software in this divx/xvid matters. So, for some nostalgic sentiment, I can’t throw it out :D
But xmpeg wasn’t much faster because of YV12. It was a little faster because I used the bressenham resize filter. But that filter really blurs too much for my taste.
If I used bicubic, which is what I use in avisynth (sharp), xmpeg would loose much of its speed. That is, when it wasn’t crashing :D

[Chibi Jasmin]

Originally posted by rui
Chibi, i had a look at vidomi some time ago, but didn’t like it either.
Those vidomi encoding modes also puzzled me. But I remember that the “thing“ crashed in my system, so I gave up. But I think they have a Pentium4 special version, maybe Pentium4 users find it useful.

About xmpeg, it was my starting software in this divx/xvid matters. So, for some nostalgic sentiment, I can’t throw it out :D
But xmpeg wasn’t much faster because of YV12. It was a little faster because I used the bressenham resize filter. But that filter really blurs too much for my taste.
If I used bicubic, which is what I use in avisynth (sharp), xmpeg would loose much of its speed. That is, when it wasn’t crashing :D

Reading what Tom said above I thought maybe XMpeg is more accurate because of YV12, not necessarily much faster...

Well, maybe DVD2AVI or now SAVE-OE integrates YV12 someday...

BTW: You know anything of some frames delayed output with XMPeg using 'reconstruct progressive frames' on ntsc-input?

[rui]

Originally posted by Chibi Jasmin


Reading what Tom said above I thought maybe XMpeg is more accurate because of YV12, not necessarily much faster...

You are correct, sorry.

Originally posted by Chibi Jasmin

BTW: You know anything of some frames delayed output with XMPeg using 'reconstruct progressive frames' on ntsc-input?


I can't help you here :(, because since i live in Europe all my dvd's are PAL.

[Chibi Jasmin]

Thanx anyway... :)

[Nic]

About Vidomi, I just assumed, seeing it states about doing YV12 encoding, it might have some useful source code (i.e. YV12 resizing etc), but I havent looked.

Ill check it out tomorrow, seeing I know some of the source is based on DVD2AVI, it might help. :)

-Nic

ps
I hadnt heard from Marty in about a month, & now he's dropped me an email... coincidence :)

[Chibi Jasmin]

The YV12 resizing in Vidomi is from MPEG2AVI according to Marty in the Vidomi Forum...

[Nic]

Seems that way Jasmin (browsing thru the source). Its very well written...you can tell he was getting paid to do it :) (the source code I get paid to write always looks very different to the stuff I write for myself :) )

-Nic

[Dali Lama]

hey nic are you saying that marty was getting paid to write Vidomi? Why?

Also, I know I asked you before, but why arn't you two guys and Tom and the rest working together on DVD2AVI or Vidomi. It seems to me like two or more smart minds working together is better than one?

Ok thanks for spilling the gossip,

Dali

[Chibi Jasmin]

Originally posted by Nic
Seems that way Jasmin (browsing thru the source). Its very well written...you can tell he was getting paid to do it :) (the source code I get paid to write always looks very different to the stuff I write for myself :) )

-Nic

I didn't test it myself and I don't know if it's true, but I saw some people in the vidomi forum say the output of the yv12 resizing is quite blurry and that's why they use rgb32 with vidomi...

[Nic]

Marty did initially get paid to do it...but with all the GPL issues, etc that fell through, vidomi had another way of making money...but that hasn't come to completion yet.

We are all working kind of together on DVD2AVI, just going in different directions...I hope eventually we will merge with all the best aspects :)
(vlad & tom work pretty much in the same direction, int21 will join when his work has calmed down, im going off on my own weird tangent...but I hope it will be worth it :) )

@Jasmin: Ill look into that, thanks for the info :)

-Nic

[Chibi Jasmin]

Originally posted by Nic
Marty did initially get paid to do it...but with all the GPL issues, etc that fell through, vidomi had another way of making money...but that hasn't come to completion yet.

We are all working kind of together on DVD2AVI, just going in different directions...I hope eventually we will merge with all the best aspects :)
(vlad & tom work pretty much in the same direction, int21 will join when his work has calmed down, im going off on my own weird tangent...but I hope it will be worth it :) )

@Jasmin: Ill look into that, thanks for the info :)

-Nic

Yep, let us know your results of looking into the yv12 resize routine.

And about DVD2AVI (and mpeg2dec.dll) I also hope, there will be ONE version at the end including all needed features.