On Wed, Oct 26, 2022 at 01:41:57PM +0200, Andreas Rheinhardt wrote:
> Peter Ross:
> > ---
> > libavcodec/eatgq.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/eatgq.c b/libavcodec/eatgq.c
> > index 89e9f20880..fdda8286ef 100644
> > --- a/liba
> On Oct 27, 2022, at 05:17, Tomas Härdin wrote:
>
> mån 2022-10-24 klockan 11:16 +0800 skrev Zhao Zhili:
>>
>> +typedef struct MediaCodecEncContext {
>> +AVClass *avclass;
>> +FFAMediaCodec *codec;
>> +int use_ndk_codec;
>> +FFANativeWindow *window;
>> +
>> +int fps;
>> +
Andreas Rheinhardt:
> It is only used by the decoders' lowres code, so only initialize
> it for decoders.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> configure | 4 ++--
> libavcodec/mpegvideo.c | 1 -
> libavcodec/mpegvideo_dec.c | 3 +++
> 3 files changed, 5 insertions(+
mån 2022-10-24 klockan 11:16 +0800 skrev Zhao Zhili:
>
> +typedef struct MediaCodecEncContext {
> + AVClass *avclass;
> + FFAMediaCodec *codec;
> + int use_ndk_codec;
> + FFANativeWindow *window;
> +
> + int fps;
> + int width;
> + int height;
> +
> + uint8_t *extradata;
>
---
libswscale/output.c | 96 ++---
1 file changed, 48 insertions(+), 48 deletions(-)
diff --git a/libswscale/output.c b/libswscale/output.c
index 0e1c1225a0..8c8f62682a 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -1109,20 +1109,20 @@ yuv2
I guess it could also be scaled to ymm if you're a big Skylake fan :P
(in which case you'd probably want to reorder the shuffle indices so
On 10/22/2022 6:02 PM, James Almer wrote:
Signed-off-by: James Almer
---
No changes since v1.
libavcodec/ac3_parser.c | 19 +++
libavcodec/ac3_parser_internal.h | 2 ++
libavcodec/ac3dec.c | 15 ++-
3 files changed, 23 insertions(+), 13 de
Peter Ross:
> ---
> libavcodec/eatgq.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/eatgq.c b/libavcodec/eatgq.c
> index 89e9f20880..fdda8286ef 100644
> --- a/libavcodec/eatgq.c
> +++ b/libavcodec/eatgq.c
> @@ -56,7 +56,7 @@ static av_cold int tgq
---
test file: https://trac.ffmpeg.org/attachment/ticket/3255/mss2_2.wmv (30 KiB)
tests/fate/microsoft.mak | 3 ++-
tests/ref/fate/mss2-region | 7 +++
2 files changed, 9 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/mss2-region
diff --git a/tests/fate/microsoft.mak b/te
---
libavcodec/eatgq.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavcodec/eatgq.c b/libavcodec/eatgq.c
index 89e9f20880..fdda8286ef 100644
--- a/libavcodec/eatgq.c
+++ b/libavcodec/eatgq.c
@@ -56,7 +56,7 @@ static av_cold int tgq_decode_init(AVCodecContext *a
On 10/26/22, Kieran Kunhya wrote:
> On Tue, 25 Oct 2022, 21:32 Peter B., wrote:
>
>> Hi everyone :)
>>
>> Would it possibly have a significant impact on coding speed of FFV1's
>> slicecrc option (Where a CRC is calculated for each frame slice), to use
>> a faster algorithm instead (if one exists)
On Tue, 25 Oct 2022, 21:32 Peter B., wrote:
> Hi everyone :)
>
> Would it possibly have a significant impact on coding speed of FFV1's
> slicecrc option (Where a CRC is calculated for each frame slice), to use
> a faster algorithm instead (if one exists)?
> I'm wondering if, for example something
12 matches
Mail list logo
