[FFmpeg-devel] [PATCH] ffmpeg.c: allow ffmpeg to output stats for each video stream
Make ffmpeg to output stats for each video/audio streams and each ouptut file
ffmpeg output log in print_report. The report of video/audio sizes is clear now
as previously all output video/audio sizes were combined to report and it is
unclear such stats is for one output files or aggregates for all output files.
Signed-off-by: Wang Cao
---
fftools/ffmpeg.c | 45 +++--
1 file changed, 31 insertions(+), 14 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index d4ac6903cc..1eaf344552 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1530,17 +1530,27 @@ static int reap_filters(int flush)
return 0;
}
-static void print_final_stats(int64_t total_size)
+static void print_final_stats()
{
uint64_t video_size = 0, audio_size = 0, extra_size = 0, other_size = 0;
uint64_t subtitle_size = 0;
uint64_t data_size = 0;
+int64_t total_size;
float percent = -1.0;
int i, j;
int pass1_used = 1;
+AVFormatContext *oc;
for (i = 0; i < nb_output_streams; i++) {
OutputStream *ost = output_streams[i];
+if (i > 0 && ost->file_index != output_streams[i-1]->file_index) {
+video_size = 0;
+audio_size = 0;
+extra_size = 0;
+other_size = 0;
+subtitle_size = 0;
+data_size = 0;
+}
switch (ost->enc_ctx->codec_type) {
case AVMEDIA_TYPE_VIDEO: video_size += ost->data_size; break;
case AVMEDIA_TYPE_AUDIO: audio_size += ost->data_size; break;
@@ -1552,7 +1562,13 @@ static void print_final_stats(int64_t total_size)
if ( (ost->enc_ctx->flags & (AV_CODEC_FLAG_PASS1 |
AV_CODEC_FLAG_PASS2))
!= AV_CODEC_FLAG_PASS1)
pass1_used = 0;
-}
+
+// Print stats for each output file.
+if (i == nb_output_streams-1 || ost->file_index !=
output_streams[i+1]->file_index) {
+oc = output_files[ost->file_index]->ctx;
+total_size = avio_size(oc->pb);
+if (total_size <= 0) // FIXME improve avio_size() so it works with
non seekable output too
+total_size = avio_tell(oc->pb);
if (data_size && total_size>0 && total_size >= data_size)
percent = 100.0 * (total_size - data_size) / data_size;
@@ -1568,6 +1584,8 @@ static void print_final_stats(int64_t total_size)
else
av_log(NULL, AV_LOG_INFO, "unknown");
av_log(NULL, AV_LOG_INFO, "\n");
+}
+}
/* print verbose per-stream stats */
for (i = 0; i < nb_input_files; i++) {
@@ -1680,13 +1698,6 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
t = (cur_time-timer_start) / 100.0;
-
-oc = output_files[0]->ctx;
-
-total_size = avio_size(oc->pb);
-if (total_size <= 0) // FIXME improve avio_size() so it works with non
seekable output too
-total_size = avio_tell(oc->pb);
-
vid = 0;
av_bprint_init(, 0, AV_BPRINT_SIZE_AUTOMATIC);
av_bprint_init(_script, 0, 1);
@@ -1697,12 +1708,13 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
if (!ost->stream_copy)
q = ost->quality / (float) FF_QP2LAMBDA;
-if (vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (is_last_report && vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
av_bprintf(, "q=%2.1f ", q);
av_bprintf(_script, "stream_%d_%d_q=%.1f\n",
ost->file_index, ost->index, q);
}
-if (!vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (is_last_report || !is_last_report && !vid) {
+if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
float fps;
frame_number = ost->frame_number;
@@ -1761,7 +1773,7 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
ost->st->time_base, AV_TIME_BASE_Q));
if (is_last_report)
nb_frames_drop += ost->last_dropped;
-}
+total_size = ost->data_size;
secs = FFABS(pts) / AV_TIME_BASE;
us = FFABS(pts) % AV_TIME_BASE;
@@ -1815,8 +1827,13 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
av_bprintf(_script, "speed=%4.3gx\n", speed);
}
+if (is_last_report)
+av_bprintf(, "\n");
+ }
+}
+
if (print_stats || is_last_report) {
-const char end = is_last_report ? '\n' : '\r';
+const char end = '\r';
if (print_stats==1 && AV_LOG_INFO > av_log_get_level()) {
fprintf(stderr, "%s%c", buf.str, end);
} else
@@ -1841,7 +1858,7 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
}
if (is_last_report)
-print_final_stats(total_size);
+print_final_stats();
}
static void
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vaapi: slice_vertical_position starts from zero for the second field
I may confirm that the error is returned from the old version of libva and vaapi driver w/wo this patch, the command below works well for me if using the new version of libva and vaapi driver. Thanks Haihao > Is your VAAPI library and VAAPI driver new enough? You need at least > libva-2.1.0 (VA-API version 1.1.0) and intel-vaapi-driver-2.1.0 for > interlaced VC-1 decoding. From the output, I think you are using an > older version and the error is just the libva library bailing out for > not supporting interlaced VC-1. > > > Regards, > Jerome > > > are these 2 patches enough or something else ? > > It feels like iam missing something but > > > > i tried > > ./ffmpeg -hwaccel vaapi -i SA10180.vc1 -pix_fmt yuv420p -f framecrc > > crcpatch12 > > > > but ffmpeg spews errors at me: > > > > ibva info: VA-API version 0.39.0 > > libva info: va_getDriverName() returns 0 > > libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so > > libva info: Found init function __vaDriverInit_0_39 > > libva info: va_openDriver() returns 0 > > Stream mapping: > > Stream #0:0 -> #0:0 (vc1 (native) -> rawvideo (native)) > > Press [q] to stop, [?] for help > > Output #0, framecrc, to 'crcpatch12': > > Metadata: > > encoder : Lavf58.17.100 > > Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x480 [SAR > > 1:1 DAR 3:2], q=2-31, 103680 kb/s, 25 fps, 25 tbn, 25 tbc > > Metadata: > > encoder : Lavc58.20.102 rawvideo > > [vc1 @ 0x3d430c0] Failed to end picture decode issue: 23 (unknown libva > > error / description missing). > > Error while decoding stream #0:0: Input/output error > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vaapi: slice_vertical_position starts from zero for the second field
Is your VAAPI library and VAAPI driver new enough? You need at least libva-2.1.0 (VA-API version 1.1.0) and intel-vaapi-driver-2.1.0 for interlaced VC-1 decoding. From the output, I think you are using an older version and the error is just the libva library bailing out for not supporting interlaced VC-1. Regards, Jerome > are these 2 patches enough or something else ? > It feels like iam missing something but > > i tried > ./ffmpeg -hwaccel vaapi -i SA10180.vc1 -pix_fmt yuv420p -f framecrc crcpatch12 > > but ffmpeg spews errors at me: > > ibva info: VA-API version 0.39.0 > libva info: va_getDriverName() returns 0 > libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so > libva info: Found init function __vaDriverInit_0_39 > libva info: va_openDriver() returns 0 > Stream mapping: > Stream #0:0 -> #0:0 (vc1 (native) -> rawvideo (native)) > Press [q] to stop, [?] for help > Output #0, framecrc, to 'crcpatch12': > Metadata: > encoder : Lavf58.17.100 > Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x480 [SAR > 1:1 DAR 3:2], q=2-31, 103680 kb/s, 25 fps, 25 tbn, 25 tbc > Metadata: > encoder : Lavc58.20.102 rawvideo > [vc1 @ 0x3d430c0] Failed to end picture decode issue: 23 (unknown libva error > / description missing). > Error while decoding stream #0:0: Input/output error ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 35/36] vaapi_encode_h265: Set level based on stream if not set by user
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> Sets the level based on the stream properties if it is not explicitly
> set by the user. Also add a tier option to set general_tier_flag, since
> that affects the level choice.
> ---
> doc/encoders.texi | 4
> libavcodec/vaapi_encode_h265.c | 34 +++---
> 2 files changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index ceddfdda64..d61a1cc4bc 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2659,6 +2659,10 @@ Include recovery points where appropriate
> (@emph{recovery_point} messages).
> @item aud
> Include access unit delimiters in the stream (not included by default).
>
> +@item tier
> +Set @emph{general_tier_flag}. This may affect the level chosen for the
> stream
> +if it is not explicitly specified.
> +
> @end table
>
> @item mjpeg_vaapi
> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> index 2cee19be68..100f8338d7 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -30,6 +30,7 @@
> #include "avcodec.h"
> #include "cbs.h"
> #include "cbs_h265.h"
> +#include "h265_profile_level.h"
> #include "hevc.h"
> #include "hevc_sei.h"
> #include "internal.h"
> @@ -48,6 +49,7 @@ typedef struct VAAPIEncodeH265Context {
> int qp;
> int aud;
> int profile;
> +int tier;
> int level;
> int sei;
>
> @@ -315,7 +317,7 @@ static int
> vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
> ptl->general_profile_space = 0;
> ptl->general_profile_space = 0;
> ptl->general_profile_idc = avctx->profile;
> -ptl->general_tier_flag = 0;
> +ptl->general_tier_flag = priv->tier;
>
> if (chroma_format == 1) {
> ptl->general_profile_compatibility_flag[1] = bit_depth == 8;
> @@ -340,7 +342,25 @@ static int
> vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
>
> ptl->general_lower_bit_rate_constraint_flag = 1;
>
> -ptl->general_level_idc = avctx->level;
> +if (avctx->level != FF_LEVEL_UNKNOWN) {
> +ptl->general_level_idc = avctx->level;
Fist check whether the level idc is legal? User may set a level which can not
be found in h265_levels.
> +} else {
> +const H265LevelDescriptor *level;
> +
> +level = ff_h265_guess_level(ptl, avctx->bit_rate,
> +ctx->surface_width, ctx->surface_height,
> +1, 1, 1, (ctx->b_per_p > 0) + 1);
> +if (level) {
> +av_log(avctx, AV_LOG_VERBOSE, "Using level %s.\n", level->name);
> +ptl->general_level_idc = level->level_idc;
> +} else {
> +av_log(avctx, AV_LOG_VERBOSE, "Stream will not conform to "
> + "any normal level; using level 8.5.\n");
> +ptl->general_level_idc = 255;
> +// The tier flag must be set in level 8.5.
> +ptl->general_tier_flag = 1;
> +}
> +}
>
> vps->vps_sub_layer_ordering_info_present_flag = 0;
> vps->vps_max_dec_pic_buffering_minus1[0] = (ctx->b_per_p > 0) + 1;
> @@ -1146,9 +1166,17 @@ static const AVOption vaapi_encode_h265_options[] = {
> { PROFILE("rext", FF_PROFILE_HEVC_REXT) },
> #undef PROFILE
>
> +{ "tier", "Set tier (general_tier_flag)",
> + OFFSET(tier), AV_OPT_TYPE_INT,
> + { .i64 = 0 }, 0, 1, FLAGS, "tier" },
> +{ "main", NULL, 0, AV_OPT_TYPE_CONST,
> + { .i64 = 0 }, 0, 0, FLAGS, "tier" },
> +{ "high", NULL, 0, AV_OPT_TYPE_CONST,
> + { .i64 = 1 }, 0, 0, FLAGS, "tier" },
> +
> { "level", "Set level (general_level_idc)",
>OFFSET(level), AV_OPT_TYPE_INT,
> - { .i64 = 153 }, 0x00, 0xff, FLAGS, "level" },
> + { .i64 = FF_LEVEL_UNKNOWN }, FF_LEVEL_UNKNOWN, 0xff, FLAGS, "level" },
>
> #define LEVEL(name, value) name, NULL, 0, AV_OPT_TYPE_CONST, \
>{ .i64 = value }, 0, 0, FLAGS, "level"
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 33/36] vaapi_encode_h265: Improve profile support
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> Set profile compatibility/constraint flags properly (including the
> constraint flags used for RExt profiles, as all streams we can currently
> generate are RExt-compatible), and use that to add support for the "Main
> Intra" and "Main 10 Intra" RExt subprofiles (for which we can re-use the
> existing Main and Main10 VAAPI profiles).
> ---
> libavcodec/Makefile| 2 +-
> libavcodec/vaapi_encode_h265.c | 71 +--
> ---
> 2 files changed, 57 insertions(+), 16 deletions(-)
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 079f546918..71b800c09d 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -371,7 +371,7 @@ OBJS-$(CONFIG_HEVC_QSV_DECODER)+= qsvdec_h2645.o
> OBJS-$(CONFIG_HEVC_QSV_ENCODER)+= qsvenc_hevc.o hevc_ps_enc.o \
>hevc_data.o
> OBJS-$(CONFIG_HEVC_RKMPP_DECODER) += rkmppdec.o
> -OBJS-$(CONFIG_HEVC_VAAPI_ENCODER) += vaapi_encode_h265.o
> +OBJS-$(CONFIG_HEVC_VAAPI_ENCODER) += h265_profile_level.o
> vaapi_encode_h265.o
> OBJS-$(CONFIG_HEVC_V4L2M2M_DECODER)+= v4l2_m2m_dec.o
> OBJS-$(CONFIG_HEVC_V4L2M2M_ENCODER)+= v4l2_m2m_enc.o
> OBJS-$(CONFIG_HNM4_VIDEO_DECODER) += hnm4video.o
> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> index 97bb9cef6c..2cee19be68 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -23,6 +23,7 @@
>
> #include "libavutil/avassert.h"
> #include "libavutil/common.h"
> +#include "libavutil/pixdesc.h"
> #include "libavutil/opt.h"
> #include "libavutil/mastering_display_metadata.h"
>
> @@ -260,9 +261,12 @@ static int
> vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
> H265RawVPS*vps = >raw_vps;
> H265RawSPS*sps = >raw_sps;
> H265RawPPS*pps = >raw_pps;
> +H265RawProfileTierLevel *ptl = >profile_tier_level;
> H265RawVUI*vui = >vui;
> VAEncSequenceParameterBufferHEVC *vseq = ctx->codec_sequence_params;
> VAEncPictureParameterBufferHEVC *vpic = ctx->codec_picture_params;
> +const AVPixFmtDescriptor *desc;
> +int chroma_format, bit_depth;
> int i;
>
> memset(>current_access_unit, 0,
> @@ -273,6 +277,25 @@ static int
> vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
> memset(pps, 0, sizeof(*pps));
>
>
> +desc = av_pix_fmt_desc_get(priv->common.input_frames->sw_format);
> +av_assert0(desc);
> +if (desc->nb_components == 1) {
> +chroma_format = 0;
> +} else {
> +if (desc->log2_chroma_w == 1 && desc->log2_chroma_h == 1) {
> +chroma_format = 1;
> +} else if (desc->log2_chroma_w == 1 && desc->log2_chroma_h == 0) {
> +chroma_format = 2;
> +} else if (desc->log2_chroma_w == 0 && desc->log2_chroma_h == 0) {
> +chroma_format = 3;
> +} else {
> +av_log(avctx, AV_LOG_ERROR, "Chroma format of input pixel format
> "
> + "%s is not supported.\n", desc->name);
> +}
> +}
> +bit_depth = desc->comp[0].depth;
> +
> +
> // VPS
>
> vps->nal_unit_header = (H265RawNALUnitHeader) {
> @@ -289,19 +312,35 @@ static int
> vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
> vps->vps_max_sub_layers_minus1 = 0;
> vps->vps_temporal_id_nesting_flag = 1;
>
> -vps->profile_tier_level = (H265RawProfileTierLevel) {
> -.general_profile_space = 0,
> -.general_profile_idc = avctx->profile,
> -.general_tier_flag = 0,
> +ptl->general_profile_space = 0;
> +ptl->general_profile_space = 0;
A duplicate line.
> +ptl->general_profile_idc = avctx->profile;
> +ptl->general_tier_flag = 0;
>
> -.general_progressive_source_flag= 1,
> -.general_interlaced_source_flag = 0,
> -.general_non_packed_constraint_flag = 1,
> -.general_frame_only_constraint_flag = 1,
> +if (chroma_format == 1) {
> +ptl->general_profile_compatibility_flag[1] = bit_depth == 8;
> +ptl->general_profile_compatibility_flag[2] = bit_depth <= 10;
> +}
> +ptl->general_profile_compatibility_flag[4] = 1;
>
> -.general_level_idc = avctx->level,
> -};
> -
> vps->profile_tier_level.general_profile_compatibility_flag[avctx->profile
> & 31] = 1;
> +ptl->general_progressive_source_flag= 1;
> +ptl->general_interlaced_source_flag = 0;
> +ptl->general_non_packed_constraint_flag = 1;
> +ptl->general_frame_only_constraint_flag = 1;
> +
> +ptl->general_max_12bit_constraint_flag = bit_depth <= 12;
> +ptl->general_max_10bit_constraint_flag = bit_depth <= 10;
> +ptl->general_max_8bit_constraint_flag = bit_depth == 8;
> +
> +
Re: [FFmpeg-devel] [PATCH v2 32/36] cbs_h264: Infer default VUI values if VUI parameters are not present
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> ---
> libavcodec/cbs_h264_syntax_template.c | 42
> +++
> 1 file changed, 42 insertions(+)
>
> diff --git a/libavcodec/cbs_h264_syntax_template.c
> b/libavcodec/cbs_h264_syntax_template.c
> index f53c02467e..03f2a15b0b 100644
> --- a/libavcodec/cbs_h264_syntax_template.c
> +++ b/libavcodec/cbs_h264_syntax_template.c
> @@ -211,6 +211,46 @@ static int FUNC(vui_parameters)(CodedBitstreamContext
> *ctx, RWContext *rw,
> return 0;
> }
>
> +static int FUNC(vui_parameters_default)(CodedBitstreamContext *ctx,
> +RWContext *rw, H264RawVUI *current,
> +H264RawSPS *sps)
> +{
> +infer(aspect_ratio_idc, 0);
> +
> +infer(video_format, 5);
> +infer(video_full_range_flag,0);
> +infer(colour_primaries, 2);
> +infer(transfer_characteristics, 2);
> +infer(matrix_coefficients, 2);
> +
> +infer(chroma_sample_loc_type_top_field,0);
> +infer(chroma_sample_loc_type_bottom_field, 0);
> +
> +infer(fixed_frame_rate_flag, 0);
> +infer(low_delay_hrd_flag,1);
> +
> +infer(pic_struct_present_flag, 0);
> +
> +infer(motion_vectors_over_pic_boundaries_flag, 1);
> +infer(max_bytes_per_pic_denom, 2);
> +infer(max_bits_per_mb_denom, 1);
> +infer(log2_max_mv_length_horizontal, 15);
> +infer(log2_max_mv_length_vertical, 15);
Both log2_max_mv_length_horizontal and log2_max_mv_length_vertical should be 16
> +
> +if ((sps->profile_idc == 44 || sps->profile_idc == 86 ||
> + sps->profile_idc == 100 || sps->profile_idc == 110 ||
> + sps->profile_idc == 122 || sps->profile_idc == 244) &&
> +sps->constraint_set3_flag) {
> +infer(max_num_reorder_frames, 0);
> +infer(max_dec_frame_buffering, 0);
> +} else {
> +infer(max_num_reorder_frames, H264_MAX_DPB_FRAMES);
> +infer(max_dec_frame_buffering, H264_MAX_DPB_FRAMES);
> +}
> +
> +return 0;
> +}
> +
> static int FUNC(sps)(CodedBitstreamContext *ctx, RWContext *rw,
> H264RawSPS *current)
> {
> @@ -315,6 +355,8 @@ static int FUNC(sps)(CodedBitstreamContext *ctx, RWContext
> *rw,
> flag(vui_parameters_present_flag);
> if (current->vui_parameters_present_flag)
> CHECK(FUNC(vui_parameters)(ctx, rw, >vui, current));
> +else
> +CHECK(FUNC(vui_parameters_default)(ctx, rw, >vui, current));
>
> CHECK(FUNC(rbsp_trailing_bits)(ctx, rw));
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavfilter/opencl.h: Add macro for setting opencl kernel
---
Hi!
I like your idea with OCL_FAIL_ON_ERR(), but still do not know which one is
better.
My idea relies on fact, that there are only few OpenCL functions which are used
multiple times in filters:
clSetKernelArg, clCreateKernel(in case when there are multiple kernels) and
maybe
clEnqueueNDRangeKernel. So that is why my purpose is totally wrap them and
significantly reduce code,
but yes, there are some restrictions, like you can not use kernel_arg++ when
setting kernel arguments.
And still most of cl-error checking statements appear after using cl-functions
listed above.
Thanks, Danil
libavfilter/opencl.h| 15 ++
libavfilter/vf_convolution_opencl.c | 43
libavfilter/vf_overlay_opencl.c | 44 +++-
libavfilter/vf_unsharp_opencl.c | 57 ++---
4 files changed, 46 insertions(+), 113 deletions(-)
diff --git a/libavfilter/opencl.h b/libavfilter/opencl.h
index c0a4519..7441b11 100644
--- a/libavfilter/opencl.h
+++ b/libavfilter/opencl.h
@@ -46,6 +46,21 @@ typedef struct OpenCLFilterContext {
intoutput_height;
} OpenCLFilterContext;
+
+/**
+ * set argument to specific Kernel.
+ * This macro relies on usage of local label "fail" and variables:
+ * avctx, cle and err.
+ */
+#define CL_SET_KERNEL_ARG(kernel, arg_num, type, arg) \
+cle = clSetKernelArg(kernel, arg_num, sizeof(type), arg); \
+if (cle != CL_SUCCESS) { \
+av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "\
+ "argument %d: error %d.\n", arg_num, cle); \
+err = AVERROR(EIO);\
+goto fail; \
+}
+
/**
* Return that all inputs and outputs support only AV_PIX_FMT_OPENCL.
*/
diff --git a/libavfilter/vf_convolution_opencl.c
b/libavfilter/vf_convolution_opencl.c
index 2df51e0..4d0ecf8 100644
--- a/libavfilter/vf_convolution_opencl.c
+++ b/libavfilter/vf_convolution_opencl.c
@@ -204,43 +204,12 @@ static int convolution_opencl_filter_frame(AVFilterLink
*inlink, AVFrame *input)
if (!dst)
break;
-cle = clSetKernelArg(ctx->kernel, 0, sizeof(cl_mem), );
-if (cle != CL_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "
- "destination image argument: %d.\n", cle);
-goto fail;
-}
-cle = clSetKernelArg(ctx->kernel, 1, sizeof(cl_mem), );
-if (cle != CL_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "
- "source image argument: %d.\n", cle);
-goto fail;
-}
-cle = clSetKernelArg(ctx->kernel, 2, sizeof(cl_int), >dims[p]);
-if (cle != CL_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "
- "matrix size argument: %d.\n", cle);
-goto fail;
-}
-cle = clSetKernelArg(ctx->kernel, 3, sizeof(cl_mem), >matrix[p]);
-if (cle != CL_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "
- "matrix argument: %d.\n", cle);
-goto fail;
-}
-cle = clSetKernelArg(ctx->kernel, 4, sizeof(cl_float), >rdivs[p]);
-if (cle != CL_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "
- "rdiv argument: %d.\n", cle);
-goto fail;
-}
-cle = clSetKernelArg(ctx->kernel, 5, sizeof(cl_float),
>biases[p]);
-if (cle != CL_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "
- "bias argument: %d.\n", cle);
-goto fail;
-}
-
+CL_SET_KERNEL_ARG(ctx->kernel, 0, cl_mem, );
+CL_SET_KERNEL_ARG(ctx->kernel, 1, cl_mem, );
+CL_SET_KERNEL_ARG(ctx->kernel, 2, cl_int, >dims[p]);
+CL_SET_KERNEL_ARG(ctx->kernel, 3, cl_mem, >matrix[p]);
+CL_SET_KERNEL_ARG(ctx->kernel, 4, cl_float, >rdivs[p]);
+CL_SET_KERNEL_ARG(ctx->kernel, 5, cl_float, >biases[p]);
err = ff_opencl_filter_work_size_from_image(avctx, global_work,
output, p, 0);
if (err < 0)
diff --git a/libavfilter/vf_overlay_opencl.c b/libavfilter/vf_overlay_opencl.c
index b43050d..556ce35 100644
--- a/libavfilter/vf_overlay_opencl.c
+++ b/libavfilter/vf_overlay_opencl.c
@@ -167,47 +167,39 @@ static int overlay_opencl_blend(FFFrameSync *fs)
kernel_arg = 0;
mem = (cl_mem)output->data[plane];
-cle = clSetKernelArg(ctx->kernel, kernel_arg++, sizeof(cl_mem), );
-if (cle != CL_SUCCESS)
-goto fail_kernel_arg;
+CL_SET_KERNEL_ARG(ctx->kernel, kernel_arg, cl_mem, );
+kernel_arg++;
mem = (cl_mem)input_main->data[plane];
-cle = clSetKernelArg(ctx->kernel, kernel_arg++, sizeof(cl_mem), );
-if (cle !=
Re: [FFmpeg-devel] [PATCH v2 30/36] cbs_h264: Fix range and default value of max mv lengths
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> The max and default values are 15, not 16.
I guessed you mixed both h264 and h265. The h264 doc i have specifies the range
for log2_max_mv_length_vertical/log2_max_mv_length_horizontal is [0, 16] and the
value of log2_max_mv_length_vertical/log2_max_mv_length_horizontal should be
inferred to 16 when log2_max_mv_length_vertical/log2_max_mv_length_horizontal is
not present.
> ---
> libavcodec/cbs_h264_syntax_template.c | 8
> libavcodec/vaapi_encode_h264.c| 4 ++--
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/cbs_h264_syntax_template.c
> b/libavcodec/cbs_h264_syntax_template.c
> index 027b555db6..21edcb799e 100644
> --- a/libavcodec/cbs_h264_syntax_template.c
> +++ b/libavcodec/cbs_h264_syntax_template.c
> @@ -185,16 +185,16 @@ static int FUNC(vui_parameters)(CodedBitstreamContext
> *ctx, RWContext *rw,
> flag(motion_vectors_over_pic_boundaries_flag);
> ue(max_bytes_per_pic_denom, 0, 16);
> ue(max_bits_per_mb_denom, 0, 16);
> -ue(log2_max_mv_length_horizontal, 0, 16);
> -ue(log2_max_mv_length_vertical, 0, 16);
> +ue(log2_max_mv_length_horizontal, 0, 15);
> +ue(log2_max_mv_length_vertical, 0, 15);
> ue(max_num_reorder_frames, 0, H264_MAX_DPB_FRAMES);
> ue(max_dec_frame_buffering, 0, H264_MAX_DPB_FRAMES);
> } else {
> infer(motion_vectors_over_pic_boundaries_flag, 1);
> infer(max_bytes_per_pic_denom, 2);
> infer(max_bits_per_mb_denom, 1);
> -infer(log2_max_mv_length_horizontal, 16);
> -infer(log2_max_mv_length_vertical, 16);
> +infer(log2_max_mv_length_horizontal, 15);
> +infer(log2_max_mv_length_vertical, 15);
>
> if ((sps->profile_idc == 44 || sps->profile_idc == 86 ||
> sps->profile_idc == 110 || sps->profile_idc == 110 ||
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index 4034053dc0..0d7780110c 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -491,8 +491,8 @@ static int
> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
>
> sps->vui.bitstream_restriction_flag= 1;
> sps->vui.motion_vectors_over_pic_boundaries_flag = 1;
> -sps->vui.log2_max_mv_length_horizontal = 16;
> -sps->vui.log2_max_mv_length_vertical = 16;
> +sps->vui.log2_max_mv_length_horizontal = 15;
> +sps->vui.log2_max_mv_length_vertical = 15;
> sps->vui.max_num_reorder_frames= (ctx->b_per_p > 0);
> sps->vui.max_dec_frame_buffering = sps->max_num_ref_frames;
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 29/36] h264_metadata: Add option to set the level of the stream
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> ---
> doc/bitstream_filters.texi | 9 +
> libavcodec/h264_metadata_bsf.c | 90
> ++
> 2 files changed, 99 insertions(+)
>
> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> index 7d7e97503a..d948c6d658 100644
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -215,6 +215,15 @@ insert the string ``hello'' associated with the given
> UUID.
> @item delete_filler
> Deletes both filler NAL units and filler SEI messages.
>
> +@item level
> +Set the level in the SPS. Refer to H.264 section A.3 and tables A-1
> +to A-5.
> +
> +The argument must be the name of a level (for example, @samp{4.2}), a
> +level_idc value (for example, @samp{42}), or the special name @samp{auto}
> +indicating that the filter should attempt to guess the level from the
> +input stream properties.
> +
> @end table
>
> @section h264_mp4toannexb
> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
> index 90ad4aad98..cb1a835fb8 100644
> --- a/libavcodec/h264_metadata_bsf.c
> +++ b/libavcodec/h264_metadata_bsf.c
> @@ -25,6 +25,7 @@
> #include "cbs.h"
> #include "cbs_h264.h"
> #include "h264.h"
> +#include "h264_levels.h"
> #include "h264_sei.h"
>
> enum {
> @@ -39,6 +40,11 @@ enum {
> FLIP_VERTICAL = 2,
> };
>
> +enum {
> +LEVEL_UNSET = -2,
> +LEVEL_AUTO = -1,
> +};
> +
> typedef struct H264MetadataContext {
> const AVClass *class;
>
> @@ -74,6 +80,8 @@ typedef struct H264MetadataContext {
> int display_orientation;
> double rotate;
> int flip;
> +
> +int level;
> } H264MetadataContext;
>
>
> @@ -208,6 +216,58 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
> CROP(bottom, crop_unit_y);
> #undef CROP
>
> +if (ctx->level != LEVEL_UNSET) {
> +int level_idc;
> +
> +if (ctx->level == LEVEL_AUTO) {
> +const H264LevelDescriptor *desc;
> +int64_t bit_rate;
> +int width, height;
> +
> +if (sps->vui.nal_hrd_parameters_present_flag) {
> +bit_rate = (sps-
> >vui.nal_hrd_parameters.bit_rate_value_minus1[0] + 1) *
> + (1 << (sps->vui.nal_hrd_parameters.bit_rate_scale + 6));
> +} else if (sps->vui.vcl_hrd_parameters_present_flag) {
> +bit_rate = (sps-
> >vui.vcl_hrd_parameters.bit_rate_value_minus1[0] + 1) *
> + (1 << (sps->vui.vcl_hrd_parameters.bit_rate_scale + 6));
> +// Adjust for VCL vs. NAL limits.
> +bit_rate = bit_rate * 6 / 5;
> +} else {
> +bit_rate = 0;
> +}
> +
> +width = 16 * (sps->pic_width_in_mbs_minus1 + 1);
> +height = 16 * (sps->pic_height_in_map_units_minus1 + 1) *
> +(2 - sps->frame_mbs_only_flag);
> +
> +desc = ff_h264_guess_level(sps->profile_idc, bit_rate,
> + width, height,
> + sps->vui.max_dec_frame_buffering);
> +if (desc) {
> +level_idc = desc->level_idc;
> +} else {
> +av_log(bsf, AV_LOG_WARNING, "Stream does not appear to "
> + "conform to any level: using level 6.2.\n");
> +level_idc = 62;
> +}
> +} else {
> +level_idc = ctx->level;
> +}
> +
> +if (level_idc == 9) {
> +if (sps->profile_idc == 66 ||
> +sps->profile_idc == 77 ||
> +sps->profile_idc == 88) {
> +sps->level_idc = 10;
> +sps->constraint_set3_flag = 1;
> +} else {
> +sps->level_idc = 9;
> +}
> +} else {
> +sps->level_idc = level_idc;
> +}
> +}
> +
> if (need_vui)
> sps->vui_parameters_present_flag = 1;
>
> @@ -683,6 +743,36 @@ static const AVOption h264_metadata_options[] = {
> 0, AV_OPT_TYPE_CONST,
> { .i64 = FLIP_VERTICAL }, .flags = FLAGS, .unit = "flip" },
>
> +{ "level", "Set level (table A-1)",
> +OFFSET(level), AV_OPT_TYPE_INT,
> +{ .i64 = LEVEL_UNSET }, LEVEL_UNSET, 0xff, FLAGS, "level" },
> +{ "auto", "Attempt to guess level from stream properties",
> +0, AV_OPT_TYPE_CONST,
> +{ .i64 = LEVEL_AUTO }, 0, 0, FLAGS, "level" },
Could you please use the same code style for AV_OPT_TYPE_CONST ?
> +#define LEVEL(name, value) name, NULL, 0, AV_OPT_TYPE_CONST, \
> +{ .i64 = value }, 0, 0, FLAGS, "level"
Also here.
> +{ LEVEL("1", 10) },
> +{ LEVEL("1b", 9) },
> +{ LEVEL("1.1", 11) },
> +{ LEVEL("1.2", 12) },
> +{ LEVEL("1.3", 13) },
> +{ LEVEL("2", 20) },
> +{ LEVEL("2.1", 21) },
> +{ LEVEL("2.2", 22) },
> +{ LEVEL("3", 30) },
> +{ LEVEL("3.1",
Re: [FFmpeg-devel] [PATCH] lavfi: add helper macro for OpenCL error handling.
On 12 June 2018 at 10:20, Ruiling Song wrote:
> Signed-off-by: Ruiling Song
> ---
> I am not sure whether do you think this would be useful?
> the main purpose is to make OpenCL error check code simpler.
> If we think this is good, I can go to replace current
> OpenCL filters to use this macro.
> for example:
> if (cle != CL_SUCCESS) {
> av_log(avctx, AV_LOG_ERROR, "Failed to enqueue kernel: %d.\n",
>cle);
> err = AVERROR(EIO);
> goto fail;
> }
> can be replaced with:
> OCL_FAIL_ON_ERR(avctx, cle, AVERROR(EIO), "Failed to enqueue kernel:
> %d.\n", cle);
>
> Thanks!
> Ruiling
> libavfilter/opencl.h | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/libavfilter/opencl.h b/libavfilter/opencl.h
> index c0a4519..c33df1c 100644
> --- a/libavfilter/opencl.h
> +++ b/libavfilter/opencl.h
> @@ -97,5 +97,16 @@ int ff_opencl_filter_work_size_from_image(AVFilterContext
> *avctx,
>size_t *work_size,
>AVFrame *frame, int plane,
>int block_alignment);
> +/**
> + * A helper macro to handle OpenCL error. It will assign errcode to
> + * variable err, log error msg, and jump to fail label on error.
> + */
> +#define OCL_FAIL_ON_ERR(logctx, cle, errcode, ...) do {\
> +if (cle != CL_SUCCESS) {\
> +av_log(logctx, AV_LOG_ERROR, __VA_ARGS__);\
> +err = errcode;\
> +goto fail;\
> +}\
> +} while(0)
>
> #endif /* AVFILTER_OPENCL_H */
> --
> 2.7.4
>
Hi!
I like your idea, but still don't know which one is better.
My idea relies on fact, that there are only few OpenCL functions which are
used multiple times in filters:
setKernelArg, clCreateKernel(in case when there are multiple kernels) and
maybe
clEnqueueNDRangeKernel. So that is why my purpose is totally wrap them and
significantly reduce code,
but yes, there are some restrictions, like you can't use kernel_arg++ when
setting kernel arguments.
And still most of cl-error checking statements appear after using
cl-functions listed above.
Thanks, Danil
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 28/36] vaapi_encode_h264: Set level based on stream if not set by user
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> ---
> libavcodec/vaapi_encode_h264.c | 34 ++
> 1 file changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index 82166d4457..4034053dc0 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -30,6 +30,7 @@
> #include "cbs.h"
> #include "cbs_h264.h"
> #include "h264.h"
> +#include "h264_levels.h"
> #include "h264_sei.h"
> #include "internal.h"
> #include "vaapi_encode.h"
> @@ -294,6 +295,7 @@ static int
> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
> H264RawPPS*pps = >raw_pps;
> VAEncSequenceParameterBufferH264 *vseq = ctx->codec_sequence_params;
> VAEncPictureParameterBufferH264 *vpic = ctx->codec_picture_params;
> +int dpb_frames;
>
> memset(>current_access_unit, 0,
> sizeof(priv->current_access_unit));
> @@ -319,7 +321,32 @@ static int
> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
> sps->constraint_set5_flag = ctx->b_per_p == 0;
> }
>
> -sps->level_idc = avctx->level;
> +if (ctx->gop_size == 1)
> +dpb_frames = 0;
> +else
> +dpb_frames = 1 + (ctx->b_per_p > 0);
> +
> +if (avctx->level != FF_LEVEL_UNKNOWN) {
> +sps->level_idc = avctx->level;
Is avctx->level always legal? if not, I think some checks on avctx->level should
be added.
> +} else {
> +const H264LevelDescriptor *level;
> +
> +level = ff_h264_guess_level(sps->profile_idc,
> +avctx->bit_rate,
> +priv->mb_width * 16,
> +priv->mb_height * 16,
> +dpb_frames);
> +if (level) {
> +av_log(avctx, AV_LOG_VERBOSE, "Using level %s.\n", level->name);
> +if (level->constraint_set3_flag)
> +sps->constraint_set3_flag = 1;
> +sps->level_idc = level->level_idc;
> +} else {
> +av_log(avctx, AV_LOG_WARNING, "Stream will not conform "
> + "to any level: using level 6.2.\n");
> +sps->level_idc = 62;
> +}
> +}
>
> sps->seq_parameter_set_id = 0;
> sps->chroma_format_idc= 1;
> @@ -329,8 +356,7 @@ static int
> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
> sps->log2_max_pic_order_cnt_lsb_minus4 =
> av_clip(av_log2(ctx->b_per_p + 1) - 2, 0, 12);
>
> -sps->max_num_ref_frames =
> -ctx->gop_size == 1 ? 0 : 1 + (ctx->b_per_p > 0);
> +sps->max_num_ref_frames = dpb_frames;
>
> sps->pic_width_in_mbs_minus1= priv->mb_width - 1;
> sps->pic_height_in_map_units_minus1 = priv->mb_height - 1;
> @@ -1005,7 +1031,7 @@ static const AVOption vaapi_encode_h264_options[] = {
>
> { "level", "Set level (level_idc)",
>OFFSET(level), AV_OPT_TYPE_INT,
> - { .i64 = 51 }, 0x00, 0xff, FLAGS, "level" },
> + { .i64 = FF_LEVEL_UNKNOWN }, FF_LEVEL_UNKNOWN, 0xff, FLAGS, "level" },
>
> #define LEVEL(name, value) name, NULL, 0, AV_OPT_TYPE_CONST, \
>{ .i64 = value }, 0, 0, FLAGS, "level"
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 25/36] vaapi_encode_mjpeg: Use CBS to store parameters and write headers
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> Also adds greyscale, 4:2:2, 4:4:4 and RGB support.
> ---
> configure | 2 +-
> doc/encoders.texi | 17 +-
> libavcodec/vaapi_encode_mjpeg.c | 529 +
> ---
> 3 files changed, 347 insertions(+), 201 deletions(-)
>
> diff --git a/configure b/configure
> index d908283954..cde32a8fad 100755
> --- a/configure
> +++ b/configure
> @@ -2939,7 +2939,7 @@ mjpeg_cuvid_decoder_deps="cuvid"
> mjpeg_qsv_encoder_deps="libmfx"
> mjpeg_qsv_encoder_select="qsvenc"
> mjpeg_vaapi_encoder_deps="VAEncPictureParameterBufferJPEG"
> -mjpeg_vaapi_encoder_select="vaapi_encode jpegtables"
> +mjpeg_vaapi_encoder_select="cbs_jpeg jpegtables vaapi_encode"
> mpeg1_cuvid_decoder_deps="cuvid"
> mpeg1_v4l2m2m_decoder_deps="v4l2_m2m mpeg1_v4l2_m2m"
> mpeg2_crystalhd_decoder_select="crystalhd"
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index b451142cfb..ceddfdda64 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2662,8 +2662,21 @@ Include access unit delimiters in the stream (not
> included by default).
> @end table
>
> @item mjpeg_vaapi
> -Always encodes using the standard quantisation and huffman tables -
> -@option{global_quality} scales the standard quantisation table (range 1-100).
> +Only baseline DCT encoding is supported. The encoder always uses the
> standard
> +quantisation and huffman tables - @option{global_quality} scales the standard
> +quantisation table (range 1-100).
> +
> +For YUV, 4:2:0, 4:2:2 and 4:4:4 subsampling modes are supported. RGB is also
> +supported, and will create an RGB JPEG.
> +
> +@table @option
> +@item jfif
> +Include JFIF header in each frame (not included by default).
> +@item huffman
> +Include standard huffman tables (on by default). Turning this off will save
> +a few hundred bytes in each output frame, but may lose compatibility with
> some
> +JPEG decoders which don't fully handle MJPEG.
> +@end table
>
> @item mpeg2_vaapi
> @option{profile} and @option{level} set the value of
> @emph{profile_and_level_indication}.
> diff --git a/libavcodec/vaapi_encode_mjpeg.c b/libavcodec/vaapi_encode_mjpeg.c
> index f76645425a..2f79070e58 100644
> --- a/libavcodec/vaapi_encode_mjpeg.c
> +++ b/libavcodec/vaapi_encode_mjpeg.c
> @@ -23,9 +23,12 @@
> #include "libavutil/common.h"
> #include "libavutil/internal.h"
> #include "libavutil/opt.h"
> -#include "libavutil/pixfmt.h"
> +#include "libavutil/pixdesc.h"
>
> #include "avcodec.h"
> +#include "bytestream.h"
> +#include "cbs.h"
> +#include "cbs_jpeg.h"
> #include "internal.h"
> #include "jpegtables.h"
> #include "mjpeg.h"
> @@ -58,253 +61,346 @@ static const unsigned char
> vaapi_encode_mjpeg_quant_chrominance[64] = {
> typedef struct VAAPIEncodeMJPEGContext {
> VAAPIEncodeContext common;
>
> +// User options.
> +int jfif;
> +int huffman;
> +
> +// Derived settings.
> int quality;
> -int component_subsample_h[3];
> -int component_subsample_v[3];
> +uint8_t jfif_data[14];
> +
> +// Writer structures.
> +JPEGRawFrameHeader frame_header;
> +JPEGRawScanscan;
> +JPEGRawApplicationData jfif_header;
> +JPEGRawQuantisationTableSpecification quant_tables;
> +JPEGRawHuffmanTableSpecification huffman_tables;
>
> -VAQMatrixBufferJPEG quant_tables;
> -VAHuffmanTableBufferJPEGBaseline huffman_tables;
> +CodedBitstreamContext *cbc;
> +CodedBitstreamFragment current_fragment;
> } VAAPIEncodeMJPEGContext;
>
> -static av_cold void vaapi_encode_mjpeg_copy_huffman(unsigned char
> *dst_lengths,
> -unsigned char
> *dst_values,
> -const unsigned char
> *src_lengths,
> -const unsigned char
> *src_values)
> +static int vaapi_encode_mjpeg_write_image_header(AVCodecContext *avctx,
> + VAAPIEncodePicture *pic,
> + VAAPIEncodeSlice *slice,
> + char *data, size_t
> *data_len)
> {
> -int i, mt;
> -
> -++src_lengths;
> +VAAPIEncodeMJPEGContext *priv = avctx->priv_data;
> +CodedBitstreamFragment *frag = >current_fragment;
> +int err;
> +
> +if (priv->jfif) {
> +err = ff_cbs_insert_unit_content(priv->cbc, frag, -1,
> + JPEG_MARKER_APPN + 0,
> + >jfif_header, NULL);
> +if (err < 0)
> +goto fail;
> +}
>
> -mt = 0;
> -for (i = 0; i < 16; i++)
> -mt += (dst_lengths[i] = src_lengths[i]);
> +err = ff_cbs_insert_unit_content(priv->cbc, frag, -1,
> + JPEG_MARKER_DQT,
> + >quant_tables, NULL);
> +
Re: [FFmpeg-devel] [PATCH] lavfi/atempo: raise max tempo limit (v2)
On 06/13/2018 07:39 AM, Pavel Koshevoy wrote:
On Thu, Jun 7, 2018 at 8:16 PM Pavel Koshevoy wrote:
---
doc/filters.texi| 17 ++---
libavfilter/af_atempo.c | 6 +++---
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 256ab42b00..6b98b04774 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1986,7 +1986,12 @@ Adjust audio tempo.
The filter accepts exactly one parameter, the audio tempo. If not
specified then the filter will assume nominal 1.0 tempo. Tempo must
-be in the [0.5, 2.0] range.
+be in the [0.5, 100.0] range.
+
+Note that tempo greater than 2 will skip some samples rather than
+blend them in. If for any reason this is a concern it is always
+possible to daisy-chain several instances of atempo to achieve the
+desired product tempo.
@subsection Examples
@@ -1998,9 +2003,15 @@ atempo=0.8
@end example
@item
-To speed up audio to 125% tempo:
+To speed up audio to 300% tempo:
+@example
+atempo=3
+@end example
+
+@item
+To speed up audio to 300% tempo by daisy-chaining two atempo instances:
@example
-atempo=1.25
+atempo=sqrt(3),atempo=sqrt(3)
@end example
@end itemize
diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index 8b214bccd7..52f15f2769 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -153,7 +153,7 @@ typedef struct ATempoContext {
static const AVOption atempo_options[] = {
{ "tempo", "set tempo scale factor",
- OFFSET(tempo), AV_OPT_TYPE_DOUBLE, { .dbl = 1.0 }, 0.5, 2.0,
+ OFFSET(tempo), AV_OPT_TYPE_DOUBLE, { .dbl = 1.0 }, 0.5, 100.0,
AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_FILTERING_PARAM },
{ NULL }
};
@@ -439,8 +439,8 @@ static int yae_load_data(ATempoContext *atempo,
return 0;
}
-// samples are not expected to be skipped:
-av_assert0(read_size <= atempo->ring);
+// samples are not expected to be skipped, unless tempo is greater than 2:
+av_assert0(read_size <= atempo->ring || atempo->tempo > 2.0);
while (atempo->position[0] < stop_here && src < src_end) {
int src_samples = (src_end - src) / atempo->stride;
--
2.16.4
Any objections if I apply this?
Pavel.
Applied, pushed
Pavel.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] New build system
2018-06-15 2:16 GMT+02:00, Martin Herkt : > FFmpeg’s build system is unique because despite its lack > of caching, one must sometimes make clean and > reconfigure everything when bisecting for bugs. Yes, this is unavoidable (make cannot know about new features without running configure). > Maybe depfile generation is buggy or someting. This is at least not a known issue (but see above). > In any case, it’s super annoying. How often do you bisect FFmpeg? I did it (at least) several hundred times over the last years, and it very rarely was a problem (if there was an issue, then because of the nature of the bug, see #3440 or #7058). > Then there’s the slowness That we should work on. > and make’s suboptimal job distribution on multi-core > systems How can I reproduce this? As said, building FFmpeg on a multi-core system (with very slow cores) is extremely fast. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 24/36] lavc/cbs: Add JPEG support
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> ---
> configure | 2 +
> libavcodec/Makefile | 1 +
> libavcodec/cbs.c | 6 +
> libavcodec/cbs_internal.h | 1 +
> libavcodec/cbs_jpeg.c | 513
> ++
> libavcodec/cbs_jpeg.h | 128 +
> libavcodec/cbs_jpeg_syntax_template.c | 191 +
> 7 files changed, 842 insertions(+)
> create mode 100644 libavcodec/cbs_jpeg.c
> create mode 100644 libavcodec/cbs_jpeg.h
> create mode 100644 libavcodec/cbs_jpeg_syntax_template.c
>
> diff --git a/configure b/configure
> index 790f55be14..d908283954 100755
> --- a/configure
> +++ b/configure
> @@ -2244,6 +2244,7 @@ CONFIG_EXTRA="
> cbs
> cbs_h264
> cbs_h265
> +cbs_jpeg
> cbs_mpeg2
> cbs_vp9
> dirac_parse
> @@ -2507,6 +2508,7 @@ threads_if_any="$THREADS_LIST"
> # subsystems
> cbs_h264_select="cbs golomb"
> cbs_h265_select="cbs golomb"
> +cbs_jpeg_select="cbs"
> cbs_mpeg2_select="cbs"
> cbs_vp9_select="cbs"
> dct_select="rdft"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 3ab071a039..2a1e0de110 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -64,6 +64,7 @@ OBJS-$(CONFIG_CABAC) += cabac.o
> OBJS-$(CONFIG_CBS) += cbs.o
> OBJS-$(CONFIG_CBS_H264)+= cbs_h2645.o h2645_parse.o
> OBJS-$(CONFIG_CBS_H265)+= cbs_h2645.o h2645_parse.o
> +OBJS-$(CONFIG_CBS_JPEG)+= cbs_jpeg.o
> OBJS-$(CONFIG_CBS_MPEG2) += cbs_mpeg2.o
> OBJS-$(CONFIG_CBS_VP9) += cbs_vp9.o
> OBJS-$(CONFIG_CRYSTALHD) += crystalhd.o
> diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
> index be6c043b58..bb3ce95971 100644
> --- a/libavcodec/cbs.c
> +++ b/libavcodec/cbs.c
> @@ -35,6 +35,9 @@ static const CodedBitstreamType *cbs_type_table[] = {
> #if CONFIG_CBS_H265
> _cbs_type_h265,
> #endif
> +#if CONFIG_CBS_JPEG
> +_cbs_type_jpeg,
> +#endif
> #if CONFIG_CBS_MPEG2
> _cbs_type_mpeg2,
> #endif
> @@ -50,6 +53,9 @@ const enum AVCodecID ff_cbs_all_codec_ids[] = {
> #if CONFIG_CBS_H265
> AV_CODEC_ID_H265,
> #endif
> +#if CONFIG_CBS_JPEG
> +AV_CODEC_ID_MJPEG,
> +#endif
> #if CONFIG_CBS_MPEG2
> AV_CODEC_ID_MPEG2VIDEO,
> #endif
> diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
> index 172b8a2515..e0e912e28e 100644
> --- a/libavcodec/cbs_internal.h
> +++ b/libavcodec/cbs_internal.h
> @@ -88,6 +88,7 @@ int ff_cbs_write_unsigned(CodedBitstreamContext *ctx,
> PutBitContext *pbc,
>
> extern const CodedBitstreamType ff_cbs_type_h264;
> extern const CodedBitstreamType ff_cbs_type_h265;
> +extern const CodedBitstreamType ff_cbs_type_jpeg;
> extern const CodedBitstreamType ff_cbs_type_mpeg2;
> extern const CodedBitstreamType ff_cbs_type_vp9;
>
> diff --git a/libavcodec/cbs_jpeg.c b/libavcodec/cbs_jpeg.c
> new file mode 100644
> index 00..365db73394
> --- /dev/null
> +++ b/libavcodec/cbs_jpeg.c
> @@ -0,0 +1,513 @@
> +/*
> + * 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
> + */
> +
> +#include "cbs.h"
> +#include "cbs_internal.h"
> +#include "cbs_jpeg.h"
> +
> +
> +#define HEADER(name) do { \
> +ff_cbs_trace_header(ctx, name); \
> +} while (0)
> +
> +#define CHECK(call) do { \
> +err = (call); \
> +if (err < 0) \
> +return err; \
> +} while (0)
> +
> +#define SUBSCRIPTS(subs, ...) (subs > 0 ? ((int[subs + 1]){ subs, __VA_ARGS__
> }) : NULL)
> +
> +#define u(width, name, range_min, range_max) \
> +xu(width, name, range_min, range_max, 0)
> +#define us(width, name, sub, range_min, range_max) \
> +xu(width, name, range_min, range_max, 1, sub)
> +
> +
> +#define READ
> +#define READWRITE read
> +#define RWContext GetBitContext
> +#define FUNC(name) cbs_jpeg_read_ ## name
> +
> +#define xu(width, name, range_min, range_max, subs, ...) do { \
> +uint32_t value = range_min; \
> +CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
> + SUBSCRIPTS(subs, __VA_ARGS__), \
> + ,
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vaapi: slice_vertical_position starts from zero for the second field
On Wed, May 09, 2018 at 07:50:23AM +0200, Jerome Borsboom wrote: > Contrary to VC-1 spec, VAAPI expects the row address of the first > macroblock row in the first slice to start from zero for the second > field in a field interlaced picture. > > Signed-off-by: Jerome Borsboom > --- > This patch set adds support for hardware decoding multi-slice field interlaced > pictures. With this patch set, the SA10180 test file decodes correctly with > VAAPI hardware acceleration. This was succesfully tested on Intel Haswell > platform. are these 2 patches enough or something else ? It feels like iam missing something but i tried ./ffmpeg -hwaccel vaapi -i SA10180.vc1 -pix_fmt yuv420p -f framecrc crcpatch12 but ffmpeg spews errors at me: ibva info: VA-API version 0.39.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_39 libva info: va_openDriver() returns 0 Stream mapping: Stream #0:0 -> #0:0 (vc1 (native) -> rawvideo (native)) Press [q] to stop, [?] for help Output #0, framecrc, to 'crcpatch12': Metadata: encoder : Lavf58.17.100 Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x480 [SAR 1:1 DAR 3:2], q=2-31, 103680 kb/s, 25 fps, 25 tbn, 25 tbc Metadata: encoder : Lavc58.20.102 rawvideo [vc1 @ 0x3d430c0] Failed to end picture decode issue: 23 (unknown libva error / description missing). Error while decoding stream #0:0: Input/output error [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] New build system
On Friday, June 15, 2018 12:45:53 AM CEST Jean-Baptiste Kempf wrote: > Hello, > > On Thu, 14 Jun 2018, at 18:03, Josh de Kock wrote: > > As such, I'd like to propose adopting a new build system to FFmpeg, > > namely Meson[1]. There has already been a fair amount of work (not by > > I think this is a great idea. > > Custom buildsystem are almost always wrong and/or broken. > Beside autotools (and sometimes CMake), everything is always broken on a > system or another. As an “outsider” who only (cross-)builds and packages FFmpeg, I concur. Except that CMake is always broken everywhere and under all circumstances unless you go out of your way to emulate sane behavior, at which point you have even more boilerplate than with custom Makefiles, and it still won’t work on anything you haven’t tested. Meson on the other hand is one of the very few build systems that actually care about packagers. FFmpeg’s build system is unique because despite its lack of caching, one must sometimes make clean and reconfigure everything when bisecting for bugs. Maybe depfile generation is buggy or someting. In any case, it’s super annoying. Then there’s the slowness and make’s suboptimal job distribution on multi-core systems and distributed builds. Not something I’d want to suffer during development. I think Meson is still a little immature in some places, but an effort should be made nonetheless. My experiences with it have been very positive, and the documentation had answers to all of my questions. It’s easy to figure out and there are few surprises, which is something I cannot say about shell scripts. Its codebase is also fairly lean compared to some of the alternatives and its developers seem open to changes, so all hope isn’t lost if there’s something fundamentally wrong with it. > And they don't want it to be turing-complete, which is great, and avoids > creating a monster. Some people might disagree with this and call it another CMake due to its custom language (which is as far from the truth as it gets), but it’s a good thing indeed. A mostly declarative build system which delegates complex tasks to external scripts with clear responsibilities (and provides some introspection) is much nicer to work with than a fat monolith with intermixed dependency testing, file template processing logic and stack machines. I think you should at least give it a try. signature.asc Description: This is a digitally signed message part. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: fix memory leak issue.
On Thu, Jun 14, 2018 at 9:44 PM Nicolas George wrote: > > Jun Zhao (2018-06-13): > > need to call av_bprint_finalize to free the memory source to match > > av_bprint_init. > > As you may have seen, in this case too, the buffer is never allocated > dynamically. > > The av_bprint_finalize() already present is thus useless (I think the > )mistake is mine), but not harmful either. > Yes, sometimes we didn't need to call av_bprint_finalize() because bprint just uses a fixed buffer (1024 - size of internal filed), but as my opinion, is it needed to recommend the caller call av_bprint_finalize() to prevent a potential memory leak if bprint using dynamically buffer and in fixed buffer case, call av_bprint_finalize() is not harmful too? Just a recommendation. > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/v4l2enc: add video4linux2 name alias
On Fri, Jun 15, 2018 at 5:56 AM Lou Logan wrote: > > On Thu, Jun 14, 2018, at 1:39 PM, Lou Logan wrote: > > Makes v4l2 indev name consistent with the v4l2 indev. > > Should say: > Makes v4l2 outdev name consistent with the v4l2 indev. > > I changed this locally before sending, but forgot to re-make the updated > patch. LGTM if fix the commit message. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/dpx: Reset n_datum for every line when decoding 12bit.
2018-06-13 14:24 GMT+02:00, Carl Eugen Hoyos : > Attached patch fixes decoding of two files (width 999) that Piotr > kindly provided, uploaded to > http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket5639/ Patch applied. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] New build system
2018-06-14 23:50 GMT+02:00, Rostislav Pehlivanov : > On 14 June 2018 at 19:56, Nicolas George wrote: > >> Josh de Kock (2018-06-14): >> > As such, I'd like to propose adopting a new build system to FFmpeg, >> namely >> > Meson[1]. >> >> I am very strongly against this. >> >> I loathe make and all it has to do with it, but really, for a project >> like this, it is the only viable option. The principles of make are >> already known by almost all potential Libre software developers, those >> in the project and those not yet. >> >> > No, it isn't. Maybe if you took a moment to look at the proposed branches > you'd notice NONE Of them remove ./configure. In fact that's precisely the > plan - to leave and still support the script for the forseeable future. > Hence your predjudice is unjustified. This simply adds support for a faster > build system to those who wish to use it. This sounds like a duplicate maintenance burden to me. Maybe the effort should go into accelerating our current script? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] New build system
Hello, On Thu, 14 Jun 2018, at 18:03, Josh de Kock wrote: > As such, I'd like to propose adopting a new build system to FFmpeg, > namely Meson[1]. There has already been a fair amount of work (not by I think this is a great idea. Custom buildsystem are almost always wrong and/or broken. Beside autotools (and sometimes CMake), everything is always broken on a system or another. The FFmpeg configure is an exception, because it's quite good; however it is far from being bug-free, in my experience. Showing those bugs in this configure got me some rages from old developers, which is why I usually don't mention them. It is also quite slow, notably the part where you have nothing shown for a long time, before getting any output. And sometimes you need to repeat over and over, in order to fix that. But it was not really worse than other solutions. However, meson is way better than autotools, and wayyy better than CMake. And I will also says that it is better than the configure. It's also done by people who understand what cross-compilation is, so that's a good point. And they don't want it to be turing-complete, which is great, and avoids creating a monster. So, +1 from me. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] New build system
On 6/15/18, James Almer wrote: > On 6/14/2018 7:10 PM, Paul B Mahol wrote: >> On 6/14/18, Nicolas George wrote: >>> Rostislav Pehlivanov (2018-06-14): No, it isn't. Maybe if you took a moment to look at the proposed branches you'd notice NONE Of them remove ./configure. In fact that's precisely the plan - to leave and still support the script for the forseeable future. Hence your predjudice is unjustified. This simply adds support for a faster build system to those who wish to use it. >>> >>> So, code duplication? Charybde rather than Scylla... >> >> Your opinions are worthless. > > And you're not adding anything to the discussion. > > Drop it already, you're being extremely aggravating these past months > for no reason whatsoever. I will not, simply because he likes to block everything he doesn't like or understands. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] New build system
On 6/14/2018 7:10 PM, Paul B Mahol wrote: > On 6/14/18, Nicolas George wrote: >> Rostislav Pehlivanov (2018-06-14): >>> No, it isn't. Maybe if you took a moment to look at the proposed branches >>> you'd notice NONE Of them remove ./configure. In fact that's precisely >>> the >>> plan - to leave and still support the script for the forseeable future. >>> Hence your predjudice is unjustified. This simply adds support for a >>> faster >>> build system to those who wish to use it. >> >> So, code duplication? Charybde rather than Scylla... > > Your opinions are worthless. And you're not adding anything to the discussion. Drop it already, you're being extremely aggravating these past months for no reason whatsoever. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] New build system
On 6/14/18, Nicolas George wrote: > Rostislav Pehlivanov (2018-06-14): >> No, it isn't. Maybe if you took a moment to look at the proposed branches >> you'd notice NONE Of them remove ./configure. In fact that's precisely >> the >> plan - to leave and still support the script for the forseeable future. >> Hence your predjudice is unjustified. This simply adds support for a >> faster >> build system to those who wish to use it. > > So, code duplication? Charybde rather than Scylla... Your opinions are worthless. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/v4l2enc: add video4linux2 name alias
On Thu, Jun 14, 2018, at 1:39 PM, Lou Logan wrote: > Makes v4l2 indev name consistent with the v4l2 indev. Should say: Makes v4l2 outdev name consistent with the v4l2 indev. I changed this locally before sending, but forgot to re-make the updated patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] New build system
Rostislav Pehlivanov (2018-06-14): > No, it isn't. Maybe if you took a moment to look at the proposed branches > you'd notice NONE Of them remove ./configure. In fact that's precisely the > plan - to leave and still support the script for the forseeable future. > Hence your predjudice is unjustified. This simply adds support for a faster > build system to those who wish to use it. So, code duplication? Charybde rather than Scylla... Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] New build system
On 14 June 2018 at 19:56, Nicolas George wrote: > Josh de Kock (2018-06-14): > > As such, I'd like to propose adopting a new build system to FFmpeg, > namely > > Meson[1]. > > I am very strongly against this. > > I loathe make and all it has to do with it, but really, for a project > like this, it is the only viable option. The principles of make are > already known by almost all potential Libre software developers, those > in the project and those not yet. > > No, it isn't. Maybe if you took a moment to look at the proposed branches you'd notice NONE Of them remove ./configure. In fact that's precisely the plan - to leave and still support the script for the forseeable future. Hence your predjudice is unjustified. This simply adds support for a faster build system to those who wish to use it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avdevice/v4l2enc: add video4linux2 name alias
Makes v4l2 indev name consistent with the v4l2 indev.
Signed-off-by: Lou Logan
---
libavdevice/v4l2enc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/v4l2enc.c b/libavdevice/v4l2enc.c
index 85200d0a36..1c36f81f90 100644
--- a/libavdevice/v4l2enc.c
+++ b/libavdevice/v4l2enc.c
@@ -106,7 +106,7 @@ static const AVClass v4l2_class = {
};
AVOutputFormat ff_v4l2_muxer = {
-.name = "v4l2",
+.name = "video4linux2,v4l2",
.long_name = NULL_IF_CONFIG_SMALL("Video4Linux2 output device"),
.priv_data_size = sizeof(V4L2Context),
.audio_codec= AV_CODEC_ID_NONE,
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Access RTCP QoS info trought AVFormatContext
I've created a thread in the Libav-user list asking if it was possible for an application to obtain the info of lost packets sent by RTCP during streams (http://ffmpeg.org/pipermail/libav-user/2018-June/011193.html). Carl answered me that this is not exposed by the external API, it is implemented only for internal use. I want my app to read this info to show a live status of the quality of the stream. As my application has access to the AVFormatContext, I figure that I can add a field to the AVFormatContext to store this data calculated in ff_rtp_check_and_send_back_rr ( https://www.ffmpeg.org/doxygen/3.0/rtpdec_8c_source.html#l00270). I would add something like: s->ic->expected_interval = expected_interval; s->ic->received_interval = received_interval; ...etc. (Or maybe an struct instead of several different fields) I am making this change to myself, but I would like to know: 1. Is there something inherently wrong with my approach? (Instead of using the AVFormatContext maybe I could use the AVIOContext. I don't know if this would make any difference) 2. Is there any chance a pull request like this will be accepted? Is there a change you would suggest to make this acceptable? (Considering all necessary documentation and such, of course) 3. Do you know any other way to achieve what I am trying to do? Thank you for your time. Vitor Vanacor ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/lagarith: Check that the range coded data stream is consistent when the probabilities indicate no data could have been coded.
Fixes: Timeout
Fixes:
8638/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LAGARITH_fuzzer-5132046098759680
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/lagarith.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/lagarith.c b/libavcodec/lagarith.c
index 0f4aa89486..ba2da2eeb2 100644
--- a/libavcodec/lagarith.c
+++ b/libavcodec/lagarith.c
@@ -141,6 +141,7 @@ static int lag_read_prob_header(lag_rac *rac, GetBitContext
*gb)
unsigned prob, cumulative_target;
unsigned cumul_prob = 0;
unsigned scaled_cumul_prob = 0;
+int nnz = 0;
rac->prob[0] = 0;
rac->prob[257] = UINT_MAX;
@@ -164,6 +165,8 @@ static int lag_read_prob_header(lag_rac *rac, GetBitContext
*gb)
prob = 256 - i;
for (j = 0; j < prob; j++)
rac->prob[++i] = 0;
+}else {
+nnz++;
}
}
@@ -172,6 +175,10 @@ static int lag_read_prob_header(lag_rac *rac,
GetBitContext *gb)
return -1;
}
+if (nnz == 1 && (show_bits_long(gb, 32) & 0xFF)) {
+return AVERROR_INVALIDDATA;
+}
+
/* Scale probabilities so cumulative probability is an even power of 2. */
scale_factor = av_log2(cumul_prob);
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 09/12] avformat/mxfdec: add support for clip wrapped essences
On Thu, 14 Jun 2018, Tomas Härdin wrote:
ons 2018-06-13 klockan 22:11 +0200 skrev Marton Balint:
On Wed, 13 Jun 2018, Tomas Härdin wrote:
> sön 2018-06-10 klockan 12:36 +0200 skrev Marton Balint:
> > Also use common code with opAtom.
> >
> > Fixes ticket #2776.
> > Partially fixes ticket #5671.
> > Fixes ticket #5866.
> >
> > > Signed-off-by: Marton Balint
> >
> > ---
> > libavformat/mxfdec.c | 281
---
> > 1 file changed, 130 insertions(+), 151 deletions(-)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> >
> > -next_ofs = mxf_set_current_edit_unit(mxf, klv.offset);
> > -
> > -if (next_ofs >= 0 && klv.next_klv > next_ofs) {
> > -/* if this check is hit then it's possible OPAtom was
treated as OP1a
> > - * truncate the packet since it's probably very large (>2
GiB is common) */
> > -avpriv_request_sample(s,
> > - "OPAtom misinterpreted as OP1a? "
> > - "KLV for edit unit %"PRId64" extending
into "
> > - "next edit unit",
> > - mxf->current_edit_unit);
> > -klv.length = next_ofs - avio_tell(s->pb);
> > +next_ofs = mxf_set_current_edit_unit(mxf, st, pos, 1);
> > +
> > +if (track->wrapping != FrameWrapped) {
> > +int64_t size;
> > +
> > +if (next_ofs <= 0) {
> > +// If we have no way to packetize the data, then
return it in chunks...
> > +int64_t max_packet_size = 33554432;
>
> Any reason for this particular number?
Not really, I chose 32 MB because it is big enough to not fragment typical
exotic files (e.g.: GOP wrapped, etc), but small enough so allocating
this much RAM in one packet does not cause any issues if we encounter a
huge KLV with some unknown (clip?) wrapping.
Perhaps add a #define MXF_MAX_CHUNK_SIZE (32 << 20) or so on the top of
the file
Sure.
To be frank, I am still not sure if this should actually work or not, or
if the parser system of libavformat can make something useful out of a
chunked source like this or not, I don't seem to have an MXF file which
triggers this.
There's no way to split it into edit units based on duration? Surely
outputing packets of size klv.length / duration should be fine? If
duration == 1 then surely the entire chunk should be read? It's easy
enough imagine DPX being wrapped inside MXF, and DPX frames can easily
be 50+ MiB. Take 8k raw 8-bit 4:4:4 video for example. 8192 x 4608 x 3
= 108 MiB. An error could be output if klv.size % duration != 0.
That is a good idea in general, but I think it is better if we implement
it in mxf_handle_missing_index_table_segment and generate a fake index
table segment with a constant edit unit byte count for clip wrapped
essences without a proper index.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 04/12] avformat/mxfdec: compute both essence_offset and essence_length in mxf_compute_essence_containers
On Thu, 14 Jun 2018, Tomas Härdin wrote:
[...]
> > +} else {
> > +int64_t op1a_essence_offset =
> > +p->this_partition +
> > +round_to_kag(p->pack_length, p->kag_size) +
> > +round_to_kag(p->header_byte_count, p->kag_size) +
> > +round_to_kag(p->index_byte_count, p->kag_size);
>
> Is this really always the case? I guess with OP1a it isn't a huge
> concern since the demuxer will find the next essence packet anyway. But
> still..
>
> I'm also fairly sure this is my code originally so.. :)
I think this tends to work well, if kag_size is not guessed. However, if
it _is_ guessed, then there might be problems, and having a 0 kagsize is
valid (only means an unknown KAG). So I am inclined to simply
use p->first_essence_klv.offset unconditionally, as you suggested in
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225629.html
Yes, past me seems to have the right idea :)
See the attached patch.
I think we should still parse kag_size even if we don't end up using it
for much. Especially since there's special cases for Sony files in
there. Did we have a sample for that? I forget.
fate-suite/mxf/C0023S01.mxf
Are there cases where we might not run across an essence KLV during
scanning but where there would be one anyway? I suspect not, not even
if we're reading an unseekable file
No, I don't think so either.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] New build system
On Thu, Jun 14, 2018 at 9:05 PM Nicolas George wrote: > > Hendrik Leppkes (2018-06-14): > > I don't mind make itself, for me its configure thats the real problem. > > Its extremely slow (we're talking minutes), for me often taking longer > > then the actual compilation (especially with ccache) - and that is > > really extremely painful. > > IIRC, a change from the fork that was merged in the last few months made > configure much much slower. It could bear investigating. > > Yet, the arguments for make apply to configure too: it is written in > standard shell script, not some newfangled system that only a few people > know. > And that exactly is the problem. Shell is horrible for this. It wants to be a real programming language but it just isn't. You could re-write configure in any actual language and so many of these problems would just be gone, and keep the remaining part of the build system as-is even. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] New build system
Hendrik Leppkes (2018-06-14): > I don't mind make itself, for me its configure thats the real problem. > Its extremely slow (we're talking minutes), for me often taking longer > then the actual compilation (especially with ccache) - and that is > really extremely painful. IIRC, a change from the fork that was merged in the last few months made configure much much slower. It could bear investigating. Yet, the arguments for make apply to configure too: it is written in standard shell script, not some newfangled system that only a few people know. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] New build system
On Thu, Jun 14, 2018 at 8:56 PM Nicolas George wrote: > > Josh de Kock (2018-06-14): > > As such, I'd like to propose adopting a new build system to FFmpeg, namely > > Meson[1]. > > I am very strongly against this. > > I loathe make and all it has to do with it, but really, for a project > like this, it is the only viable option. The principles of make are > already known by almost all potential Libre software developers, those > in the project and those not yet. > > Make is also a very mature system, with many interoperable > implementations; and although FFmpeg relies on a lot of extensions that > are specific to GNU make, these extensions themselves are very mature > and I think implemented in a few other versions. It is completely > different from using a very young project that has only a single > implementation and that still evolves so much that you did not manage to > use a released version. > > I don't mind make itself, for me its configure thats the real problem. Its extremely slow (we're talking minutes), for me often taking longer then the actual compilation (especially with ccache) - and that is really extremely painful. configure is also whats causing all those headaches, not make. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] New build system
Josh de Kock (2018-06-14): > As such, I'd like to propose adopting a new build system to FFmpeg, namely > Meson[1]. I am very strongly against this. I loathe make and all it has to do with it, but really, for a project like this, it is the only viable option. The principles of make are already known by almost all potential Libre software developers, those in the project and those not yet. Make is also a very mature system, with many interoperable implementations; and although FFmpeg relies on a lot of extensions that are specific to GNU make, these extensions themselves are very mature and I think implemented in a few other versions. It is completely different from using a very young project that has only a single implementation and that still evolves so much that you did not manage to use a released version. Add to that that this Meson comes from the GNOME / freedesktop crowd, who is not known for its attachment to durability and API stability. From where I stand, Meson is the new autotools; maybe in ten years we will be able to observe that it was really a progress compared to autotools. But in the meantime, there are reasons for FFmpeg to have avoided autotools like plague, and they apply to Meson the same. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Only set pkt->duration to non negative values
On Thu, Jun 14, 2018 at 09:13:19AM -0700, Sasi Inguva wrote: > looks good to me thx, will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavutil/encryption_info: Allow multiple init info.
On Thu, Jun 7, 2018 at 11:51 AM Jacob Trimble wrote: > > On Thu, May 31, 2018 at 5:50 PM Jacob Trimble wrote: > > > > On Thu, May 31, 2018 at 9:40 AM Jacob Trimble wrote: > > > > > > On Fri, May 25, 2018 at 6:13 PM Michael Niedermayer > > > wrote: > > > > > > > > [...] > > > > > > > > > Added fix for issue found by Chrome's ClusterFuzz > > > > > (http://crbug.com/846662). > > > > > > > > this belongs in a seperate patch unless its a bug specific to the code > > > > added > > > > with this patch > > > > > > > > > > Ok. Now this patch depends on > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2018-May/230782.html. > > > > > > > Noticed some bugs when integrating it. > > > > > > [...] > > > > > > > > -- > > > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > > > > > I have often repented speaking, but never of holding my tongue. > > > > -- Xenocrates > > > > ___ > > > > ffmpeg-devel mailing list > > > > ffmpeg-devel@ffmpeg.org > > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > Removed controversial NULL checks. This patch no longer depends on anything. Ping. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Only set pkt->duration to non negative values
looks good to me
On Wed, Jun 13, 2018 at 10:11 AM Michael Niedermayer
wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mov.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 5d9ffa69a3..0acf981aef 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -7586,7 +7586,9 @@ static int mov_read_packet(AVFormatContext *s,
> AVPacket *pkt)
> } else {
> int64_t next_dts = (sc->current_sample < st->nb_index_entries) ?
> st->index_entries[sc->current_sample].timestamp :
> st->duration;
> -pkt->duration = next_dts - pkt->dts;
> +
> +if (next_dts >= pkt->dts)
> +pkt->duration = next_dts - pkt->dts;
> pkt->pts = pkt->dts;
> }
> if (st->discard == AVDISCARD_ALL)
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC] New build system
Hi, The current build system is a rather large, and complex monolithic build system. The configure script takes a sizeable amount of time to execute, making improving, and modifying it a pain. It is completely written custom from scratch, while this may not sound terrible it definitely makes maintaining it more difficult than it needs to be (there have been 23 emails, or about 5% of the ML volume, regarding configure since the start of the month). As you all probably know, there are many issues with building on Windows, some include the configure script taking considerably longer than on other platforms. A new build system could solve most of these issues if done correctly, as well as having other added benefits. As such, I'd like to propose adopting a new build system to FFmpeg, namely Meson[1]. There has already been a fair amount of work (not by me) put into this, producing something which builds a fully working static configuration (configurable options are not implemented yet), on Linux, Windows and macOS[2]. If you would like to try it out, it currently requires Meson from master. VLC will also likely be switching to Meson, which is another reason to consider it. I remember JEEB and atomnuker potentially being interested in this, but unsure if they still are. What's working? - Working Windows support - Working Linux support - Working macOS support - Non-FATE tests What's left to do? - Assembler extensions (mmx etc..) - Porting the FATE test suite - Continue going over the configure script and importing various bits of logic - Exposing options, for now everything is automatically enabled - Compatibility ./configure shell script [1] https://github.com/mesonbuild/meson [2] https://github.com/MathieuDuponchelle/FFmpeg Any comments, and thoughts on a new build system would be much appreciated including concerns regarding it. -- Josh ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avcodec/videotoolboxenc: fix invalid session on iOS
Cf. comment. Restart the VT session when the APP goes from foreground to
background and vice versa.
---
libavcodec/videotoolboxenc.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 1060055ba5..ac847358ab 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -2175,8 +2175,27 @@ static int create_cv_pixel_buffer(AVCodecContext
*avctx,
#if TARGET_OS_IPHONE
pix_buf_pool = VTCompressionSessionGetPixelBufferPool(vtctx->session);
if (!pix_buf_pool) {
-av_log(avctx, AV_LOG_ERROR, "Could not get pixel buffer pool.\n");
-return AVERROR_EXTERNAL;
+/* On iOS, the VT session is invalidated when the APP switches from
+ * foreground to background and vice versa. Fetch the actual error code
+ * of the VT session to detect that case and restart the VT session
+ * accordingly. */
+OSStatus vtstatus;
+
+vtstatus = VTCompressionSessionPrepareToEncodeFrames(vtctx->session);
+if (vtstatus == kVTInvalidSessionErr) {
+CFRelease(vtctx->session);
+vtctx->session = NULL;
+status = vtenc_configure_encoder(avctx);
+if (status == 0)
+pix_buf_pool =
VTCompressionSessionGetPixelBufferPool(vtctx->session);
+}
+if (!pix_buf_pool) {
+av_log(avctx, AV_LOG_ERROR, "Could not get pixel buffer pool.\n");
+return AVERROR_EXTERNAL;
+}
+else
+av_log(avctx, AV_LOG_WARNING, "VT session restarted because of a "
+ "kVTInvalidSessionErr error.\n");
}
status = CVPixelBufferPoolCreatePixelBuffer(NULL,
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] avcodec/dirac_dwt_template: Fix undefined behavior in interleave()
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type
'int'
Fixes:
8697/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5197148130902016
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/dirac_dwt_template.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dirac_dwt_template.c b/libavcodec/dirac_dwt_template.c
index 8c25c1f822..528fc7e9e7 100644
--- a/libavcodec/dirac_dwt_template.c
+++ b/libavcodec/dirac_dwt_template.c
@@ -57,8 +57,8 @@ static av_always_inline void RENAME(interleave)(TYPE *dst,
TYPE *src0, TYPE *src
{
int i;
for (i = 0; i < w2; i++) {
-dst[2*i ] = (src0[i] + add) >> shift;
-dst[2*i+1] = (src1[i] + add) >> shift;
+dst[2*i ] = (src0[i] + (unsigned)add) >> shift;
+dst[2*i+1] = (src1[i] + (unsigned)add) >> shift;
}
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] avcodec/decode: Consider STRIDE_ALIGN in get_buffer_internal() when checking width
STRIDE_ALIGN is not known in libavutil so av_image_check_size* cannot consider
it
Fixes: OOM
Fixes:
8291/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5176528009691136
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 421a8f1a35..6a3a4df179 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1837,7 +1837,7 @@ static int get_buffer_internal(AVCodecContext *avctx,
AVFrame *frame, int flags)
int ret;
if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) {
-if ((ret = av_image_check_size2(avctx->width, avctx->height,
avctx->max_pixels, AV_PIX_FMT_NONE, 0, avctx)) < 0 || avctx->pix_fmt<0) {
+if ((ret = av_image_check_size2(FFALIGN(avctx->width, STRIDE_ALIGN),
avctx->height, avctx->max_pixels, AV_PIX_FMT_NONE, 0, avctx)) < 0 ||
avctx->pix_fmt<0) {
av_log(avctx, AV_LOG_ERROR, "video_get_buffer: image parameters
invalid\n");
return AVERROR(EINVAL);
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/4] avcodec/aacdec_fixed: Fix undefined integer overflow in apply_independent_coupling_fixed()
Fixes: signed integer overflow: 1195517 * 2048 cannot be represented in type
'int'
Fixes:
8636/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-4695836326887424
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/aacdec_fixed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/aacdec_fixed.c b/libavcodec/aacdec_fixed.c
index 167f5b68a1..1bdb93f5bc 100644
--- a/libavcodec/aacdec_fixed.c
+++ b/libavcodec/aacdec_fixed.c
@@ -436,7 +436,7 @@ static void apply_independent_coupling_fixed(AACContext *ac,
else {
for (i = 0; i < len; i++) {
tmp = (int)(((int64_t)src[i] * c + (int64_t)0x10) >> 37);
- dest[i] += tmp * (1 << shift);
+ dest[i] += tmp * (1U << shift);
}
}
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] avutil/common: Fix undefined behavior in av_clip_uintp2_c()
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an
unsigned type to negate this value to itself
Fixes:
8521/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5639024952737792
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavutil/common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/common.h b/libavutil/common.h
index 0fffa67714..8db0291170 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -228,7 +228,7 @@ static av_always_inline av_const int av_clip_intp2_c(int a,
int p)
*/
static av_always_inline av_const unsigned av_clip_uintp2_c(int a, int p)
{
-if (a & ~((1<> 31 & ((1<> 31 & ((1
Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: fix memory leak issue.
Jun Zhao (2018-06-13): > need to call av_bprint_finalize to free the memory source to match > av_bprint_init. As you may have seen, in this case too, the buffer is never allocated dynamically. The av_bprint_finalize() already present is thus useless (I think the mistake is mine), but not harmful either. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg.c: allow ffmpeg to output stats for each video stream - Make ffmpeg to output stats for each video/audio streams and each ouptut file ffmpeg output log in print_report. T
Signed-off-by: Wang Cao
---
fftools/ffmpeg.c | 45 +++--
1 file changed, 31 insertions(+), 14 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index d4ac6903cc..1eaf344552 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1530,17 +1530,27 @@ static int reap_filters(int flush)
return 0;
}
-static void print_final_stats(int64_t total_size)
+static void print_final_stats()
{
uint64_t video_size = 0, audio_size = 0, extra_size = 0, other_size = 0;
uint64_t subtitle_size = 0;
uint64_t data_size = 0;
+int64_t total_size;
float percent = -1.0;
int i, j;
int pass1_used = 1;
+AVFormatContext *oc;
for (i = 0; i < nb_output_streams; i++) {
OutputStream *ost = output_streams[i];
+if (i > 0 && ost->file_index != output_streams[i-1]->file_index) {
+video_size = 0;
+audio_size = 0;
+extra_size = 0;
+other_size = 0;
+subtitle_size = 0;
+data_size = 0;
+}
switch (ost->enc_ctx->codec_type) {
case AVMEDIA_TYPE_VIDEO: video_size += ost->data_size; break;
case AVMEDIA_TYPE_AUDIO: audio_size += ost->data_size; break;
@@ -1552,7 +1562,13 @@ static void print_final_stats(int64_t total_size)
if ( (ost->enc_ctx->flags & (AV_CODEC_FLAG_PASS1 |
AV_CODEC_FLAG_PASS2))
!= AV_CODEC_FLAG_PASS1)
pass1_used = 0;
-}
+
+// Print stats for each output file.
+if (i == nb_output_streams-1 || ost->file_index !=
output_streams[i+1]->file_index) {
+oc = output_files[ost->file_index]->ctx;
+total_size = avio_size(oc->pb);
+if (total_size <= 0) // FIXME improve avio_size() so it works with
non seekable output too
+total_size = avio_tell(oc->pb);
if (data_size && total_size>0 && total_size >= data_size)
percent = 100.0 * (total_size - data_size) / data_size;
@@ -1568,6 +1584,8 @@ static void print_final_stats(int64_t total_size)
else
av_log(NULL, AV_LOG_INFO, "unknown");
av_log(NULL, AV_LOG_INFO, "\n");
+}
+}
/* print verbose per-stream stats */
for (i = 0; i < nb_input_files; i++) {
@@ -1680,13 +1698,6 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
t = (cur_time-timer_start) / 100.0;
-
-oc = output_files[0]->ctx;
-
-total_size = avio_size(oc->pb);
-if (total_size <= 0) // FIXME improve avio_size() so it works with non
seekable output too
-total_size = avio_tell(oc->pb);
-
vid = 0;
av_bprint_init(, 0, AV_BPRINT_SIZE_AUTOMATIC);
av_bprint_init(_script, 0, 1);
@@ -1697,12 +1708,13 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
if (!ost->stream_copy)
q = ost->quality / (float) FF_QP2LAMBDA;
-if (vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (is_last_report && vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
av_bprintf(, "q=%2.1f ", q);
av_bprintf(_script, "stream_%d_%d_q=%.1f\n",
ost->file_index, ost->index, q);
}
-if (!vid && enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (is_last_report || !is_last_report && !vid) {
+if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
float fps;
frame_number = ost->frame_number;
@@ -1761,7 +1773,7 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
ost->st->time_base, AV_TIME_BASE_Q));
if (is_last_report)
nb_frames_drop += ost->last_dropped;
-}
+total_size = ost->data_size;
secs = FFABS(pts) / AV_TIME_BASE;
us = FFABS(pts) % AV_TIME_BASE;
@@ -1815,8 +1827,13 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
av_bprintf(_script, "speed=%4.3gx\n", speed);
}
+if (is_last_report)
+av_bprintf(, "\n");
+ }
+}
+
if (print_stats || is_last_report) {
-const char end = is_last_report ? '\n' : '\r';
+const char end = '\r';
if (print_stats==1 && AV_LOG_INFO > av_log_get_level()) {
fprintf(stderr, "%s%c", buf.str, end);
} else
@@ -1841,7 +1858,7 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
}
if (is_last_report)
-print_final_stats(total_size);
+print_final_stats();
}
static void ifilter_parameters_from_codecpar(InputFilter *ifilter,
AVCodecParameters *par)
--
2.18.0.rc1.242.g61856ae69a-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 04/12] avformat/mxfdec: compute both essence_offset and essence_length in mxf_compute_essence_containers
ons 2018-06-13 klockan 21:58 +0200 skrev Marton Balint:
>
> On Wed, 13 Jun 2018, Tomas Härdin wrote:
>
> > sön 2018-06-10 klockan 12:36 +0200 skrev Marton Balint:
> > > Also compute the correct essence_offset and essence_length for all clip
> > > wrapped
> > > essences.
> > >
> > > > Signed-off-by: Marton Balint
> > >
> > > ---
> > > libavformat/mxfdec.c | 108
> > > +++
> > > 1 file changed, 57 insertions(+), 51 deletions(-)
> > >
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > index 1ab34f4873..67b0028e88 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -98,6 +98,7 @@ typedef struct MXFPartition {
> > > int pack_length;
> > > int64_t pack_ofs; ///< absolute offset of pack in
> > > file, including run-in
> > > int64_t body_offset;
> > > +KLVPacket first_essence_klv;
> > > } MXFPartition;
> > >
> > > typedef struct MXFCryptoContext {
> > > @@ -2782,47 +2783,76 @@ static int
> > > mxf_parse_handle_partition_or_eof(MXFContext *mxf)
> > > return mxf->parsing_backward ? mxf_seek_to_previous_partition(mxf) :
> > > 1;
> > > }
> > >
> > > +static int64_t round_to_kag(int64_t position, int kag_size)
> > > +{
> > > +/* TODO: account for run-in? the spec isn't clear whether KAG should
> > > account for it */
> > > +/* NOTE: kag_size may be any integer between 1 - 2^10 */
> > > +int64_t ret = (position / kag_size) * kag_size;
> > > +return ret == position ? ret : ret + kag_size;
> >
> > This should probably just be
> >
> > return ((position + kag_size - 1) / kag_size) * kag_size;
> >
> > but maybe there's some fine point I'm overlooking. What happens if
> > kag_size is a smallish value like 16?
> >
> > A check for position > INT64_MAX - kag_size might also be appropriate.
>
> Well, this is your code as well :), I just moved it to avoid a forward
> declaration.
>
> >
> > > +}
> > > +
> > > +static MXFWrappingScheme mxf_get_wrapping_by_body_sid(AVFormatContext
> > > *s, int body_sid)
> > > +{
> > > +for (int i = 0; i < s->nb_streams; i++) {
> > > +MXFTrack *track = s->streams[i]->priv_data;
> > > +if (track && track->body_sid == body_sid && track->wrapping !=
> > > UnknownWrapped)
> > > +return track->wrapping;
> > > +}
> > > +return UnknownWrapped;
> > > +}
> > > +
> > > /**
> > > * Figures out the proper offset and length of the essence container in
> > > each partition
> > > */
> > > -static void mxf_compute_essence_containers(MXFContext *mxf)
> > > +static void mxf_compute_essence_containers(AVFormatContext *s)
> > > {
> > > +MXFContext *mxf = s->priv_data;
> > > int x;
> > >
> > > -/* everything is already correct */
> > > -if (mxf->op == OPAtom)
> > > -return;
> > > -
> > > for (x = 0; x < mxf->partitions_count; x++) {
> > > MXFPartition *p = >partitions[x];
> > > +MXFWrappingScheme wrapping;
> > >
> > > if (!p->body_sid)
> > > continue; /* BodySID == 0 -> no essence */
> > >
> > > -if (x >= mxf->partitions_count - 1)
> > > -break; /* FooterPartition - can't compute length
> > > (and we don't need to) */
> > > +/* for non clip-wrapped essences we compute essence_offset
> > > + * for clip wrapped essences we point essence_offset after the
> > > KL (usually klv.offset + 20 or 25)
> > > + */
> > >
> > > -/* essence container spans to the next partition */
> > > -p->essence_length = mxf->partitions[x+1].this_partition -
> > > p->essence_offset;
> > > +wrapping = (mxf->op == OPAtom) ? ClipWrapped :
> > > mxf_get_wrapping_by_body_sid(s, p->body_sid);
> > >
> > > -if (p->essence_length < 0) {
> > > -/* next ThisPartition < essence_offset */
> > > -p->essence_length = 0;
> > > -av_log(mxf->fc, AV_LOG_ERROR,
> > > - "partition %i: bad ThisPartition = %"PRIX64"\n",
> > > - x+1, mxf->partitions[x+1].this_partition);
> > > +if (wrapping == ClipWrapped) {
> > > +p->essence_offset = p->first_essence_klv.next_klv -
> > > p->first_essence_klv.length;
> > > +p->essence_length = p->first_essence_klv.length;
> >
> > Much nicer
> >
> > > +} else {
> > > +int64_t op1a_essence_offset =
> > > +p->this_partition +
> > > +round_to_kag(p->pack_length, p->kag_size) +
> > > +round_to_kag(p->header_byte_count, p->kag_size) +
> > > +round_to_kag(p->index_byte_count, p->kag_size);
> >
> > Is this really always the case? I guess with OP1a it isn't a huge
> > concern since the demuxer will find the next essence packet anyway. But
> > still..
> >
> > I'm also fairly sure this is my code originally so.. :)
>
> I think this tends to work well, if
Re: [FFmpeg-devel] [PATCH 08/12] avformat/mxfdec: add support for returning the partition for mxf_edit_unit_absolute_offset and mxf_absolute_bodysid_offset
ons 2018-06-13 klockan 22:16 +0200 skrev Marton Balint:
>
> On Wed, 13 Jun 2018, Tomas Härdin wrote:
>
> > sön 2018-06-10 klockan 12:36 +0200 skrev Marton Balint:
> > > > Signed-off-by: Marton Balint
> > >
> > > ---
> > > libavformat/mxfdec.c | 18 ++
> > > 1 file changed, 10 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > index 0f4cc9c3a3..8054e051cf 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -1399,7 +1399,7 @@ static int mxf_get_sorted_table_segments(MXFContext
> > > *mxf, int *nb_sorted_segment
> > > /**
> > > * Computes the absolute file offset of the given essence container
> > > offset
> > > */
> > > -static int mxf_absolute_bodysid_offset(MXFContext *mxf, int body_sid,
> > > int64_t offset, int64_t *offset_out)
> > > +static int mxf_absolute_bodysid_offset(MXFContext *mxf, int body_sid,
> > > int64_t offset, int64_t *offset_out, MXFPartition **partition_out)
> > > {
> > > MXFPartition *last_p = NULL;
> > > int a, b, m, m0;
> > > @@ -1427,6 +1427,8 @@ static int mxf_absolute_bodysid_offset(MXFContext
> > > *mxf, int body_sid, int64_t of
> > >
> > > if (last_p && (!last_p->essence_length || last_p->essence_length >
> > > (offset - last_p->body_offset))) {
> > > *offset_out = last_p->essence_offset + (offset -
> > > last_p->body_offset);
> > > +if (partition_out)
> > > +*partition_out = last_p;
> > > return 0;
> > > }
> > >
> > > @@ -1461,7 +1463,7 @@ static int64_t mxf_essence_container_end(MXFContext
> > > *mxf, int body_sid)
> > > }
> > >
> > > /* EditUnit -> absolute offset */
> > > -static int mxf_edit_unit_absolute_offset(MXFContext *mxf, MXFIndexTable
> > > *index_table, int64_t edit_unit, int64_t *edit_unit_out, int64_t
> > > *offset_out, int nag)
> > > +static int mxf_edit_unit_absolute_offset(MXFContext *mxf, MXFIndexTable
> > > *index_table, int64_t edit_unit, int64_t *edit_unit_out, int64_t
> > > *offset_out, MXFPartition **partition_out, int nag)
> >
> > Putting the pointer last would give a more readable patch, plus it's
> > nicer if all output vars are on the end (just a style preference)
>
> This is your code as well ;), "nag" was already the last, so it would be
> strange to put *partition_out after "nag", but have *offset_out before
> "nag".
Yeah. Whatever you feel like is fine
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 09/12] avformat/mxfdec: add support for clip wrapped essences
ons 2018-06-13 klockan 22:11 +0200 skrev Marton Balint:
>
> On Wed, 13 Jun 2018, Tomas Härdin wrote:
>
> > sön 2018-06-10 klockan 12:36 +0200 skrev Marton Balint:
> > > Also use common code with opAtom.
> > >
> > > Fixes ticket #2776.
> > > Partially fixes ticket #5671.
> > > Fixes ticket #5866.
> > >
> > > > Signed-off-by: Marton Balint
> > >
> > > ---
> > > libavformat/mxfdec.c | 281
> > > ---
> > > 1 file changed, 130 insertions(+), 151 deletions(-)
> > >
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > >
> > > -next_ofs = mxf_set_current_edit_unit(mxf, klv.offset);
> > > -
> > > -if (next_ofs >= 0 && klv.next_klv > next_ofs) {
> > > -/* if this check is hit then it's possible OPAtom was
> > > treated as OP1a
> > > - * truncate the packet since it's probably very large
> > > (>2 GiB is common) */
> > > -avpriv_request_sample(s,
> > > - "OPAtom misinterpreted as OP1a? "
> > > - "KLV for edit unit %"PRId64"
> > > extending into "
> > > - "next edit unit",
> > > - mxf->current_edit_unit);
> > > -klv.length = next_ofs - avio_tell(s->pb);
> > > +next_ofs = mxf_set_current_edit_unit(mxf, st, pos, 1);
> > > +
> > > +if (track->wrapping != FrameWrapped) {
> > > +int64_t size;
> > > +
> > > +if (next_ofs <= 0) {
> > > +// If we have no way to packetize the data, then
> > > return it in chunks...
> > > +int64_t max_packet_size = 33554432;
> >
> > Any reason for this particular number?
>
> Not really, I chose 32 MB because it is big enough to not fragment typical
> exotic files (e.g.: GOP wrapped, etc), but small enough so allocating
> this much RAM in one packet does not cause any issues if we encounter a
> huge KLV with some unknown (clip?) wrapping.
Perhaps add a #define MXF_MAX_CHUNK_SIZE (32 << 20) or so on the top of
the file
> To be frank, I am still not sure if this should actually work or not, or
> if the parser system of libavformat can make something useful out of a
> chunked source like this or not, I don't seem to have an MXF file which
> triggers this.
There's no way to split it into edit units based on duration? Surely
outputing packets of size klv.length / duration should be fine? If
duration == 1 then surely the entire chunk should be read? It's easy
enough imagine DPX being wrapped inside MXF, and DPX frames can easily
be 50+ MiB. Take 8k raw 8-bit 4:4:4 video for example. 8192 x 4608 x 3
= 108 MiB. An error could be output if klv.size % duration != 0.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize vp8 decoding in vp8dsp.
> > 2018-06-14 9:36 GMT+02:00, Shiyou Yin : > > From: gxw > > > > Optimize vp8 decoding with mmi in function: > > 1. ff_vp8_h_loop_filter8uv_mmi. > > 2. ff_vp8_v_loop_filter8uv_mmi. > > 3. ff_vp8_h_loop_filter16_mmi. > > 4. ff_vp8_v_loop_filter16_mmi. > > Please add some numbers about the speedup, overall and / or > function-wise. Ok,I will enrich the commit message.By the way, May I ask two questions. 1. what should I do after making some changes for the patch,Should I resent a new mail with 'git send-email' or what. 2. How should I know if my patch have passed the review process. > > > +#if 0 > > int i; > > > > for (i = 0; i < 8; i++) > > @@ -630,6 +876,73 @@ static av_always_inline void > > vp8_v_loop_filter8_mmi(uint8_t *dst, > > else > > filter_mbedge(dst + i * 1, stride); > > } > > +#else > > I suspect you maintain this code but unless there is a very > good reason, you should remove dead / replaced code, not > comment it out. > You are right, I will remove it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] qt-faststart - print errors to stderr
This patch makes qt-faststart output errors to stderr instead of stdout, following a discussion with Michael on another thread... Thanks! Eran 0001-qt-faststart-print-errors-to-stderr.patch Description: 0001-qt-faststart-print-errors-to-stderr.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: suppress code scan complain
2018-06-14 5:08 GMT+02:00, Li, Zhong :
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Carl Eugen Hoyos
>> Sent: Wednesday, June 13, 2018 6:11 PM
>> To: FFmpeg development discussions and patches
>>
>> Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: suppress code scan
>> complain
>>
>> 2018-06-13 12:05 GMT+02:00, Li, Zhong :
>> >> -Original Message-
>> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>> Behalf
>> >> Of Carl Eugen Hoyos
>> >> Sent: Wednesday, June 13, 2018 5:42 PM
>> >> To: FFmpeg development discussions and patches
>> >>
>> >> Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: suppress code scan
>> >> complain
>> >>
>> >> 2018-05-24 11:39 GMT+02:00, Li, Zhong :
>> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>> >> Behalf
>> >> >> Of Carl Eugen Hoyos
>> >> >> Sent: Thursday, May 24, 2018 5:33 PM
>> >> >> To: FFmpeg development discussions and patches
>> >> >>
>> >> >> Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: suppress code
>> >> >> scan complain
>> >> >>
>> >> >> 2018-05-24 10:35 GMT+02:00, Li, Zhong :
>> >> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org]
>> On
>> >> >> Behalf
>> >> >> >> Of Carl Eugen Hoyos
>> >> >> >> Sent: Wednesday, May 23, 2018 8:32 PM
>> >> >> >> To: FFmpeg development discussions and patches
>> >> >> >>
>> >> >> >> Subject: Re: [FFmpeg-devel] [PATCH v2] lavc/qsv: suppress code
>> >> >> >> scan complain
>> >> >> >>
>> >> >> >> 2018-05-23 12:46 GMT+02:00, Zhong Li :
>> >> >> >> > Suppress the complain "variables 'type' is used but maybe
>> >> >> >> > uninitialized".
>> >> >> >> > ---
>> >> >> >> > libavcodec/qsv.c | 5 -
>> >> >> >> > 1 file changed, 4 insertions(+), 1 deletion(-)
>> >> >> >> >
>> >> >> >> > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c index
>> >> >> >> > 45e1c25..3ff4f2c 100644
>> >> >> >> > --- a/libavcodec/qsv.c
>> >> >> >> > +++ b/libavcodec/qsv.c
>> >> >> >> > @@ -31,6 +31,7 @@
>> >> >> >> > #include "libavutil/hwcontext.h"
>> >> >> >> > #include "libavutil/hwcontext_qsv.h"
>> >> >> >> > #include "libavutil/imgutils.h"
>> >> >> >> > +#include "libavutil/avassert.h"
>> >> >> >> >
>> >> >> >> > #include "avcodec.h"
>> >> >> >> > #include "qsv_internal.h"
>> >> >> >> > @@ -197,7 +198,7 @@ int
>> >> ff_qsv_find_surface_idx(QSVFramesContext
>> >> >> >> *ctx,
>> >> >> >> > QSVFrame *frame)
>> >> >> >> >
>> >> >> >> > enum AVPictureType ff_qsv_map_pictype(int mfx_pic_type) {
>> >> >> >> > -enum AVPictureType type;
>> >> >> >> > +enum AVPictureType type = AV_PICTURE_TYPE_NONE;
>> >> >> >> > switch (mfx_pic_type & 0x7) {
>> >> >> >> > case MFX_FRAMETYPE_I:
>> >> >> >> > if (mfx_pic_type & MFX_FRAMETYPE_S) @@ -214,6
>> >> +215,8
>> >> >> >> @@ enum
>> >> >> >> > AVPictureType ff_qsv_map_pictype(int mfx_pic_type)
>> >> >> >> > else
>> >> >> >> > type = AV_PICTURE_TYPE_P;
>> >> >> >> > break;
>> >> >> >> > +default:
>> >> >> >> > +av_assert0(0);
>> >> >> >>
>> >> >> >> I didn't test but I would have expected that exactly one of
>> >> >> >> these changes is sufficient to silence the warning, no?
>> >> >> >
>> >> >> > Thanks for review. It is not a compile warning and just found by
>> >> >> > Coverity Scan, I've double-confirmed this patch is useful to
>> >> >> > suppress the code scan complain.
>> >> >>
>> >> >> Of course, I understand.
>> >> >>
>> >> >> My question was if one of the two changes (ie either the variable
>> >> >> initialization or the assert) isn't enough to suppress the code
>> >> >> scan complain.
>> >> >
>> >> > I've confirmed that, running scan again. The complain is
>> >> > disappeared now.
>> >>
>> >> Then why did you push both changes instead of only one of them?
>> >
>> > This one has been reviewed by you
>>
>> My two questions were:
>> Isn't it enough to only change the variable initialization (and change
>> nothing
>> in the switch) to silence the complain?
>> Isn't it enough to only add the default case to the switch (and change
>> nothing in the variable initialization) to silence the complain?
>>
>> You committed changing both the variable initialization and added a
>> default
>> case, one should have been enough.
>
> Ok, I misunderstood you doubted any one of these two changes can silence the
> complain.
> Yes, one is enough for the complain. (the first version of this patch is
> just to change the variable initialization. Mark suggested to add the
> assert() to check the input is valid).
> So maybe you would like to keep the assert() and remove the variable
> initialization?
That would have been my original suggestion, yes.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf/aviobuf: Raise Statistics verbosity to VERBOSE.
Hi! Attached patch makes debugging a little easier (ticket #7257, could somebody who knows the concat demuxer confirm that this is unavoidable - or isn't it? 33854 seeks with concat and five seeks with original file input, four seeks after remuxing the input file, no matter if file or concat input). Please comment, Carl Eugen From c36af7c223faf8195999efa1649bda71e777a85b Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Thu, 14 Jun 2018 11:21:31 +0200 Subject: [PATCH] lavf/aviobuf: Increase Statistics verbosity to AV_LOG_VERBOSE. --- libavformat/aviobuf.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c index e752d0e..5a33f82 100644 --- a/libavformat/aviobuf.c +++ b/libavformat/aviobuf.c @@ -1202,9 +1202,9 @@ int avio_close(AVIOContext *s) av_freep(>opaque); av_freep(>buffer); if (s->write_flag) -av_log(s, AV_LOG_DEBUG, "Statistics: %d seeks, %d writeouts\n", s->seek_count, s->writeout_count); +av_log(s, AV_LOG_VERBOSE, "Statistics: %d seeks, %d writeouts\n", s->seek_count, s->writeout_count); else -av_log(s, AV_LOG_DEBUG, "Statistics: %"PRId64" bytes read, %d seeks\n", s->bytes_read, s->seek_count); +av_log(s, AV_LOG_VERBOSE, "Statistics: %"PRId64" bytes read, %d seeks\n", s->bytes_read, s->seek_count); av_opt_free(s); avio_context_free(); -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize vp8 decoding in vp8dsp.
2018-06-14 9:36 GMT+02:00, Shiyou Yin : > From: gxw > > Optimize vp8 decoding with mmi in function: > 1. ff_vp8_h_loop_filter8uv_mmi. > 2. ff_vp8_v_loop_filter8uv_mmi. > 3. ff_vp8_h_loop_filter16_mmi. > 4. ff_vp8_v_loop_filter16_mmi. Please add some numbers about the speedup, overall and / or function-wise. > +#if 0 > int i; > > for (i = 0; i < 8; i++) > @@ -630,6 +876,73 @@ static av_always_inline void > vp8_v_loop_filter8_mmi(uint8_t *dst, > else > filter_mbedge(dst + i * 1, stride); > } > +#else I suspect you maintain this code but unless there is a very good reason, you should remove dead / replaced code, not comment it out. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize vp8 decoding in vp8dsp.
From: gxw Optimize vp8 decoding with mmi in function: 1. ff_vp8_h_loop_filter8uv_mmi. 2. ff_vp8_v_loop_filter8uv_mmi. 3. ff_vp8_h_loop_filter16_mmi. 4. ff_vp8_v_loop_filter16_mmi. Change-Id: Iba567c7ab4c6a284b5e8ccbc567575448a508350 Signed-off-by: gxw Signed-off-by: Shiyou Yin --- libavcodec/mips/vp8dsp_mmi.c | 408 +++ 1 file changed, 408 insertions(+) diff --git a/libavcodec/mips/vp8dsp_mmi.c b/libavcodec/mips/vp8dsp_mmi.c index f972628..7103d5d 100644 --- a/libavcodec/mips/vp8dsp_mmi.c +++ b/libavcodec/mips/vp8dsp_mmi.c @@ -25,6 +25,251 @@ #include "constants.h" #include "libavutil/mips/mmiutils.h" +#define DECLARE_DOUBLE_1double db_1 +#define DECLARE_DOUBLE_2double db_2 +#define DECLARE_UINT32_Tuint32_t it_1 +#define RESTRICT_ASM_DOUBLE_1 [db_1]"="(db_1) +#define RESTRICT_ASM_DOUBLE_2 [db_2]"="(db_2) +#define RESTRICT_ASM_UINT32_T [it_1]"="(it_1) + +#define MMI_PSRAB(src, size)\ +"li %[it_1],0x08\n\t" \ +"dmtc1 %[it_1],%[db_1] \n\t" \ +"psllh %[db_2],"#src", %[db_1] \n\t" \ +PTR_ADDU"%[it_1], "#size",%[it_1] \n\t" \ +"dmtc1 %[it_1],%[db_1] \n\t" \ +"psrah %[db_2],%[db_2],%[db_1] \n\t" \ +"psrah "#src", "#src", %[db_1] \n\t" \ +PTR_SUBU"%[it_1], %[it_1],"#size" \n\t" \ +"dmtc1 %[it_1],%[db_1] \n\t" \ +"psllh "#src", "#src", %[db_1] \n\t" \ +"xor%[db_1],%[db_1],%[db_1] \n\t" \ +"li %[it_1],0x00ff00ff \n\t" \ +"dmtc1 %[it_1],%[db_1] \n\t" \ +"punpcklwd %[db_1],%[db_1],%[db_1] \n\t" \ +"and%[db_2],%[db_2],%[db_1] \n\t" \ +"paddb "#src", "#src", %[db_2] \n\t" + +#define MMI_PSRLB(src, size)\ +"li %[it_1],0x08\n\t" \ +"dmtc1 %[it_1],%[db_1] \n\t" \ +"psllh %[db_2],"#src", %[db_1] \n\t" \ +PTR_ADDU"%[it_1], "#size",%[it_1] \n\t" \ +"dmtc1 %[it_1],%[db_1] \n\t" \ +"psrlh %[db_2],%[db_2],%[db_1] \n\t" \ +"psrlh "#src", "#src", %[db_1] \n\t" \ +PTR_SUBU"%[it_1], %[it_1],"#size" \n\t" \ +"dmtc1 %[it_1],%[db_1] \n\t" \ +"psllh "#src", "#src", %[db_1] \n\t" \ +"paddb "#src", "#src", %[db_2] \n\t" + +#define MMI_PCMPGTUB(dst, src1, src2) \ +"pcmpeqb%[db_1],"#src1","#src2" \n\t" \ +"pmaxub %[db_2],"#src1","#src2" \n\t" \ +"pcmpeqb%[db_2],%[db_2],"#src1" \n\t" \ +"xor"#dst", %[db_2],%[db_1] \n\t" + +#define MMI_BTOH(dst_l, dst_r, src) \ +"xor%[db_1],%[db_1],%[db_1] \n\t" \ +"pcmpgtb%[db_2],%[db_1],"#src" \n\t" \ +"punpcklbh "#dst_r", "#src", %[db_2] \n\t" \ +"punpckhbh "#dst_l", "#src", %[db_2] \n\t" + +#define MMI_TRANSPOSE8x8_UB_UB(src_0, src_1, src_2, src_3, \ + src_4, src_5, src_6, src_7, \ + dst_0, dst_1, dst_2, dst_3, \ + dst_4, dst_5, dst_6, dst_7) \ +"li %[it_1],0xe4\n\t" \ +"dmtc1 %[it_1],%[db_1] \n\t" \ +"pshufh %[db_2],"#src_0", %[db_1] \n\t" \ +"punpcklbh "#dst_0", "#src_0", "#src_1"\n\t" \ +"punpckhbh "#dst_1", %[db_2],"#src_1"\n\t" \ +"pshufh %[db_2],"#src_2", %[db_1] \n\t" \ +"punpcklbh "#dst_2", "#src_2", "#src_3"\n\t" \ +"punpckhbh "#dst_3", %[db_2],"#src_3"\n\t" \ +
Re: [FFmpeg-devel] [PATCH v2 16/36] vaapi_encode: Clean up rate control configuration
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Xiang, Haihao
> Sent: Thursday, June 14, 2018 2:08 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 16/36] vaapi_encode: Clean up rate
> control configuration
>
> On Wed, 2018-06-13 at 23:42 +0100, Mark Thompson wrote:
> > On 13/06/18 08:03, Xiang, Haihao wrote:
> > > On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> > > > Query which modes are supported and select between VBR and CBR
> > > > based on that - this removes all of the codec-specific rate
> > > > control mode selection code.
> > > > ---
> > > > doc/encoders.texi | 2 -
> > > > libavcodec/vaapi_encode.c | 173
> ---
> > > >
> > > > -
> > > > libavcodec/vaapi_encode.h | 6 +-
> > > > libavcodec/vaapi_encode_h264.c | 18 +
> > > > libavcodec/vaapi_encode_h265.c | 14 +---
> > > > libavcodec/vaapi_encode_mjpeg.c | 3 +-
> > > > libavcodec/vaapi_encode_mpeg2.c | 9 +--
> > > > libavcodec/vaapi_encode_vp8.c | 13 +--
> > > > libavcodec/vaapi_encode_vp9.c | 13 +--
> > > > 9 files changed, 137 insertions(+), 114 deletions(-)
> > > >
> > > > ...
> > > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > > > index f4c063734c..5de5483454 100644
> > > > --- a/libavcodec/vaapi_encode.c
> > > > +++ b/libavcodec/vaapi_encode.c
> > > > ...
> > > > @@ -1313,44 +1286,144 @@ static av_cold int
> > > > vaapi_encode_config_attributes(AVCodecContext *avctx) static
> > > > av_cold int vaapi_encode_init_rate_control(AVCodecContext *avctx)
> > > > {
> > > > VAAPIEncodeContext *ctx = avctx->priv_data;
> > > > -int rc_bits_per_second;
> > > > -int rc_target_percentage;
> > > > -int rc_window_size;
> > > > -int hrd_buffer_size;
> > > > -int hrd_initial_buffer_fullness;
> > > > +int64_t rc_bits_per_second;
> > > > +int rc_target_percentage;
> > > > +int rc_window_size;
> > > > +int64_t hrd_buffer_size;
> > > > +int64_t hrd_initial_buffer_fullness;
> > > > int fr_num, fr_den;
> > > > +VAConfigAttrib rc_attr = { VAConfigAttribRateControl };
> > > > +VAStatus vas;
> > > > +
> > > > +vas = vaGetConfigAttributes(ctx->hwctx->display,
> > > > +ctx->va_profile,
> ctx->va_entrypoint,
> > > > +_attr, 1);
> > > > +if (vas != VA_STATUS_SUCCESS) {
> > > > +av_log(avctx, AV_LOG_ERROR, "Failed to query rate control
> "
> > > > + "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
> > > > +return AVERROR_EXTERNAL;
> > > > +}
> > > >
> > > > -if (avctx->bit_rate > INT32_MAX) {
> > > > -av_log(avctx, AV_LOG_ERROR, "Target bitrate of 2^31 bps
> or "
> > > > - "higher is not supported.\n");
> > > > +if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> > > > +av_log(avctx, AV_LOG_VERBOSE, "Driver does not report
> any "
> > > > + "supported rate control modes: assuming constant-
> > > > quality.\n");
> > >
> > > How about logging it as warning message?
> >
> > What would a user do about it?
> >
>
> User may know what is not supported in the driver and he/she might get
> wrong result, he/she may file an issue to the driver.
>
> > (Note that it gets logged for JPEG encoding on all versions of the
> > i965 driver except the most recent, so if it were a warning it would
> > be seen by everyone using those versions.)
> >
> > > > +ctx->va_rc_mode = VA_RC_CQP;
> > > > +return 0;
> > > > +}
> > > > +if (avctx->flags & AV_CODEC_FLAG_QSCALE ||
> > > > +avctx->bit_rate <= 0) {
> > > > +if (rc_attr.value & VA_RC_CQP) {
> > > > +av_log(avctx, AV_LOG_VERBOSE, "Using
> constant-quality
> > > > mode.\n");
> > > > +ctx->va_rc_mode = VA_RC_CQP;
> > > > +return 0;
> > > > +} else {
> > > > +av_log(avctx, AV_LOG_ERROR, "Driver does not
> support "
> > > > + "constant-quality mode (%#x).\n",
> rc_attr.value);
> > > > +return AVERROR(EINVAL);
> > > > +}
> > > > +}
> > > > +
> > > > +if (!(rc_attr.value & (VA_RC_CBR | VA_RC_VBR))) {
> > > > +av_log(avctx, AV_LOG_ERROR, "Driver does not support any
> "
> > > > + "bitrate-targetted rate control modes.\n");
> > > > return AVERROR(EINVAL);
> > > > }
> > > >
> > > > if (avctx->rc_buffer_size)
> > > > hrd_buffer_size = avctx->rc_buffer_size;
> > > > +else if (avctx->rc_max_rate > 0)
> > > > +hrd_buffer_size = avctx->rc_max_rate;
> > > > else
> > > > hrd_buffer_size = avctx->bit_rate;
> > > > -if (avctx->rc_initial_buffer_occupancy)
> > > > +if (avctx->rc_initial_buffer_occupancy) {
> > > > +if (avctx->rc_initial_buffer_occupancy > hrd_buffer_size) {
> > > > +
[FFmpeg-devel] [PATCH 7/7] avcodec/mips: [loongson] reoptimize put pixels with mmi v2.
Reoptimize following functions with mmi:
1. ff_put_pixels4_8_mmi.
2. ff_put_pixels8_8_mmi.
3. ff_put_pixels16_8_mmi.
4. ff_add_pixels_clamped_mmi.
Change-Id: I80bf76b4d8d79c32c6c1913fe80fd5a828e937f1
Signed-off-by: Shiyou Yin
---
libavcodec/mips/hpeldsp_mmi.c | 133 +++---
libavcodec/mips/idctdsp_mmi.c | 71 +-
2 files changed, 89 insertions(+), 115 deletions(-)
diff --git a/libavcodec/mips/hpeldsp_mmi.c b/libavcodec/mips/hpeldsp_mmi.c
index 1bba70e..3272367 100644
--- a/libavcodec/mips/hpeldsp_mmi.c
+++ b/libavcodec/mips/hpeldsp_mmi.c
@@ -29,36 +29,32 @@
void ff_put_pixels4_8_mmi(uint8_t *block, const uint8_t *pixels,
ptrdiff_t line_size, int h)
{
-double ftmp[2];
-mips_reg addr[2];
DECLARE_VAR_LOW32;
-DECLARE_VAR_ADDRT;
__asm__ volatile (
-PTR_ADDU "%[addr1], %[line_size], %[line_size]\n\t"
"1: \n\t"
-PTR_ADDU "%[addr0], %[pixels], %[line_size]\n\t"
-MMI_ULWC1(%[ftmp0], %[pixels], 0x00)
-MMI_ULWC1(%[ftmp1], %[addr0], 0x00)
-MMI_SWC1(%[ftmp0], %[block], 0x00)
-MMI_SWXC1(%[ftmp1], %[block], %[line_size], 0x00)
-PTR_ADDU "%[pixels], %[pixels], %[addr1]\n\t"
-PTR_ADDU "%[block], %[block], %[addr1]\n\t"
-
-PTR_ADDU "%[addr0], %[pixels], %[line_size]\n\t"
-MMI_ULWC1(%[ftmp0], %[pixels], 0x00)
-MMI_ULWC1(%[ftmp1], %[addr0], 0x00)
-MMI_SWC1(%[ftmp0], %[block], 0x00)
-MMI_SWXC1(%[ftmp1], %[block], %[line_size], 0x00)
-PTR_ADDU "%[pixels], %[pixels], %[addr1]\n\t"
-PTR_ADDU "%[block], %[block], %[addr1]\n\t"
+MMI_ULWC1($f0, %[pixels], 0x00)
+PTR_ADDU "%[pixels], %[pixels], %[line_size] \n\t"
+MMI_ULWC1($f1, %[pixels], 0x00)
+PTR_ADDU "%[pixels], %[pixels], %[line_size] \n\t"
+MMI_ULWC1($f2, %[pixels], 0x00)
+PTR_ADDU "%[pixels], %[pixels], %[line_size] \n\t"
+MMI_ULWC1($f3, %[pixels], 0x00)
+PTR_ADDU "%[pixels], %[pixels], %[line_size] \n\t"
PTR_ADDI "%[h], %[h], -0x04 \n\t"
+
+MMI_SWC1($f0, %[block], 0x00)
+PTR_ADDU "%[block], %[block], %[line_size]\n\t"
+MMI_SWC1($f1, %[block], 0x00)
+PTR_ADDU "%[block], %[block], %[line_size]\n\t"
+MMI_SWC1($f2, %[block], 0x00)
+PTR_ADDU "%[block], %[block], %[line_size]\n\t"
+MMI_SWC1($f3, %[block], 0x00)
+PTR_ADDU "%[block], %[block], %[line_size]\n\t"
+
"bnez %[h], 1b \n\t"
-: [ftmp0]"="(ftmp[0]),[ftmp1]"="(ftmp[1]),
- RESTRICT_ASM_LOW32
- RESTRICT_ASM_ADDRT
- [addr0]"="(addr[0]),[addr1]"="(addr[1]),
+: RESTRICT_ASM_LOW32
[block]"+"(block), [pixels]"+"(pixels),
[h]"+"(h)
: [line_size]"r"((mips_reg)line_size)
@@ -69,37 +65,32 @@ void ff_put_pixels4_8_mmi(uint8_t *block, const uint8_t
*pixels,
void ff_put_pixels8_8_mmi(uint8_t *block, const uint8_t *pixels,
ptrdiff_t line_size, int h)
{
-double ftmp[2];
-mips_reg addr[3];
DECLARE_VAR_ALL64;
__asm__ volatile (
-PTR_ADDU "%[addr1], %[line_size], %[line_size]\n\t"
"1: \n\t"
-MMI_ULDC1(%[ftmp0], %[pixels], 0x00)
-PTR_ADDU "%[addr0], %[pixels], %[line_size]\n\t"
-MMI_ULDC1(%[ftmp1], %[addr0], 0x00)
-MMI_SDC1(%[ftmp0], %[block], 0x00)
-PTR_ADDU "%[addr2], %[block], %[line_size]\n\t"
-MMI_SDC1(%[ftmp1], %[addr2], 0x00)
-PTR_ADDU "%[pixels], %[pixels], %[addr1]\n\t"
-PTR_ADDU "%[block], %[block], %[addr1]\n\t"
-
-MMI_ULDC1(%[ftmp0], %[pixels], 0x00)
-PTR_ADDU "%[addr0], %[pixels], %[line_size]\n\t"
-MMI_ULDC1(%[ftmp1], %[addr0], 0x00)
-MMI_SDC1(%[ftmp0], %[block], 0x00)
-PTR_ADDU "%[addr2], %[block], %[line_size]\n\t"
-MMI_SDC1(%[ftmp1], %[addr2], 0x00)
-PTR_ADDU "%[pixels], %[pixels], %[addr1]\n\t"
-PTR_ADDU "%[block], %[block], %[addr1]\n\t"
+MMI_ULDC1($f0, %[pixels], 0x00)
+PTR_ADDU "%[pixels], %[pixels], %[line_size] \n\t"
+MMI_ULDC1($f1, %[pixels], 0x00)
+PTR_ADDU "%[pixels], %[pixels], %[line_size]
[FFmpeg-devel] [PATCH 4/7] avcodec/mips: [loongson] optimize ff_put_pixels16_8 V2.
Remove useless variable addr.
Change-Id: I0e91e6052dc5b44da3c0825d965ecba3dd1c9595
Signed-off-by: Shiyou Yin
---
libavcodec/mips/hpeldsp_mmi.c | 43 ---
1 file changed, 20 insertions(+), 23 deletions(-)
diff --git a/libavcodec/mips/hpeldsp_mmi.c b/libavcodec/mips/hpeldsp_mmi.c
index 2dbef22..1bba70e 100644
--- a/libavcodec/mips/hpeldsp_mmi.c
+++ b/libavcodec/mips/hpeldsp_mmi.c
@@ -111,44 +111,41 @@ void ff_put_pixels16_8_mmi(uint8_t *block, const uint8_t
*pixels,
ptrdiff_t line_size, int h)
{
double ftmp[4];
-mips_reg addr[2];
DECLARE_VAR_ALL64;
-DECLARE_VAR_ADDRT;
__asm__ volatile (
-PTR_ADDU "%[addr1], %[line_size], %[line_size]\n\t"
-"1: \n\t"
-PTR_ADDU "%[addr0], %[pixels], %[line_size]\n\t"
+"1:\n\t"
MMI_ULDC1(%[ftmp0], %[pixels], 0x00)
MMI_ULDC1(%[ftmp2], %[pixels], 0x08)
-MMI_ULDC1(%[ftmp1], %[addr0], 0x00)
-MMI_ULDC1(%[ftmp3], %[addr0], 0x08)
+PTR_ADDU "%[pixels], %[pixels], %[line_size] \n\t"
+MMI_ULDC1(%[ftmp1], %[pixels], 0x00)
+MMI_ULDC1(%[ftmp3], %[pixels], 0x08)
MMI_SDC1(%[ftmp0], %[block], 0x00)
-MMI_SDXC1(%[ftmp1], %[block], %[line_size], 0x00)
MMI_SDC1(%[ftmp2], %[block], 0x08)
-MMI_SDXC1(%[ftmp3], %[block], %[line_size], 0x08)
-PTR_ADDU "%[pixels], %[pixels], %[addr1]\n\t"
-PTR_ADDU "%[block], %[block], %[addr1]\n\t"
+PTR_ADDU "%[block], %[block], %[line_size] \n\t"
+MMI_SDC1(%[ftmp1], %[block], 0x00)
+MMI_SDC1(%[ftmp3], %[block], 0x08)
+PTR_ADDU "%[pixels], %[pixels], %[line_size] \n\t"
+PTR_ADDU "%[block], %[block], %[line_size] \n\t"
-PTR_ADDU "%[addr0], %[pixels], %[line_size]\n\t"
MMI_ULDC1(%[ftmp0], %[pixels], 0x00)
MMI_ULDC1(%[ftmp2], %[pixels], 0x08)
-MMI_ULDC1(%[ftmp1], %[addr0], 0x00)
-MMI_ULDC1(%[ftmp3], %[addr0], 0x08)
+PTR_ADDU "%[pixels], %[pixels], %[line_size] \n\t"
+MMI_ULDC1(%[ftmp1], %[pixels], 0x00)
+MMI_ULDC1(%[ftmp3], %[pixels], 0x08)
MMI_SDC1(%[ftmp0], %[block], 0x00)
-MMI_SDXC1(%[ftmp1], %[block], %[line_size], 0x00)
MMI_SDC1(%[ftmp2], %[block], 0x08)
-MMI_SDXC1(%[ftmp3], %[block], %[line_size], 0x08)
-PTR_ADDU "%[pixels], %[pixels], %[addr1]\n\t"
-PTR_ADDU "%[block], %[block], %[addr1]\n\t"
-
-PTR_ADDI "%[h], %[h], -0x04 \n\t"
-"bnez %[h], 1b \n\t"
+PTR_ADDU "%[block], %[block], %[line_size] \n\t"
+MMI_SDC1(%[ftmp1], %[block], 0x00)
+MMI_SDC1(%[ftmp3], %[block], 0x08)
+PTR_ADDU "%[pixels], %[pixels], %[line_size] \n\t"
+PTR_ADDU "%[block], %[block], %[line_size] \n\t"
+
+PTR_ADDI "%[h], %[h], -0x04 \n\t"
+"bnez %[h], 1b \n\t"
: [ftmp0]"="(ftmp[0]),[ftmp1]"="(ftmp[1]),
[ftmp2]"="(ftmp[2]),[ftmp3]"="(ftmp[3]),
RESTRICT_ASM_ALL64
- RESTRICT_ASM_ADDRT
- [addr0]"="(addr[0]),[addr1]"="(addr[1]),
[block]"+"(block), [pixels]"+"(pixels),
[h]"+"(h)
: [line_size]"r"((mips_reg)line_size)
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/7] avcodec: [loongson] fix bug of mss2-wmv failed in fate test.
Failed case: mss2-wmv In ff_vc1_inv_trans series functions, pmullh instrunction was used to do the multiplication of 16 bits data. It will cause overflow problem. Change-Id: I9e37e9764d1858b9713be4cafd5c78bf75ee14f7 Signed-off-by: Shiyou Yin --- libavcodec/mips/vc1dsp_mmi.c | 1493 +++--- 1 file changed, 957 insertions(+), 536 deletions(-) diff --git a/libavcodec/mips/vc1dsp_mmi.c b/libavcodec/mips/vc1dsp_mmi.c index 01e7f9f..4840c01 100644 --- a/libavcodec/mips/vc1dsp_mmi.c +++ b/libavcodec/mips/vc1dsp_mmi.c @@ -27,118 +27,99 @@ #include "hpeldsp_mips.h" #include "libavutil/mips/mmiutils.h" - -#define VC1_INV_TRANCS_8_STEP1_MMI(fp1, fp2, fp3, fp4,\ - o1,o2,o3,o4, \ - t1,t2,t3,t4, \ - ff_p1, ff_p2, ff_p3, ff_p4) \ -"pmullh "#t1" , "#fp1" , "#ff_p1"\n\t" \ -"pmullh "#t2" , "#fp2" , "#ff_p2"\n\t" \ -"pmullh "#t3" , "#fp3" , "#ff_p3"\n\t" \ -"pmullh "#t4" , "#fp4" , "#ff_p4"\n\t" \ -"paddh "#o1" , "#t1" , "#t2" \n\t" \ -"paddh "#o1" , "#o1" , "#t3" \n\t" \ -"paddh "#o1" , "#o1" , "#t4" \n\t" \ -\ -"pmullh "#t1" , "#fp1" , "#ff_p2"\n\t" \ -"pmullh "#t2" , "#fp2" , "#ff_p4"\n\t" \ -"pmullh "#t3" , "#fp3" , "#ff_p1"\n\t" \ -"pmullh "#t4" , "#fp4" , "#ff_p3"\n\t" \ -"psubh "#o2" , "#t1" , "#t2" \n\t" \ -"psubh "#o2" , "#o2" , "#t3" \n\t" \ -"psubh "#o2" , "#o2" , "#t4" \n\t" \ -\ -"pmullh "#t1" , "#fp1" , "#ff_p3"\n\t" \ -"pmullh "#t2" , "#fp2" , "#ff_p1"\n\t" \ -"pmullh "#t3" , "#fp3" , "#ff_p4"\n\t" \ -"pmullh "#t4" , "#fp4" , "#ff_p2"\n\t" \ -"psubh "#o3" , "#t1" , "#t2" \n\t" \ -"paddh "#o3" , "#o3" , "#t3" \n\t" \ -"paddh "#o3" , "#o3" , "#t4" \n\t" \ -\ -"pmullh "#t1" , "#fp1" , "#ff_p4"\n\t" \ -"pmullh "#t2" , "#fp2" , "#ff_p3"\n\t" \ -"pmullh "#t3" , "#fp3" , "#ff_p2"\n\t" \ -"pmullh "#t4" , "#fp4" , "#ff_p1"\n\t" \ -"psubh "#o4" , "#t1" , "#t2" \n\t" \ -"paddh "#o4" , "#o4" , "#t3" \n\t" \ -"psubh "#o4" , "#o4" , "#t4" \n\t" - - -#define VC1_INV_TRANCS_8_STEP2_MMI(fp1, fp2, fp3, fp4,\ - fp5, fp6, fp7, fp8,\ - o1,o2,o3,o4, \ - ff_p1, ff_p2, ff_p3, ff_pw) \ -"paddh "#fp5" , "#fp1" , "#fp2" \n\t" \ -"psubh "#fp6" , "#fp1" , "#fp2" \n\t" \ -"pmullh "#fp5" , "#fp5" , "#ff_p1"\n\t" \ -"pmullh "#fp6" , "#fp6" , "#ff_p1"\n\t" \ -"paddh "#fp5" , "#fp5" , "#ff_pw"\n\t" \ -"paddh "#fp6" , "#fp6" , "#ff_pw"\n\t" \ -\ -"pmullh "#fp1" , "#fp3" , "#ff_p2"\n\t" \ -"pmullh "#fp2" , "#fp4" , "#ff_p3"\n\t" \ -"pmullh "#fp3" , "#fp3" , "#ff_p3"\n\t" \ -"pmullh "#fp4" , "#fp4" , "#ff_p2"\n\t" \ -"paddh "#fp7" , "#fp1" , "#fp2" \n\t" \ -"psubh "#fp8" , "#fp3" , "#fp4" \n\t" \ +#define VC1_INV_TRANCS_8_TYPE1(o1, o2, r1, r2, r3, r4, c0) \ +"li %[tmp0],"#r1" \n\t" \ +"mtc1 %[tmp0],%[ftmp13] \n\t" \ +
[FFmpeg-devel] [PATCH 5/7] avcodec: [loongson] optimize get_cabac_inline with asm.
Optimize function get_cabac_inline with asm.
Change-Id: I67f5e96b30589d925fa13c5a4595f1f2924f17e1
Signed-off-by: Shiyou Yin
---
libavcodec/cabac_functions.h | 3 ++
libavcodec/mips/cabac.h | 119 +++
2 files changed, 122 insertions(+)
create mode 100644 libavcodec/mips/cabac.h
diff --git a/libavcodec/cabac_functions.h b/libavcodec/cabac_functions.h
index fe72a82..bb2b421 100644
--- a/libavcodec/cabac_functions.h
+++ b/libavcodec/cabac_functions.h
@@ -45,6 +45,9 @@
#if ARCH_X86
# include "x86/cabac.h"
#endif
+#if ARCH_MIPS
+# include "mips/cabac.h"
+#endif
static const uint8_t * const ff_h264_norm_shift = ff_h264_cabac_tables +
H264_NORM_SHIFT_OFFSET;
static const uint8_t * const ff_h264_lps_range = ff_h264_cabac_tables +
H264_LPS_RANGE_OFFSET;
diff --git a/libavcodec/mips/cabac.h b/libavcodec/mips/cabac.h
new file mode 100644
index 000..a22c1ea
--- /dev/null
+++ b/libavcodec/mips/cabac.h
@@ -0,0 +1,119 @@
+/*
+ * Loongson SIMD optimized h264chroma
+ *
+ * Copyright (c) 2015 Loongson Technology Corporation Limited
+ * Copyright (c) 2015 Shiyou Yin
+ *
+ * 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
+ */
+
+#ifndef AVCODEC_MIPS_CABAC_H
+#define AVCODEC_MIPS_CABAC_H
+
+#include "libavcodec/cabac.h"
+#include "libavutil/mips/mmiutils.h"
+#include "config.h"
+
+#define get_cabac_inline get_cabac_inline_mips
+static av_always_inline int get_cabac_inline(CABACContext *c,
+ uint8_t * const state){
+mips_reg tmp0, tmp1, tmp2, bit;
+
+__asm__ volatile (
+"lbu %[bit],0(%[state]) \n\t"
+"and %[tmp0], %[c_range], 0xC0 \n\t"
+PTR_ADDU "%[tmp0], %[tmp0],%[tmp0] \n\t"
+PTR_ADDU "%[tmp0], %[tmp0],%[tables] \n\t"
+PTR_ADDU "%[tmp0], %[tmp0],%[bit]\n\t"
+/* tmp1: RangeLPS */
+"lbu %[tmp1], %[lps_off](%[tmp0]) \n\t"
+
+PTR_SUBU "%[c_range],%[c_range], %[tmp1] \n\t"
+PTR_SLL "%[tmp0], %[c_range], 0x11 \n\t"
+PTR_SUBU "%[tmp0], %[tmp0],%[c_low] \n\t"
+
+/* tmp2: lps_mask */
+PTR_SRA "%[tmp2], %[tmp0],0x1F \n\t"
+/* If tmp0 < 0, lps_mask == 0x*/
+/* If tmp0 >= 0, lps_mask == 0x*/
+"beqz %[tmp2], 1f\n\t"
+PTR_SLL "%[tmp0], %[c_range], 0x11 \n\t"
+PTR_SUBU "%[c_low], %[c_low], %[tmp0] \n\t"
+PTR_SUBU "%[tmp0], %[tmp1],%[c_range]\n\t"
+PTR_ADDU "%[c_range],%[c_range], %[tmp0] \n\t"
+"xor %[bit],%[bit], %[tmp2] \n\t"
+
+"1:\n\t"
+/* tmp1: *state */
+PTR_ADDU "%[tmp0], %[tables], %[bit]\n\t"
+"lbu %[tmp1], %[mlps_off](%[tmp0]) \n\t"
+/* tmp2: lps_mask */
+PTR_ADDU "%[tmp0], %[tables], %[c_range]\n\t"
+"lbu %[tmp2], %[norm_off](%[tmp0]) \n\t"
+
+"sb %[tmp1], 0(%[state]) \n\t"
+"and %[bit],%[bit], 0x01 \n\t"
+PTR_SLL "%[c_range],%[c_range], %[tmp2] \n\t"
+PTR_SLL "%[c_low], %[c_low], %[tmp2] \n\t"
+
+"and %[tmp0], %[c_low], %[cabac_mask] \n\t"
+"bnez %[tmp0], 1f\n\t"
+PTR_ADDI "%[tmp0], %[c_low], -0X01 \n\t"
+"xor %[tmp0], %[c_low], %[tmp0] \n\t"
+PTR_SRA "%[tmp0], %[tmp0],0x0f \n\t"
+PTR_ADDU "%[tmp0], %[tmp0],%[tables] \n\t"
+"lbu %[tmp2], %[norm_off](%[tmp0]) \n\t"
+#if CABAC_BITS == 16
+"lbu %[tmp0], 0(%[c_bytestream])
[FFmpeg-devel] [PATCH 3/7] avcodec/mips: [loongson] optimize memset in h264dsp.
Optimized memset with mmi in function: 1. ff_h264_add_pixels4_8_mmi. 2. ff_h264_idct_add_8_mmi. 3. ff_h264_idct8_add_8_mmi. Change-Id: Ifde1dd36c053970e33ac9cfc660cb21b17b1bd6d Signed-off-by: Shiyou Yin --- libavcodec/mips/h264dsp_mmi.c | 36 +--- 1 file changed, 33 insertions(+), 3 deletions(-) diff --git a/libavcodec/mips/h264dsp_mmi.c b/libavcodec/mips/h264dsp_mmi.c index ac6fa99..8cc632c 100644 --- a/libavcodec/mips/h264dsp_mmi.c +++ b/libavcodec/mips/h264dsp_mmi.c @@ -59,6 +59,17 @@ void ff_h264_add_pixels4_8_mmi(uint8_t *dst, int16_t *src, int stride) MMI_SWC1(%[ftmp2], %[dst1], 0x00) MMI_SWC1(%[ftmp3], %[dst2], 0x00) MMI_SWC1(%[ftmp4], %[dst3], 0x00) + +/* memset(src, 0, 32); */ +"xor%[ftmp0], %[ftmp0], %[ftmp0]\n\t" +"gssdlc1%[ftmp0], 0x07(%[src])\n\t" +"gssdrc1%[ftmp0], 0x00(%[src])\n\t" +"gssdlc1%[ftmp0], 0x0f(%[src])\n\t" +"gssdrc1%[ftmp0], 0x08(%[src])\n\t" +"gssdlc1%[ftmp0], 0x17(%[src])\n\t" +"gssdrc1%[ftmp0], 0x10(%[src])\n\t" +"gssdlc1%[ftmp0], 0x1f(%[src])\n\t" +"gssdrc1%[ftmp0], 0x18(%[src])\n\t" : [ftmp0]"="(ftmp[0]),[ftmp1]"="(ftmp[1]), [ftmp2]"="(ftmp[2]),[ftmp3]"="(ftmp[3]), [ftmp4]"="(ftmp[4]),[ftmp5]"="(ftmp[5]), @@ -72,7 +83,6 @@ void ff_h264_add_pixels4_8_mmi(uint8_t *dst, int16_t *src, int stride) : "memory" ); -memset(src, 0, 32); } void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t *block, int stride) @@ -152,6 +162,17 @@ void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t *block, int stride) MMI_SWC1(%[ftmp2], %[dst], 0x00) "packushb %[ftmp0], %[ftmp0], %[ftmp7]\n\t" MMI_SWXC1(%[ftmp0], %[dst], %[stride], 0x00) + +/* memset(block, 0, 32) */ +"xor%[ftmp0], %[ftmp0], %[ftmp0]\n\t" +"gssdlc1%[ftmp0], 0x07(%[block]) \n\t" +"gssdrc1%[ftmp0], 0x00(%[block]) \n\t" +"gssdlc1%[ftmp0], 0x0f(%[block]) \n\t" +"gssdrc1%[ftmp0], 0x08(%[block]) \n\t" +"gssdlc1%[ftmp0], 0x17(%[block]) \n\t" +"gssdrc1%[ftmp0], 0x10(%[block]) \n\t" +"gssdlc1%[ftmp0], 0x1f(%[block]) \n\t" +"gssdrc1%[ftmp0], 0x18(%[block]) \n\t" : [ftmp0]"="(ftmp[0]),[ftmp1]"="(ftmp[1]), [ftmp2]"="(ftmp[2]),[ftmp3]"="(ftmp[3]), [ftmp4]"="(ftmp[4]),[ftmp5]"="(ftmp[5]), @@ -167,7 +188,6 @@ void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t *block, int stride) : "memory" ); -memset(block, 0, 32); } void ff_h264_idct8_add_8_mmi(uint8_t *dst, int16_t *block, int stride) @@ -617,6 +637,17 @@ void ff_h264_idct8_add_8_mmi(uint8_t *dst, int16_t *block, int stride) MMI_SWC1(%[ftmp6], %[addr0], 0x00) MMI_SWXC1(%[ftmp7], %[addr0], %[stride], 0x00) PTR_ADDIU "$29,$29,0x20\n\t" + +/* memset(block, 0, 32) */ +"xor%[ftmp0], %[ftmp0], %[ftmp0]\n\t" +"gssdlc1%[ftmp0], 0x07(%[block]) \n\t" +"gssdrc1%[ftmp0], 0x00(%[block]) \n\t" +"gssdlc1%[ftmp0], 0x0f(%[block]) \n\t" +"gssdrc1%[ftmp0], 0x08(%[block]) \n\t" +"gssdlc1%[ftmp0], 0x17(%[block]) \n\t" +"gssdrc1%[ftmp0], 0x10(%[block]) \n\t" +"gssdlc1%[ftmp0], 0x1f(%[block]) \n\t" +"gssdrc1%[ftmp0], 0x18(%[block]) \n\t" : [ftmp0]"="(ftmp[0]),[ftmp1]"="(ftmp[1]), [ftmp2]"="(ftmp[2]),[ftmp3]"="(ftmp[3]), [ftmp4]"="(ftmp[4]),[ftmp5]"="(ftmp[5]), @@ -638,7 +669,6 @@ void ff_h264_idct8_add_8_mmi(uint8_t *dst, int16_t *block, int stride) : "$29","memory" ); -memset(block, 0, 128); } void ff_h264_idct_dc_add_8_mmi(uint8_t *dst, int16_t *block, int stride) -- 2.1.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/7] avcodec/mips: [loongson] reoptimize h264_chroma_mc8_mmi v2.
Reoptimize function ff_put_h264_chroma_mc8_mmi and ff_avg_h264_chroma_mc8_mmi
v2.
Change-Id: If24813daec2c625c9901d047f6a05ff6b8153383
Signed-off-by: Shiyou Yin
---
libavcodec/mips/h264chroma_mmi.c | 740 ---
1 file changed, 454 insertions(+), 286 deletions(-)
diff --git a/libavcodec/mips/h264chroma_mmi.c b/libavcodec/mips/h264chroma_mmi.c
index bafe0f9..7087dbf 100644
--- a/libavcodec/mips/h264chroma_mmi.c
+++ b/libavcodec/mips/h264chroma_mmi.c
@@ -29,326 +29,323 @@
void ff_put_h264_chroma_mc8_mmi(uint8_t *dst, uint8_t *src, ptrdiff_t stride,
int h, int x, int y)
{
-const int A = (8 - x) * (8 - y);
-const int B = x * (8 - y);
-const int C = (8 - x) * y;
-const int D = x * y;
-const int E = B + C;
+int A = 64, B, C, D, E;
double ftmp[10];
uint64_t tmp[1];
-mips_reg addr[1];
DECLARE_VAR_ALL64;
-if (D) {
+if ((x == 0) && (y == 0)) { // x == 0, y == 0
+/* A=64 */
__asm__ volatile (
-"xor%[ftmp0], %[ftmp0], %[ftmp0]\n\t"
-"dli%[tmp0],0x06\n\t"
-"pshufh %[A], %[A], %[ftmp0]\n\t"
-"pshufh %[B], %[B], %[ftmp0]\n\t"
-"mtc1 %[tmp0],%[ftmp9]\n\t"
-"pshufh %[C], %[C], %[ftmp0]\n\t"
-"pshufh %[D], %[D], %[ftmp0]\n\t"
+"xor%[ftmp0], %[ftmp0], %[ftmp0] \n\t"
+"dli%[tmp0],0x06 \n\t"
+"mtc1 %[tmp0],%[ftmp4] \n\t"
-"1: \n\t"
-PTR_ADDU "%[addr0], %[src], %[stride] \n\t"
+"1:\n\t"
MMI_ULDC1(%[ftmp1], %[src], 0x00)
-MMI_ULDC1(%[ftmp2], %[src], 0x01)
-MMI_ULDC1(%[ftmp3], %[addr0], 0x00)
-MMI_ULDC1(%[ftmp4], %[addr0], 0x01)
-
-"punpcklbh %[ftmp5], %[ftmp1], %[ftmp0]\n\t"
-"punpckhbh %[ftmp6], %[ftmp1], %[ftmp0]\n\t"
-"punpcklbh %[ftmp7], %[ftmp2], %[ftmp0]\n\t"
-"punpckhbh %[ftmp8], %[ftmp2], %[ftmp0]\n\t"
-"pmullh %[ftmp5], %[ftmp5], %[A]\n\t"
-"pmullh %[ftmp7], %[ftmp7], %[B]\n\t"
-"paddh %[ftmp1], %[ftmp5], %[ftmp7]\n\t"
-"pmullh %[ftmp6], %[ftmp6], %[A]\n\t"
-"pmullh %[ftmp8], %[ftmp8], %[B]\n\t"
-"paddh %[ftmp2], %[ftmp6], %[ftmp8]\n\t"
-
-"punpcklbh %[ftmp5], %[ftmp3], %[ftmp0]\n\t"
-"punpckhbh %[ftmp6], %[ftmp3], %[ftmp0]\n\t"
-"punpcklbh %[ftmp7], %[ftmp4], %[ftmp0]\n\t"
-"punpckhbh %[ftmp8], %[ftmp4], %[ftmp0]\n\t"
-"pmullh %[ftmp5], %[ftmp5], %[C]\n\t"
-"pmullh %[ftmp7], %[ftmp7], %[D]\n\t"
-"paddh %[ftmp3], %[ftmp5], %[ftmp7]\n\t"
-"pmullh %[ftmp6], %[ftmp6], %[C]\n\t"
-"pmullh %[ftmp8], %[ftmp8], %[D]\n\t"
-"paddh %[ftmp4], %[ftmp6], %[ftmp8]\n\t"
-
-"paddh %[ftmp1], %[ftmp1], %[ftmp3]\n\t"
-"paddh %[ftmp2], %[ftmp2], %[ftmp4]\n\t"
-"paddh %[ftmp1], %[ftmp1], %[ff_pw_32] \n\t"
-"paddh %[ftmp2], %[ftmp2], %[ff_pw_32] \n\t"
-"psrlh %[ftmp1], %[ftmp1], %[ftmp9]\n\t"
-"psrlh %[ftmp2], %[ftmp2], %[ftmp9]\n\t"
-"packushb %[ftmp1], %[ftmp1], %[ftmp2]\n\t"
-"addi %[h], %[h], -0x01 \n\t"
+"addi %[h], %[h], -0x04 \n\t"
+PTR_ADDU "%[src], %[src], %[stride] \n\t"
+MMI_ULDC1(%[ftmp5], %[src], 0x00)
+PTR_ADDU "%[src], %[src], %[stride] \n\t"
+MMI_ULDC1(%[ftmp6], %[src], 0x00)
+PTR_ADDU "%[src], %[src], %[stride] \n\t"
+MMI_ULDC1(%[ftmp7], %[src], 0x00)
+
+"punpcklbh %[ftmp2], %[ftmp1], %[ftmp0] \n\t"
+
Re: [FFmpeg-devel] [PATCH v2 19/36] vaapi_encode: Clean up the packed header configuration
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> Add a larger warning more clearly explaining the consequences of missing
> packed header support in the driver. Also only write the extradata if the
> user actually requests it via the GLOBAL_HEADER flag.
> ---
> libavcodec/vaapi_encode.c | 118 +
> ---
> libavcodec/vaapi_encode.h | 7 ++-
> libavcodec/vaapi_encode_h264.c | 2 +-
> libavcodec/vaapi_encode_h265.c | 2 +-
> libavcodec/vaapi_encode_mjpeg.c | 2 +-
> libavcodec/vaapi_encode_mpeg2.c | 4 +-
> libavcodec/vaapi_encode_vp8.c | 6 +-
> libavcodec/vaapi_encode_vp9.c | 6 +-
> 8 files changed, 79 insertions(+), 68 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index af9224c98f..14d1846ea3 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1210,60 +1210,6 @@ fail:
> return err;
> }
>
> -static av_cold int vaapi_encode_config_attributes(AVCodecContext *avctx)
> -{
> -VAAPIEncodeContext *ctx = avctx->priv_data;
> -VAStatus vas;
> -int i;
> -
> -VAConfigAttrib attr[] = {
> -{ VAConfigAttribEncPackedHeaders },
> -};
> -
> -vas = vaGetConfigAttributes(ctx->hwctx->display,
> -ctx->va_profile, ctx->va_entrypoint,
> -attr, FF_ARRAY_ELEMS(attr));
> -if (vas != VA_STATUS_SUCCESS) {
> -av_log(avctx, AV_LOG_ERROR, "Failed to fetch config "
> - "attributes: %d (%s).\n", vas, vaErrorStr(vas));
> -return AVERROR(EINVAL);
> -}
> -
> -for (i = 0; i < FF_ARRAY_ELEMS(attr); i++) {
> -if (attr[i].value == VA_ATTRIB_NOT_SUPPORTED) {
> -// Unfortunately we have to treat this as "don't know" and hope
> -// for the best, because the Intel MJPEG encoder returns this
> -// for all the interesting attributes.
> -av_log(avctx, AV_LOG_DEBUG, "Attribute (%d) is not supported.\n",
> - attr[i].type);
> -continue;
> -}
> -switch (attr[i].type) {
> -case VAConfigAttribEncPackedHeaders:
> -if (ctx->va_packed_headers & ~attr[i].value) {
> -// This isn't fatal, but packed headers are always
> -// preferable because they are under our control.
> -// When absent, the driver is generating them and some
> -// features may not work (e.g. VUI or SEI in H.264).
> -av_log(avctx, AV_LOG_WARNING, "Warning: some packed "
> - "headers are not supported (want %#x, got %#x).\n",
> - ctx->va_packed_headers, attr[i].value);
> -ctx->va_packed_headers &= attr[i].value;
> -}
> -ctx->config_attributes[ctx->nb_config_attributes++] =
> -(VAConfigAttrib) {
> -.type = VAConfigAttribEncPackedHeaders,
> -.value = ctx->va_packed_headers,
> -};
> -break;
> -default:
> -av_assert0(0 && "Unexpected config attribute.");
> -}
> -}
> -
> -return 0;
> -}
> -
> static av_cold int vaapi_encode_init_rate_control(AVCodecContext *avctx)
> {
> VAAPIEncodeContext *ctx = avctx->priv_data;
> @@ -1494,6 +1440,65 @@ static av_cold int
> vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> return 0;
> }
>
> +static av_cold int vaapi_encode_init_packed_headers(AVCodecContext *avctx)
> +{
> +VAAPIEncodeContext *ctx = avctx->priv_data;
> +VAStatus vas;
> +VAConfigAttrib attr = { VAConfigAttribEncPackedHeaders };
> +
> +vas = vaGetConfigAttributes(ctx->hwctx->display,
> +ctx->va_profile,
> +ctx->va_entrypoint,
> +, 1);
> +if (vas != VA_STATUS_SUCCESS) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to query packed headers "
> + "attribute: %d (%s).\n", vas, vaErrorStr(vas));
> +return AVERROR_EXTERNAL;
> +}
> +
> +if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> +if (ctx->packed_headers) {
> +av_log(avctx, AV_LOG_WARNING, "Driver does not support any "
> + "packed headers (wanted %#x).\n", ctx->packed_headers);
> +} else {
> +av_log(avctx, AV_LOG_VERBOSE, "Driver does not support any "
> + "packed headers (none wanted).\n");
> +}
> +ctx->va_packed_headers = 0;
> +} else {
> +if (ctx->packed_headers & ~attr.value) {
> +av_log(avctx, AV_LOG_WARNING, "Driver does not support some "
> + "wanted packed headers (wanted %#x, found %#x).\n",
> + ctx->packed_headers, attr.value);
> +} else {
> +av_log(avctx, AV_LOG_VERBOSE, "All wanted packed headers "
> + "available
Re: [FFmpeg-devel] [PATCH v2 18/36] vaapi_encode: Clean up the GOP structure configuration
On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> Choose what types of reference frames will be used based on what types
> are available, and make the intra-only mode explicit (GOP size one,
> which must be used for MJPEG).
> ---
> libavcodec/vaapi_encode.c | 83 +++-
> -
> libavcodec/vaapi_encode.h | 1 +
> libavcodec/vaapi_encode_h264.c | 4 +-
> libavcodec/vaapi_encode_h265.c | 4 +-
> libavcodec/vaapi_encode_mjpeg.c | 1 +
> libavcodec/vaapi_encode_mpeg2.c | 2 +-
> libavcodec/vaapi_encode_vp8.c | 7 +---
> libavcodec/vaapi_encode_vp9.c | 7 ++--
> 8 files changed, 68 insertions(+), 41 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 0e806a29e3..af9224c98f 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -680,7 +680,7 @@ static int vaapi_encode_get_next(AVCodecContext *avctx,
> return AVERROR(ENOMEM);
>
> if (ctx->input_order == 0 || ctx->force_idr ||
> -ctx->gop_counter >= avctx->gop_size) {
> +ctx->gop_counter >= ctx->gop_size) {
> pic->type = PICTURE_TYPE_IDR;
> ctx->force_idr = 0;
> ctx->gop_counter = 1;
> @@ -703,7 +703,7 @@ static int vaapi_encode_get_next(AVCodecContext *avctx,
> // encode-after it, but not exceeding the GOP size.
>
> for (i = 0; i < ctx->b_per_p &&
> - ctx->gop_counter < avctx->gop_size; i++) {
> + ctx->gop_counter < ctx->gop_size; i++) {
> pic = vaapi_encode_alloc(avctx);
> if (!pic)
> goto fail;
> @@ -1217,7 +1217,6 @@ static av_cold int
> vaapi_encode_config_attributes(AVCodecContext *avctx)
> int i;
>
> VAConfigAttrib attr[] = {
> -{ VAConfigAttribEncMaxRefFrames },
> { VAConfigAttribEncPackedHeaders },
> };
>
> @@ -1240,24 +1239,6 @@ static av_cold int
> vaapi_encode_config_attributes(AVCodecContext *avctx)
> continue;
> }
> switch (attr[i].type) {
> -case VAConfigAttribEncMaxRefFrames:
> -{
> -unsigned int ref_l0 = attr[i].value & 0x;
> -unsigned int ref_l1 = (attr[i].value >> 16) & 0x;
> -
> -if (avctx->gop_size > 1 && ref_l0 < 1) {
> -av_log(avctx, AV_LOG_ERROR, "P frames are not "
> - "supported (%#x).\n", attr[i].value);
> -return AVERROR(EINVAL);
> -}
> -if (avctx->max_b_frames > 0 && ref_l1 < 1) {
> -av_log(avctx, AV_LOG_WARNING, "B frames are not "
> - "supported (%#x) by the underlying driver.\n",
> - attr[i].value);
> -avctx->max_b_frames = 0;
> -}
> -}
> -break;
> case VAConfigAttribEncPackedHeaders:
> if (ctx->va_packed_headers & ~attr[i].value) {
> // This isn't fatal, but packed headers are always
> @@ -1465,6 +1446,54 @@ static av_cold int
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
> return 0;
> }
>
> +static av_cold int vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> +{
> +VAAPIEncodeContext *ctx = avctx->priv_data;
> +VAStatus vas;
> +VAConfigAttrib attr = { VAConfigAttribEncMaxRefFrames };
> +uint32_t ref_l0, ref_l1;
> +
> +vas = vaGetConfigAttributes(ctx->hwctx->display,
> +ctx->va_profile,
> +ctx->va_entrypoint,
> +, 1);
> +if (vas != VA_STATUS_SUCCESS) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to query reference frames "
> + "attribute: %d (%s).\n", vas, vaErrorStr(vas));
> +return AVERROR_EXTERNAL;
> +}
> +
> +if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> +ref_l0 = ref_l1 = 0;
> +} else {
> +ref_l0 = attr.value & 0x;
> +ref_l1 = attr.value >> 16 & 0x;
> +}
> +
> +if (avctx->gop_size <= 1) {
> +av_log(avctx, AV_LOG_VERBOSE, "Using intra frames only.\n");
> +ctx->gop_size = 1;
> +} else if (ref_l0 < 1) {
> +av_log(avctx, AV_LOG_ERROR, "Driver does not support any "
> + "reference frames.\n");
> +return AVERROR(EINVAL);
> +} else if (ref_l1 < 1 || avctx->max_b_frames < 1) {
> +av_log(avctx, AV_LOG_VERBOSE, "Using intra and P-frames "
> + "(supported references: %d / %d).\n", ref_l0, ref_l1);
> +ctx->gop_size = avctx->gop_size;
> +ctx->p_per_i = INT_MAX;
How about removing p_per_i? I see p_per_i is used only in the following 'else
if' statement and I don't think ctx->p_counter can be INT_MAX in reality.
} else if (ctx->p_counter >= ctx->p_per_i) {...}
> +ctx->b_per_p = 0;
> +} else {
> +av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-frames "
> +
Re: [FFmpeg-devel] [PATCH v2 16/36] vaapi_encode: Clean up rate control configuration
On Wed, 2018-06-13 at 23:42 +0100, Mark Thompson wrote:
> On 13/06/18 08:03, Xiang, Haihao wrote:
> > On Fri, 2018-06-08 at 00:43 +0100, Mark Thompson wrote:
> > > Query which modes are supported and select between VBR and CBR based
> > > on that - this removes all of the codec-specific rate control mode
> > > selection code.
> > > ---
> > > doc/encoders.texi | 2 -
> > > libavcodec/vaapi_encode.c | 173 ---
> > >
> > > -
> > > libavcodec/vaapi_encode.h | 6 +-
> > > libavcodec/vaapi_encode_h264.c | 18 +
> > > libavcodec/vaapi_encode_h265.c | 14 +---
> > > libavcodec/vaapi_encode_mjpeg.c | 3 +-
> > > libavcodec/vaapi_encode_mpeg2.c | 9 +--
> > > libavcodec/vaapi_encode_vp8.c | 13 +--
> > > libavcodec/vaapi_encode_vp9.c | 13 +--
> > > 9 files changed, 137 insertions(+), 114 deletions(-)
> > >
> > > ...
> > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > > index f4c063734c..5de5483454 100644
> > > --- a/libavcodec/vaapi_encode.c
> > > +++ b/libavcodec/vaapi_encode.c
> > > ...
> > > @@ -1313,44 +1286,144 @@ static av_cold int
> > > vaapi_encode_config_attributes(AVCodecContext *avctx)
> > > static av_cold int vaapi_encode_init_rate_control(AVCodecContext *avctx)
> > > {
> > > VAAPIEncodeContext *ctx = avctx->priv_data;
> > > -int rc_bits_per_second;
> > > -int rc_target_percentage;
> > > -int rc_window_size;
> > > -int hrd_buffer_size;
> > > -int hrd_initial_buffer_fullness;
> > > +int64_t rc_bits_per_second;
> > > +int rc_target_percentage;
> > > +int rc_window_size;
> > > +int64_t hrd_buffer_size;
> > > +int64_t hrd_initial_buffer_fullness;
> > > int fr_num, fr_den;
> > > +VAConfigAttrib rc_attr = { VAConfigAttribRateControl };
> > > +VAStatus vas;
> > > +
> > > +vas = vaGetConfigAttributes(ctx->hwctx->display,
> > > +ctx->va_profile, ctx->va_entrypoint,
> > > +_attr, 1);
> > > +if (vas != VA_STATUS_SUCCESS) {
> > > +av_log(avctx, AV_LOG_ERROR, "Failed to query rate control "
> > > + "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
> > > +return AVERROR_EXTERNAL;
> > > +}
> > >
> > > -if (avctx->bit_rate > INT32_MAX) {
> > > -av_log(avctx, AV_LOG_ERROR, "Target bitrate of 2^31 bps or "
> > > - "higher is not supported.\n");
> > > +if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> > > +av_log(avctx, AV_LOG_VERBOSE, "Driver does not report any "
> > > + "supported rate control modes: assuming constant-
> > > quality.\n");
> >
> > How about logging it as warning message?
>
> What would a user do about it?
>
User may know what is not supported in the driver and he/she might get wrong
result, he/she may file an issue to the driver.
> (Note that it gets logged for JPEG encoding on all versions of the i965 driver
> except the most recent, so if it were a warning it would be seen by everyone
> using those versions.)
>
> > > +ctx->va_rc_mode = VA_RC_CQP;
> > > +return 0;
> > > +}
> > > +if (avctx->flags & AV_CODEC_FLAG_QSCALE ||
> > > +avctx->bit_rate <= 0) {
> > > +if (rc_attr.value & VA_RC_CQP) {
> > > +av_log(avctx, AV_LOG_VERBOSE, "Using constant-quality
> > > mode.\n");
> > > +ctx->va_rc_mode = VA_RC_CQP;
> > > +return 0;
> > > +} else {
> > > +av_log(avctx, AV_LOG_ERROR, "Driver does not support "
> > > + "constant-quality mode (%#x).\n", rc_attr.value);
> > > +return AVERROR(EINVAL);
> > > +}
> > > +}
> > > +
> > > +if (!(rc_attr.value & (VA_RC_CBR | VA_RC_VBR))) {
> > > +av_log(avctx, AV_LOG_ERROR, "Driver does not support any "
> > > + "bitrate-targetted rate control modes.\n");
> > > return AVERROR(EINVAL);
> > > }
> > >
> > > if (avctx->rc_buffer_size)
> > > hrd_buffer_size = avctx->rc_buffer_size;
> > > +else if (avctx->rc_max_rate > 0)
> > > +hrd_buffer_size = avctx->rc_max_rate;
> > > else
> > > hrd_buffer_size = avctx->bit_rate;
> > > -if (avctx->rc_initial_buffer_occupancy)
> > > +if (avctx->rc_initial_buffer_occupancy) {
> > > +if (avctx->rc_initial_buffer_occupancy > hrd_buffer_size) {
> > > +av_log(avctx, AV_LOG_ERROR, "Invalid RC buffer settings: "
> > > + "must have initial buffer size (%d) < "
> > > + "buffer size (%"PRId64").\n",
> > > + avctx->rc_initial_buffer_occupancy, hrd_buffer_size);
> > > +return AVERROR(EINVAL);
> > > +}
> > > hrd_initial_buffer_fullness = avctx->rc_initial_buffer_occupancy;
> > > -else
> > > +} else {
> > > hrd_initial_buffer_fullness = hrd_buffer_size * 3 / 4;
> > > +}
