Hey Martin
> +ctx->tex_fun = ctx->dxtc.rgtc1u_block;
> +avctx->pix_fmt = AV_PIX_FMT_RGB0;
The rgtc1u_block function places the single channel value in every channel
except the alpha channel
The pixel format you have chosen is one which disregards the alpha channel
The output of
Yo
> Patch 1 : 0004-libavcodec-texturedspenc-add-rgtc1u-encoding
> +/**
> + * Compress one block of RGBA pixels in a RGTC1U texture and store the
> + * resulting bytes in 'dst'. Alpha is preserved.
> + *
> + * @param dstoutput buffer.
> + * @param stride scanline in bytes.
> + * @param block
> On 27 Sep 2017, at 11:59, Martin Vignali wrote:
>
>>
>>> +ctx->tex_fun = ctx->dxtc.rgtc1u_block;
>>> +avctx->pix_fmt = AV_PIX_FMT_RGB0;
>>
>> The rgtc1u_block function places the single channel value in every channel
>> except the alpha channel
>> The pixel format you have c
> On 27 Sep 2017, at 14:20, Martin Vignali wrote:
>
> 2017-09-27 13:25 GMT+02:00 Tom Butterworth <mailto:bangno...@gmail.com>>:
>
>>
>>
>>> On 27 Sep 2017, at 11:59, Martin Vignali
>> wrote:
>>>
>>>>
>>>&g
On Wed, 27 Sep 2017 at 16:52 Carl Eugen Hoyos wrote:
> 2017-09-27 15:20 GMT+02:00 Martin Vignali :
> > 2017-09-27 13:25 GMT+02:00 Tom Butterworth :
> >
> >>
> >>
> >> > On 27 Sep 2017, at 11:59, Martin Vignali
> >> wrote:
> >> &g
> On 9 Oct 2017, at 22:36, Carl Eugen Hoyos wrote:
>
> 2017-10-09 21:34 GMT+02:00 Martin Vignali :
>
IMHO, from a compositing point of view, alpha only and gray is
the same thing.
It's common (in cgi compositing for example), to use alpha (or
matte) as separate gray only fi
>> Patches 0001, 0002, 0006 and 0007 LGTM and are uncontentious. As they are
>> required for Hap Q Alpha support I will commit these shortly, assuming
>> nobody objects.
>>
>>
> Ok for that, so we can discuss in parallel about HAPQAlpha support (with
> RGBA pix_fmt output this time ! :-)
>
I’v
"Vidvox Hap", not "Vidvox Hap encoder" or "Vidvox Hap decoder". Fixes bad name
in fmmpeg -codecs, matches other codec naming.
---
libavcodec/codec_desc.c | 2 +-
libavcodec/hapdec.c | 2 +-
libavcodec/hapenc.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcod
This allows a subsequent change to compress directly into the output packet
when possible.
---
libavcodec/hapenc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hapenc.c b/libavcodec/hapenc.c
index 076923b..7056b62 100644
--- a/libavcodec/hapenc.c
+++ b/libav
The secondary compression in Hap is optional, this change exposes that option to
the user as some use-cases favour higher bitrate files to reduce workload
decoding.
Adds "none" or "snappy" as options for "compressor". Selecting "none" disregards
"chunks" option: chunking is only of benefit decompre
This allows a subsequent change to compress directly into the output packet
when possible.
---
libavcodec/hapenc.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hapenc.c b/libavcodec/hapenc.c
index 076923b..79b6074 100644
--- a/libavcodec/hapenc.c
+++
The secondary compression in Hap is optional, this change exposes that option to
the user as some use-cases favour higher bitrate files to reduce workload
decoding.
Adds "none" or "snappy" as options for "compressor". Selecting "none" disregards
"chunks" option: chunking is only of benefit decompre
On Tue, 8 Nov 2016 at 12:44 Michael Niedermayer
wrote:
...
> > -static void compress_texture(AVCodecContext *avctx, const AVFrame *f)
> > +static void compress_texture(AVCodecContext *avctx, uint8_t *out, const
> AVFrame *f)
>
> passing an output array without array size into a function raises a
thanks, pushed
On Tue, 8 Nov 2016 at 14:14 Michael Niedermayer
wrote:
> On Tue, Nov 08, 2016 at 01:30:53PM +0000, Tom Butterworth wrote:
> > This allows a subsequent change to compress directly into the output
> packet when possible.
> > ---
> > libavcodec/hapenc.c
Thanks for your comments Martin -
> > Adds "none" or "snappy" as options for "compressor". Selecting "none"
> > disregards
> > > "chunks" option: chunking is only of benefit decompressing Snappy.
> > > ---
>
>
> Maybe can be useful, to have a log,
> if chunk_count != 1 and compression is none, to
Thanks Michael and Martin
I'll push this and offer a new patch with documentation for the Hap encoder
in doc/encoders.texi.
On Wed, 9 Nov 2016 at 07:37 Martin Vignali wrote:
> > >
> > > Maybe can be useful, to have a log,
> > > if chunk_count != 1 and compression is none, to show to the user, t
Documents options and behaviour, noting when 'chunks' option will
not be honoured.
Signed-off-by: Tom Butterworth
---
doc/encoders.texi | 39 +++
1 file changed, 39 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index ba60e0
Hi Martin
From 0002-avcodec-hapqa_extract_bsf-add-new-bsf-filter:
> if (ctx->texture == 1) {
> ...
The ordering of sections in a Hap frame is not specified, so you can’t assume
the first is the colour and the second alpha - you will have to query the
section types for both sections and choose
Image dimensions were rounded down causing rows to wrap early if dimensions
were not a multiple of 4.
---
libavcodec/s3tc.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/libavcodec/s3tc.c b/libavcodec/s3tc.c
index 4743d78..9886b1d 100644
--- a/libav
:30 PM Michael Niedermayer wrote:
> On Thu, May 07, 2015 at 04:17:10PM +0100, Tom Butterworth wrote:
> > Image dimensions were rounded down causing rows to wrap early if
> dimensions were not a multiple of 4.
> > ---
> > libavcodec/s3tc.c | 23 +--
:09, Michael Niedermayer wrote:
>
> On Thu, May 07, 2015 at 03:37:46PM +0000, Tom Butterworth wrote:
> > I took variables bx and by to be shorthand for block x and block y, so I
> > renamed them because they now refer to pixel and not block positions -
> > would you rather they rema
Fix alpha position error for edge blocks of odd-dimensioned frames
---
libavcodec/s3tc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/s3tc.c b/libavcodec/s3tc.c
index 9886b1d..a422874 100644
--- a/libavcodec/s3tc.c
+++ b/libavcodec/s3tc.c
@@ -71,8 +71,10 @@ sta
Hi all
I have coincidentally been working on Hap support for libavcodec as well.
There are a couple of formats that are based on texture compression,
> usually called DXTn or BCn, and described here:
> http://en.wikipedia.org/wiki/S3_Texture_Compression. Currently in
> libavcodec only txd uses th
Currently for large job counts, pthread_slice.c acquires and releases a lock
between each job. Acquiring the locks can take more time than the job itself.
The DDS and Hap decoders naively create a job per 4x4 pixel block. For a 4Kx2K
frame:
decode before patch: 1562ms
decode after patch:
This change will reject frames with a texture type which doesn't match the
stream description.
---
libavcodec/hapdec.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hapdec.c b/libavcodec/hapdec.c
index e6b7d61..5986a3f 100644
--- a/lib
Some uses of Snappy require uncompressing to positions within an existing
buffer. Also adds a function to get the uncompressed length of Snappy data.
---
libavcodec/hapdec.c | 7 ++-
libavcodec/snappy.c | 24 +---
libavcodec/snappy.h | 19 ++-
3 files chan
@@
+/*
+ * Vidvox Hap utility functions
+ * Copyright (C) 2015 Tom Butterworth
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
The sample for fate test added in this commit is at
http://files.kriss.cx/hapy-12-chunks.mov
On 16 July 2015 at 13:23, Tom Butterworth wrote:
> ---
> libavcodec/Makefile | 4 +-
> libavcodec/hap.c | 51 +
> libavcodec/hap.h | 68
&
Thanks Michael, new patch set to replace this patch incoming.
On 17 July 2015 at 20:13, Michael Niedermayer wrote:
> On Thu, Jul 16, 2015 at 01:23:23PM +0100, Tom Butterworth wrote:
>> ---
>> libavcodec/Makefile | 4 +-
>> libavcodec/hap.c | 51 +
---
libavcodec/hapdec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hapdec.c b/libavcodec/hapdec.c
index f55d4b7..8e90904 100644
--- a/libavcodec/hapdec.c
+++ b/libavcodec/hapdec.c
@@ -79,8 +79,10 @@ static int setup_texture(AVCodecContext *avctx, size_t
leng
Hap utility functions
+ * Copyright (C) 2015 Tom Butterworth
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
---
libavcodec/hap.h | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/libavcodec/hap.h b/libavcodec/hap.h
index bd0fd37..f36d09a 100644
--- a/libavcodec/hap.h
+++ b/libavcodec/hap.h
@@ -29,12 +29,23 @@
#include "bytestream.h"
#include "texturedsp.h"
---
libavcodec/hapdec.c | 27 ---
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/libavcodec/hapdec.c b/libavcodec/hapdec.c
index 7eff9e0..f55d4b7 100644
--- a/libavcodec/hapdec.c
+++ b/libavcodec/hapdec.c
@@ -74,7 +74,6 @@ static int setup_texture(AVCodecCon
fixes issue where alpha is ignored in some players
---
libavcodec/hapenc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/hapenc.c b/libavcodec/hapenc.c
index 7daadce..cb5dcfa 100644
--- a/libavcodec/hapenc.c
+++ b/libavcodec/hapenc.c
@@ -242,16 +242,19 @@ static av_cold int hap
On 23 October 2015 at 08:32, Carl Eugen Hoyos wrote:
> Tom Butterworth gmail.com> writes:
>
> > fixes issue where alpha is ignored in some players
>
> Your patch looks ok to me, RGB0 should be added as an
> input colour space but this can be an independent patch.
>
&g
LGTM, thanks
On 23 October 2015 at 08:30, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes hap colour spaces as reminded by Tom Butterworth.
>
> Please comment, Carl Eugen
>
> ___
> ffmpeg-devel mailing list
> ffm
Niedermayer
h264* Loren Merritt, Michael Niedermayer
+ hap* Tom Butterworth
huffyuv* Michael Niedermayer, Christophe Gisquet
idcinvideo.c Mike Melanson
imc
A bug was introduced in 977105407cae55876041dddbf4ce0934cdd4cd6c whereby when
frame height wasn't divisible by the number of threads, pixels would be omitted
from the bottom rows during decode.
---
libavcodec/hap.h| 1 +
libavcodec/hapdec.c | 17 +++--
2 files changed, 12 insertio
A bug was introduced in 6b2b26e7af3ede0abfb46eb5725c26d1083f50bc whereby when
frame height wasn't divisible by the number of threads, pixels would be omitted
from the bottom rows during decode.
---
libavcodec/dds.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git
This is broken for some numbers of threads, sorry - I'll follow up
with a revision
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This is broken for some numbers of threads, sorry - I'll follow up
with a revision
> as with the hap patch, doesnt this result in possibly significantly
> larger last slice (which could cause the thread executing that to
> take much longer then the other threads thus slowing things down
> compared
---
libavcodec/hapenc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hapenc.c b/libavcodec/hapenc.c
index 174fba1..8261fe9 100644
--- a/libavcodec/hapenc.c
+++ b/libavcodec/hapenc.c
@@ -133,8 +133,10 @@ static int hap_compress_frame(AVCodecContext *avctx,
u
---
libavcodec/hapenc.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/libavcodec/hapenc.c b/libavcodec/hapenc.c
index 8261fe9..39c1c5a 100644
--- a/libavcodec/hapenc.c
+++ b/libavcodec/hapenc.c
@@ -46,8 +46,10 @@
#define HAP_MAX_CHUNKS 64
enum H
43 matches
Mail list logo
