Re: [FFmpeg-devel] [PATCH 4/4] zmbvenc: use unsigned values for score calculations

2018-12-25 Thread Tomas Härdin
lör 2018-12-22 klockan 15:54 + skrev Matthew Fearnley:
> > On 22 Dec 2018, at 12:15, Tomas Härdin  wrote:
> > 
> > tor 2018-12-20 klockan 17:48 + skrev Matthew Fearnley:
> > > > > > On Thu, 20 Dec 2018 at 16:30, Tomas Härdin  > > > > > .se> wrote:
> > > > 
> > > > Trivial enough. You could probably roll many or even all of
> > > > these
> > > > patches together
> > > 
> > > Thanks for your feedback.  I was reluctant to submit so many
> > > patches, but I
> > > worried at the time that combining them would require an overly
> > > long commit
> > > message.  Maybe I'm being too verbose though...
> > > What's the best way to submit a combined patch - from a
> > > Patchwork/mailing
> > > list perspective?
> > 
> > How large a patch should be is somewhat arbitrary. I tend to try to
> > keep each patch related to a single "concept". And of course
> > separating
> > cosmetic and functional changes
> > 
> > It's mostly the having to have PATCH 3/4 before PATCH 1/4 prompting
> > this suggestion. Or maybe rolling them together
> 
> If I roll the patches together (and include the additional
> suggestions in PATCH 1), would it be best to just email a new patch,
> and have these closed?

If you have a new set of patches then a new thread is best, yes

/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 4/4] zmbvenc: use unsigned values for score calculations

2018-12-22 Thread Matthew Fearnley

> On 22 Dec 2018, at 12:15, Tomas Härdin  wrote:
> 
> tor 2018-12-20 klockan 17:48 + skrev Matthew Fearnley:
> On Thu, 20 Dec 2018 at 16:30, Tomas Härdin  wrote:
>>> 
>>> Trivial enough. You could probably roll many or even all of these
>>> patches together
>> 
>> Thanks for your feedback.  I was reluctant to submit so many patches, but I
>> worried at the time that combining them would require an overly long commit
>> message.  Maybe I'm being too verbose though...
>> What's the best way to submit a combined patch - from a Patchwork/mailing
>> list perspective?
> 
> How large a patch should be is somewhat arbitrary. I tend to try to
> keep each patch related to a single "concept". And of course separating
> cosmetic and functional changes
> 
> It's mostly the having to have PATCH 3/4 before PATCH 1/4 prompting
> this suggestion. Or maybe rolling them together

If I roll the patches together (and include the additional suggestions in PATCH 
1), would it be best to just email a new patch, and have these closed?

Still struggling with general procedure here a bit...
Thanks for bearing with me.

Matthew
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 4/4] zmbvenc: use unsigned values for score calculations

2018-12-22 Thread Tomas Härdin
tor 2018-12-20 klockan 17:48 + skrev Matthew Fearnley:
> > On Thu, 20 Dec 2018 at 16:30, Tomas Härdin  wrote:
> 
> > Trivial enough. You could probably roll many or even all of these
> > patches together
> > 
> 
> Thanks for your feedback.  I was reluctant to submit so many patches, but I
> worried at the time that combining them would require an overly long commit
> message.  Maybe I'm being too verbose though...
> What's the best way to submit a combined patch - from a Patchwork/mailing
> list perspective?

How large a patch should be is somewhat arbitrary. I tend to try to
keep each patch related to a single "concept". And of course separating
 cosmetic and functional changes

It's mostly the having to have PATCH 3/4 before PATCH 1/4 prompting
this suggestion. Or maybe rolling them together

The primary reason for making nice patches it for making runs of git-
bisect easier

/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 4/4] zmbvenc: use unsigned values for score calculations

2018-12-20 Thread Matthew Fearnley
On Thu, 20 Dec 2018 at 16:30, Tomas Härdin  wrote:

> Trivial enough. You could probably roll many or even all of these
> patches together
>

Thanks for your feedback.  I was reluctant to submit so many patches, but I
worried at the time that combining them would require an overly long commit
message.  Maybe I'm being too verbose though...
What's the best way to submit a combined patch - from a Patchwork/mailing
list perspective?

Thanks again for your reviews.  I'm happy to make any changes necessary for
them to be committed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 4/4] zmbvenc: use unsigned values for score calculations

2018-12-20 Thread Tomas Härdin
ons 2018-12-19 klockan 22:00 + skrev matthew.w.fearn...@gmail.com:
> > From: Matthew Fearnley 
> 
> All the values in score_tab are positive or 0, and so should be the sum
> returned by block_cmp().
> 
> The logic in zmbv_me() assumes that all 'bv' values will be non-negative,
> in order to guarantee an early return if ever bv==0.
> ---
>  libavcodec/zmbvenc.c | 7 ---

Trivial enough. You could probably roll many or even all of these
patches together

/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 4/4] zmbvenc: use unsigned values for score calculations

2018-12-19 Thread matthew . w . fearnley
From: Matthew Fearnley 

All the values in score_tab are positive or 0, and so should be the sum
returned by block_cmp().

The logic in zmbv_me() assumes that all 'bv' values will be non-negative,
in order to guarantee an early return if ever bv==0.
---
 libavcodec/zmbvenc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavcodec/zmbvenc.c b/libavcodec/zmbvenc.c
index 0ebae1b254..9e1b44f15d 100644
--- a/libavcodec/zmbvenc.c
+++ b/libavcodec/zmbvenc.c
@@ -63,11 +63,11 @@ typedef struct ZmbvEncContext {
  * XXX should be optimized and moved to DSPContext
  * TODO handle out of edge ME
  */
-static inline int block_cmp(ZmbvEncContext *c, uint8_t *src, int stride,
+static inline unsigned int block_cmp(ZmbvEncContext *c, uint8_t *src, int 
stride,
 uint8_t *src2, int stride2, int bw, int bh,
 int *xored)
 {
-int sum = 0;
+unsigned int sum = 0;
 int i, j;
 uint16_t histogram[256] = {0};
 
@@ -99,7 +99,8 @@ static inline int block_cmp(ZmbvEncContext *c, uint8_t *src, 
int stride,
 static int zmbv_me(ZmbvEncContext *c, uint8_t *src, int sstride, uint8_t *prev,
int pstride, int x, int y, int *mx, int *my, int *xored)
 {
-int dx, dy, tx, ty, tv, bv, bw, bh;
+int dx, dy, tx, ty, bw, bh;
+unsigned int tv, bv;
 int txored;
 
 *mx = *my = 0;
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel