> On 2 Apr 2019, at 16:48, Tomas Härdin wrote:
>
> mån 2019-04-01 klockan 13:29 +0100 skrev Matthew Fearnley:
>>>>> On 1 Apr 2019, at 10:28, Tomas Härdin wrote:
>>>
>>> fre 2019-03-29 klockan 22:23 + skrev Matthew Fearnley:
>>>&g
> On 1 Apr 2019, at 10:28, Tomas Härdin wrote:
>
> fre 2019-03-29 klockan 22:23 +0000 skrev Matthew Fearnley:
>>>> On Wed, 27 Mar 2019 at 09:42, Tomas Härdin wrote:
>>>> Additional minor fix: use PTRDIFF_SPECIFIER for `src - c->decomp_buf`.
>>>>
On Wed, 27 Mar 2019 at 09:42, Tomas Härdin wrote:
> tis 2019-03-26 klockan 22:13 + skrev Matthew Fearnley:
> > This brings the channel order in line with that used in 32-bit mode
> (BGR0).
> >
> > 24-bit decoding is disabled by default (#ifdef ZMBV_ENABLE_24BPP), and
Support is #ifdef'd out at this stage, using ZMBV_ENABLE_24BPP (like in
the zmbv.c decoder)
---
libavcodec/zmbvenc.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/zmbvenc.c b/libavcodec/zmbvenc.c
index 98029de5f6..48871758e0 100644
--- a/libavcodec/zmbvenc.c
+++ b/libavco
This brings the channel order in line with that used in 32-bit mode (BGR0).
24-bit decoding is disabled by default (#ifdef ZMBV_ENABLE_24BPP), and no
prior encoders or sample videos are known to exist for this bit depth, so
I consider this change in implementation is unlikely to affect anyone.
Th
> On 12 Mar 2019, at 11:46, Tomas Härdin wrote:
>
> tis 2019-03-12 klockan 10:27 +0000 skrev Matthew Fearnley:
>>> On 11 Mar 2019, at 10:37, Tomas Härdin wrote:
>>>
>>>
>>> There's some justification for adding sub-8bpp, like BMP. b
> On 11 Mar 2019, at 10:37, Tomas Härdin wrote:
>
> fre 2019-03-08 klockan 21:39 +0000 skrev Matthew Fearnley:
>>>> On Fri, 8 Mar 2019 at 18:07, Carl Eugen Hoyos wrote:
>>>> 2019-03-08 15:04 GMT+01:00, Tomas Härdin :
>>>>
>>>> Maybe we
On Fri, 8 Mar 2019 at 18:07, Carl Eugen Hoyos wrote:
> 2019-03-08 15:04 GMT+01:00, Tomas Härdin :
> > tor 2019-03-07 klockan 14:42 +0000 skrev Matthew Fearnley:
> >> This consists mostly of the following changes:
> >> - add newly supported pixel formats (RGB555LE, RG
This consists mostly of the following changes:
- add newly supported pixel formats (RGB555LE, RGB565LE, BGR0)
- select the ZMBV format (c->fmt) and bytes per pixel (c->bypp) based on
avctx->pix_fmt
- multiply widths/x-values by c->bypp, in places where bytes, not pixels, are
expected
- disable
On Thu, 21 Feb 2019 at 19:28, Michael Niedermayer
wrote:
> On Thu, Feb 21, 2019 at 11:19:08AM +0100, Tomas Härdin wrote:
> > ons 2019-02-20 klockan 22:12 +0100 skrev Michael Niedermayer:
> > > On Sat, Feb 09, 2019 at 01:10:20PM +, Matthew Fearnley wrote:
> > > &
On Thu, 21 Feb 2019 at 10:26, Tomas Härdin wrote:
> ons 2019-02-20 klockan 23:33 +0100 skrev Carl Eugen Hoyos:
> > > 2019-02-10 16:42 GMT+01:00, Tomas Härdin :
> > > lör 2019-02-09 klockan 13:10 + skrev Matthew Fearnley:
> > > > - Improve block choices b
On Thu, 31 Jan 2019 at 15:00, Tomas Härdin wrote:
>
> > 1. The entropy calculation in block_cmp() omits the score of histogram[0]
> > from the final sum.
> > It's tempting to do this to bias the scores in favour of 0-bytes, but in
> > reality, blocks with a majority of 0 (or any other byte) will
- Improve block choices by counting 0-bytes in the entropy score
- Make histogram use uint16_t type, to allow byte counts from 16*16
(current block size) up to 255*255 (maximum allowed 8bpp block size)
- Make sure score table is big enough for a full block's worth of bytes
- Calculate *xored withou
- Clamp ME range to -64..63 (prevents corruption when me_range is too high)
- Allow MV's up to *and including* the positive range limit
- Allow out-of-edge ME by padding the prev buffer with a border of 0's
- Try previous MV before checking the rest (improves speed in some cases)
- More robust logi
On Sun, 20 Jan 2019 at 15:16, Tomas Härdin wrote:
> > Hi. Just to say, I tried setting up additional score_tabs for the
> > bottom/right partial blocks. Unfortunately, after implementing it and
> > ironing out the bugs, the new score tables actually caused a slight
> > increase in file size!
>
On Tue, 25 Dec 2018 at 09:35, Tomas Härdin wrote:
> lör 2018-12-22 klockan 15:32 + skrev Matthew Fearnley:
> > > > >
> > > > Note that bw,bh aren't guaranteed to equal ZMBV_BLOCK, so
> `histogram[0] ==
> > > > bw*bh` would have to be
> On 18 Jan 2019, at 23:00, Michael Niedermayer wrote:
>
> Fixes: Timeout
> Fixes:
> 12192/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264
>
> Before:
> clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264
> in 15423 ms
> After:
> cl
> On 22 Dec 2018, at 12:15, Tomas Härdin wrote:
>
> tor 2018-12-20 klockan 17:48 +0000 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
>>&g
> On 20 Dec 2018, at 16:30, Tomas Härdin wrote:
>
> ons 2018-12-19 klockan 22:00 + skrev matthew.w.fearn...@gmail.com:
>>> From: Matthew Fearnley
>>
>> score_tab[] was only declared/initialised for elements 0..255, but with
>> block sizes set to
> On 22 Dec 2018, at 12:11, Tomas Härdin wrote:
>
> tor 2018-12-20 klockan 17:46 +0000 skrev Matthew Fearnley:
>>>> On Thu, 20 Dec 2018 at 16:30, Tomas Härdin wrote:
>>>
>>> I have a feeling this could be sped up further by just doing *xored =
>>
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
messa
On Thu, 20 Dec 2018 at 16:30, Tomas Härdin wrote:
> I have a feeling this could be sped up further by just doing *xored =
> histogram[0] == ZMBV_BLOCK*ZMBV_BLOCK after the loops, if [PATCH 3/4]
> is applied before this. Computing both histogram and xored in the loop
> seems pointless.
>
You're r
more
resilient to future changes, but I think this patch is good to go, as it is now.
Kind regards
Matthew
> On 15 Dec 2018, at 20:54, Matthew Fearnley
> wrote:
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman
On Sun, 9 Dec 2018 at 16:27, Michael Niedermayer
wrote:
> On Sat, Dec 08, 2018 at 02:53:44PM +0100, Tomas Härdin wrote:
> > lör 2018-12-08 klockan 00:29 +0000 skrev Matthew Fearnley:
> > > Hi Tomas, thanks for looking through my patch.
> > >
> > > > &g
Hi Tomas, thanks for looking through my patch.
> > Practically, this patch fixes graphical glitches e.g. when reencoding
the
> > Commander Keen sample video with me_range 65 or higher:
> >
> > ffmpeg -i keen4e_000.avi -c:v zmbv -me_range 65 keen4e_me65.avi
> I'd expect this problem to pop up
25 matches
Mail list logo