headers
List, Peter | 1 Aug 2007 11:22
Favicon

Re: out-of-range motion vectors

Dear all,

 

Ok, it now is clarified that motion-vectors of sizes like 500 are legal and it was shown how it can happen that these sizes are generated. I think there is more to it though:

Do these vectors represent a true motion of 125 full pels, or has the estimation algorithm gone into some local minima far away from the “real” motion?

I believe, most of the time these very large vectors produce largely suboptimal results.

 

To avoid the drift to larger and larger values one could first do a  RD-weighted check whether  motion compensation with the predictor (you called it candidate position!?) generates a better result than motion compensation with (0,0).

If (0,0) wins, we would do our search from there.

Maybe there are better methods to avoid this drift, but what ever method, it could be a simple way to further improve coding efficiency.

 

Regards

                          Peter

 

 

 

-----------------------------------------------------------------

Dr. Peter List

Senior Engineer

T-Systems Enterprise Services GmbH

Deutsche-Telekom-Allee 7, 64295 Darmstadt, Germany

Phone:   +49 6151 937 3878

Fax:       +49 6151 937 7748

E-Mail:    mailto:Peter.List <at> t-systems.com

Internet: http://www.t-systems.com

_____________________________________

 

T-Systems Enterprise Services GmbH

Supervisory Board: René Obermann (Chairman)

Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann,

Ulrich Kemp, Axel Knobe*, Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger*

Commercial register: Amtsgericht Frankfurt am Main HRB 55933

Registered office: Frankfurt am Main

WEEE -Reg.-No. DE87523644

*Member of the Board of Directors as defined under section 35 GmbHG

 

Notice: This transmittal and/or attachments may be privileged or confidential. If you are

not the intended recipient, you are hereby notified that you have received this transmittal

in error; any review, dissemination, or copying is strictly prohibited. If you received this

transmittal in error, please notify us immediately by reply and immediately delete this

message and all its attachments. Thank you.

_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 5 comments |
headers
Gabriel Bouvigne | 1 Aug 2007 11:45
Favicon

Re: out-of-range motion vectors

List, Peter a écrit :
> To avoid the drift to larger and larger values one could first do a 
>  RD-weighted check whether  motion compensation with the predictor (you 
> called it candidate position!?) generates a better result than motion 
> compensation with (0,0).
> 
> If (0,0) wins, we would do our search from there.

That is already done: (0,0) is one of the initial candidates
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 4 comments |
headers
CAdevel | 1 Aug 2007 11:46
Picon

Re: out-of-range motion vectors

What part makes sense?

If you're wondering why 37 > mvrange, that might be because mvrange isn't
strictly enforced. I do strictly enforce the limits of the standard
(2048 horizontal, 512 vertical), but any smaller mvrange is regarded only
as a suggestion, and various mv refinement procedures may extend several
pixels beyond the nominal range.
 
 
This part made sense allready. What I did not expect was legal motion vectors of ranges up to 500. But you explained how this 'drifting' can happen, and now I understand. Thank you Loren!
 
By the way, I checked the standard on the limits on the motion vectors and I found that the horizontal motion vector range is limited to [-2048,2047,75] luma samples. However the vertical motion vector limit depends on the level (Table A.1 of the standard) and can be 64, 128, 256, or 512. I assume x264 obeys these limits?

The remarks of Peter makes sense to me. When analyzing movies and finding these large motion vectors, I did not see any 'pictural' reason for these large vectors. It would be worthwhile investigating the idea of Peter of preventing drifting. However, this is where it stops for me. I am desinging multimedia processors and I found out that I have to count on large motion vectors any time.
 
Thanx again
Cor
 
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 1 comment |
headers
List, Peter | 1 Aug 2007 12:04
Favicon

Re: out-of-range motion vectors

Ok, great...

So, do you think the drift to enormous motion values is not an issue? 
When I read what Cor observed:

> When analyzing movies and finding these large motion vectors, 
> I did not see any 'pictural' reason for these large vectors.

I reason there still might be some suboptimality in the algorithm (not a criticism). Probably just a little
tweak would be enough...

Regards
                    Peter

> List, Peter a écrit :
> > To avoid the drift to larger and larger values one could first do a
> >  RD-weighted check whether  motion compensation with the predictor (you
> > called it candidate position!?) generates a better result than motion
> > compensation with (0,0).
> >
> > If (0,0) wins, we would do our search from there.
> 
> That is already done: (0,0) is one of the initial candidates

_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 3 comments |
headers
Gabriel Bouvigne | 1 Aug 2007 12:08
Favicon

Re: out-of-range motion vectors

List, Peter a écrit :
> So, do you think the drift to enormous motion values is not an issue? 

Don't get me wrong: I think that in some cases it is an issue, and that 
fixing this issue could potentially improve compressibility.

> When I read what Cor observed:
> 
>> When analyzing movies and finding these large motion vectors, 
>> I did not see any 'pictural' reason for these large vectors.
> 
> I reason there still might be some suboptimality in the algorithm (not a criticism). Probably just a
little tweak would be enough...

My guess is that it might requires more than just a little tweak, 
otherwise someone would have already done it.
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 2 comments |
headers
Foxy | 1 Aug 2007 12:33
Picon
Favicon

Re: out-of-range motion vectors

Gabriel Bouvigne wrote:
> List, Peter a écrit :
>   
>> So, do you think the drift to enormous motion values is not an issue? 
>>     
>
> Don't get me wrong: I think that in some cases it is an issue, and that 
> fixing this issue could potentially improve compressibility.
>
>   
Not necessarily. I've been looking for the Doom9 thread, but it was 
discussed in the context of interframe interpolation that the truest 
motion of any given block may not correspond to the least residue or 
most efficient coding. It's better for x264 to choose the most efficient 
way to code a frame (and those it depends on) than to make the vectors 
look pretty.
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 1 comment |
headers
List, Peter | 1 Aug 2007 13:31
Favicon

Re: out-of-range motion vectors


> Von: Foxy [mailto:foxyshadis <at> hotmail.com]

> Gabriel Bouvigne wrote:
> > List, Peter a écrit :
> >
> >> So, do you think the drift to enormous motion values is not an issue?
> >>
> >
> > Don't get me wrong: I think that in some cases it is an issue, and that
> > fixing this issue could potentially improve compressibility.
> >
> >
> Not necessarily. I've been looking for the Doom9 thread, but it was
> discussed in the context of interframe interpolation that the truest
> motion of any given block may not correspond to the least residue or
> most efficient coding. It's better for x264 to choose the most efficient
> way to code a frame (and those it depends on) than to make the vectors
> look pretty.

Two comments to these arguments:

1. Don't forget that these huge vectors are most likely NOT the best 
vectors and coding them can be pretty inefficient. That is because if 
you start at an offset of 125 full pels, but have a search range of 
only +-32 you would not be able to check the vector range of 0...+-93!
That's why I talk about "drift". Once far enough off from the true 
minimum we might never find "the way back" and have in fact VERY bad vectors. That hopefully does not happen
in the x264 implementation though, 
because we always check the (0,0) vector in parallel as I just learned.  
One point here could be the following: 
If we start from a very large offset, because the predictor has a very 
large value, the (0,0) prediction might get a very high RD-weight, and 
get rejected for just this reason. Probably one could experiment with 
varying (reducing) the motion-vector RD-weight for the (0,0) case... 

2. Even if these vectors are the most efficient from an RD point of view 
and in fact produce the highest SNR. Still, the SUBJECTIVE quality 
might be better with the "true motion". The "true motion" usually has SAD 
values very close to the mathematical minimum anyways. 

Regards
Peter

_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 0 comments |
headers
Loren Merritt | 1 Aug 2007 18:25

Re: out-of-range motion vectors

On Wed, 1 Aug 2007, CAdevel wrote:

> By the way, I checked the standard on the limits on the motion vectors and I
> found that the horizontal motion vector range is limited to [-2048,2047,75]
> luma samples. However the vertical motion vector limit depends on the level
> (Table A.1 of the standard) and can be 64, 128, 256, or 512. I assume x264
> obeys these limits?

No. The default mvrange ("auto") does vary according to level, but as I 
said it's not enforced, only suggested.
Levels are purely informative anyway. I tend to ignore them except for the 
few most important limitations (resolution and bitrate).

> The remarks of Peter makes sense to me. When analyzing movies and finding
> these large motion vectors, I did not see any 'pictural' reason for these
> large vectors. It would be worthwhile investigating the idea of Peter of
> preventing drifting. However, this is where it stops for me. I am desinging
> multimedia processors and I found out that I have to count on large motion
> vectors any time.

In any block where there is no corresponding object in the previous frame, 
the output of motion estimation will be essentially random. Most of the 
time such blocks will be intra coded, but occasionally they find some 
feature of the previous frame thats worth something as a prediction.
Or maybe a macroblock is partitioned, and one partition is nicely inter 
predicted while another partition should be intra, but h264 only allows 
whole macroblocks to be intra or not, so the encoder has to pick some 
mv. Or intra might be prevented for other reasons: some CQMs screw with 
mode decision.

--Loren Merritt
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 0 comments |
headers
Gabriel Bouvigne | 2 Aug 2007 10:47
Favicon

b frame bias and first b frame

Right now, we can see within x264_slicetype_analyse that b frame bias is 
impacting decision to use b frames only from the second b in a row:

Choosing to insert a first B frame after a P/I is not influenced by b 
frame bias, but if it is decided to insert a B, then the next b frames 
decisions are impacted by b frame bias (ie: PB?, but not P?)

Shouldn't B frame bias also impact decision to insert the first B?

(no really sure about my wording within this mail)

--
Gabriel
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 4 comments |
headers
Loren Merritt | 2 Aug 2007 11:16

Re: b frame bias and first b frame

On Thu, 2 Aug 2007, Gabriel Bouvigne wrote:

> Right now, we can see within x264_slicetype_analyse that b frame bias is
> impacting decision to use b frames only from the second b in a row:
>
> Choosing to insert a first B frame after a P/I is not influenced by b
> frame bias, but if it is decided to insert a B, then the next b frames
> decisions are impacted by b frame bias (ie: PB?, but not P?)
>
> Shouldn't B frame bias also impact decision to insert the first B?

slicetype.c line 308

--Loren Merritt
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Permalink | Reply | 3 comments |

Gmane