Quoting Devin Heitmueller (2023-06-09 17:13:17)
> Hi Artem,
>
> On Fri, Jun 9, 2023 at 9:19 AM Artem Smorodin
> wrote:
> >
> > When up-converting frame rate, ffmpeg duplicates frames including side
> > data. This causes duplicated characters in the output. This patch removes
> > A53 side data f
These are physically compatible formats and are potentially useful.
Signed-off-by: Philip Langdale
---
libavutil/hwcontext_cuda.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
index 5ae7711c94..22eb9f5513 100644
--- a/libavutil/hw
I've been sitting on this for 3 1/2 years now(!), and I finally got
around to fixing the loose ends and convincing myself that it was
correct. It follows the same basic structure as yadif_cuda, including
leaving out the edge handling, to avoid expensive branching.
Signed-off-by: Philip Langdale
-
On Sat, 25 Mar 2023 00:02:03 +0100
Thomas Mundt wrote:
> Hi Philip,
>
> Philip Langdale schrieb am Fr., 24. März 2023,
> 23:21:
>
> > bwdif inherited this check from yadif, which was originally
> > supposed to prefer the spatial predictor if the temporal predictor
> > was too far off.
> >
> >
Tomas Härdin:
> +typedef struct MSRLEContext {
> +const AVClass *class;
> +int curframe;
> +AVFrame *last_frame;
> +} MSRLEContext;
> +
> +static av_cold int msrle_encode_init(AVCodecContext *avctx)
> +{
> +avctx->bits_per_coded_sample = 8;
> +return 0;
> +}
> +
> +static void w
jpeg2000 overrides the global lowres variable with a lowres field called
reduction_factor
ffmpeg -lowres X causes the reduction_factor to be set
ffplay -lowres X causes both lowres and the reduction_factor to be set
ossfuss sets only lowres
only the ffmpeg variant works. This patch tries to make
This combination is not working (it writes out of array)
Signed-off-by: Michael Niedermayer
---
libavcodec/jpeg2000dec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 0e95cca64e..d6f2a5938e 100644
--- a/libavcodec/jpeg2000dec.c
On Sat, Jun 10, 2023 at 10:55 PM Lynne wrote:
> Why do they all have the same timing?
>
The processing procedure for these workloads is the same,
except for the difference in block width. (8xH, 4xH, 2xH)
So, the number of instructions remains constant.
Since these workloads handle a small amount
Jun 9, 2023, 09:17 by arnie.chang-at-sifive@ffmpeg.org:
> Optimize the put and avg filtering for 4xH and 2xH blocks
>
> Signed-off-by: Arnie Chang
> ---
> checkasm: using random seed 3475799765
> RVVi32:
> - h264chroma.chroma_mc [OK]
> checkasm: all 6 tests passed
> avg_h264_chroma_mc1_8_c:
On Sun, May 21, 2023 at 10:25 PM James Almer wrote:
> On 5/21/2023 10:03 AM, Nuo Mi wrote:
> > ---
> > libavcodec/vvc/Makefile |4 +-
> > libavcodec/vvc/vvc_data.c | 3295
> > libavcodec/vvc/vvc_data.h | 69 +
> > libavcodec/vvc/vvc_ps.c | 3379
Paul B Mahol:
> +static av_cold int decode_init(AVCodecContext *avctx)
> +{
> +VMIXContext *s = avctx->priv_data;
> +
> +avctx->bits_per_raw_sample = 8;
> +avctx->pix_fmt = AV_PIX_FMT_YUV422P;
> +
> +avctx->coded_width = FFALIGN(avctx->width, 16);
> +avctx->coded_height = FFALIG
11 matches
Mail list logo
