Re: [FFmpeg-devel] [PATCH] lavf/qsvvpp: avoid the double-free when working in sys memory mode
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Li, Zhong > Sent: Thursday, May 30, 2019 13:15 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] lavf/qsvvpp: avoid the double-free > when working in sys memory mode > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > Of Fu, Linjie > > Sent: Wednesday, May 29, 2019 5:08 PM > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH] lavf/qsvvpp: avoid the double-free > > when working in sys memory mode > > > > > -Original Message- > > > From: Fu, Linjie > > > Sent: Monday, April 15, 2019 21:24 > > > To: ffmpeg-devel@ffmpeg.org > > > Cc: Fu, Linjie > > > Subject: [PATCH] lavf/qsvvpp: avoid the double-free when working in > > > sys memory mode > > > > > > Currently, picref will be freed by calling av_frame_free(&picref) in > > > submit_frame() in qsvvpp.c when working in system memory mode,and > > > normally it is freed in filter_frame() in vf_vpp_qsv.c when working in > > > other modes. > > > > > > Double free happens when working in system memory mode, remove to > fix > > > the memory issue. > > > > > > Signed-off-by: Linjie Fu > > > --- > > > Can be reproduced by applying the system memory patch and > qsvdec+vpp: > > > ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -c:v h264_qsv > > > -i > > > input.mp4 \ > > > -vf > > "vpp_qsv=w=960:h=540,format=rgb32" > > Is it possible to reproduce with another command line? It can work with > mainline on Linux. vpp_qsv with system software path could reproduce this with mainline version: ffmpeg -init_hw_device qsv=foo -filter_hw_device foo -v debug -f rawvideo -pix_fmt nv12 -s:v 852x480 -i 852x480.nv12 -vf 'vpp_qsv=w=500:h=400' -f rawvideo -pix_fmt nv12 qsv.nv12 This happens when the size of the input stream is not 32 aligned and has more than 1 frames. > > > -f null - libavfilter/qsvvpp.c | 1 - > > > 1 file changed, 1 deletion(-) > > > > > > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c index > > > 06efdf5089..5cd1d5d345 100644 > > > --- a/libavfilter/qsvvpp.c > > > +++ b/libavfilter/qsvvpp.c > > > @@ -316,7 +316,6 @@ static QSVFrame *submit_frame(QSVVPPContext > > *s, > > > AVFilterLink *inlink, AVFrame *p > > > } > > > > > > av_frame_copy_props(qsv_frame->frame, picref); > > > -av_frame_free(&picref); > > > } else > > > qsv_frame->frame = av_frame_clone(picref); > > > > > > -- > > > 2.17.1 > > Ping? > > Patch LGTM > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/qsvenc: repeat mpeg2 missing headers [v2]
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Andreas Håkon > Sent: Tuesday, May 28, 2019 6:48 PM > To: FFmpeg development discussions and patches > > Subject: [FFmpeg-devel] [PATCH] libavformat/qsvenc: repeat mpeg2 missing > headers [v2] > > Hi, > > This patch supersedes #13105 (https://patchwork.ffmpeg.org/patch/13105/) > > A new (simpler and more robust) implementationof of the reinsertion of the > missing headers in the MPEG-2 bitstream from the HW QSV encoder. > > The problem is quite simple: The bitstream generated by the MPEG-2 QSV > encoder only incorporates the SEQ_START_CODE and EXT_START_CODE > headers in the first GOP. This generates a result that is not suitable for > streaming or broadcasting. > With this patch the "mpeg2_qsv" encoder is at the same level as the > "mpeg2video", as the software implementation repeats these headers by > default in each GOP. > > Regards. > A.H. 1. Doesn't dump_extra filter to add extradata to all key packets work well? 2. You always insert such a repeat header without any option to turn it off, thus should not be default behavior IMHO. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/rtsp: Add -first_rtcp_ntp_time_path option to write the first NTP time to a file.
On Thu, May 23, 2019 at 8:10 PM Jonathan Viney
wrote:
> On Thu, May 23, 2019 at 7:14 PM Moritz Barsnick wrote:
>
>> On Thu, May 23, 2019 at 16:51:16 +1200, Jonathan Viney wrote:
>> > > The NTP time from the first RTCP packet is currently extracted in
>> > > libavformat/rtsp.c and stored in AVFormatContext.start_time_realtime.
>> > > However, there is no way to access this value when using ffmpeg from
>> the
>> > > commandline.
>> > >
>> > > This patch adds an option when using an RTSP input to write the value
>> to a
>> > > file when it is received.
>>
>> Is this useful for anything? Would it be more useful in a metadata key?
>> (Just wondering, not critisizing.)
>>
>
> I agree having it transferred to a metadata key in the output would be
> useful. That was my first thought, but seems like it would be a larger
> patch and I wasn't sure if it would be able to write to the metadata for
> streaming formats like fragmented MP4 (which is what I'm using) because the
> RTCP packet arrives some time after the output metadata would have be
> written (from what I understand). Please correct me if I'm wrong about that.
>
>
>>
>> > +av_strlcatf(buf, sizeof(buf), "%lld",
>> s->start_time_realtime);
>>
>> start_time_realtime is int64_t, so the format identifier should be
>> '"%" PRIi64'.
>>
>
> Thanks - will update the patch.
>
Updated patch.
Regards,
-Jonathan.
From d2e1b11161e825bc8d40a4a368180c8a69ed6a75 Mon Sep 17 00:00:00 2001
From: Jonathan Viney
Date: Thu, 23 May 2019 14:24:16 +1200
Subject: [PATCH] avformat/rtsp: add -first_rtcp_ntp_time_path option to write
the first NTP time to a file.
Signed-off-by: Jonathan Viney
---
libavformat/rtsp.c | 16
libavformat/rtsp.h | 6 ++
2 files changed, 22 insertions(+)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index c153cac88b..cda92be162 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -96,6 +96,7 @@ const AVOption ff_rtsp_options[] = {
{ "min_port", "set minimum local UDP port", OFFSET(rtp_port_min),
AV_OPT_TYPE_INT, {.i64 = RTSP_RTP_PORT_MIN}, 0, 65535, DEC|ENC },
{ "max_port", "set maximum local UDP port", OFFSET(rtp_port_max),
AV_OPT_TYPE_INT, {.i64 = RTSP_RTP_PORT_MAX}, 0, 65535, DEC|ENC },
{ "listen_timeout", "set maximum timeout (in seconds) to wait for incoming
connections (-1 is infinite, imply flag listen)", OFFSET(initial_timeout),
AV_OPT_TYPE_INT, {.i64 = -1}, INT_MIN, INT_MAX, DEC },
+{ "first_rtcp_ntp_time_path", "path to write first NTP time (in
microseconds) received in RTCP packet", OFFSET(first_rtcp_ntp_time_path),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC },
#if FF_API_OLD_RTSP_OPTIONS
{ "timeout", "set maximum timeout (in seconds) to wait for incoming
connections (-1 is infinite, imply flag listen) (deprecated, use
listen_timeout)", OFFSET(initial_timeout), AV_OPT_TYPE_INT, {.i64 = -1},
INT_MIN, INT_MAX, DEC },
{ "stimeout", "set timeout (in microseconds) of socket TCP I/O
operations", OFFSET(stimeout), AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, INT_MAX,
DEC },
@@ -2256,6 +2257,21 @@ redo:
(uint64_t) rtpctx->st->time_base.num *
100,
rtpctx->st->time_base.den);
}
+
+// Write the NTP start time
+if (rt->first_rtcp_ntp_time_path) {
+AVIOContext *ioctx = NULL;
+int ret;
+ret = avio_open(&ioctx, rt->first_rtcp_ntp_time_path,
AVIO_FLAG_WRITE);
+if (ret < 0) {
+av_log(s, AV_LOG_WARNING, "unable to open %s to
write first rtcp ntp time\n", rt->first_rtcp_ntp_time_path);
+} else {
+char buf[21] = "";
+av_strlcatf(buf, sizeof(buf), "%"PRIi64,
s->start_time_realtime);
+avio_write(ioctx, buf, strlen(buf));
+avio_closep(&ioctx);
+}
+}
}
}
if (ret == -RTCP_BYE) {
diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
index 54a9a30c16..4df24b743a 100644
--- a/libavformat/rtsp.h
+++ b/libavformat/rtsp.h
@@ -408,6 +408,12 @@ typedef struct RTSPState {
*/
char *user_agent;
+/**
+ * Path to write the first RTCP unix time in microseconds, if
+ * it is received as part of the stream.
+ */
+char *first_rtcp_ntp_time_path;
+
char default_lang[4];
int buffer_size;
int pkt_size;
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf/qsvvpp: avoid the double-free when working in sys memory mode
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Fu, Linjie > Sent: Wednesday, May 29, 2019 5:08 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] lavf/qsvvpp: avoid the double-free > when working in sys memory mode > > > -Original Message- > > From: Fu, Linjie > > Sent: Monday, April 15, 2019 21:24 > > To: ffmpeg-devel@ffmpeg.org > > Cc: Fu, Linjie > > Subject: [PATCH] lavf/qsvvpp: avoid the double-free when working in > > sys memory mode > > > > Currently, picref will be freed by calling av_frame_free(&picref) in > > submit_frame() in qsvvpp.c when working in system memory mode,and > > normally it is freed in filter_frame() in vf_vpp_qsv.c when working in > > other modes. > > > > Double free happens when working in system memory mode, remove to fix > > the memory issue. > > > > Signed-off-by: Linjie Fu > > --- > > Can be reproduced by applying the system memory patch and qsvdec+vpp: > > ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -c:v h264_qsv > > -i > > input.mp4 \ > > -vf > "vpp_qsv=w=960:h=540,format=rgb32" Is it possible to reproduce with another command line? It can work with mainline on Linux. > > -f null - libavfilter/qsvvpp.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c index > > 06efdf5089..5cd1d5d345 100644 > > --- a/libavfilter/qsvvpp.c > > +++ b/libavfilter/qsvvpp.c > > @@ -316,7 +316,6 @@ static QSVFrame *submit_frame(QSVVPPContext > *s, > > AVFilterLink *inlink, AVFrame *p > > } > > > > av_frame_copy_props(qsv_frame->frame, picref); > > -av_frame_free(&picref); > > } else > > qsv_frame->frame = av_frame_clone(picref); > > > > -- > > 2.17.1 > Ping? Patch LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avcodec: Add librav1e encoder
On Wed, May 29, 2019 at 2:28 PM Derek Buitenhuis
wrote:
> Uses the crav1e C bindings for rav1e.
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -1378,6 +1378,35 @@ makes it possible to store non-rgb pix_fmts.
>
> @end table
>
> +@section librav1e
> +
> +rav1e AV1 encoder wrapper.
> +
> +Requires the presence of the rav1e headers and library from crav1e
> +during configuration. You need to explicitly configue the build with
>
nit: typo configure
+
> +static inline RaPixelRange range_map(enum AVColorRange range)
> +
> +{
>
nit: extra line
+switch (range) {
> +case AVCOL_RANGE_MPEG:
> +return RA_PIXEL_RANGE_LIMITED;
> +case AVCOL_RANGE_JPEG:
> +return RA_PIXEL_RANGE_FULL;
> +default:
> +return RA_PIXEL_RANGE_UNSPECIFIED;
> +}
> +}
> +
> +static inline RaChromaSampling pix_fmt_map(enum AVPixelFormat pix_fmt)
> +{
> +switch (pix_fmt) {
> +case AV_PIX_FMT_YUV420P:
> +case AV_PIX_FMT_YUV420P10:
> +case AV_PIX_FMT_YUV420P12:
> +return RA_CHROMA_SAMPLING_CS420;
> +case AV_PIX_FMT_YUV422P:
> +case AV_PIX_FMT_YUV422P10:
> +case AV_PIX_FMT_YUV422P12:
> +return RA_CHROMA_SAMPLING_CS422;
> +case AV_PIX_FMT_YUV444P:
> +case AV_PIX_FMT_YUV444P10:
> +case AV_PIX_FMT_YUV444P12:
> +return RA_CHROMA_SAMPLING_CS444;
>
no love for the J formats? ;_;
could they be added to librav1e_pix_fmts[]?
+
> +static av_cold int librav1e_encode_init(AVCodecContext *avctx)
> +{
> +librav1eContext *ctx = avctx->priv_data;
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(avctx->pix_fmt);
>
nit: check desc != NULL
+RaConfig *cfg = NULL;
> +int rret;
> +int ret = 0;
> +
>
[...]
> +
> +rret = rav1e_config_parse_int(cfg, "threads", avctx->thread_count);
> +if (rret < 0)
> +av_log(avctx, AV_LOG_WARNING, "Invalid number of threads,
> defaulting to auto.\n");
> +
> +if (avctx->bit_rate && ctx->quantizer < 0) {
>
would be nice to have an info/debug line about the rc in use
> +static int librav1e_send_frame(AVCodecContext *avctx, const AVFrame
> *frame)
> +{
> +librav1eContext *ctx = avctx->priv_data;
> +int ret;
> +
> +if (!ctx->rframe && frame) {
> +const AVPixFmtDescriptor *desc =
> av_pix_fmt_desc_get(frame->format);
>
> nit: check desc != NULL
> +ctx->rframe = rav1e_frame_new(ctx->ctx);
> +if (!ctx->rframe) {
> +av_log(avctx, AV_LOG_ERROR, "Could not allocate new rav1e
> frame.\n");
> +return AVERROR(ENOMEM);
> +}
> +
>
overall lgtm
--
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/vf_gblur: add x86 SIMD optimizations
For details of the implementation, please refer to the comment
inlined in the assembly code. It improves the horizontal pass
performance about 100% under single thread.
Tested overall performance using the command(avx2 enabled):
./ffmpeg -i 1080p.mp4 -vf gblur -f null /dev/null
./ffmpeg -i 1080p.mp4 -vf gblur=threads=1 -f null /dev/null
For single thread, the fps improves from 43 to 60, about 40%.
For multi-thread, the fps improves from 110 to 130, about 20%.
Signed-off-by: Ruiling Song
---
libavfilter/gblur.h | 54 ++
libavfilter/vf_gblur.c | 66 +---
libavfilter/x86/Makefile| 2 +
libavfilter/x86/vf_gblur.asm| 182
libavfilter/x86/vf_gblur_init.c | 36 +++
5 files changed, 302 insertions(+), 38 deletions(-)
create mode 100644 libavfilter/gblur.h
create mode 100644 libavfilter/x86/vf_gblur.asm
create mode 100644 libavfilter/x86/vf_gblur_init.c
diff --git a/libavfilter/gblur.h b/libavfilter/gblur.h
new file mode 100644
index 00..97217044d0
--- /dev/null
+++ b/libavfilter/gblur.h
@@ -0,0 +1,54 @@
+/*
+ * Copyright (c) 2011 Pascal Getreuer
+ * Copyright (c) 2016 Paul B Mahol
+ *
+ * Redistribution and use in source and binary forms, with or without
modification,
+ * are permitted provided that the following conditions are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials provided
+ *with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * HOLDER BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef AVFILTER_GBLUR_H
+#define AVFILTER_GBLUR_H
+#include "avfilter.h"
+
+typedef struct GBlurContext {
+const AVClass *class;
+
+float sigma;
+float sigmaV;
+int steps;
+int planes;
+
+int depth;
+int planewidth[4];
+int planeheight[4];
+float *buffer;
+float boundaryscale;
+float boundaryscaleV;
+float postscale;
+float postscaleV;
+float nu;
+float nuV;
+int nb_planes;
+void (*horiz_slice)(float *buffer, int width, int height, int steps, float
nu, float bscale);
+} GBlurContext;
+void ff_gblur_init_x86(GBlurContext *s);
+#endif
diff --git a/libavfilter/vf_gblur.c b/libavfilter/vf_gblur.c
index b91a8c074a..4e876bca05 100644
--- a/libavfilter/vf_gblur.c
+++ b/libavfilter/vf_gblur.c
@@ -30,29 +30,11 @@
#include "libavutil/pixdesc.h"
#include "avfilter.h"
#include "formats.h"
+#include "gblur.h"
#include "internal.h"
#include "video.h"
+#include
-typedef struct GBlurContext {
-const AVClass *class;
-
-float sigma;
-float sigmaV;
-int steps;
-int planes;
-
-int depth;
-int planewidth[4];
-int planeheight[4];
-float *buffer;
-float boundaryscale;
-float boundaryscaleV;
-float postscale;
-float postscaleV;
-float nu;
-float nuV;
-int nb_planes;
-} GBlurContext;
#define OFFSET(x) offsetof(GBlurContext, x)
#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
@@ -72,39 +54,44 @@ typedef struct ThreadData {
int width;
} ThreadData;
-static int filter_horizontally(AVFilterContext *ctx, void *arg, int jobnr, int
nb_jobs)
+static void horiz_slice_c(float *buffer, int width, int height, int steps,
+ float nu, float bscale)
{
-GBlurContext *s = ctx->priv;
-ThreadData *td = arg;
-const int height = td->height;
-const int width = td->width;
-const int slice_start = (height * jobnr ) / nb_jobs;
-const int slice_end = (height * (jobnr+1)) / nb_jobs;
-const float boundaryscale = s->boundaryscale;
-const int steps = s->steps;
-const float nu = s->nu;
-float *buffer = s->buffer;
-int y, x, step;
+int step, x, y;
float *ptr;
-
-/* Filter horizontally along each row */
-for (y = slice_start; y < slice_end; y++) {
+for (y = 0; y < height; y++) {
for (step = 0; step < steps; step++) {
ptr = buffer + width * y;
-ptr[0] *= boundaryscale;
+ptr[0] *= bsc
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: add master display and light level sei for HDR10
On Wed, May 29, 2019 at 7:11 PM Dennis Mungai wrote: > On Tue, May 28, 2019, 01:15 James Almer wrote: > > > On 5/27/2019 7:13 PM, Timo Rothenpieler wrote: > > > On 27.05.2019 23:49, Lance Wang wrote: > > >> On Saturday, May 25, 2019, James Almer wrote: > > >> > > >>> On 5/22/2019 3:59 AM, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > The testing command for the HDR10 output with nvenc: > > $ ./ffmpeg_g -y -i 4K.mp4 -c:v hevc_nvenc -g 7 -color_primaries > bt2020 > > >>> -colorspace bt2020_ncl -color_trc smpte2084 -sei hdr10 \ > > -master_display "G(13250,34500)B(7500,3000)R( > > >>> 34000,16000)WP(15635,16450)L(1000,50)" -max_cll "0, 0" test.ts > > > > Please notice it is preferable to use the frame sei side data than > > >>> master_display and max_cll paramters config > > --- > > libavcodec/nvenc.c | 129 > > > > libavcodec/nvenc.h | 18 ++ > > libavcodec/nvenc_hevc.c | 11 > > 3 files changed, 158 insertions(+) > > > > diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c > > index 75dda6d689..3fd0eca4a5 100644 > > --- a/libavcodec/nvenc.c > > +++ b/libavcodec/nvenc.c > > @@ -22,6 +22,9 @@ > > #include "config.h" > > > > #include "nvenc.h" > > +#include "cbs_h265.h" > > >>> > > >>> This doesn't seem right. The encoder isn't using this framework at > all. > > >>> > > >>> You're apparently including this only to get the > > >>> H265RawSEIMasteringDisplayColourVolume and > > >>> H265RawSEIContentLightLevelInfo structs, which you don't really need > to > > >>> fill sei_data[i].payload > > >>> > > >>> OK, I'll remove the dependent for the two structure and update the > > >>> patch. > > >> > > >> > > > > > > I'm still not convinced that all this belong in an encoder. > > > Can it really not be made into a filter that adds it as extra data to > > > frames? There got to be other frame consumers that use this kind of > data. > > > > hevc_metadata (h265_metadata_bsf.c) already exists. It should be trivial > > to add support for this there. > > > > Case in point: Some encoders, such as hevc_vaapi, present private codec > options for the retention of specific SEIs, such as HDR (and is on by > default), yet others, such as the QSV runtime, have no such options. > > Wiring this into a bitstream filter (such as hevc_metadata), etc would > easily address such disparities without mucking around with convoluted > private encoder options. > I haven't seen any support for the SEI data process for the hevc_metadata. That's great if any expert to extend the hevc_metadata for the SEI HDR support in future. > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avcodec: Add librav1e encoder
On 5/29/2019 3:28 PM, Derek Buitenhuis wrote:
> Uses the crav1e C bindings for rav1e.
>
> Port to the new send/receive API by: James Almer .
>
> Signed-off-by: Derek Buitenhuis
> ---
> Changes since v2:
>
> * Removed 4:0:0 support; seems broken in rav1e (ref:
> https://github.com/xiph/rav1e/issues/1312)
> * Moved to use FF_CODEC_CAP_INIT_CLEANUP.
> * Set time base for ratecontrol purposes (tested, as well).
> * Used desc->nb_components for loop.
> ---
> configure | 4 +
> doc/encoders.texi | 29 +++
> doc/general.texi | 7 +
> libavcodec/Makefile| 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/librav1e.c | 415 +
> 6 files changed, 457 insertions(+)
> create mode 100644 libavcodec/librav1e.c
[...]
> +static av_cold int librav1e_encode_init(AVCodecContext *avctx)
> +{
> +librav1eContext *ctx = avctx->priv_data;
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(avctx->pix_fmt);
> +RaConfig *cfg = NULL;
> +int rret;
> +int ret = 0;
> +
> +cfg = rav1e_config_default();
> +if (!cfg) {
> +av_log(avctx, AV_LOG_ERROR, "Could not allocate rav1e config.\n");
> +ret = AVERROR_EXTERNAL;
You can return directly here.
> +goto end;
> +}
> +
> +rav1e_config_set_time_base(cfg, (RaRational) {
> + avctx->time_base.num * avctx->ticks_per_frame,
> + avctx->time_base.den
> + });
> +
> +if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
> + const AVBitStreamFilter *filter =
> av_bsf_get_by_name("extract_extradata");
> + int bret;
> +
> + if (!filter) {
> +av_log(avctx, AV_LOG_ERROR, "extract_extradata bitstream filter "
> + "not found. This is a bug, please report it.\n");
> +ret = AVERROR_BUG;
> +goto end;
> + }
> +
> + bret = av_bsf_alloc(filter, &ctx->bsf);
> + if (bret < 0) {
> + ret = bret;
> + goto end;
> + }
> +
> + bret = avcodec_parameters_from_context(ctx->bsf->par_in, avctx);
> + if (bret < 0) {
> + ret = bret;
> + goto end;
> + }
> +
> + bret = av_bsf_init(ctx->bsf);
> + if (bret < 0) {
> + ret = bret;
> + goto end;
> + }
> +}
> +
> +if (ctx->rav1e_opts) {
> +AVDictionary *dict= NULL;
> +AVDictionaryEntry *en = NULL;
> +
> +if (!av_dict_parse_string(&dict, ctx->rav1e_opts, "=", ":", 0)) {
> +while (en = av_dict_get(dict, "", en, AV_DICT_IGNORE_SUFFIX)) {
> +int parse_ret = rav1e_config_parse(cfg, en->key, en->value);
> +if (parse_ret < 0)
> +av_log(avctx, AV_LOG_WARNING, "Invalid value for %s:
> %s.\n", en->key, en->value);
> +}
> +av_dict_free(&dict);
> +}
> +}
> +
> +rret = rav1e_config_parse_int(cfg, "width", avctx->width);
> +if (rret < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid width passed to rav1e.\n");
> +ret = AVERROR_INVALIDDATA;
> +goto end;
> +}
> +
> +rret = rav1e_config_parse_int(cfg, "height", avctx->height);
> +if (rret < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid width passed to rav1e.\n");
> +ret = AVERROR_INVALIDDATA;
> +goto end;
> +}
> +
> +rret = rav1e_config_parse_int(cfg, "threads", avctx->thread_count);
> +if (rret < 0)
> +av_log(avctx, AV_LOG_WARNING, "Invalid number of threads, defaulting
> to auto.\n");
> +
> +if (avctx->bit_rate && ctx->quantizer < 0) {
> +int max_quantizer = avctx->qmax >= 0 ? avctx->qmax : 255;
> +
> +rret = rav1e_config_parse_int(cfg, "quantizer", max_quantizer);
> +if (rret < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Could not set max quantizer.\n");
> +ret = AVERROR_EXTERNAL;
> +goto end;
> +}
> +
> +rret = rav1e_config_parse_int(cfg, "bitrate", avctx->bit_rate);
> +if (rret < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Could not set bitrate.\n");
> +ret = AVERROR_INVALIDDATA;
> +goto end;
> +}
> +} else if (ctx->quantizer >= 0) {
> +rret = rav1e_config_parse_int(cfg, "quantizer", ctx->quantizer);
> +if (rret < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Could not set quantizer.\n");
> +ret = AVERROR_EXTERNAL;
> +goto end;
> +}
> +}
> +
> +rret = rav1e_config_set_pixel_format(cfg, desc->comp[0].depth,
> + pix_fmt_map(avctx->pix_fmt),
> +
> chroma_loc_map(avctx->chroma_sample_location),
> + range_map(avctx->color_range));
> +if (rret < 0) {
> +
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: grow packet if vaMapBuffer returns multiple buffers
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Mark Thompson > Sent: Thursday, May 30, 2019 07:17 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: grow packet if > vaMapBuffer returns multiple buffers > > On 29/05/2019 21:57, Linjie Fu wrote: > > It seems that VA_CODED_BUF_STATUS_SINGLE_NALU allows driver to > map > > buffer for each slice. > > > > Currently, assigning new buffer for pkt when multiple buffer returns > > from vaMapBuffer will cover the previous encoded pkt data and lead > > to encode issues. > > > > Using av_grow_packet to expand pkt if several buffers are returned. > > > > Signed-off-by: Linjie Fu > > --- > > libavcodec/vaapi_encode.c | 12 ++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > What driver uses this? It was found while enabling VP9 VDENC on ICL with iHD. vaMapBuffer returns two bufs in the buf_list including a zero-sized buf. IMHO, it should be fixed in driver level, but I guess ffmpeg should be able to cope with the multiple buf situation as well. https://github.com/intel/media-driver/issues/624 > > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c > > index 2dda451..2812237 100644 > > --- a/libavcodec/vaapi_encode.c > > +++ b/libavcodec/vaapi_encode.c > > @@ -490,6 +490,7 @@ static int vaapi_encode_output(AVCodecContext > *avctx, > > VACodedBufferSegment *buf_list, *buf; > > VAStatus vas; > > int err; > > +uint8_t *ptr; > > > > err = vaapi_encode_wait(avctx, pic); > > if (err < 0) > > @@ -509,11 +510,18 @@ static int vaapi_encode_output(AVCodecContext > *avctx, > > av_log(avctx, AV_LOG_DEBUG, "Output buffer: %u bytes " > > "(status %08x).\n", buf->size, buf->status); > > > > -err = av_new_packet(pkt, buf->size); > > +if (pkt->size) > > +err = av_grow_packet(pkt, buf->size); > > av_grow_packet() can reallocate the buffer, which will change its address. > > To avoid repeated new allocations and copies, perhaps it would be better to > iterate through the list first to find out how large the single packet needs > to > be? Avoiding repeated memcpy and reallocation sounds better to me. Thanks Mark. - Linjie ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavcodec/vp9: Fix VP9 dynamic resolution changing decoding on VAAPI.
On 28/05/2019 08:46, Yan Wang wrote:
>
> On 5/28/2019 3:16 PM, Hendrik Leppkes wrote:
>> On Tue, May 28, 2019 at 8:57 AM Yan Wang wrote:
>>> When the format change, the VAAPI context cannot be destroyed.
>>> Otherwise, the reference frame surface will lost.
>>>
>>> Signed-off-by: Yan Wang
>>> ---
>>> libavcodec/decode.c | 6 ++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
>>> index 6c31166ec2..3eda1dc42c 100644
>>> --- a/libavcodec/decode.c
>>> +++ b/libavcodec/decode.c
>>> @@ -1397,7 +1397,9 @@ int ff_get_format(AVCodecContext *avctx, const enum
>>> AVPixelFormat *fmt)
>>>
>>> for (;;) {
>>> // Remove the previous hwaccel, if there was one.
>>> +#if !CONFIG_VP9_VAAPI_HWACCEL
>>> hwaccel_uninit(avctx);
>>> +#endif
>>>
>>> user_choice = avctx->get_format(avctx, choices);
>>> if (user_choice == AV_PIX_FMT_NONE) {
>>> @@ -1479,7 +1481,11 @@ int ff_get_format(AVCodecContext *avctx, const enum
>>> AVPixelFormat *fmt)
>>> "missing configuration.\n", desc->name);
>>> goto try_again;
>>> }
>>> +#if CONFIG_VP9_VAAPI_HWACCEL
>>> + if (hw_config->hwaccel && !avctx->hwaccel) {
>>> +#else
>>> if (hw_config->hwaccel) {
>>> +#endif
>>> av_log(avctx, AV_LOG_DEBUG, "Format %s requires hwaccel "
>>> "initialisation.\n", desc->name);
>>> err = hwaccel_init(avctx, hw_config);
>>> --
>>> 2.17.2
>>>
>> This change feels just wrong. First of all, preprocessors are
>> absolutely the wrong way to go about this.
>
> Sorry for this. I am new guy for ffmpeg development. What way should be
>
> better? I can refine it.
>
>> Secondly, if the frames need to change size, or surface format, then
>> this absolutely needs to be called, doesn't it?
>
> Based on VP9 spec, the frame resolution can be changed per frame. But current
>
> frame will need refer to previous frame still. So if destroy the VAAPI
> context, it
>
> will cause reference frame surface in VAAPI driver lost.
>
> In fact, this patch is for the issue:
>
> https://github.com/intel/media-driver/issues/629
>
> its 2nd frame (128x128) will refer to the 1st frame (256x256).
Can you explain exactly what is going wrong here? The surface is definitely
still present - the reference frame list entry holds a reference to it.
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: grow packet if vaMapBuffer returns multiple buffers
On 29/05/2019 21:57, Linjie Fu wrote:
> It seems that VA_CODED_BUF_STATUS_SINGLE_NALU allows driver to map
> buffer for each slice.
>
> Currently, assigning new buffer for pkt when multiple buffer returns
> from vaMapBuffer will cover the previous encoded pkt data and lead
> to encode issues.
>
> Using av_grow_packet to expand pkt if several buffers are returned.
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/vaapi_encode.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
What driver uses this?
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 2dda451..2812237 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -490,6 +490,7 @@ static int vaapi_encode_output(AVCodecContext *avctx,
> VACodedBufferSegment *buf_list, *buf;
> VAStatus vas;
> int err;
> +uint8_t *ptr;
>
> err = vaapi_encode_wait(avctx, pic);
> if (err < 0)
> @@ -509,11 +510,18 @@ static int vaapi_encode_output(AVCodecContext *avctx,
> av_log(avctx, AV_LOG_DEBUG, "Output buffer: %u bytes "
> "(status %08x).\n", buf->size, buf->status);
>
> -err = av_new_packet(pkt, buf->size);
> +if (pkt->size)
> +err = av_grow_packet(pkt, buf->size);
av_grow_packet() can reallocate the buffer, which will change its address.
To avoid repeated new allocations and copies, perhaps it would be better to
iterate through the list first to find out how large the single packet needs to
be?
> +else {
> +err = av_new_packet(pkt, buf->size);
> +ptr = pkt->data;
> +}
> +
> if (err < 0)
> goto fail_mapped;
>
> -memcpy(pkt->data, buf->buf, buf->size);
> +memcpy(ptr, buf->buf, buf->size);
> +ptr += buf->size;
> }
>
> if (pic->type == PICTURE_TYPE_IDR)
>
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec: Add librav1e encoder
Hi, > +during configuration. You need to explicitly configue the build with ^ configure > +Sets the maximum qauntizer (floor) to use when using bitrate mode. ^ quantizer Cheers, Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/vf_zscale: add slice threading
Signed-off-by: Paul B Mahol
---
libavfilter/vf_zscale.c | 335 +---
1 file changed, 211 insertions(+), 124 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index f0309272fa..082150adf0 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -74,6 +74,16 @@ enum var_name {
VARS_NB
};
+typedef struct ZScaleThreadContext {
+void *tmp;
+size_t tmp_size;
+
+zimg_image_format src_format, dst_format;
+zimg_image_format alpha_src_format, alpha_dst_format;
+zimg_graph_builder_params alpha_params, params;
+zimg_filter_graph *alpha_graph, *graph;
+} ZScaleThreadContext;
+
typedef struct ZScaleContext {
const AVClass *class;
@@ -100,6 +110,8 @@ typedef struct ZScaleContext {
double nominal_peak_luminance;
int approximate_gamma;
+int nb_threads;
+
char *w_expr; ///< width expression string
char *h_expr; ///< height expression string
@@ -110,13 +122,7 @@ typedef struct ZScaleContext {
int force_original_aspect_ratio;
-void *tmp;
-size_t tmp_size;
-
-zimg_image_format src_format, dst_format;
-zimg_image_format alpha_src_format, alpha_dst_format;
-zimg_graph_builder_params alpha_params, params;
-zimg_filter_graph *alpha_graph, *graph;
+ZScaleThreadContext *ztd;
enum AVColorSpace in_colorspace, out_colorspace;
enum AVColorTransferCharacteristic in_trc, out_trc;
@@ -204,6 +210,12 @@ static int config_props(AVFilterLink *outlink)
int ret;
int factor_w, factor_h;
+s->nb_threads = ff_filter_get_nb_threads(ctx);
+av_freep(&s->ztd);
+s->ztd = av_calloc(s->nb_threads, sizeof(*s->ztd));
+if (!s->ztd)
+return AVERROR(ENOMEM);
+
var_values[VAR_IN_W] = var_values[VAR_IW] = inlink->w;
var_values[VAR_IN_H] = var_values[VAR_IH] = inlink->h;
var_values[VAR_OUT_W] = var_values[VAR_OW] = NAN;
@@ -458,10 +470,12 @@ static int convert_range(enum AVColorRange color_range)
}
static void format_init(zimg_image_format *format, AVFrame *frame, const
AVPixFmtDescriptor *desc,
-int colorspace, int primaries, int transfer, int
range, int location)
+int colorspace, int primaries, int transfer, int
range, int location,
+int width, int height,
+int slice_start, int slice_end)
{
-format->width = frame->width;
-format->height = frame->height;
+format->width = width;
+format->height = height;
format->subsample_w = desc->log2_chroma_w;
format->subsample_h = desc->log2_chroma_h;
format->depth = desc->comp[0].depth;
@@ -472,6 +486,10 @@ static void format_init(zimg_image_format *format, AVFrame
*frame, const AVPixFm
format->transfer_characteristics = transfer == - 1 ?
convert_trc(frame->color_trc) : transfer;
format->pixel_range = (desc->flags & AV_PIX_FMT_FLAG_RGB) ?
ZIMG_RANGE_FULL : range == -1 ? convert_range(frame->color_range) : range;
format->chroma_location = location == -1 ?
convert_chroma_location(frame->chroma_location) : location;
+format->active_region.left = 0;
+format->active_region.top = slice_start;
+format->active_region.width = width;
+format->active_region.height = slice_end - slice_start;
}
static int graph_build(zimg_filter_graph **graph, zimg_graph_builder_params
*params,
@@ -502,16 +520,163 @@ static int graph_build(zimg_filter_graph **graph,
zimg_graph_builder_params *par
return 0;
}
+typedef struct ThreadData {
+AVFrame *in, *out;
+const AVPixFmtDescriptor *desc, *odesc;
+} ThreadData;
+
+static int prepare_graph(AVFilterContext *ctx, void *arg, int jobnr, int
nb_jobs)
+{
+ZScaleContext *s = ctx->priv;
+ThreadData *td = arg;
+AVFrame *in = td->in;
+AVFrame *out = td->out;
+const AVPixFmtDescriptor *desc = td->desc;
+const AVPixFmtDescriptor *odesc = td->odesc;
+const int in_slice_start = (in->height * jobnr) / nb_jobs;
+const int in_slice_end = (in->height * (jobnr+1)) / nb_jobs;
+const int out_slice_start = (out->height * jobnr) / nb_jobs;
+const int out_slice_end = (out->height * (jobnr+1)) / nb_jobs;
+int ret;
+
+zimg_image_format_default(&s->ztd[jobnr].src_format, ZIMG_API_VERSION);
+zimg_image_format_default(&s->ztd[jobnr].dst_format, ZIMG_API_VERSION);
+zimg_graph_builder_params_default(&s->ztd[jobnr].params, ZIMG_API_VERSION);
+
+s->ztd[jobnr].params.dither_type = s->dither;
+s->ztd[jobnr].params.cpu_type = ZIMG_CPU_AUTO;
+s->ztd[jobnr].params.resample_filter = s->filter;
+s->ztd[jobnr].params.resample_filter_uv = s->filter;
+s->ztd[jobnr].params.nominal_peak_luminance = s->nominal_peak_luminance;
+s->ztd[jobnr].params.allow_approximate_gamma = s->approximate_gamma;
+
+format_init(&s->ztd[jobnr].src_format, in, desc, s->colorspace_in,
+s->primaries_in, s->trc_in, s
Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc: adaptive alignment for teletext PES packets
On Tue, May 28, 2019 at 05:48:27PM +, Andreas Håkon wrote: > Hi Michael, > > > with which software has the generated mpeg-ts been tested ? > > do you have any testecases ? > > Our test cases are mainly DVB-C broadcasts and mobile streaming. > All clients play well. And internal testing is done using the > well-known DVB Inspector. adding information about testing or other things that increase the confidence of a reviewer that a change is correct should decrease the time until its applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFMPEG DEVEL] [PATCH v6] fftools/ffprobe: Add S12M Timecode output as side data (such as SEI TC)
Thank you very much! Le lun. 27 mai 2019 à 00:35, Marton Balint a écrit : > > > On Sat, 25 May 2019, Antonin Gouzer wrote: > > > Hello, > > Shame on me, I didn't test the patch with the json format, only xml and > flat. > > It's ok now. > > ok for XML too. > > > > Thanks! > > Thanks, applied. > > Regards, > Marton > > > > > > > Le sam. 25 mai 2019 à 00:27, Marton Balint a écrit : > >> > >> > >> > >> On Fri, 24 May 2019, Antonin Gouzer wrote: > >> > >> > --- > >> > Add S12M Timecode output with the show_frame option > >> > Multiple timecodes (3) for one frame support > >> > Control side date Size to 16 > >> > Correct ffrpobe.xsd to allow multiple timecodes in side_data element > >> > --- > >> > doc/ffprobe.xsd | 8 > >> > fftools/ffprobe.c | 14 +- > >> > 2 files changed, 21 insertions(+), 1 deletion(-) > >> > >> I almost committed this, but found another issue: the JSON output > >> contained the "timecode" key multiple times. Apparently in order for the > >> JSON output to work, we need a separate section for arrays. > >> > >> I managed to make those changes (see the attached patch), it affected > the > >> XML output slightly as well. Please let me know if this is satisfactory > to > >> you. > >> > >> Thanks, > >> Marton___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > >> To unsubscribe, visit link above, or email > >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] avcodec: Add librav1e encoder
Uses the crav1e C bindings for rav1e.
Port to the new send/receive API by: James Almer .
Signed-off-by: Derek Buitenhuis
---
Changes since v2:
* Removed 4:0:0 support; seems broken in rav1e (ref:
https://github.com/xiph/rav1e/issues/1312)
* Moved to use FF_CODEC_CAP_INIT_CLEANUP.
* Set time base for ratecontrol purposes (tested, as well).
* Used desc->nb_components for loop.
---
configure | 4 +
doc/encoders.texi | 29 +++
doc/general.texi | 7 +
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/librav1e.c | 415 +
6 files changed, 457 insertions(+)
create mode 100644 libavcodec/librav1e.c
diff --git a/configure b/configure
index 32fc26356c..e61644b012 100755
--- a/configure
+++ b/configure
@@ -254,6 +254,7 @@ External library support:
--enable-libopenmpt enable decoding tracked files via libopenmpt [no]
--enable-libopus enable Opus de/encoding via libopus [no]
--enable-libpulseenable Pulseaudio input via libpulse [no]
+ --enable-librav1eenable AV1 encoding via rav1e [no]
--enable-librsvg enable SVG rasterization via librsvg [no]
--enable-librubberband enable rubberband needed for rubberband filter [no]
--enable-librtmp enable RTMP[E] support via librtmp [no]
@@ -1778,6 +1779,7 @@ EXTERNAL_LIBRARY_LIST="
libopenmpt
libopus
libpulse
+librav1e
librsvg
librtmp
libshine
@@ -3173,6 +3175,7 @@ libopenmpt_demuxer_deps="libopenmpt"
libopus_decoder_deps="libopus"
libopus_encoder_deps="libopus"
libopus_encoder_select="audio_frame_queue"
+librav1e_encoder_deps="librav1e"
librsvg_decoder_deps="librsvg"
libshine_encoder_deps="libshine"
libshine_encoder_select="audio_frame_queue"
@@ -6199,6 +6202,7 @@ enabled libopus && {
}
}
enabled libpulse && require_pkg_config libpulse libpulse
pulse/pulseaudio.h pa_context_new
+enabled librav1e && require_pkg_config librav1e rav1e rav1e.h
rav1e_context_new
enabled librsvg && require_pkg_config librsvg librsvg-2.0
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
enabled librtmp && require_pkg_config librtmp librtmp librtmp/rtmp.h
RTMP_Socket
enabled librubberband && require_pkg_config librubberband "rubberband >=
1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ && append
librubberband_extralibs "-lstdc++"
diff --git a/doc/encoders.texi b/doc/encoders.texi
index eefd124751..cd75d778ff 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1378,6 +1378,35 @@ makes it possible to store non-rgb pix_fmts.
@end table
+@section librav1e
+
+rav1e AV1 encoder wrapper.
+
+Requires the presence of the rav1e headers and library from crav1e
+during configuration. You need to explicitly configue the build with
+@code{--enable-librav1e}.
+
+@subsection Options
+
+@table @option
+@item qmax
+Sets the maximum qauntizer (floor) to use when using bitrate mode.
+
+@item qp
+Uses quantizers mode to encode at the given quantizer.
+
+@item rav1e-params
+Set rav1e options using a list of @var{key}=@var{value} couples separated
+by ":". See @command{rav1e --help} for a list of options.
+
+For example to specify librav1e encoding options with @option{-rav1e-params}:
+
+@example
+ffmpeg -i input -c:v librav1e -b:v 500K -rav1e-params speed=5:low_latency=true
output.mp4
+@end example
+
+@end table
+
@section libaom-av1
libaom AV1 encoder wrapper.
diff --git a/doc/general.texi b/doc/general.texi
index ec437230e3..6a1cd11a22 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -243,6 +243,13 @@ FFmpeg can use the OpenJPEG libraries for
decoding/encoding J2K videos. Go to
instructions. To enable using OpenJPEG in FFmpeg, pass
@code{--enable-libopenjpeg} to
@file{./configure}.
+@section rav1e
+
+FFmpeg can make use of rav1e (Rust AV1 Encoder) via its C bindings to encode
videos.
+Go to @url{https://github.com/lu-zero/crav1e/} and
@url{https://github.com/xiph/rav1e/}
+and follow the instructions. To enable using rav1e in FFmpeg, pass
@code{--enable-librav1e}
+to @file{./configure}.
+
@section TwoLAME
FFmpeg can make use of the TwoLAME library for MP2 encoding.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index edccd73037..dc589ce35d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -988,6 +988,7 @@ OBJS-$(CONFIG_LIBOPUS_DECODER)+= libopusdec.o
libopus.o \
vorbis_data.o
OBJS-$(CONFIG_LIBOPUS_ENCODER)+= libopusenc.o libopus.o \
vorbis_data.o
+OBJS-$(CONFIG_LIBRAV1E_ENCODER) += librav1e.o
OBJS-$(CONFIG_LIBSHINE_ENCODER) += libshine.o
OBJS-$(CONFIG_LIBSPEEX_DECODER) += libspeexdec.o
OBJS-$(CONFIG_LIBSPEEX_ENCODER) += libspeexenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 6178d3
Re: [FFmpeg-devel] [PATCH v5] avformat/ifv: added support for ifv cctv files
On Tue, May 28, 2019 at 11:30:13PM +0200, Reimar Döffinger wrote: > Hi! > Did you intentionally not send to the list? Okay I just realised I have been replying personally to all comments whereas I should have sent them to the list ':D > > On 28.05.2019, at 17:32, Swaraj Hota wrote: > > > On Sun, May 26, 2019 at 09:44:35PM +0200, Reimar Döffinger wrote: > >> On Sun, May 26, 2019 at 01:46:32AM +0530, Swaraj Hota wrote: > >>> +st = avformat_new_stream(s, NULL); > >>> +if (!st) > >>> +return AVERROR(ENOMEM); > >>> + > >>> +st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO; > >>> +st->codecpar->codec_id = AV_CODEC_ID_H264; > >>> +st->codecpar->width = ifv->width; > >>> +st->codecpar->height = ifv->height; > >>> +st->start_time = 0; > >>> +ifv->video_stream_index = st->index; > >> > >> I suspect that it would have been ok to > >> just assume/assert this will always be 0. > >> > > > > Okay, but I didn't get what exact change are you suggesting? Should > > I replace st->index with 0 here? Or should I get rid of > > ifv->video/audio_stream_index variables and instead use 0 and 1 > > everywhere? > > I think it's fine, now that you already wrote the code. > Just saying that you probably didn't really have to implement quite as much. > Will keep that in mind :) > >>> +static int ifv_read_packet(AVFormatContext *s, AVPacket *pkt) > >> > >> As far as I can tell, you just choose between audio > >> and video by the closest timestamp. > > > > Yes. > > > >> While this might be ok considering the limited importance > >> and uses of the format, it is rather simplistic. > >> I do not know if it follows the latest best practices, > >> but mov_find_next_sample is an example of a more > >> sophisticated way. > >> It takes into account whether the underlying transport > >> has issues seeking (like http, or even worse piped input) > >> and in that case prefers file position over timestamp > >> position. > >> It also avoids wasting time reading streams marked as > >> AVDISCARD_ALL (in mov_read_packet is that check). > >> Maybe others following the project more closely > >> can give additional/better best practice tips. > > > > Okay, I get that, but as you said considering the limited importance and > > uses of the format, we must also consider if it is worth all the effort, > > cuz it can also get more messy ':D Besides I have been working on this > > format since over a month or two now, and understanding, writing and > > debugging > > this change might take quite some time ':D > > > > I have been trying to comply with all good practices but I think a working > > demuxer is quite enough for a minority format like this (e.g. even the > > dhav format is quite simplistic), but again I can't say that, > > if others agree that it is a necessity I will work on it. > > Entirely depends on the purpose. > If the aim is to have a working demuxer, I think it is acceptable from what I > looked at. > I guess the only concern might be that not supporting piped input would be a > bit of a regression from the first patch. Is there another simpler way to support piped input? Can you explain a bit? > If the aim is to learn and possibly tackle more involved formats it might be > useful. But even then maybe rather as a separate patch later... > Actually another reason is that I now have to focus on my gsoc project, so yeah, a separate patch later seems like a good idea to me :) Thank you. Swaraj ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] ERROR ffmpeg
root@encoder3:~# ffprobe -i udp://@239.255.3.165:1234 ffprobe version N-93880-gc3458f06f4 Copyright (c) 2007-2019 the FFmpeg developers built with gcc 7 (Ubuntu 7.4.0-1ubuntu1~18.04) configuration: --pkg-config-flags=--static --prefix=/root/ffmpeg_build --extra-cflags=-I/root/ffmpeg_build/include --extra-ldflags=-L/root/ffmpeg_build/lib --bindir=/root/bin --enable-cuda-nvcc --enable-cuvid --enable-libnpp --extra-cflags=-I/usr/local/cuda/include/ --extra-ldflags=-L/usr/local/cuda/lib64/ --enable-gpl --enable-libass --enable-libfdk-aac --enable-vaapi --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-nonfree --enable-nvenc --enable-shared libavutil 56. 28.100 / 56. 28.100 libavcodec 58. 52.101 / 58. 52.101 libavformat58. 27.103 / 58. 27.103 libavdevice58. 7.100 / 58. 7.100 libavfilter 7. 53.101 / 7. 53.101 libswscale 5. 4.101 / 5. 4.101 libswresample 3. 4.100 / 3. 4.100 libpostproc55. 4.100 / 55. 4.100 [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] decode_slice_header error [h264 @ 0x55f1307934c0] no frame! [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] decode_slice_header error [h264 @ 0x55f1307934c0] no frame! [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] decode_slice_header error [h264 @ 0x55f1307934c0] no frame! [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] decode_slice_header error [h264 @ 0x55f1307934c0] no frame! [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] decode_slice_header error [h264 @ 0x55f1307934c0] no frame! [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] decode_slice_header error [h264 @ 0x55f1307934c0] no frame! [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] decode_slice_header error [h264 @ 0x55f1307934c0] no frame! [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] decode_slice_header error [h264 @ 0x55f1307934c0] no frame! [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] decode_slice_header error [h264 @ 0x55f1307934c0] no frame! [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] decode_slice_header error [h264 @ 0x55f1307934c0] no frame! [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] decode_slice_header error [h264 @ 0x55f1307934c0] no frame! [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] SPS unavailable in decode_picture_timing [h264 @ 0x55f1307934c0] non-existing PPS 0 referenced [h264 @ 0x55f1307934c0] decode_slice_header error [h264 @ 0x55f1307934c0] no frame! [h264 @ 0x55f1307934c0] SPS unavailable in decode_pict
[FFmpeg-devel] [PATCH] avcodec/gdv: Check remaining output after decode 5/6/8/
Improves: Timeout (355sec -> 97sec)
Improves:
14709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_GDV_fuzzer-5704215281795072
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
---
libavcodec/gdv.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/gdv.c b/libavcodec/gdv.c
index 9cf30c09e4..a5ce6b799e 100644
--- a/libavcodec/gdv.c
+++ b/libavcodec/gdv.c
@@ -308,7 +308,7 @@ static int decompress_5(AVCodecContext *avctx, unsigned
skip)
int len;
int b = bytestream2_get_byte(gb);
if (b == 0) {
-break;
+return 0;
}
if (b != 0xFF) {
len = b;
@@ -323,6 +323,8 @@ static int decompress_5(AVCodecContext *avctx, unsigned
skip)
lz_copy(pb, g2, off, len);
}
}
+if (bytestream2_get_bytes_left_p(pb) > 0)
+return AVERROR_INVALIDDATA;
return 0;
}
@@ -445,6 +447,9 @@ static int decompress_68(AVCodecContext *avctx, unsigned
skip, unsigned use8)
}
}
+if (bytestream2_get_bytes_left_p(pb) > 0)
+return AVERROR_INVALIDDATA;
+
return 0;
}
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec: Add librav1e encoder
On 29/05/2019 17:12, James Almer wrote:
>> +end:
>> +if (cfg)
>> +rav1e_config_unref(cfg);
>> +
>> +if (ret)
>> +librav1e_encode_close(avctx);
>
> Use the FF_CODEC_CAP_INIT_CLEANUP flag in AVCodec.caps_internal instead.
> It will call AVCodec.close() on AVCodec.init() failure.
OK.
>> +.pix_fmts = (const enum AVPixelFormat[]) {
>> +AV_PIX_FMT_YUV420P,
>> +AV_PIX_FMT_YUV420P10,
>> +AV_PIX_FMT_YUV420P12,
>> +AV_PIX_FMT_YUV422P,
>> +AV_PIX_FMT_YUV422P10,
>> +AV_PIX_FMT_YUV422P12,
>> +AV_PIX_FMT_YUV444P,
>> +AV_PIX_FMT_YUV444P10,
>> +AV_PIX_FMT_YUV444P12,
>> +AV_PIX_FMT_GRAY8,
>> +AV_PIX_FMT_GRAY10,
>> +AV_PIX_FMT_GRAY12,
>> +AV_PIX_FMT_NONE
>
> Nit: Split this off, like libx26* do.
OK.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec: Add librav1e encoder
On 5/29/2019 11:41 AM, Derek Buitenhuis wrote:
> Uses the crav1e C bindings for rav1e.
>
> Port to the new send/receive API by: James Almer .
>
> Signed-off-by: Derek Buitenhuis
> ---
> The only thing I didn't address from the last set of replies was the
> second 'ret' variable, since I prefer it that way (having a separate
> ret for avcodec values and external values.
> ---
> configure | 4 +
> doc/encoders.texi | 29 +++
> doc/general.texi | 7 +
> libavcodec/Makefile| 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/librav1e.c | 417 +
> 6 files changed, 459 insertions(+)
> create mode 100644 libavcodec/librav1e.c
[...]
> +end:
> +if (cfg)
> +rav1e_config_unref(cfg);
> +
> +if (ret)
> +librav1e_encode_close(avctx);
Use the FF_CODEC_CAP_INIT_CLEANUP flag in AVCodec.caps_internal instead.
It will call AVCodec.close() on AVCodec.init() failure.
[...]
> +AVCodec ff_librav1e_encoder = {
> +.name = "librav1e",
> +.long_name = NULL_IF_CONFIG_SMALL("librav1e AV1"),
> +.type = AVMEDIA_TYPE_VIDEO,
> +.id = AV_CODEC_ID_AV1,
> +.init = librav1e_encode_init,
> +.send_frame = librav1e_send_frame,
> +.receive_packet = librav1e_receive_packet,
> +.close = librav1e_encode_close,
> +.priv_data_size = sizeof(librav1eContext),
> +.priv_class = &class,
> +.defaults = librav1e_defaults,
> +.pix_fmts = (const enum AVPixelFormat[]) {
> +AV_PIX_FMT_YUV420P,
> +AV_PIX_FMT_YUV420P10,
> +AV_PIX_FMT_YUV420P12,
> +AV_PIX_FMT_YUV422P,
> +AV_PIX_FMT_YUV422P10,
> +AV_PIX_FMT_YUV422P12,
> +AV_PIX_FMT_YUV444P,
> +AV_PIX_FMT_YUV444P10,
> +AV_PIX_FMT_YUV444P12,
> +AV_PIX_FMT_GRAY8,
> +AV_PIX_FMT_GRAY10,
> +AV_PIX_FMT_GRAY12,
> +AV_PIX_FMT_NONE
Nit: Split this off, like libx26* do.
> +},
> +.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
> +.wrapper_name = "librav1e",
> +};
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Is this a regression or not?
Am 28.05.19 um 21:33 schrieb Marton Balint: > > > On Tue, 28 May 2019, Nomis101 🐝 wrote: > >> I regularly build HandBrake against the latest FFmpeg master to check if all >> works as expected or something is broken and I need to open a bug. With the >> latest master I found some issues, but I'm >> unsure if this is a regression or not. >> After commit f9271d0158122c9e043b7d83f691884b65ec1ba5 HB doesn't recognize >> the audio stream anymore, so the encoded file has no audio stream at all. Is >> this >> 1. A regression and I should report this to the FFmpeg bug tracker >> or is it >> 2. A change in the way how streams are handled and all FFmpeg-depended >> applications will need to modify their code accordingly? > > From this description I don't know. Open a ticket in trac.ffmpeg.org and > post the command line handbrake generates and the ffmpeg command output. > > Thanks, > Marton > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > Thanks. I did report it to trac.ffmpeg.org now as #7928. It turned out, it was not the commit from my initital post. So, sorry for blaming the wrong commit. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec: Add librav1e encoder
On 29/05/2019 16:01, Lynne wrote:
> for (int i = 0; i < desc->nb_components; i++) {
> rav1e_frame_fill_plane() should probably return an error if the plane index
> is invalid.
Yep. Fixed locally.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec: Add librav1e encoder
May 29, 2019, 3:41 PM by derek.buitenh...@gmail.com:
> +
> +static int librav1e_send_frame(AVCodecContext *avctx, const AVFrame *frame)
> +{
> +librav1eContext *ctx = avctx->priv_data;
> +int ret;
> +
> +if (!ctx->rframe && frame) {
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
> +
> +ctx->rframe = rav1e_frame_new(ctx->ctx);
> +if (!ctx->rframe) {
> +av_log(avctx, AV_LOG_ERROR, "Could not allocate new rav1e
> frame.\n");
> +return AVERROR(ENOMEM);
> +}
> +
> +for (int i = 0; i < 3; i++) {
>
for (int i = 0; i < desc->nb_components; i++) {
rav1e_frame_fill_plane() should probably return an error if the plane index is
invalid.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avcodec: Add librav1e encoder
Uses the crav1e C bindings for rav1e.
Port to the new send/receive API by: James Almer .
Signed-off-by: Derek Buitenhuis
---
The only thing I didn't address from the last set of replies was the
second 'ret' variable, since I prefer it that way (having a separate
ret for avcodec values and external values.
---
configure | 4 +
doc/encoders.texi | 29 +++
doc/general.texi | 7 +
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/librav1e.c | 417 +
6 files changed, 459 insertions(+)
create mode 100644 libavcodec/librav1e.c
diff --git a/configure b/configure
index 32fc26356c..e61644b012 100755
--- a/configure
+++ b/configure
@@ -254,6 +254,7 @@ External library support:
--enable-libopenmpt enable decoding tracked files via libopenmpt [no]
--enable-libopus enable Opus de/encoding via libopus [no]
--enable-libpulseenable Pulseaudio input via libpulse [no]
+ --enable-librav1eenable AV1 encoding via rav1e [no]
--enable-librsvg enable SVG rasterization via librsvg [no]
--enable-librubberband enable rubberband needed for rubberband filter [no]
--enable-librtmp enable RTMP[E] support via librtmp [no]
@@ -1778,6 +1779,7 @@ EXTERNAL_LIBRARY_LIST="
libopenmpt
libopus
libpulse
+librav1e
librsvg
librtmp
libshine
@@ -3173,6 +3175,7 @@ libopenmpt_demuxer_deps="libopenmpt"
libopus_decoder_deps="libopus"
libopus_encoder_deps="libopus"
libopus_encoder_select="audio_frame_queue"
+librav1e_encoder_deps="librav1e"
librsvg_decoder_deps="librsvg"
libshine_encoder_deps="libshine"
libshine_encoder_select="audio_frame_queue"
@@ -6199,6 +6202,7 @@ enabled libopus && {
}
}
enabled libpulse && require_pkg_config libpulse libpulse
pulse/pulseaudio.h pa_context_new
+enabled librav1e && require_pkg_config librav1e rav1e rav1e.h
rav1e_context_new
enabled librsvg && require_pkg_config librsvg librsvg-2.0
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
enabled librtmp && require_pkg_config librtmp librtmp librtmp/rtmp.h
RTMP_Socket
enabled librubberband && require_pkg_config librubberband "rubberband >=
1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ && append
librubberband_extralibs "-lstdc++"
diff --git a/doc/encoders.texi b/doc/encoders.texi
index eefd124751..cd75d778ff 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1378,6 +1378,35 @@ makes it possible to store non-rgb pix_fmts.
@end table
+@section librav1e
+
+rav1e AV1 encoder wrapper.
+
+Requires the presence of the rav1e headers and library from crav1e
+during configuration. You need to explicitly configue the build with
+@code{--enable-librav1e}.
+
+@subsection Options
+
+@table @option
+@item qmax
+Sets the maximum qauntizer (floor) to use when using bitrate mode.
+
+@item qp
+Uses quantizers mode to encode at the given quantizer.
+
+@item rav1e-params
+Set rav1e options using a list of @var{key}=@var{value} couples separated
+by ":". See @command{rav1e --help} for a list of options.
+
+For example to specify librav1e encoding options with @option{-rav1e-params}:
+
+@example
+ffmpeg -i input -c:v librav1e -b:v 500K -rav1e-params speed=5:low_latency=true
output.mp4
+@end example
+
+@end table
+
@section libaom-av1
libaom AV1 encoder wrapper.
diff --git a/doc/general.texi b/doc/general.texi
index ec437230e3..6a1cd11a22 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -243,6 +243,13 @@ FFmpeg can use the OpenJPEG libraries for
decoding/encoding J2K videos. Go to
instructions. To enable using OpenJPEG in FFmpeg, pass
@code{--enable-libopenjpeg} to
@file{./configure}.
+@section rav1e
+
+FFmpeg can make use of rav1e (Rust AV1 Encoder) via its C bindings to encode
videos.
+Go to @url{https://github.com/lu-zero/crav1e/} and
@url{https://github.com/xiph/rav1e/}
+and follow the instructions. To enable using rav1e in FFmpeg, pass
@code{--enable-librav1e}
+to @file{./configure}.
+
@section TwoLAME
FFmpeg can make use of the TwoLAME library for MP2 encoding.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index edccd73037..dc589ce35d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -988,6 +988,7 @@ OBJS-$(CONFIG_LIBOPUS_DECODER)+= libopusdec.o
libopus.o \
vorbis_data.o
OBJS-$(CONFIG_LIBOPUS_ENCODER)+= libopusenc.o libopus.o \
vorbis_data.o
+OBJS-$(CONFIG_LIBRAV1E_ENCODER) += librav1e.o
OBJS-$(CONFIG_LIBSHINE_ENCODER) += libshine.o
OBJS-$(CONFIG_LIBSPEEX_DECODER) += libspeexdec.o
OBJS-$(CONFIG_LIBSPEEX_ENCODER) += libspeexenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 6178d31b5c..8a59f39a90 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -702
Re: [FFmpeg-devel] [PATCH] avcodec/h264_slice: set the SEI parameters early on the AVCodecContext
On 5/29/2019 10:16 AM, Steve Lhomme wrote:
> It's better to do it before the buffers are actually created. At least in VLC
> we currently don't support changing some parameters dynamically easily so we
> don't use the information if it comes after the buffer are created.
>
> Co-authored-by: James Almer
> ---
> libavcodec/h264_slice.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 1c9a270fb6..5ceee107a0 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -1092,6 +1092,12 @@ static int h264_init_ps(H264Context *h, const
> H264SliceContext *sl, int first_sl
> h->avctx->colorspace = sps->colorspace;
> }
> }
> +
> +if (h->sei.alternative_transfer.present &&
> +
> av_color_transfer_name(h->sei.alternative_transfer.preferred_transfer_characteristics)
> &&
> +h->sei.alternative_transfer.preferred_transfer_characteristics
> != AVCOL_TRC_UNSPECIFIED) {
> +h->avctx->color_trc =
> h->sei.alternative_transfer.preferred_transfer_characteristics;
> +}
> }
>
> if (!h->context_initialized || must_reinit || needs_reinit) {
> @@ -1332,12 +1338,6 @@ static int h264_export_frame_props(H264Context *h)
> h->sei.picture_timing.timecode_cnt = 0;
> }
>
> -if (h->sei.alternative_transfer.present &&
> -
> av_color_transfer_name(h->sei.alternative_transfer.preferred_transfer_characteristics)
> &&
> -h->sei.alternative_transfer.preferred_transfer_characteristics !=
> AVCOL_TRC_UNSPECIFIED) {
> -h->avctx->color_trc = cur->f->color_trc =
> h->sei.alternative_transfer.preferred_transfer_characteristics;
> -}
> -
> return 0;
LTGM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] mpeg12enc: Use all Closed Captions side data
As suggested elsewhere, here's the output of git diff -w, I hope that helps :)
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index 2bc5289d63..0162939399 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -547,8 +547,13 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, int
picture_number)
}
if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && s->a53_cc) {
- side_data = av_frame_get_side_data(s->current_picture_ptr->f,
- AV_FRAME_DATA_A53_CC);
+ int i;
+
+ for (i = 0; i < s->current_picture_ptr->f->nb_side_data; i++) {
+ side_data = s->current_picture_ptr->f->side_data[i];
+ if (side_data->type != AV_FRAME_DATA_A53_CC)
+ continue;
+
if (side_data) {
if (side_data->size <= A53_MAX_CC_COUNT * 3 && side_data->size
% 3 == 0) {
int i = 0;
@@ -575,6 +580,7 @@ void ff_mpeg1_encode_picture_header(MpegEncContext *s, int
picture_number)
}
}
}
+ }
s->mb_y = 0;
ff_mpeg1_encode_slice_header(s);
On 5/13/19 3:39 PM, Carl Eugen Hoyos wrote:
> Am Mi., 10. Apr. 2019 um 13:26 Uhr schrieb Mathieu Duponchelle
> :
>
>> No problem
> I don't see an updated patch.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder
On 29/05/2019 01:19, James Darnley wrote: > IIRC either qp or cqp Yeah, I'll use that; it makes sense. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Add support for recognizing DNG/CinemaDNG files
Do not review, I found some CinemaDNG images that do not work. I will figure out a better solution. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/h264_slice: set the SEI parameters early on the AVCodecContext
It's better to do it before the buffers are actually created. At least in VLC
we currently don't support changing some parameters dynamically easily so we
don't use the information if it comes after the buffer are created.
Co-authored-by: James Almer
---
libavcodec/h264_slice.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 1c9a270fb6..5ceee107a0 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1092,6 +1092,12 @@ static int h264_init_ps(H264Context *h, const
H264SliceContext *sl, int first_sl
h->avctx->colorspace = sps->colorspace;
}
}
+
+if (h->sei.alternative_transfer.present &&
+
av_color_transfer_name(h->sei.alternative_transfer.preferred_transfer_characteristics)
&&
+h->sei.alternative_transfer.preferred_transfer_characteristics !=
AVCOL_TRC_UNSPECIFIED) {
+h->avctx->color_trc =
h->sei.alternative_transfer.preferred_transfer_characteristics;
+}
}
if (!h->context_initialized || must_reinit || needs_reinit) {
@@ -1332,12 +1338,6 @@ static int h264_export_frame_props(H264Context *h)
h->sei.picture_timing.timecode_cnt = 0;
}
-if (h->sei.alternative_transfer.present &&
-
av_color_transfer_name(h->sei.alternative_transfer.preferred_transfer_characteristics)
&&
-h->sei.alternative_transfer.preferred_transfer_characteristics !=
AVCOL_TRC_UNSPECIFIED) {
-h->avctx->color_trc = cur->f->color_trc =
h->sei.alternative_transfer.preferred_transfer_characteristics;
-}
-
return 0;
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/tiff: Add support for recognizing DNG/CinemaDNG files
From: Nick Renieris
In DNG images with the .tiff extension, it solves the issue where the
TIFF thumbnail in IFD 0 was incorrectly parsed (related confusion: [1]).
Embedded thumbnails for DNG images can still be decoded with the added
"-dng_thumb" option.
Maintains current support for CinemaDNG (at least the ones found
in the wild) by detecting them and not erroring out in that case.
Additionally:
- Renamed TIFF_WHITE_LEVEL to DNG_WHITE_LEVEL since it is specified
in the DNG spec.
- Added/changed some comments to be more precise in differentiating
between TIFF, TIFF/EP and DNG values.
Related to ticket: https://trac.ffmpeg.org/ticket/4364
[1]:
https://superuser.com/questions/546879/creating-video-from-dng-images-with-ffmpeg
Signed-off-by: Nick Renieris
---
libavcodec/tiff.c | 48 +-
libavcodec/tiff.h | 36 +-
libavformat/img2.c | 1 +
3 files changed, 79 insertions(+), 6 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 79e6242549..23d979eada 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -56,7 +56,9 @@ typedef struct TiffContext {
int get_subimage;
uint16_t get_page;
+int get_dng_thumb;
+enum TiffType tiff_type;
int width, height;
unsigned int bpp, bppcount;
uint32_t palette[256];
@@ -70,6 +72,7 @@ typedef struct TiffContext {
int predictor;
int fill_order;
uint32_t res[4];
+int is_thumbnail;
int is_bayer;
uint8_t pattern[4];
@@ -94,6 +97,11 @@ typedef struct TiffContext {
TiffGeoTag *geotags;
} TiffContext;
+static void tiff_set_type(TiffContext *s, enum TiffType tiff_type) {
+if (s->tiff_type < tiff_type) // Prioritize higher-valued entries
+s->tiff_type = tiff_type;
+}
+
static void free_geotags(TiffContext *const s)
{
int i;
@@ -948,6 +956,8 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
}
switch (tag) {
+case TIFF_SUBFILE:
+s->is_thumbnail = (value != 0);
case TIFF_WIDTH:
s->width = value;
break;
@@ -1088,7 +1098,7 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
case TIFF_SUB_IFDS:
s->sub_ifd = value;
break;
-case TIFF_WHITE_LEVEL:
+case DNG_WHITE_LEVEL:
s->white_level = value;
break;
case TIFF_CFA_PATTERN_DIM:
@@ -1339,6 +1349,27 @@ static int tiff_decode_tag(TiffContext *s, AVFrame
*frame)
case TIFF_SOFTWARE_NAME:
ADD_METADATA(count, "software", NULL);
break;
+case DNG_VERSION:
+if (count == 4) {
+unsigned int ver[4];
+ver[0] = ff_tget(&s->gb, type, s->le);
+ver[1] = ff_tget(&s->gb, type, s->le);
+ver[2] = ff_tget(&s->gb, type, s->le);
+ver[3] = ff_tget(&s->gb, type, s->le);
+
+av_log(s->avctx, AV_LOG_DEBUG, "DNG file, version %u.%u.%u.%u\n",
+ver[0], ver[1], ver[2], ver[3]);
+
+tiff_set_type(s, TIFF_TYPE_DNG);
+}
+break;
+case CINEMADNG_TIME_CODES:
+case CINEMADNG_FRAME_RATE:
+case CINEMADNG_T_STOP:
+case CINEMADNG_REEL_NAME:
+case CINEMADNG_CAMERA_LABEL:
+tiff_set_type(s, TIFF_TYPE_CINEMADNG);
+break;
default:
if (s->avctx->err_recognition & AV_EF_EXPLODE) {
av_log(s->avctx, AV_LOG_ERROR,
@@ -1387,6 +1418,7 @@ static int decode_frame(AVCodecContext *avctx,
s->le = le;
// TIFF_BPP is not a required tag and defaults to 1
again:
+s->is_thumbnail = 0;
s->bppcount= s->bpp = 1;
s->photometric = TIFF_PHOTOMETRIC_NONE;
s->compr = TIFF_RAW;
@@ -1394,6 +1426,7 @@ again:
s->white_level = 0;
s->is_bayer= 0;
s->cur_page= 0;
+s->tiff_type = TIFF_TYPE_TIFF;
free_geotags(s);
// Reset these offsets so we can tell if they were set this frame
@@ -1408,6 +1441,18 @@ again:
return ret;
}
+if (s->tiff_type == TIFF_TYPE_DNG) {
+if (!s->get_dng_thumb) {
+av_log(avctx, AV_LOG_ERROR, "DNG images are not supported\n");
+av_log(avctx, AV_LOG_INFO, "You can use -dng_thumb to decode an
embedded TIFF thumbnail (if any) instead\n");
+return AVERROR_INVALIDDATA;
+}
+if (!s->is_thumbnail) {
+av_log(avctx, AV_LOG_INFO, "No embedded thumbnail present\n");
+return AVERROR_EOF;
+}
+}
+
/** whether we should look for this IFD's SubIFD */
retry_for_subifd = s->sub_ifd && s->get_subimage;
/** whether we should look for this multi-page IFD's next page */
@@ -1671,6 +1716,7 @@ static av_cold int tiff_end(AVCodecContext *avctx)
static const AVOption tiff_options[] = {
{ "subimage", "decode subimage instead if available",
OFFSET(get_subimage), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1,
AV_OPT_FLAG_DECODING_PARAM | AV_OPT_FLAG_VIDEO_PARAM },
{ "page", "page
Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Add support for recognizing DNG/CinemaDNG files
This was meant to be a reply to http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244744.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] libavfilter: Add derain filter
Remove the rain in the input image/video by applying the derain
methods based on convolutional neural networks. Training scripts
as well as scripts for model generation are provided in the
repository at https://github.com/XueweiMeng/derain_filter.git.
Signed-off-by: Xuewei Meng
---
doc/filters.texi | 34 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_derain.c | 216 +++
4 files changed, 252 insertions(+)
create mode 100644 libavfilter/vf_derain.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 4fdcfe919e..f1d3841ed3 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8248,6 +8248,40 @@ delogo=x=0:y=0:w=100:h=77:band=10
@end itemize
+@section derain
+
+Remove the rain in the input image/video by applying the derain methods based
on
+convolutional neural networks. Supported models:
+
+@itemize
+@item
+Recurrent Squeeze-and-Excitation Context Aggregation Net (RESCAN).
+See
@url{http://openaccess.thecvf.com/content_ECCV_2018/papers/Xia_Li_Recurrent_Squeeze-and-Excitation_Context_ECCV_2018_paper.pdf}.
+@end itemize
+
+Training scripts as well as scripts for model generation are provided in
+the repository at @url{https://github.com/XueweiMeng/derain_filter.git}.
+
+The filter accepts the following options:
+
+@table @option
+@item dnn_backend
+Specify which DNN backend to use for model loading and execution. This option
accepts
+the following values:
+
+@table @samp
+@item native
+Native implementation of DNN loading and execution.
+@end table
+Default value is @samp{native}.
+
+@item model
+Set path to model file specifying network architecture and its parameters.
+Note that different backends use different file formats. TensorFlow backend
+can load files for both formats, while native backend can load files for only
+its format.
+@end table
+
@section deshake
Attempt to fix small changes in horizontal and/or vertical shift. This
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 9a61c25b05..b7191d0081 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -200,6 +200,7 @@ OBJS-$(CONFIG_DCTDNOIZ_FILTER) +=
vf_dctdnoiz.o
OBJS-$(CONFIG_DEBAND_FILTER) += vf_deband.o
OBJS-$(CONFIG_DEBLOCK_FILTER)+= vf_deblock.o
OBJS-$(CONFIG_DECIMATE_FILTER) += vf_decimate.o
+OBJS-$(CONFIG_DERAIN_FILTER) += vf_derain.o
OBJS-$(CONFIG_DECONVOLVE_FILTER) += vf_convolve.o framesync.o
OBJS-$(CONFIG_DEDOT_FILTER) += vf_dedot.o
OBJS-$(CONFIG_DEFLATE_FILTER)+= vf_neighbor.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 40534738ee..f3c8883960 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -196,6 +196,7 @@ extern AVFilter ff_vf_deinterlace_vaapi;
extern AVFilter ff_vf_dejudder;
extern AVFilter ff_vf_delogo;
extern AVFilter ff_vf_denoise_vaapi;
+extern AVFilter ff_vf_derain;
extern AVFilter ff_vf_deshake;
extern AVFilter ff_vf_despill;
extern AVFilter ff_vf_detelecine;
diff --git a/libavfilter/vf_derain.c b/libavfilter/vf_derain.c
new file mode 100644
index 00..f7bbf314e5
--- /dev/null
+++ b/libavfilter/vf_derain.c
@@ -0,0 +1,216 @@
+/*
+ * Copyright (c) 2019 Xuewei Meng
+ *
+ * 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
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Filter implementing image derain filter using deep convolutional networks.
+ *
http://openaccess.thecvf.com/content_ECCV_2018/html/Xia_Li_Recurrent_Squeeze-and-Excitation_Context_ECCV_2018_paper.html
+ */
+
+#include "libavformat/avio.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "dnn_interface.h"
+#include "formats.h"
+#include "internal.h"
+
+typedef struct DRContext {
+const AVClass *class;
+
+char *model_filename;
+DNNBackendType backend_type;
+DNNModule *dnn_module;
+DNNModel *model;
+DNNInputData input;
+DNNDataoutput;
+} DRContext;
+
+#define CLIP(x, min, max) (x < min ? min : (x > max ? max : x))
+#define OFFSET(x) offsetof(DRContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM | AV_OPT_FLAG_VIDEO_PARAM
+static const AVOption derain_options[] = {
+{ "dnn
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/nvenc: add master display and light level sei for HDR10
On Tue, May 28, 2019, 01:15 James Almer wrote: > On 5/27/2019 7:13 PM, Timo Rothenpieler wrote: > > On 27.05.2019 23:49, Lance Wang wrote: > >> On Saturday, May 25, 2019, James Almer wrote: > >> > >>> On 5/22/2019 3:59 AM, lance.lmw...@gmail.com wrote: > From: Limin Wang > > The testing command for the HDR10 output with nvenc: > $ ./ffmpeg_g -y -i 4K.mp4 -c:v hevc_nvenc -g 7 -color_primaries bt2020 > >>> -colorspace bt2020_ncl -color_trc smpte2084 -sei hdr10 \ > -master_display "G(13250,34500)B(7500,3000)R( > >>> 34000,16000)WP(15635,16450)L(1000,50)" -max_cll "0, 0" test.ts > > Please notice it is preferable to use the frame sei side data than > >>> master_display and max_cll paramters config > --- > libavcodec/nvenc.c | 129 > > libavcodec/nvenc.h | 18 ++ > libavcodec/nvenc_hevc.c | 11 > 3 files changed, 158 insertions(+) > > diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c > index 75dda6d689..3fd0eca4a5 100644 > --- a/libavcodec/nvenc.c > +++ b/libavcodec/nvenc.c > @@ -22,6 +22,9 @@ > #include "config.h" > > #include "nvenc.h" > +#include "cbs_h265.h" > >>> > >>> This doesn't seem right. The encoder isn't using this framework at all. > >>> > >>> You're apparently including this only to get the > >>> H265RawSEIMasteringDisplayColourVolume and > >>> H265RawSEIContentLightLevelInfo structs, which you don't really need to > >>> fill sei_data[i].payload > >>> > >>> OK, I'll remove the dependent for the two structure and update the > >>> patch. > >> > >> > > > > I'm still not convinced that all this belong in an encoder. > > Can it really not be made into a filter that adds it as extra data to > > frames? There got to be other frame consumers that use this kind of data. > > hevc_metadata (h265_metadata_bsf.c) already exists. It should be trivial > to add support for this there. > Case in point: Some encoders, such as hevc_vaapi, present private codec options for the retention of specific SEIs, such as HDR (and is on by default), yet others, such as the QSV runtime, have no such options. Wiring this into a bitstream filter (such as hevc_metadata), etc would easily address such disparities without mucking around with convoluted private encoder options. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavf/qsvvpp: avoid the double-free when working in sys memory mode
> -Original Message- > From: Fu, Linjie > Sent: Monday, April 15, 2019 21:24 > To: ffmpeg-devel@ffmpeg.org > Cc: Fu, Linjie > Subject: [PATCH] lavf/qsvvpp: avoid the double-free when working in sys > memory mode > > Currently, picref will be freed by calling av_frame_free(&picref) in > submit_frame() in qsvvpp.c when working in system memory mode,and > normally it > is freed in filter_frame() in vf_vpp_qsv.c when working in other modes. > > Double free happens when working in system memory mode, remove to > fix the memory issue. > > Signed-off-by: Linjie Fu > --- > Can be reproduced by applying the system memory patch and qsvdec+vpp: > ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -c:v h264_qsv -i > input.mp4 \ > -vf "vpp_qsv=w=960:h=540,format=rgb32" -f > null - > libavfilter/qsvvpp.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c > index 06efdf5089..5cd1d5d345 100644 > --- a/libavfilter/qsvvpp.c > +++ b/libavfilter/qsvvpp.c > @@ -316,7 +316,6 @@ static QSVFrame *submit_frame(QSVVPPContext *s, > AVFilterLink *inlink, AVFrame *p > } > > av_frame_copy_props(qsv_frame->frame, picref); > -av_frame_free(&picref); > } else > qsv_frame->frame = av_frame_clone(picref); > > -- > 2.17.1 Ping? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate continuous memory
Mediasdk calls CMRT to copy from video to system memory and requires
memory to be continuously allocated across Y and UV.
Add a new path to allocate continuous memory when using system out.
Use av_image_fill_pointers to arrange data according to pixfmt.
Signed-off-by: Linjie Fu
---
[v2]: use av_image_fill_pointers
libavfilter/qsvvpp.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
index 06efdf5089..6eeed7e632 100644
--- a/libavfilter/qsvvpp.c
+++ b/libavfilter/qsvvpp.c
@@ -27,6 +27,7 @@
#include "libavutil/hwcontext_qsv.h"
#include "libavutil/time.h"
#include "libavutil/pixdesc.h"
+#include "libavutil/imgutils.h"
#include "internal.h"
#include "qsvvpp.h"
@@ -51,6 +52,7 @@ struct QSVVPPContext {
enum AVPixelFormat out_sw_format; /* Real output format */
mfxVideoParam vpp_param;
mfxFrameInfo *frame_infos; /* frame info for each input */
+AVBufferPool *pool;
/* members related to the input/output surface */
int in_mem_mode;
@@ -375,10 +377,24 @@ static QSVFrame *query_frame(QSVVPPContext *s,
AVFilterLink *outlink)
out_frame->surface = (mfxFrameSurface1 *)out_frame->frame->data[3];
} else {
/* Get a frame with aligned dimensions.
- * Libmfx need system memory being 128x64 aligned */
-out_frame->frame = ff_get_video_buffer(outlink,
- FFALIGN(outlink->w, 128),
- FFALIGN(outlink->h, 64));
+ * Libmfx need system memory being 128x64 aligned
+ * and continuously allocated across Y and UV */
+out_frame->frame = av_frame_alloc();
+if (!out_frame->frame) {
+return NULL;
+}
+
+out_frame->frame->linesize[0] = FFALIGN(outlink->w, 128);
+out_frame->frame->linesize[1] = out_frame->frame->linesize[0];
+out_frame->frame->buf[0] = av_buffer_pool_get(s->pool);
+out_frame->frame->format = outlink->format;
+
+if (!out_frame->frame->buf[0])
+return NULL;
+
+av_image_fill_pointers(out_frame->frame->data,
out_frame->frame->format,
+FFALIGN(outlink->h, 64),
out_frame->frame->buf[0]->data,
+
out_frame->frame->linesize);
if (!out_frame->frame)
return NULL;
@@ -483,8 +499,13 @@ static int init_vpp_session(AVFilterContext *avctx,
QSVVPPContext *s)
av_buffer_unref(&outlink->hw_frames_ctx);
outlink->hw_frames_ctx = out_frames_ref;
-} else
+} else {
s->out_mem_mode = MFX_MEMTYPE_SYSTEM_MEMORY;
+s->pool = av_buffer_pool_init(av_image_get_buffer_size(outlink->format,
+FFALIGN(outlink->w,
128),
+FFALIGN(outlink->h,
64), 1),
+av_buffer_allocz);
+}
/* extract the properties of the "master" session given to us */
ret = MFXQueryIMPL(device_hwctx->session, &impl);
@@ -674,6 +695,7 @@ int ff_qsvvpp_free(QSVVPPContext **vpp)
/* release all the resources */
clear_frame_list(&s->in_frame_list);
clear_frame_list(&s->out_frame_list);
+av_buffer_pool_uninit(&s->pool);
av_freep(&s->surface_ptrs_in);
av_freep(&s->surface_ptrs_out);
av_freep(&s->ext_buffers);
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/vaapi_encode: grow packet if vaMapBuffer returns multiple buffers
It seems that VA_CODED_BUF_STATUS_SINGLE_NALU allows driver to map
buffer for each slice.
Currently, assigning new buffer for pkt when multiple buffer returns
from vaMapBuffer will cover the previous encoded pkt data and lead
to encode issues.
Using av_grow_packet to expand pkt if several buffers are returned.
Signed-off-by: Linjie Fu
---
libavcodec/vaapi_encode.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 2dda451..2812237 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -490,6 +490,7 @@ static int vaapi_encode_output(AVCodecContext *avctx,
VACodedBufferSegment *buf_list, *buf;
VAStatus vas;
int err;
+uint8_t *ptr;
err = vaapi_encode_wait(avctx, pic);
if (err < 0)
@@ -509,11 +510,18 @@ static int vaapi_encode_output(AVCodecContext *avctx,
av_log(avctx, AV_LOG_DEBUG, "Output buffer: %u bytes "
"(status %08x).\n", buf->size, buf->status);
-err = av_new_packet(pkt, buf->size);
+if (pkt->size)
+err = av_grow_packet(pkt, buf->size);
+else {
+err = av_new_packet(pkt, buf->size);
+ptr = pkt->data;
+}
+
if (err < 0)
goto fail_mapped;
-memcpy(pkt->data, buf->buf, buf->size);
+memcpy(ptr, buf->buf, buf->size);
+ptr += buf->size;
}
if (pic->type == PICTURE_TYPE_IDR)
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] avfilter/vf_unsharp: enable slice threading
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Song, Ruiling > Sent: Thursday, May 23, 2019 9:26 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH V2] avfilter/vf_unsharp: enable slice > threading > > > -Original Message- > > From: Song, Ruiling > > Sent: Thursday, May 16, 2019 5:48 PM > > To: ffmpeg-devel@ffmpeg.org > > Cc: Song, Ruiling > > Subject: [PATCH V2] avfilter/vf_unsharp: enable slice threading > > > > benchmarking with a simple command: > > ffmpeg -i 1080p.mp4 -vf unsharp=la=3:ca=3 -an -f null /dev/null > > with the patch, the fps increase from 50 to 120 on my local machine (i7- > > 6770HQ). > > > > v2: > > make av_image_copy_plane() only copy per-slice content. > > > > Signed-off-by: Ruiling Song > Ping? Any comments? Ping? Will apply next week if nobody against. Ruiling ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] lavfi/lut: Add slice threading support
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Paul B Mahol > Sent: Wednesday, May 29, 2019 4:24 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH V2] lavfi/lut: Add slice threading > support > > On 5/29/19, Song, Ruiling wrote: > >> -Original Message- > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > >> Of Jun Zhao > >> Sent: Saturday, May 25, 2019 10:33 AM > >> To: ffmpeg-devel@ffmpeg.org > >> Cc: Jun Zhao > >> Subject: [FFmpeg-devel] [PATCH V2] lavfi/lut: Add slice threading support > >> > >> V2: - update comments > >> > >> Jun Zhao (1): > >> lavfi/lut: Add slice threading support > >> > >> libavfilter/vf_lut.c | 329 +--- > --- > >> --- > >> 1 files changed, 216 insertions(+), 113 deletions(-) > > I have attached the patch which I would like to happen. > > I only test lutyuv on 1080p input, seems the performance penalty is less > > than 5%. > > I would like also hear performance numbers from your environment. > > I am not sure do you like the patch? > > > > You should use function pointers. Do you mean function pointer for the per-pixel function? I think function pointer will introduce extra burden of function call per each pixel, while for now, the xxx_pixel_8/16 is just inlined. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] lavfi/lut: Add slice threading support
On Wed, May 29, 2019 at 4:31 PM Paul B Mahol wrote: > > On 5/29/19, Song, Ruiling wrote: > >> -Original Message- > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > >> Of Jun Zhao > >> Sent: Saturday, May 25, 2019 10:33 AM > >> To: ffmpeg-devel@ffmpeg.org > >> Cc: Jun Zhao > >> Subject: [FFmpeg-devel] [PATCH V2] lavfi/lut: Add slice threading support > >> > >> V2: - update comments > >> > >> Jun Zhao (1): > >> lavfi/lut: Add slice threading support > >> > >> libavfilter/vf_lut.c | 329 +-- > >> --- > >> 1 files changed, 216 insertions(+), 113 deletions(-) > > I have attached the patch which I would like to happen. > > I only test lutyuv on 1080p input, seems the performance penalty is less > > than 5%. > > I would like also hear performance numbers from your environment. > > I am not sure do you like the patch? > > > > You should use function pointers. Will using function pointers to avoid runtime check is_16bits, Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] lavfi/lut: Add slice threading support
On Wed, May 29, 2019 at 4:19 PM Song, Ruiling wrote: > > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > > Of Jun Zhao > > Sent: Saturday, May 25, 2019 10:33 AM > > To: ffmpeg-devel@ffmpeg.org > > Cc: Jun Zhao > > Subject: [FFmpeg-devel] [PATCH V2] lavfi/lut: Add slice threading support > > > > V2: - update comments > > > > Jun Zhao (1): > > lavfi/lut: Add slice threading support > > > > libavfilter/vf_lut.c | 329 +-- > > --- > > 1 files changed, 216 insertions(+), 113 deletions(-) > I have attached the patch which I would like to happen. > I only test lutyuv on 1080p input, seems the performance penalty is less than > 5%. > I would like also hear performance numbers from your environment. > I am not sure do you like the patch? > > Ruiling > > Thanks the refine to avoid redundancy, will update after performance compare and other test. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] lavfi/lut: Add slice threading support
On 5/29/19, Song, Ruiling wrote: >> -Original Message- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Jun Zhao >> Sent: Saturday, May 25, 2019 10:33 AM >> To: ffmpeg-devel@ffmpeg.org >> Cc: Jun Zhao >> Subject: [FFmpeg-devel] [PATCH V2] lavfi/lut: Add slice threading support >> >> V2: - update comments >> >> Jun Zhao (1): >> lavfi/lut: Add slice threading support >> >> libavfilter/vf_lut.c | 329 +-- >> --- >> 1 files changed, 216 insertions(+), 113 deletions(-) > I have attached the patch which I would like to happen. > I only test lutyuv on 1080p input, seems the performance penalty is less > than 5%. > I would like also hear performance numbers from your environment. > I am not sure do you like the patch? > You should use function pointers. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2] lavfi/lut: Add slice threading support
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Jun Zhao > Sent: Saturday, May 25, 2019 10:33 AM > To: ffmpeg-devel@ffmpeg.org > Cc: Jun Zhao > Subject: [FFmpeg-devel] [PATCH V2] lavfi/lut: Add slice threading support > > V2: - update comments > > Jun Zhao (1): > lavfi/lut: Add slice threading support > > libavfilter/vf_lut.c | 329 +-- > --- > 1 files changed, 216 insertions(+), 113 deletions(-) I have attached the patch which I would like to happen. I only test lutyuv on 1080p input, seems the performance penalty is less than 5%. I would like also hear performance numbers from your environment. I am not sure do you like the patch? Ruiling > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". 0001-avoid-too-much-duplicate-code.patch Description: 0001-avoid-too-much-duplicate-code.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
