[FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the multi-thread HWAccel decode error
Fix the issue: https://github.com/intel/media-driver/issues/317
the root cause is update_dimensions will be called multple times
when decoder thread number is not only 1, but update_dimensions
call get_pixel_format in each decode thread will trigger the
hwaccel_uninit/hwaccel_init more than once. But only one hwaccel
should be shared with all decode threads.
in current context,
there are 3 situations in the update_dimensions():
1. First time calling. No matter single thread or multithread,
get_pixel_format() should be called after dimensions were
set;
2. Dimention changed at the runtime. Dimention need to be
updated when macroblocks_base is already allocated,
get_pixel_format() should be called to recreate new frames
according to updated dimension;
3. Multithread first time calling. After decoder init, the
other threads will call update_dimensions() at first time
to allocate macroblocks_base and set dimensions.
But get_pixel_format() is shouldn't be called due to low
level frames and context are already created.
In this fix, we only call update_dimensions as need.
Signed-off-by: Wang, Shaofei
Reviewed-by: Jun, Zhao
Reviewed-by: Haihao Xiang
---
Updated typo in the commit message
libavcodec/vp8.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index ba79e5f..0a7f38b 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -187,7 +187,7 @@ static av_always_inline
int update_dimensions(VP8Context *s, int width, int height, int is_vp7)
{
AVCodecContext *avctx = s->avctx;
-int i, ret;
+int i, ret, dim_reset = 0;
if (width != s->avctx->width || ((width+15)/16 != s->mb_width ||
(height+15)/16 != s->mb_height) && s->macroblocks_base ||
height != s->avctx->height) {
@@ -196,9 +196,12 @@ int update_dimensions(VP8Context *s, int width, int
height, int is_vp7)
ret = ff_set_dimensions(s->avctx, width, height);
if (ret < 0)
return ret;
+
+dim_reset = (s->macroblocks_base != NULL);
}
-if (!s->actually_webp && !is_vp7) {
+if ((s->pix_fmt == AV_PIX_FMT_NONE || dim_reset) &&
+ !s->actually_webp && !is_vp7) {
s->pix_fmt = get_pixel_format(s);
if (s->pix_fmt < 0)
return AVERROR(EINVAL);
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter/vf_gblur: add x86 SIMD optimizations
On 12.06.2019, at 03:00, Ruiling Song wrote: > ffmpeg | branch: master | Ruiling Song | Wed May 15 > 17:54:10 2019 +0800| [83f9da77684e7ea0d8e9f9712ec716424140043a] | committer: > Ruiling Song > > avfilter/vf_gblur: add x86 SIMD optimizations > > The horizontal pass get ~2x performance with the patch > under single thread. > > Tested overall performance using the command(avx2 enabled): > ./ffmpeg -i 1080p.mp4 -vf gblur -f null /dev/null > ./ffmpeg -i 1080p.mp4 -vf gblur=threads=1 -f null /dev/null > For single thread, the fps improves from 43 to 60, about 40%. > For multi-thread, the fps improves from 110 to 130, about 20%. > > Signed-off-by: Ruiling Song > >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=83f9da77684e7ea0d8e9f9712ec716424140043a > --- > > libavfilter/gblur.h | 55 > libavfilter/vf_gblur.c | 71 +++ > libavfilter/x86/Makefile| 2 + > libavfilter/x86/vf_gblur.asm| 185 > libavfilter/x86/vf_gblur_init.c | 36 > 5 files changed, 310 insertions(+), 39 deletions(-) > > diff --git a/libavfilter/gblur.h b/libavfilter/gblur.h > new file mode 100644 > index 00..87129801de > --- /dev/null > +++ b/libavfilter/gblur.h > @@ -0,0 +1,55 @@ > +/* > + * Copyright (c) 2011 Pascal Getreuer > + * Copyright (c) 2016 Paul B Mahol > + * > + * Redistribution and use in source and binary forms, with or without > modification, > + * are permitted provided that the following conditions are met: > + * > + * * Redistributions of source code must retain the above copyright > + *notice, this list of conditions and the following disclaimer. > + * * Redistributions in binary form must reproduce the above > + *copyright notice, this list of conditions and the following > + *disclaimer in the documentation and/or other materials provided > + *with the distribution. Where does this license come from? Is that even GPL-compatible? I mean how is someone compiling ffmpeg even supposed to know they have to put this license text in their documentation? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables
On 11-06-2019 04:35 AM, greg Luce wrote:
I created this issue on the bugtracker but I'm trying to format it
properly for this channel
https://trac.ffmpeg.org/ticket/7947
The actual filter change was written by Calvin Walton
---
diff --git a/doc/filters.texi b/doc/filters.texi
index ec1c7c7591..332f4ddc80 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8584,6 +8584,17 @@ The thickness of the drawn box.
These constants allow the @var{x}, @var{y}, @var{w}, @var{h} and
@var{t} expressions to refer to
each other, so you may for example specify @code{y=x/dar} or @code{h=w/dar}.
+@item pict_type
+A 1 character description of the current packet's input picture type.
+
+@item pkt_pos
+The current packet's position in the input datastream (in bytes from
the head of the source file)
Add a note that a value of -1 indicates this info is not available.
+
+@item pkt_duration
+The current packet's input duration
+
+@item pkt_size
+The current packet's input size (in bytes)
@end table
@@ -9032,6 +9043,14 @@ The first argument is mandatory and specifies
the metadata key.
The second argument is optional and specifies a default value, used when the
metadata key is not found or empty.
+The use of the term metadata in ffmpeg refers to extra data,
+often user-provided or generated live during decode by other filters.
Extradata in ffmpeg parlance refers primarily to codec configuration.
Metadata is typically exported as strings by the demuxer.
(Also, filters operate *after* decoding).
+If you're trying to read data from teh frames in a stream or file, run
+@code{ffprobe -show_frames}. If the information doesn't show up between
+@code{[FRAME]} and @code{[/FRAME]} in the form
@code{TAG:[metadata_key]=[metadata_value]}
+then it won't be visible to this function.
This isn't accurate. Metadata may be generated during filtering and
discarded before output. In which case, drawtext inserted after
generation can still access it but it won't show up in the input. I
believe you are trying to document that packet fields (like the three in
this patch) aren't available, unless specifically supported
Rewrite it as a positive statement.
"
Available metadata can be identified by inspecting entries starting with
TAG included within each frame section printed by running @code{ffprobe
-show_frames}.
String metadata generated in filters leading to the drawtext filter are
also available.
"
@item n, frame_num
The frame number, starting from 0.
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 01cd7fa122..8f4badbdb5 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -88,6 +88,9 @@ static const char *const var_names[] = {
"x",
"y",
"pict_type",
+"pkt_pos",
+"pkt_duration",
+"pkt_size",
NULL
};
@@ -125,6 +128,9 @@ enum var_name {
VAR_X,
VAR_Y,
VAR_PICT_TYPE,
+VAR_PKT_POS,
+VAR_PKT_DURATION,
+VAR_PKT_SIZE,
VAR_VARS_NB
};
@@ -1516,6 +1522,9 @@ static int filter_frame(AVFilterLink *inlink,
AVFrame *frame)
NAN : frame->pts * av_q2d(inlink->time_base);
s->var_values[VAR_PICT_TYPE] = frame->pict_type;
+s->var_values[VAR_PKT_POS] = frame->pkt_pos;
+s->var_values[VAR_PKT_DURATION] = frame->pkt_duration *
av_q2d(inlink->time_base);
+s->var_values[VAR_PKT_SIZE] = frame->pkt_size;
s->metadata = frame->metadata;
draw_text(ctx, frame, frame->width, frame->height);
---
___
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2 1/2] libavfilter/dnn: add script to convert TensorFlow model (.pb) to native model (.model)
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > Guo, Yejun > Sent: Monday, June 10, 2019 11:10 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH V2 1/2] libavfilter/dnn: add script to > convert TensorFlow model (.pb) to native model (.model) > > > > > -Original Message- > > From: Guo, Yejun > > Sent: Tuesday, June 04, 2019 3:10 PM > > To: ffmpeg-devel@ffmpeg.org > > Cc: Guo, Yejun > > Subject: [PATCH V2 1/2] libavfilter/dnn: add script to convert TensorFlow > model > > (.pb) to native model (.model) > > > > For example, given TensorFlow model file espcn.pb, > > to generate native model file espcn.model, just run: > > python convert.py espcn.pb > > > > In current implementation, the native model file is generated for > > specific dnn network with hard-code python scripts maintained out of ffmpeg. > > For example, srcnn network used by vf_sr is generated with > > > https://github.com/HighVoltageRocknRoll/sr/blob/master/generate_header_a > > nd_model.py#L85 > > > > In this patch, the script is designed as a general solution which > > converts general TensorFlow model .pb file into .model file. The script > > now has some tricky to be compatible with current implemention, will > > be refined step by step. > > > > The script is also added into ffmpeg source tree. It is expected there > > will be many more patches and community needs the ownership of it. > > > > Another technical direction is to do the conversion in c/c++ code within > > ffmpeg source tree. While .pb file is organized with protocol buffers, > > it is not easy to do such work with tiny c/c++ code, see more discussion > > at http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244496.html. So, > > choose the python script. > > > > Signed-off-by: Guo, Yejun > > --- > > .gitignore| 1 + > > libavfilter/dnn/python/convert.py | 52 ++ > > libavfilter/dnn/python/convert_from_tensorflow.py | 201 > > ++ > > 3 files changed, 254 insertions(+) > > create mode 100644 libavfilter/dnn/python/convert.py > > create mode 100644 libavfilter/dnn/python/convert_from_tensorflow.py there are three options for the place to put these .py scripts. 1) at libavfilter/dnn/python/ the point is to put all the dnn stuffs together 2) at tools/python/ the point is that there is already a .py script under tools/ 3) create a new project controlled by ffmpeg the point is that the python scripts should not be part of ffmpeg source tree. (btw, how to apply such sub project?) My idea is that the script generates dnn native model file which is loaded by ffmpeg c code, it is better to put the script within the ffmpeg source tree, and all the dnn stuffs would be better to put together, thanks. anyway, I'm open to any option, just to make the progress continue ... > > ping for review, thanks. > > Here is my rough plan after this patch. > - move dnn relative .h/.c from libavfilter to libavfilter/dnn, it is expected > there > will be more files for dnn module (code for both model loading and execution). > - add a layer for padding (tf.pad) for native mode and its fate test. > - change the script to add tf.pad support, and so the native model and the tf > model of vf_sr will be the same. > in current implementation, the two models have a little difference, it makes > the script not a general solution to convert tf model to native model. > - add layer maximum and fate test. This layer appears in tf model, but not in > native model, of vf_sr. > - introduce operand concept in native mode (both execution and model), to > support data split and merge/concat in the network, such split/concat is very > common. > it also makes possible to reuse memory for the intermediate data as the > output of the hidden layers. > - tune conv2d layer performance (it is very slow now) or add more layers for > native mode. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] yuv420_bgr24_mmxext conversion taking significant time
On Mon, 10 Jun 2019 17:42:00 -0700 Adrian Tong wrote: > I have been trying to implement yuv420_to_bgr24 using SSE2 instruction. I > ran into the case where the output of C implemented yuv420_to_bgr24 has > slightly different resulting bgr24 image from MMX implemented > yuv420_to_bgr24. Is this expected behavior ? Yes, some of the MMX implementations choose speed over accuracy, I ran to that myself when doing PPC versions. For a SSE version, if an accurate version is fast enough, please try to match the C version. Otherwise try to match MMX. - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, RFC] lavc/vp9dec: fix the multi-thread HWAccel decode error
On Tue, Jun 11, 2019 at 9:20 AM Linjie Fu wrote: > > Fix the multi-thread HWAccel decode error for vp9. > > VP9 supports the resolution changing. In multi-thread mode, worker-threads > destroy and free the first created VAAPIDecodeContext if resolution change > happens and create new one. Other threads still request to destroy previous > and demand for new context. This leads to decode failures and memory issue. > > Modify to call hwaccel_uninit/hwaccel_init by ff_thread_get_format only > when the first-come thread detected the resolution changing. > s->gf_fmt, s->w and s->h are updated through vp9_decode_update_thread_context, wouldn't they prevent re-initialization already, as long as the size only changes once? If not, why not? Perhaps thats a better avenue to fix it, then hacky conditions like this one. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH, RFC] lavc/vp9dec: fix the multi-thread HWAccel decode error
Fix the multi-thread HWAccel decode error for vp9.
VP9 supports the resolution changing. In multi-thread mode, worker-threads
destroy and free the first created VAAPIDecodeContext if resolution change
happens and create new one. Other threads still request to destroy previous
and demand for new context. This leads to decode failures and memory issue.
Modify to call hwaccel_uninit/hwaccel_init by ff_thread_get_format only
when the first-come thread detected the resolution changing.
Signed-off-by: Linjie Fu
---
Fix the same issue vaapi_vp8 decoding meets:
https://patchwork.ffmpeg.org/patch/12507/
libavcodec/vp9.c| 18 ++
libavcodec/vp9dec.h | 2 ++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index acf3ffc..e2fad9d 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -179,6 +179,7 @@ static int update_size(AVCodecContext *avctx, int w, int h)
uint8_t *p;
int bytesperpixel = s->bytesperpixel, ret, cols, rows;
int lflvl_len, i;
+int dim_reset = 0;
av_assert0(w > 0 && h > 0);
@@ -186,6 +187,10 @@ static int update_size(AVCodecContext *avctx, int w, int h)
if ((ret = ff_set_dimensions(avctx, w, h)) < 0)
return ret;
+if (!avctx->internal->hwaccel_priv_data ||
+s->context == avctx->internal->hwaccel_priv_data)
+dim_reset = 1;
+
switch (s->pix_fmt) {
case AV_PIX_FMT_YUV420P:
case AV_PIX_FMT_YUV420P10:
@@ -216,16 +221,21 @@ static int update_size(AVCodecContext *avctx, int w, int
h)
*fmtp++ = s->pix_fmt;
*fmtp = AV_PIX_FMT_NONE;
-ret = ff_thread_get_format(avctx, pix_fmts);
-if (ret < 0)
-return ret;
+if (dim_reset) {
+ret = ff_thread_get_format(avctx, pix_fmts);
+if (ret < 0)
+return ret;
+
+avctx->pix_fmt = ret;
+}
-avctx->pix_fmt = ret;
s->gf_fmt = s->pix_fmt;
s->w = w;
s->h = h;
}
+s->context = avctx->internal->hwaccel_priv_data;
+
cols = (w + 7) >> 3;
rows = (h + 7) >> 3;
diff --git a/libavcodec/vp9dec.h b/libavcodec/vp9dec.h
index 66573ed..bc3f36c 100644
--- a/libavcodec/vp9dec.h
+++ b/libavcodec/vp9dec.h
@@ -152,6 +152,8 @@ typedef struct VP9Context {
int block_alloc_using_2pass;
uint16_t mvscale[3][2];
uint8_t mvstep[3][2];
+
+void *context;
} VP9Context;
struct VP9TileData {
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4 2/2] doc/filters.texi: don't need to be in gray8 for find image
From: Limin Wang Signed-off-by: Limin Wang --- doc/filters.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/filters.texi b/doc/filters.texi index ec1c7c7591..90c57430a6 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -10150,7 +10150,7 @@ It accepts the following options: @table @option @item object -Filepath of the object image, needs to be in gray8. +Filepath of the object image. @item threshold Detection threshold, default is 0.5. -- 2.21.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/2] libavfilter/vf_blend.c: remove duplicate code with macro-defined function
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_blend.c | 188 +++--
1 file changed, 48 insertions(+), 140 deletions(-)
diff --git a/libavfilter/vf_blend.c b/libavfilter/vf_blend.c
index 46e0518d26..cf71200773 100644
--- a/libavfilter/vf_blend.c
+++ b/libavfilter/vf_blend.c
@@ -555,156 +555,64 @@ static av_cold void uninit(AVFilterContext *ctx)
av_expr_free(s->params[i].e);
}
+#define DEFINE_INIT_BLEND_FUNC(depth, nbits)
\
+static av_cold void init_blend_func_##depth##_##nbits##bit(FilterParams
*param) \
+{
\
+switch (param->mode) {
\
+case BLEND_ADDITION: param->blend = blend_addition_##depth##bit;
break; \
+case BLEND_GRAINMERGE: param->blend = blend_grainmerge_##depth##bit;
break; \
+case BLEND_AND:param->blend = blend_and_##depth##bit;
break; \
+case BLEND_AVERAGE:param->blend = blend_average_##depth##bit;
break; \
+case BLEND_BURN: param->blend = blend_burn_##depth##bit;
break; \
+case BLEND_DARKEN: param->blend = blend_darken_##depth##bit;
break; \
+case BLEND_DIFFERENCE: param->blend = blend_difference_##depth##bit;
break; \
+case BLEND_GRAINEXTRACT: param->blend =
blend_grainextract_##depth##bit; break; \
+case BLEND_DIVIDE: param->blend = blend_divide_##depth##bit;
break; \
+case BLEND_DODGE: param->blend = blend_dodge_##depth##bit;
break; \
+case BLEND_EXCLUSION: param->blend = blend_exclusion_##depth##bit;
break; \
+case BLEND_EXTREMITY: param->blend = blend_extremity_##depth##bit;
break; \
+case BLEND_FREEZE: param->blend = blend_freeze_##depth##bit;
break; \
+case BLEND_GLOW: param->blend = blend_glow_##depth##bit;
break; \
+case BLEND_HARDLIGHT: param->blend = blend_hardlight_##depth##bit;
break; \
+case BLEND_HARDMIX:param->blend = blend_hardmix_##depth##bit;
break; \
+case BLEND_HEAT: param->blend = blend_heat_##depth##bit;
break; \
+case BLEND_LIGHTEN:param->blend = blend_lighten_##depth##bit;
break; \
+case BLEND_LINEARLIGHT:param->blend =
blend_linearlight_##depth##bit;break; \
+case BLEND_MULTIPLY: param->blend = blend_multiply_##depth##bit;
break; \
+case BLEND_MULTIPLY128:param->blend =
blend_multiply128_##depth##bit;break; \
+case BLEND_NEGATION: param->blend = blend_negation_##depth##bit;
break; \
+case BLEND_NORMAL: param->blend = blend_normal_##nbits##bit;
break; \
+case BLEND_OR: param->blend = blend_or_##depth##bit;
break; \
+case BLEND_OVERLAY:param->blend = blend_overlay_##depth##bit;
break; \
+case BLEND_PHOENIX:param->blend = blend_phoenix_##depth##bit;
break; \
+case BLEND_PINLIGHT: param->blend = blend_pinlight_##depth##bit;
break; \
+case BLEND_REFLECT:param->blend = blend_reflect_##depth##bit;
break; \
+case BLEND_SCREEN: param->blend = blend_screen_##depth##bit;
break; \
+case BLEND_SOFTLIGHT: param->blend = blend_softlight_##depth##bit;
break; \
+case BLEND_SUBTRACT: param->blend = blend_subtract_##depth##bit;
break; \
+case BLEND_VIVIDLIGHT: param->blend = blend_vividlight_##depth##bit;
break; \
+case BLEND_XOR:param->blend = blend_xor_##depth##bit;
break; \
+}
\
+}
+DEFINE_INIT_BLEND_FUNC(8, 8);
+DEFINE_INIT_BLEND_FUNC(10, 16);
+DEFINE_INIT_BLEND_FUNC(12, 16);
+DEFINE_INIT_BLEND_FUNC(16, 16);
+
void ff_blend_init(FilterParams *param, int depth)
{
switch (depth) {
case 8:
-switch (param->mode) {
-case BLEND_ADDITION: param->blend = blend_addition_8bit; break;
-case BLEND_GRAINMERGE: param->blend = blend_grainmerge_8bit; break;
-case BLEND_AND:param->blend = blend_and_8bit;break;
-case BLEND_AVERAGE:param->blend = blend_average_8bit;break;
-case BLEND_BURN: param->blend = blend_burn_8bit; break;
-case BLEND_DARKEN: param->blend = blend_darken_8bit; break;
-case BLEND_DIFFERENCE: param->blend = blend_difference_8bit; break;
-case BLEND_GRAINEXTRACT: param->blend = blend_grainextract_8bit; break;
-case BLEND_DIVIDE: param->blend = blend_divide_8bit; break;
-case BLEND_DODGE:
[FFmpeg-devel] [PATCH v2 1/2] libavfilter/vf_blend.c: remove duplicate code with same function
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_blend.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/libavfilter/vf_blend.c b/libavfilter/vf_blend.c
index 83f3d591a8..46e0518d26 100644
--- a/libavfilter/vf_blend.c
+++ b/libavfilter/vf_blend.c
@@ -582,9 +582,7 @@ void ff_blend_init(FilterParams *param, int depth)
case BLEND_MULTIPLY: param->blend = blend_multiply_8bit; break;
case BLEND_MULTIPLY128:param->blend = blend_multiply128_8bit;break;
case BLEND_NEGATION: param->blend = blend_negation_8bit; break;
-case BLEND_NORMAL: param->blend = param->opacity == 1 ?
blend_copytop_8 :
- param->opacity == 0 ?
blend_copybottom_8 :
- blend_normal_8bit; break;
+case BLEND_NORMAL: param->blend = blend_normal_8bit; break;
case BLEND_OR: param->blend = blend_or_8bit; break;
case BLEND_OVERLAY:param->blend = blend_overlay_8bit;break;
case BLEND_PHOENIX:param->blend = blend_phoenix_8bit;break;
@@ -621,9 +619,7 @@ void ff_blend_init(FilterParams *param, int depth)
case BLEND_MULTIPLY: param->blend = blend_multiply_10bit; break;
case BLEND_MULTIPLY128:param->blend = blend_multiply128_10bit;break;
case BLEND_NEGATION: param->blend = blend_negation_10bit; break;
-case BLEND_NORMAL: param->blend = param->opacity == 1 ?
blend_copytop_16 :
- param->opacity == 0 ?
blend_copybottom_16 :
- blend_normal_16bit;break;
+case BLEND_NORMAL: param->blend = blend_normal_16bit; break;
case BLEND_OR: param->blend = blend_or_10bit;break;
case BLEND_OVERLAY:param->blend = blend_overlay_10bit; break;
case BLEND_PHOENIX:param->blend = blend_phoenix_10bit; break;
@@ -660,9 +656,7 @@ void ff_blend_init(FilterParams *param, int depth)
case BLEND_MULTIPLY: param->blend = blend_multiply_12bit; break;
case BLEND_MULTIPLY128:param->blend = blend_multiply128_12bit;break;
case BLEND_NEGATION: param->blend = blend_negation_12bit; break;
-case BLEND_NORMAL: param->blend = param->opacity == 1 ?
blend_copytop_16 :
- param->opacity == 0 ?
blend_copybottom_16 :
- blend_normal_16bit;break;
+case BLEND_NORMAL: param->blend = blend_normal_16bit; break;
case BLEND_OR: param->blend = blend_or_12bit;break;
case BLEND_OVERLAY:param->blend = blend_overlay_12bit; break;
case BLEND_PHOENIX:param->blend = blend_phoenix_12bit; break;
@@ -699,9 +693,7 @@ void ff_blend_init(FilterParams *param, int depth)
case BLEND_MULTIPLY: param->blend = blend_multiply_16bit; break;
case BLEND_MULTIPLY128:param->blend = blend_multiply128_16bit;break;
case BLEND_NEGATION: param->blend = blend_negation_16bit; break;
-case BLEND_NORMAL: param->blend = param->opacity == 1 ?
blend_copytop_16 :
- param->opacity == 0 ?
blend_copybottom_16 :
- blend_normal_16bit;break;
+case BLEND_NORMAL: param->blend = blend_normal_16bit; break;
case BLEND_OR: param->blend = blend_or_16bit;break;
case BLEND_OVERLAY:param->blend = blend_overlay_16bit; break;
case BLEND_PHOENIX:param->blend = blend_phoenix_16bit; break;
@@ -718,6 +710,11 @@ void ff_blend_init(FilterParams *param, int depth)
if (param->opacity == 0 && param->mode != BLEND_NORMAL) {
param->blend = depth > 8 ? blend_copytop_16 : blend_copytop_8;
+} else if (param->mode == BLEND_NORMAL) {
+if (param->opacity == 1)
+param->blend = depth > 8 ? blend_copytop_16 : blend_copytop_8;
+else if (param->opacity == 0)
+param->blend = depth > 8 ? blend_copybottom_16 :
blend_copybottom_8;
}
if (ARCH_X86)
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc: new interlaced mux mode
Hi, An additional comment on the matter... ‐‐‐ Original Message ‐‐‐ On Monday, 10 de June de 2019 19:29, Andreas Håkon wrote: > Hi, > > --- > > --- > From aa02575cc11bed0fd2ae2a01368c8673ad48e64b Mon Sep 17 00:00:00 2001 > > From: Andreas Hakon < > andreas.ha...@protonmail.com >> > > Date: Mon, 10 Jun 2019 18:14:56 +0100 > Subject: [PATCH] libavformat/mpegtsenc: new interlaced mux mode > > This patch implements a new optional "parallel muxing mode" in the MPEGTS > muxer. > The strategy that implements the current mux (selected by default) is based on > writing full PES packages sequentially. This mode can be problematic when > using > with DTV broadcasts, as some large video PES packets can delay the writing of > other elementary streams. > The new optional parameter "-mpegts_extra_mux 1" enables a different strategy. > Instead of writing all PES packets sequentially, the first TS packet of each > PES > packet is written when the PES packet is started. But the rest of the PES data > will be written later, and interlaced between all the mux streams. > This new (optional) behavior has clear advantages when multiplexing multiple > programs with several video streams. And although this does not turn the > current implementation into a professional muxer, it brings the result closer > to what professional equipment does. > > Signed-off-by: Andreas Hakon < > andreas.ha...@protonmail.com >> > > --- > libavformat/mpegtsenc.c | 305 > --- > 1 file changed, 233 insertions(+), 72 deletions(-) This patch line's old! +/* NOTE: The return value is negative when the onlyone flag generates the exit. */ Please, remove it. Other than this, the rest of the patch is valid. We've tested it for weeks and see no issues. Regards. A.H. --- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [Patch v2] drawtext: ignore last newline
This is a new version from my last patch.
As Gyan suggested it is now optional to skip/trim the last line break.
From 8d31aab97ceaaec4947e1628e2ff1391dd77d4b2 Mon Sep 17 00:00:00 2001
From: Jonathan Baecker
Date: Tue, 11 Jun 2019 14:33:50 +0200
Subject: [PATCH] trim last empty line
---
libavfilter/vf_drawtext.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 01cd7fa12..22ec870ed 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -139,7 +139,7 @@ typedef struct DrawTextContext {
int exp_mode; ///< expansion mode to use for the text
int reinit; ///< tells if the filter is being reinited
#if CONFIG_LIBFONTCONFIG
-uint8_t *font; ///< font to be used
+uint8_t *font; ///< font to be used
#endif
uint8_t *fontfile; ///< font to be used
uint8_t *text; ///< text to be drawn
@@ -162,6 +162,7 @@ typedef struct DrawTextContext {
unsigned int default_fontsize; ///< default font size to use
int line_spacing; ///< lines spacing in pixels
+int trim_end; ///< skip last empty line - true/false
short int draw_box; ///< draw box around text - true or false
int boxborderw; ///< box border width
int use_kerning;///< font kerning is used - true/false
@@ -211,6 +212,7 @@ static const AVOption drawtext_options[]= {
{"boxcolor","set box color",OFFSET(boxcolor.rgba),
AV_OPT_TYPE_COLOR, {.str="white"}, CHAR_MIN, CHAR_MAX, FLAGS},
{"bordercolor", "set border color", OFFSET(bordercolor.rgba),
AV_OPT_TYPE_COLOR, {.str="black"}, CHAR_MIN, CHAR_MAX, FLAGS},
{"shadowcolor", "set shadow color", OFFSET(shadowcolor.rgba),
AV_OPT_TYPE_COLOR, {.str="black"}, CHAR_MIN, CHAR_MAX, FLAGS},
+{"trim_end","trim last empty line", OFFSET(trim_end),
AV_OPT_TYPE_BOOL, {.i64=0}, 0,1 , FLAGS},
{"box", "set box", OFFSET(draw_box),
AV_OPT_TYPE_BOOL, {.i64=0}, 0,1 , FLAGS},
{"boxborderw", "set box border width", OFFSET(boxborderw),
AV_OPT_TYPE_INT,{.i64=0}, INT_MIN, INT_MAX , FLAGS},
{"line_spacing", "set line spacing in pixels", OFFSET(line_spacing),
AV_OPT_TYPE_INT,{.i64=0}, INT_MIN, INT_MAX,FLAGS},
@@ -1377,6 +1379,18 @@ static int draw_text(AVFilterContext *ctx, AVFrame
*frame,
/* compute and save position for each glyph */
glyph = NULL;
+
+if (s->trim_end) {
+/* skip last newline character */
+char * last = text + len - 1;
+char * second_last = text + len - 2;
+
+if (*second_last == '\r' && *last == '\n')
+*second_last = 0;
+else if (*last == '\r' || *last == '\n')
+*last = 0;
+}
+
for (i = 0, p = text; *p; i++) {
GET_UTF8(code, *p++, continue;);
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/6] lavf: rename tls_securetransport to tls_apple
---
libavformat/Makefile | 2 +-
libavformat/{tls_securetransport.c => tls_apple.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename libavformat/{tls_securetransport.c => tls_apple.c} (100%)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index df87c54a58..358d4abf49 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -614,7 +614,7 @@ TLS-OBJS-$(CONFIG_GNUTLS)+= tls_gnutls.o
TLS-OBJS-$(CONFIG_LIBTLS)+= tls_libtls.o
TLS-OBJS-$(CONFIG_MBEDTLS) += tls_mbedtls.o
TLS-OBJS-$(CONFIG_OPENSSL) += tls_openssl.o
-TLS-OBJS-$(CONFIG_SECURETRANSPORT) += tls_securetransport.o
+TLS-OBJS-$(CONFIG_SECURETRANSPORT) += tls_apple.o
TLS-OBJS-$(CONFIG_SCHANNEL) += tls_schannel.o
OBJS-$(CONFIG_TLS_PROTOCOL) += tls.o $(TLS-OBJS-yes)
OBJS-$(CONFIG_UDP_PROTOCOL) += udp.o ip.o
diff --git a/libavformat/tls_securetransport.c b/libavformat/tls_apple.c
similarity index 100%
rename from libavformat/tls_securetransport.c
rename to libavformat/tls_apple.c
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/6] lavf/tls_apple: fix crash on unexpected PEM types
---
libavformat/tls_apple.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/tls_apple.c b/libavformat/tls_apple.c
index 2ff6622565..37d63f3b27 100644
--- a/libavformat/tls_apple.c
+++ b/libavformat/tls_apple.c
@@ -165,6 +165,12 @@ static int load_identity(URLContext *h, SecIdentityRef
*identity, CFArrayRef *ce
if ((ret = import_pem(h, c->tls_shared.key_file, )) < 0)
goto end;
+if (CFGetTypeID(CFArrayGetValueAtIndex(*certArray, 0)) !=
SecCertificateGetTypeID() ||
+CFGetTypeID(CFArrayGetValueAtIndex(keyArray, 0)) != SecKeyGetTypeID())
{
+ret = AVERROR_INVALIDDATA;
+goto end;
+}
+
if (!(*identity = SecIdentityCreate(kCFAllocatorDefault,
(SecCertificateRef)CFArrayGetValueAtIndex(*certArray, 0),
(SecKeyRef)CFArrayGetValueAtIndex(keyArray,
0 {
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/6] lavf/tls: factor ff_tls_process_underlying into its own function
---
libavformat/tls.c | 45 +++--
libavformat/tls.h | 1 +
2 files changed, 28 insertions(+), 18 deletions(-)
diff --git a/libavformat/tls.c b/libavformat/tls.c
index 10e0792e29..ccd551061d 100644
--- a/libavformat/tls.c
+++ b/libavformat/tls.c
@@ -51,6 +51,29 @@ static void set_options(TLSShared *c, const char *uri)
if (!c->key_file && av_find_info_tag(buf, sizeof(buf), "key", p))
c->key_file = av_strdup(buf);
+
+if (av_find_info_tag(buf, sizeof(buf), "listen", p))
+c->listen = 1;
+}
+
+int ff_tls_process_underlying(TLSShared *c, URLContext *parent, const char
*uri, int *port)
+{
+struct addrinfo hints = { 0 }, *ai = NULL;
+
+set_options(c, uri);
+
+av_url_split(NULL, 0, NULL, 0, c->underlying_host,
sizeof(c->underlying_host), port, NULL, 0, uri);
+
+hints.ai_flags = AI_NUMERICHOST;
+if (!getaddrinfo(c->underlying_host, NULL, , )) {
+c->numerichost = 1;
+freeaddrinfo(ai);
+}
+
+if (!c->host && !(c->host = av_strdup(c->underlying_host)))
+return AVERROR(ENOMEM);
+
+ return 0;
}
int ff_tls_open_underlying(TLSShared *c, URLContext *parent, const char *uri,
AVDictionary **options)
@@ -58,37 +81,23 @@ int ff_tls_open_underlying(TLSShared *c, URLContext
*parent, const char *uri, AV
int port;
const char *p;
char buf[200], opts[50] = "";
-struct addrinfo hints = { 0 }, *ai = NULL;
const char *proxy_path;
int use_proxy;
+int ret;
-set_options(c, uri);
+if ((ret = ff_tls_process_underlying(c, parent, uri, )) < 0)
+return ret;
if (c->listen)
snprintf(opts, sizeof(opts), "?listen=1");
-av_url_split(NULL, 0, NULL, 0, c->underlying_host,
sizeof(c->underlying_host), , NULL, 0, uri);
-
p = strchr(uri, '?');
-if (!p) {
+if (!p)
p = opts;
-} else {
-if (av_find_info_tag(opts, sizeof(opts), "listen", p))
-c->listen = 1;
-}
ff_url_join(buf, sizeof(buf), "tcp", NULL, c->underlying_host, port, "%s",
p);
-hints.ai_flags = AI_NUMERICHOST;
-if (!getaddrinfo(c->underlying_host, NULL, , )) {
-c->numerichost = 1;
-freeaddrinfo(ai);
-}
-
-if (!c->host && !(c->host = av_strdup(c->underlying_host)))
-return AVERROR(ENOMEM);
-
proxy_path = getenv("http_proxy");
use_proxy = !ff_http_match_no_proxy(getenv("no_proxy"),
c->underlying_host) &&
proxy_path && av_strstart(proxy_path, "http://;, NULL);
diff --git a/libavformat/tls.h b/libavformat/tls.h
index beb19d6d55..a954f51733 100644
--- a/libavformat/tls.h
+++ b/libavformat/tls.h
@@ -51,6 +51,7 @@ typedef struct TLSShared {
{"listen", "Listen for incoming connections", offsetof(pstruct,
options_field . listen),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, .flags =
TLS_OPTFL }, \
{"verifyhost", "Verify against a specific hostname", offsetof(pstruct,
options_field . host), AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }
+int ff_tls_process_underlying(TLSShared *c, URLContext *parent, const char
*uri, int *port);
int ff_tls_open_underlying(TLSShared *c, URLContext *parent, const char *uri,
AVDictionary **options);
void ff_gnutls_init(void);
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/6] lavf/tls_apple: factor loading SecItemIdentity into its own (Mac-only) function
This allows us to easily reuse this function with NWF
---
libavformat/tls_apple.c | 34 +-
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/libavformat/tls_apple.c b/libavformat/tls_apple.c
index 37380541b1..2ff6622565 100644
--- a/libavformat/tls_apple.c
+++ b/libavformat/tls_apple.c
@@ -150,28 +150,46 @@ end:
return ret;
}
-static int load_cert(URLContext *h)
+static int load_identity(URLContext *h, SecIdentityRef *identity, CFArrayRef
*certArray)
{
+#if !HAVE_SECITEMIMPORT
+return AVERROR_PATCHWELCOME;
+#else
TLSContext *c = h->priv_data;
int ret = 0;
-CFArrayRef certArray = NULL;
CFArrayRef keyArray = NULL;
-SecIdentityRef id = NULL;
-CFMutableArrayRef outArray = NULL;
-if ((ret = import_pem(h, c->tls_shared.cert_file, )) < 0)
+if ((ret = import_pem(h, c->tls_shared.cert_file, certArray)) < 0)
goto end;
if ((ret = import_pem(h, c->tls_shared.key_file, )) < 0)
goto end;
-if (!(id = SecIdentityCreate(kCFAllocatorDefault,
-
(SecCertificateRef)CFArrayGetValueAtIndex(certArray, 0),
+if (!(*identity = SecIdentityCreate(kCFAllocatorDefault,
+
(SecCertificateRef)CFArrayGetValueAtIndex(*certArray, 0),
(SecKeyRef)CFArrayGetValueAtIndex(keyArray,
0 {
ret = AVERROR_UNKNOWN;
goto end;
}
+end:
+if (keyArray)
+CFRelease(keyArray);
+return ret;
+#endif
+}
+
+static int load_cert(URLContext *h)
+{
+TLSContext *c = h->priv_data;
+int ret = 0;
+SecIdentityRef id = NULL;
+CFArrayRef certArray = NULL;
+CFMutableArrayRef outArray = NULL;
+
+if ((ret = load_identity(h, , )) < 0)
+goto end;
+
if (!(outArray = CFArrayCreateMutableCopy(kCFAllocatorDefault, 0,
certArray))) {
ret = AVERROR(ENOMEM);
goto end;
@@ -184,8 +202,6 @@ static int load_cert(URLContext *h)
end:
if (certArray)
CFRelease(certArray);
-if (keyArray)
-CFRelease(keyArray);
if (outArray)
CFRelease(outArray);
if (id)
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/6] lavf/tls_apple: add support for the new Network framework
Network.framework was added in macOS 10.14/iOS 12, replacing Secure Transport.
Its TLS functionality is (currently) implemented on top of BoringSSL.
Secure Transport is deprecated as of macOS 10.15/iOS 13. It'll likely remain
available for the forseeable future, but it's considered "legacy" and won't
receive new features; most significantly, TLS 1.3. Network.framework also adds
additional functionality (like multipath TCP) that ffmpeg may eventually want
to support.
The new code is behind compile-time checks for header availability, as well
as runtime checks for OS version. The framework is linked weakly, so ffmpeg
built with Network.framework support will continue to work normally on OS
versions prior to macOS 10.14/iOS 12, with the Secure Transport code path
being taken.
Currently, it's not possible to build tls_apple without support for Secure
Transport. I'm not sure if that's a useful case currently, though I suppose
if its headers are ever removed then we'll need to add some compile-time
conditionals.
---
configure | 11 +-
libavformat/Makefile| 1 +
libavformat/tls_apple.c | 401 +++-
3 files changed, 404 insertions(+), 9 deletions(-)
diff --git a/configure b/configure
index 32fc26356c..81be23a54f 100755
--- a/configure
+++ b/configure
@@ -301,6 +301,8 @@ External library support:
--enable-mbedtls enable mbedTLS, needed for https support
if openssl, gnutls or libtls is not used [no]
--enable-mediacodec enable Android MediaCodec support [no]
+ --disable-nwfdisable Apple Network.framework, needed for TLS
support
+ on macOS if openssl and gnutls are not used
[autodetect]
--enable-libmysofa enable libmysofa, needed for sofalizer filter [no]
--enable-openal enable OpenAL 1.1 capture support [no]
--enable-opencl enable OpenCL processing [no]
@@ -1693,6 +1695,7 @@ EXTERNAL_AUTODETECT_LIBRARY_LIST="
libxcb_shape
libxcb_xfixes
lzma
+nwf
schannel
sdl2
securetransport
@@ -3357,6 +3360,7 @@ https_protocol_suggest="zlib"
icecast_protocol_select="http_protocol"
mmsh_protocol_select="http_protocol"
mmst_protocol_select="network"
+nwf_conflict="openssl gnutls libtls mbedtls"
rtmp_protocol_conflict="librtmp_protocol"
rtmp_protocol_select="tcp_protocol"
rtmp_protocol_suggest="zlib"
@@ -3378,7 +3382,7 @@ sctp_protocol_select="network"
securetransport_conflict="openssl gnutls libtls mbedtls"
srtp_protocol_select="rtp_protocol srtp"
tcp_protocol_select="network"
-tls_protocol_deps_any="gnutls openssl schannel securetransport libtls mbedtls"
+tls_protocol_deps_any="gnutls nwf openssl schannel securetransport libtls
mbedtls"
tls_protocol_select="tcp_protocol"
udp_protocol_select="network"
udplite_protocol_select="network"
@@ -6353,8 +6357,11 @@ if enabled decklink; then
esac
fi
+enabled nwf &&
+check_lib nwf "Network/Network.h" "nw_connection_create"
"-Wl,-framework,CoreFoundation -Wl,-framework,Security
-Wl,-weak_framework,Network" ||
+disable nwf
+
enabled securetransport &&
-check_func SecIdentityCreate "-Wl,-framework,CoreFoundation
-Wl,-framework,Security" &&
check_lib securetransport "Security/SecureTransport.h Security/Security.h"
"SSLCreateContext" "-Wl,-framework,CoreFoundation -Wl,-framework,Security" ||
disable securetransport
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 358d4abf49..fdf981bedc 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -613,6 +613,7 @@ OBJS-$(CONFIG_TCP_PROTOCOL) += tcp.o
TLS-OBJS-$(CONFIG_GNUTLS)+= tls_gnutls.o
TLS-OBJS-$(CONFIG_LIBTLS)+= tls_libtls.o
TLS-OBJS-$(CONFIG_MBEDTLS) += tls_mbedtls.o
+TLS-OBJS-$(CONFIG_NWF) += tls_apple.o
TLS-OBJS-$(CONFIG_OPENSSL) += tls_openssl.o
TLS-OBJS-$(CONFIG_SECURETRANSPORT) += tls_apple.o
TLS-OBJS-$(CONFIG_SCHANNEL) += tls_schannel.o
diff --git a/libavformat/tls_apple.c b/libavformat/tls_apple.c
index 23042eb8ee..dd202eb9c0 100644
--- a/libavformat/tls_apple.c
+++ b/libavformat/tls_apple.c
@@ -19,7 +19,7 @@
*/
#include
-
+#include
#include "avformat.h"
#include "avio_internal.h"
@@ -37,18 +37,88 @@
#include
#include
+#if CONFIG_NWF
+#include
+#endif
+
// We use a private API call here; it's good enough for WebKit.
SecIdentityRef __attribute__((weak)) SecIdentityCreate(CFAllocatorRef
allocator, SecCertificateRef certificate, SecKeyRef privateKey);
#define ioErr -36
+#define NWF_CHECK __builtin_available(macOS 10.14, iOS 12.0, watchOS 5.0, tvOS
12.0, *)
+
typedef struct TLSContext {
const AVClass *class;
TLSShared tls_shared;
SSLContextRef ssl_context;
CFArrayRef ca_array;
int lastErr;
+#if CONFIG_NWF
+nw_connection_t nw_conn;
+dispatch_semaphore_t semaphore;
+
[FFmpeg-devel] [PATCH 4/6] lavf/tls_apple: link to SecIdentityCreate weakly
This is a private API, so it might go away in a future macOS version.
Linking to it weakly means that if it does, we won't crash during symbol lookup.
---
libavformat/tls_apple.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavformat/tls_apple.c b/libavformat/tls_apple.c
index 37d63f3b27..23042eb8ee 100644
--- a/libavformat/tls_apple.c
+++ b/libavformat/tls_apple.c
@@ -38,7 +38,7 @@
#include
// We use a private API call here; it's good enough for WebKit.
-SecIdentityRef SecIdentityCreate(CFAllocatorRef allocator, SecCertificateRef
certificate, SecKeyRef privateKey);
+SecIdentityRef __attribute__((weak)) SecIdentityCreate(CFAllocatorRef
allocator, SecCertificateRef certificate, SecKeyRef privateKey);
#define ioErr -36
typedef struct TLSContext {
@@ -165,6 +165,11 @@ static int load_identity(URLContext *h, SecIdentityRef
*identity, CFArrayRef *ce
if ((ret = import_pem(h, c->tls_shared.key_file, )) < 0)
goto end;
+if (!SecIdentityCreate) {
+ret = AVERROR_PATCHWELCOME;
+goto end;
+}
+
if (CFGetTypeID(CFArrayGetValueAtIndex(*certArray, 0)) !=
SecCertificateGetTypeID() ||
CFGetTypeID(CFArrayGetValueAtIndex(keyArray, 0)) != SecKeyGetTypeID())
{
ret = AVERROR_INVALIDDATA;
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] yuv420_bgr24_mmxext conversion taking significant time
On Mon, 10 Jun 2019 at 23:02, Lauri Kasanen wrote: > On Mon, 10 Jun 2019 17:42:00 -0700 > Adrian Tong wrote: > > > I have been trying to implement yuv420_to_bgr24 using SSE2 instruction. I > > ran into the case where the output of C implemented yuv420_to_bgr24 has > > slightly different resulting bgr24 image from MMX implemented > > yuv420_to_bgr24. Is this expected behavior ? > > Yes, some of the MMX implementations choose speed over accuracy, I ran > to that myself when doing PPC versions. For a SSE version, if an > accurate version is fast enough, please try to match the C version. > Otherwise try to match MMX. > Thanks for confirming, Lauri. I am reading the MMX code for YUV420 to BGR24, I am a little bit confused by it. Particularly, we shift left by 3 bits (multiply by 8) for better precision. How does this increase precision ? Also, the conversion formula has some floating point numbers as coefficient, But we are doing integer type multiplication here. https://github.com/FFmpeg/FFmpeg/blob/master/libswscale/x86/yuv2rgb_template.c#L92 Thanks - Adrian > > - Lauri > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc: new interlaced mux mode
Hello, On Mon, 10. Jun 17:29, Andreas Håkon wrote: > Hi, > > Here is a list of comments on this patch: > (Note: I use for all the tests the file > https://samples.ffmpeg.org/HDTV/bshi01.tp) > > - By default the current behavior is selected. You can verify that this > patch doesn’t alter the original behavior with this simple test: > > $ ffmpeg-original -i bshi01.tp \ > -c:v copy -c:a copy -c:d copy \ > -f mpegts -muxrate 22M bshi01-stock.ts > > $ ffmpeg-patched -i bshi01.tp \ > -c:v copy -c:a copy -c:d copy \ > -f mpegts -muxrate 22M -mpegts_extra_mux 0 bshi01- new.ts > > $ cmp -b bshi01-stock.ts bshi01-new.ts > > So both files are identical. The patch therefore doesn’t introduce any > changes in the implementation of the sequential mode. > > - To check the new interlaced mode you can perform this other test: > > $ ffmpeg-patched -y -loglevel verbose -i bshi01.tp \ > -map "i:0x100" -c:0 copy \ > -map "i:0x110" -c:a:0 mp2 -ac:0 2 -ar:0 48000 -ab:0 384k \ > -map "i:0x130" -c:2 copy \ > -map "i:0x110" -c:3 copy \ > -map "i:0x100" -c:4 copy \ > -program title=Prog1:st=0:st=1:st=2 \ > -program title=Prog2:st=3:st=4 \ > -f mpegts -muxrate 44M -mpegts_extra_mux 1 bshi01-mode1.ts > > $ ffmpeg-patched -y -loglevel verbose -i bshi01.tp \ > -map "i:0x100" -c:0 copy \ > -map "i:0x110" -c:a:0 mp2 -ac:0 2 -ar:0 48000 -ab:0 384k \ > -map "i:0x130" -c:2 copy \ > -map "i:0x110" -c:3 copy \ > -map "i:0x100" -c:4 copy \ > -program title=Prog1:st=0:st=1:st=2 \ > -program title=Prog2:st=3:st=4 \ > -f mpegts -muxrate 44M -mpegts_extra_mux 0 bshi01-mode0.ts > > And you can observe: > > a) The size of the files “bshi01-mode0.ts” and “bshi01-mode1.ts” is > almost the same. If you inspect the content, you can verify that the > difference is based solely on: a) an small increase in the number of > NULL packets in mode 1; b) a few new packets with only PCR and > not payload in the first video stream. > > b) If you demux the three files to elemental streams, then you can > check that the content is identical. Using the linux package “tstools” > you can do this check: > > $ ts2es -pid 256 bshi01-mode0.ts bshi01-mode0-256.m2v > $ ts2es -pid 260 bshi01-mode0.ts bshi01-mode0-260.m2v > $ ts2es -pid 257 bshi01-mode0.ts bshi01-mode0-257.mp2 > $ ts2es -pid 259 bshi01-mode0.ts bshi01-mode0-259.aac > > $ ts2es -pid 256 bshi01-mode1.ts bshi01-mode1-256.m2v > $ ts2es -pid 260 bshi01-mode1.ts bshi01-mode1-260.m2v > $ ts2es -pid 257 bshi01-mode1.ts bshi01-mode1-257.mp2 > $ ts2es -pid 259 bshi01-mode1.ts bshi01-mode1-259.aac > > c) If you look at the internal content of the files you can verify that > the original “bshi01.tp” file has all pids interlaced, but this isn’t true > for the file “bshi01-mode0.ts”. However, the file “bshi01-mode1.ts” > has an internal structure similar to that of the original file. > You can view the content using the well-known tool > “DVB Inspector” with the “Grid View” option. > > These tests confirm the correctness of the implementation of this > new multiplexing mode. > > - Last but not least, this patch fixes a bug within the current > implementation. When several programs are used in the same > TS file, the function “mpegts_init()” incorrectly initializes the > “service->pcr_pid” when several services are used. The current > code only sets this value for the last service, and leaves the > others uninitialized. This patch solves the problem by looping over > all services to establish the correct values. > > Please check this patch so that it can be accepted. > Regards. > A.H. > > --- > From aa02575cc11bed0fd2ae2a01368c8673ad48e64b Mon Sep 17 00:00:00 2001 > From: Andreas Hakon > Date: Mon, 10 Jun 2019 18:14:56 +0100 > Subject: [PATCH] libavformat/mpegtsenc: new interlaced mux mode > > This patch implements a new optional "parallel muxing mode" in the MPEGTS > muxer. > The strategy that implements the current mux (selected by default) is based on > writing full PES packages sequentially. This mode can be problematic when > using > with DTV broadcasts, as some large video PES packets can delay the writing of > other elementary streams. Could you go into more detail as to why this causes problems for DTV broadcasts? > The new optional parameter "-mpegts_extra_mux 1" enables a different strategy. > Instead of writing all PES packets sequentially, the first TS packet of each > PES > packet is written when the PES packet is started. But the rest of the PES data > will be written later, and interlaced between all the mux streams. > This new (optional) behavior has clear advantages when multiplexing multiple > programs with several video streams. And although this does not turn the > current implementation into a professional muxer, it brings the result closer > to what professional equipment does. > > Signed-off-by: Andreas Hakon > --- > libavformat/mpegtsenc.c | 305 > --- > 1 file changed, 233
Re: [FFmpeg-devel] [PATCH] set AVFrame decode_error_flags in case of decoding error by h264dec
On Sun, Jun 09, 2019 at 10:45:13PM -0700, Amir Pauker wrote:
> set AVFrame decode_error_flags in case h->slice_ctx->er.error_occurred is set
> after the call to ff_h264_execute_decode_slices. This allows the user to
> detect
> concealed decoding errors in the call to avcodec_receive_frame
>
> Signed-off-by: Amir Pauker
> ---
> libavcodec/h264dec.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index 00d922f..67dee11 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -758,6 +758,12 @@ static int decode_nal_units(H264Context *h, const
> uint8_t *buf, int buf_size)
> }
>
> ret = ff_h264_execute_decode_slices(h);
> +
> +// set decode_error_flags to allow users to detect concealed decoding
> errors
> +if( (ret < 0 || h->slice_ctx->er.error_occurred) && h->cur_pic_ptr){
> +h->cur_pic_ptr->f->decode_error_flags |=
> FF_DECODE_ERROR_INVALID_BITSTREAM|FF_DECODE_ERROR_MISSING_REFERENCE;
> +}
This is not correct.
error_occurred does not imply the 2 specific errors
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
What does censorship reveal? It reveals fear. -- Julian Assange
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] FFmpeg android support
Hello. I working on android internals and made some changes in latest ffmpeg for making it compilable by clang and some additional changes for making it work under android. The job is not finished yet but if community has not objections I'd prefer to share these changes and integrate them in ffmpeg instead of making our own fork Does community offiicial support android? -- Thanks! Dmitry ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V2 1/2] libavfilter/dnn: add script to convert TensorFlow model (.pb) to native model (.model)
Hi, Em ter, 11 de jun de 2019 às 05:00, Guo, Yejun escreveu: > > > there are three options for the place to put these .py scripts. > 1) at libavfilter/dnn/python/ > the point is to put all the dnn stuffs together > 2) at tools/python/ > the point is that there is already a .py script under tools/ > 3) create a new project controlled by ffmpeg > the point is that the python scripts should not be part of ffmpeg source > tree. > (btw, how to apply such sub project?) > I think option (2) is better as it is already there, even if (1) is more convenient. > My idea is that the script generates dnn native model file which is loaded by > ffmpeg c code, > it is better to put the script within the ffmpeg source tree, and all the dnn > stuffs would be better to put together, thanks. > > anyway, I'm open to any option, just to make the progress continue ... > > > > > ping for review, thanks. > > > > Here is my rough plan after this patch. > > - move dnn relative .h/.c from libavfilter to libavfilter/dnn, it is > > expected there > > will be more files for dnn module (code for both model loading and > > execution). > > - add a layer for padding (tf.pad) for native mode and its fate test. > > - change the script to add tf.pad support, and so the native model and the > > tf > > model of vf_sr will be the same. > > in current implementation, the two models have a little difference, it > > makes > > the script not a general solution to convert tf model to native model. > > - add layer maximum and fate test. This layer appears in tf model, but not > > in > > native model, of vf_sr. > > - introduce operand concept in native mode (both execution and model), to > > support data split and merge/concat in the network, such split/concat is > > very > > common. > > it also makes possible to reuse memory for the intermediate data as the > > output of the hidden layers. > > - tune conv2d layer performance (it is very slow now) or add more layers for > > native mode. > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg android support
On 11.06.2019, at 20:46, Dmitry A wrote: > Hello. > I working on android internals and made some changes in latest ffmpeg for > making it compilable by clang and some additional changes for making it > work under android. > The job is not finished yet but if community has not objections I'd prefer > to share these changes and integrate them in ffmpeg instead of making our > own fork It would be best to just share them. Anything that is "quite clean" should not be an issue to accept. If it gets very non-standard/Android-specific there might be objections, especially due to lack of automated testing (see also below), and because it seems other users do not seem to need them (?). > Does community offiicial support android? "Support" can mean all kinds of things. I believe there are quite a few people using it, at least VLC for example. But none of the "reinvented the wheel" build processes are supported. As most objective measure, it seems not tested via fate.ffmpeg.org, which always is a bad sign. Best regards, Reimar Döffinger ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] set AVFrame decode_error_flags in case of decoding error by h264dec
Thanks Michael Niedermayer for looking into this
What I am trying to solve is having a way to detect concealed decoding
errors by the caller to avcodec_receive_frame.
Should I add a general value e.g. #define
FF_DECODE_ERROR_DECODE_ERROR_OCCURRED 4 ?
Thanks
Amir
On Tue, Jun 11, 2019 at 11:39 AM Michael Niedermayer
wrote:
> On Sun, Jun 09, 2019 at 10:45:13PM -0700, Amir Pauker wrote:
> > set AVFrame decode_error_flags in case h->slice_ctx->er.error_occurred
> is set
> > after the call to ff_h264_execute_decode_slices. This allows the user to
> detect
> > concealed decoding errors in the call to avcodec_receive_frame
> >
> > Signed-off-by: Amir Pauker
> > ---
> > libavcodec/h264dec.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> > index 00d922f..67dee11 100644
> > --- a/libavcodec/h264dec.c
> > +++ b/libavcodec/h264dec.c
> > @@ -758,6 +758,12 @@ static int decode_nal_units(H264Context *h, const
> uint8_t *buf, int buf_size)
> > }
> >
> > ret = ff_h264_execute_decode_slices(h);
> > +
> > +// set decode_error_flags to allow users to detect concealed
> decoding errors
> > +if( (ret < 0 || h->slice_ctx->er.error_occurred) && h->cur_pic_ptr){
> > +h->cur_pic_ptr->f->decode_error_flags |=
> FF_DECODE_ERROR_INVALID_BITSTREAM|FF_DECODE_ERROR_MISSING_REFERENCE;
> > +}
>
> This is not correct.
> error_occurred does not imply the 2 specific errors
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> What does censorship reveal? It reveals fear. -- Julian Assange
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/3] libavfilter/vf_cover_rect: support for cover image with more pixel format and different width and height
On Tue, Jun 11, 2019 at 01:38:43PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_cover_rect.c | 49 +++--
> 1 file changed, 36 insertions(+), 13 deletions(-)
>
> diff --git a/libavfilter/vf_cover_rect.c b/libavfilter/vf_cover_rect.c
> index 898debf09d..22389b79d2 100644
> --- a/libavfilter/vf_cover_rect.c
> +++ b/libavfilter/vf_cover_rect.c
> @@ -28,6 +28,7 @@
> #include "internal.h"
>
> #include "lavfutils.h"
> +#include "lswsutils.h"
>
> enum mode {
> MODE_COVER,
> @@ -40,6 +41,7 @@ typedef struct CoverContext {
> int mode;
> char *cover_filename;
> AVFrame *cover_frame;
> +AVFrame *match_frame;
> int width, height;
> } CoverContext;
>
> @@ -71,21 +73,21 @@ static int config_input(AVFilterLink *inlink)
> return 0;
> }
>
> -static void cover_rect(CoverContext *cover, AVFrame *in, int offx, int offy)
> +static void cover_rect(AVFrame *cover_frame, AVFrame *in, int offx, int offy)
> {
> int x, y, p;
>
> for (p = 0; p < 3; p++) {
> uint8_t *data = in->data[p] + (offx>>!!p) + (offy>>!!p) *
> in->linesize[p];
> -const uint8_t *src = cover->cover_frame->data[p];
> -int w = AV_CEIL_RSHIFT(cover->cover_frame->width , !!p);
> -int h = AV_CEIL_RSHIFT(cover->cover_frame->height, !!p);
> +const uint8_t *src = cover_frame->data[p];
> +int w = AV_CEIL_RSHIFT(cover_frame->width , !!p);
> +int h = AV_CEIL_RSHIFT(cover_frame->height, !!p);
> for (y = 0; y < h; y++) {
> for (x = 0; x < w; x++) {
> data[x] = src[x];
> }
> data += in->linesize[p];
> -src += cover->cover_frame->linesize[p];
> +src += cover_frame->linesize[p];
> }
> }
> }
> @@ -138,7 +140,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> CoverContext *cover = ctx->priv;
> AVDictionaryEntry *ex, *ey, *ew, *eh;
> int x = -1, y = -1, w = -1, h = -1;
> +enum AVPixelFormat in_format;
> char *xendptr = NULL, *yendptr = NULL, *wendptr = NULL, *hendptr = NULL;
> +AVFrame *cover_frame = NULL;
> +int ret;
>
> ex = av_dict_get(in->metadata, "lavfi.rect.x", NULL, AV_DICT_MATCH_CASE);
> ey = av_dict_get(in->metadata, "lavfi.rect.y", NULL, AV_DICT_MATCH_CASE);
> @@ -167,13 +172,30 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> }
> w = FFMIN(w, in->width - x);
> h = FFMIN(h, in->height - y);
> +in_format = in->format;
>
> if (w > in->width || h > in->height || w <= 0 || h <= 0)
> return AVERROR(EINVAL);
>
> if (cover->cover_frame) {
> -if (w != cover->cover_frame->width || h !=
> cover->cover_frame->height)
> -return AVERROR(EINVAL);
> +if (w != cover->cover_frame->width || h !=
> cover->cover_frame->height ||
> +in_format != cover->cover_frame->format) {
> +if (!cover->match_frame && !(cover->match_frame =
> av_frame_alloc()))
> +return AVERROR(EINVAL);
> +
> +if ((ret = ff_scale_image(cover->match_frame->data,
> cover->match_frame->linesize,
> +w, h, in_format, cover->cover_frame->data,
> cover->cover_frame->linesize,
> +cover->cover_frame->width,
> cover->cover_frame->height,
> +cover->cover_frame->format, ctx)) < 0)
> +return AVERROR(EINVAL);
This looks like the same static cover image would be converted again for each
input frame
which if iam not misreading this would be doing the exact same operation over
and over
again, thats same wastefull
[]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/3] libavfilter/vf_cover_rect.c: free the allocated frame
On Tue, Jun 11, 2019 at 01:38:42PM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavfilter/vf_cover_rect.c | 1 + > 1 file changed, 1 insertion(+) will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg android support
ср, 12 июн. 2019 г. в 01:09, Reimar Döffinger : > On 11.06.2019, at 20:46, Dmitry A wrote: > > > Hello. > > I working on android internals and made some changes in latest ffmpeg for > > making it compilable by clang and some additional changes for making it > > work under android. > > The job is not finished yet but if community has not objections I'd > prefer > > to share these changes and integrate them in ffmpeg instead of making our > > own fork > > It would be best to just share them. > Anything that is "quite clean" should not be an issue to accept. > If it gets very non-standard/Android-specific there might be objections, > especially due to lack of automated testing (see also below), and because > it seems other users do not seem to need them (?). > > > Does community offiicial support android? > > "Support" can mean all kinds of things. > I believe there are quite a few people using it, at least VLC for example. > But none of the "reinvented the wheel" build processes are supported. > As most objective measure, it seems not tested via fate.ffmpeg.org, which > always is a bad sign. > > Best regards, > Reimar Döffinger > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". Thanks for you reply! I'll read about contribution process and start to share patchs step by step. One bug I able to reproduce under linux also when ffmpeg is built snatdalone .. I able to provide exact configuration and mp4 file. It hangs in file protocol during ffurl_connect I still don't understand the root cause ... -- Thanks! Dmitry ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 2/2] doc/filters.texi: don't need to be in gray8 for find image
On Tue, Jun 11, 2019 at 02:07:30PM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > doc/filters.texi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/filters.texi b/doc/filters.texi > index ec1c7c7591..90c57430a6 100644 > --- a/doc/filters.texi > +++ b/doc/filters.texi > @@ -10150,7 +10150,7 @@ It accepts the following options: > > @table @option > @item object > -Filepath of the object image, needs to be in gray8. > +Filepath of the object image. this belongs in the same patch which changes the code accordingly thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] vf_drawtext: Add pkt_pos, pkt_duration, pkt_size as variables
This is on the bug tracker at https://trac.ffmpeg.org/ticket/7947
Created with the help of the excellent Calvin Walton
and rewritten with the advice of the excellent Gyan
---
doc/filters.texi | 24 +++-
libavfilter/vf_drawtext.c | 9 +
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index ec1c7c7591..e2ca2a8c08 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8961,8 +8961,23 @@ the width of the rendered text
@item y
the x and y offset coordinates where the text is drawn.
-These parameters allow the @var{x} and @var{y} expressions to refer
+These parameters allow the @var{x} and @var{y} expressions to refer to
each other, so you can for example specify @code{y=x/dar}.
+
+@item pict_type
+A 1 character description of the current packet's input picture type.
+
+@item pkt_pos
+The current packet's position in the input datastream (in bytes from
the head of the source file).
+
+A value of -1 indicates this info is not available.
+
+@item pkt_duration
+The current packet's input duration.
+
+@item pkt_size
+The current packet's input size (in bytes).
+
@end table
@anchor{drawtext_expansion}
@@ -9032,6 +9047,13 @@ The first argument is mandatory and specifies
the metadata key.
The second argument is optional and specifies a default value, used when the
metadata key is not found or empty.
+Available metadata can be identified by inspecting entries starting with
+TAG included within each frame section printed by running @code{ffprobe
+-show_frames}.
+
+String metadata generated in filters leading to the drawtext filter are
+also available.
+
@item n, frame_num
The frame number, starting from 0.
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 01cd7fa122..8f4badbdb5 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -88,6 +88,9 @@ static const char *const var_names[] = {
"x",
"y",
"pict_type",
+"pkt_pos",
+"pkt_duration",
+"pkt_size",
NULL
};
@@ -125,6 +128,9 @@ enum var_name {
VAR_X,
VAR_Y,
VAR_PICT_TYPE,
+VAR_PKT_POS,
+VAR_PKT_DURATION,
+VAR_PKT_SIZE,
VAR_VARS_NB
};
@@ -1516,6 +1522,9 @@ static int filter_frame(AVFilterLink *inlink,
AVFrame *frame)
NAN : frame->pts * av_q2d(inlink->time_base);
s->var_values[VAR_PICT_TYPE] = frame->pict_type;
+s->var_values[VAR_PKT_POS] = frame->pkt_pos;
+s->var_values[VAR_PKT_DURATION] = frame->pkt_duration *
av_q2d(inlink->time_base);
+s->var_values[VAR_PKT_SIZE] = frame->pkt_size;
s->metadata = frame->metadata;
draw_text(ctx, frame, frame->width, frame->height);
--
2.22.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V3 2/2] checkasm/vf_gblur: add test for horiz_slice simd
> -Original Message- > From: Song, Ruiling > Sent: Friday, June 7, 2019 5:59 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: RE: [FFmpeg-devel] [PATCH V3 2/2] checkasm/vf_gblur: add test for > horiz_slice simd > > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > Of Michael Niedermayer > > Sent: Thursday, June 6, 2019 6:45 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH V3 2/2] checkasm/vf_gblur: add test > for > > horiz_slice simd > > > > On Wed, Jun 05, 2019 at 10:29:36PM +0800, Ruiling Song wrote: > > > Signed-off-by: Ruiling Song > > > --- > > > tests/checkasm/Makefile | 1 + > > > tests/checkasm/checkasm.c | 3 ++ > > > tests/checkasm/checkasm.h | 1 + > > > tests/checkasm/vf_gblur.c | 67 > > +++ > > > tests/fate/checkasm.mak | 1 + > > > 5 files changed, 73 insertions(+) > > > create mode 100644 tests/checkasm/vf_gblur.c > > > > this patchset seems to fix the fate failure of the last > Thanks Michael, I will wait a few more days to see if anybody has comment > on the patch. > Will apply later next week if no objection. Patchset Applied. > > > > > thanks > > > > [...] > > -- > > Michael GnuPG fingerprint: > > 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > He who knows, does not speak. He who speaks, does not know. -- Lao Tsu ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 2/2] doc/filters.texi: don't need to be in gray8 for find image
On Wed, Jun 12, 2019 at 5:23 AM Michael Niedermayer wrote: > On Tue, Jun 11, 2019 at 02:07:30PM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > doc/filters.texi | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/doc/filters.texi b/doc/filters.texi > > index ec1c7c7591..90c57430a6 100644 > > --- a/doc/filters.texi > > +++ b/doc/filters.texi > > @@ -10150,7 +10150,7 @@ It accepts the following options: > > > > @table @option > > @item object > > -Filepath of the object image, needs to be in gray8. > > +Filepath of the object image. > > this belongs in the same patch which changes the code accordingly > > thx > > OK, I'll put into one patch and send update version. > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No snowflake in an avalanche ever feels responsible. -- Voltaire > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/3] libavfilter/vf_cover_rect: support for cover image with more pixel format and different width and height
On Wed, Jun 12, 2019 at 4:51 AM Michael Niedermayer
wrote:
> On Tue, Jun 11, 2019 at 01:38:43PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_cover_rect.c | 49 +++--
> > 1 file changed, 36 insertions(+), 13 deletions(-)
> >
> > diff --git a/libavfilter/vf_cover_rect.c b/libavfilter/vf_cover_rect.c
> > index 898debf09d..22389b79d2 100644
> > --- a/libavfilter/vf_cover_rect.c
> > +++ b/libavfilter/vf_cover_rect.c
> > @@ -28,6 +28,7 @@
> > #include "internal.h"
> >
> > #include "lavfutils.h"
> > +#include "lswsutils.h"
> >
> > enum mode {
> > MODE_COVER,
> > @@ -40,6 +41,7 @@ typedef struct CoverContext {
> > int mode;
> > char *cover_filename;
> > AVFrame *cover_frame;
> > +AVFrame *match_frame;
> > int width, height;
> > } CoverContext;
> >
> > @@ -71,21 +73,21 @@ static int config_input(AVFilterLink *inlink)
> > return 0;
> > }
> >
> > -static void cover_rect(CoverContext *cover, AVFrame *in, int offx, int
> offy)
> > +static void cover_rect(AVFrame *cover_frame, AVFrame *in, int offx, int
> offy)
> > {
> > int x, y, p;
> >
> > for (p = 0; p < 3; p++) {
> > uint8_t *data = in->data[p] + (offx>>!!p) + (offy>>!!p) *
> in->linesize[p];
> > -const uint8_t *src = cover->cover_frame->data[p];
> > -int w = AV_CEIL_RSHIFT(cover->cover_frame->width , !!p);
> > -int h = AV_CEIL_RSHIFT(cover->cover_frame->height, !!p);
> > +const uint8_t *src = cover_frame->data[p];
> > +int w = AV_CEIL_RSHIFT(cover_frame->width , !!p);
> > +int h = AV_CEIL_RSHIFT(cover_frame->height, !!p);
> > for (y = 0; y < h; y++) {
> > for (x = 0; x < w; x++) {
> > data[x] = src[x];
> > }
> > data += in->linesize[p];
> > -src += cover->cover_frame->linesize[p];
> > +src += cover_frame->linesize[p];
> > }
> > }
> > }
> > @@ -138,7 +140,10 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *in)
> > CoverContext *cover = ctx->priv;
> > AVDictionaryEntry *ex, *ey, *ew, *eh;
> > int x = -1, y = -1, w = -1, h = -1;
> > +enum AVPixelFormat in_format;
> > char *xendptr = NULL, *yendptr = NULL, *wendptr = NULL, *hendptr =
> NULL;
> > +AVFrame *cover_frame = NULL;
> > +int ret;
> >
> > ex = av_dict_get(in->metadata, "lavfi.rect.x", NULL,
> AV_DICT_MATCH_CASE);
> > ey = av_dict_get(in->metadata, "lavfi.rect.y", NULL,
> AV_DICT_MATCH_CASE);
> > @@ -167,13 +172,30 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *in)
> > }
> > w = FFMIN(w, in->width - x);
> > h = FFMIN(h, in->height - y);
> > +in_format = in->format;
> >
> > if (w > in->width || h > in->height || w <= 0 || h <= 0)
> > return AVERROR(EINVAL);
> >
> > if (cover->cover_frame) {
> > -if (w != cover->cover_frame->width || h !=
> cover->cover_frame->height)
> > -return AVERROR(EINVAL);
> > +if (w != cover->cover_frame->width || h !=
> cover->cover_frame->height ||
> > +in_format != cover->cover_frame->format) {
> > +if (!cover->match_frame && !(cover->match_frame =
> av_frame_alloc()))
> > +return AVERROR(EINVAL);
> > +
> > +if ((ret = ff_scale_image(cover->match_frame->data,
> cover->match_frame->linesize,
> > +w, h, in_format, cover->cover_frame->data,
> cover->cover_frame->linesize,
> > +cover->cover_frame->width,
> cover->cover_frame->height,
> > +cover->cover_frame->format, ctx)) < 0)
> > +return AVERROR(EINVAL);
>
> This looks like the same static cover image would be converted again for
> each input frame
> which if iam not misreading this would be doing the exact same operation
> over and over
> again, thats same wastefull
>
> I plan to add code t to find more different object with different width
and height, however the cover image is same.
So it's necessary to convert it after get the real find object width and
height. If you use the same width and height with
current code, it'll do the same function. After the patch applied, I'll
send with another patch to avoid conversion every time
if width and height, format is same.
> []
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH, RFC] lavc/vp9dec: fix the multi-thread HWAccel decode error
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Hendrik Leppkes > Sent: Tuesday, June 11, 2019 15:50 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH, RFC] lavc/vp9dec: fix the multi-thread > HWAccel decode error > > On Tue, Jun 11, 2019 at 9:20 AM Linjie Fu wrote: > > > > Fix the multi-thread HWAccel decode error for vp9. > > > > VP9 supports the resolution changing. In multi-thread mode, worker- > threads > > destroy and free the first created VAAPIDecodeContext if resolution > change > > happens and create new one. Other threads still request to destroy > previous > > and demand for new context. This leads to decode failures and memory > issue. > > > > Modify to call hwaccel_uninit/hwaccel_init by ff_thread_get_format only > > when the first-come thread detected the resolution changing. > > > > s->gf_fmt, s->w and s->h are updated through > vp9_decode_update_thread_context, wouldn't they prevent > re-initialization already, as long as the size only changes once? > If not, why not? Perhaps thats a better avenue to fix it, then hacky > conditions like this one. > Thanks Hendrik, need to reconsider this and seek for a better solution. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v10 1/2] lavf/vf_transpose: add exif orientation support
On Sun, Jun 9, 2019 at 2:28 PM Jun Li wrote:
> Add exif orientation support and expose an option.
> ---
> libavfilter/hflip.h| 2 +
> libavfilter/transpose.h| 14
> libavfilter/vf_hflip.c | 40 ++---
> libavfilter/vf_transpose.c | 168 -
> 4 files changed, 192 insertions(+), 32 deletions(-)
>
> diff --git a/libavfilter/hflip.h b/libavfilter/hflip.h
> index 204090dbb4..4e89bae3fc 100644
> --- a/libavfilter/hflip.h
> +++ b/libavfilter/hflip.h
> @@ -35,5 +35,7 @@ typedef struct FlipContext {
>
> int ff_hflip_init(FlipContext *s, int step[4], int nb_planes);
> void ff_hflip_init_x86(FlipContext *s, int step[4], int nb_planes);
> +int ff_hflip_config_props(FlipContext* s, AVFilterLink *inlink);
> +int ff_hflip_filter_slice(FlipContext *s, AVFrame *in, AVFrame *out, int
> job, int nb_jobs, int vlifp);
>
> #endif /* AVFILTER_HFLIP_H */
> diff --git a/libavfilter/transpose.h b/libavfilter/transpose.h
> index aa262b9487..5da08bddc0 100644
> --- a/libavfilter/transpose.h
> +++ b/libavfilter/transpose.h
> @@ -34,4 +34,18 @@ enum TransposeDir {
> TRANSPOSE_VFLIP,
> };
>
> +enum OrientationType {
> +ORIENTATION_AUTO_TRANSPOSE = -2,
> +ORIENTATION_AUTO_FLIP = -1,
> +ORIENTATION_NONE = 0,
> +ORIENTATION_NORMAL,
> +ORIENTATION_HFLIP,
> +ORIENTATION_ROTATE180,
> +ORIENTATION_VFLIP,
> +ORIENTATION_HFLIP_ROTATE270CW,
> +ORIENTATION_ROTATE90CW,
> +ORIENTATION_HFLIP_ROTATE90CW,
> +ORIENTATION_ROTATE270CW
> +};
> +
> #endif
> diff --git a/libavfilter/vf_hflip.c b/libavfilter/vf_hflip.c
> index b77afc77fc..d24ca5c2e7 100644
> --- a/libavfilter/vf_hflip.c
> +++ b/libavfilter/vf_hflip.c
> @@ -125,9 +125,8 @@ static void hflip_qword_c(const uint8_t *ssrc, uint8_t
> *ddst, int w)
> dst[j] = src[-j];
> }
>
> -static int config_props(AVFilterLink *inlink)
> +int ff_hflip_config_props(FlipContext* s, AVFilterLink *inlink)
> {
> -FlipContext *s = inlink->dst->priv;
> const AVPixFmtDescriptor *pix_desc =
> av_pix_fmt_desc_get(inlink->format);
> const int hsub = pix_desc->log2_chroma_w;
> const int vsub = pix_desc->log2_chroma_h;
> @@ -144,6 +143,12 @@ static int config_props(AVFilterLink *inlink)
> return ff_hflip_init(s, s->max_step, nb_planes);
> }
>
> +static int config_props(AVFilterLink *inlink)
> +{
> +FlipContext *s = inlink->dst->priv;
> +return ff_hflip_config_props(s, inlink);
> +}
> +
> int ff_hflip_init(FlipContext *s, int step[4], int nb_planes)
> {
> int i;
> @@ -170,14 +175,10 @@ typedef struct ThreadData {
> AVFrame *in, *out;
> } ThreadData;
>
> -static int filter_slice(AVFilterContext *ctx, void *arg, int job, int
> nb_jobs)
> +int ff_hflip_filter_slice(FlipContext *s, AVFrame *in, AVFrame *out, int
> job, int nb_jobs, int vflip)
> {
> -FlipContext *s = ctx->priv;
> -ThreadData *td = arg;
> -AVFrame *in = td->in;
> -AVFrame *out = td->out;
> uint8_t *inrow, *outrow;
> -int i, plane, step;
> +int i, plane, step, outlinesize;
>
> for (plane = 0; plane < 4 && in->data[plane] && in->linesize[plane];
> plane++) {
> const int width = s->planewidth[plane];
> @@ -187,19 +188,36 @@ static int filter_slice(AVFilterContext *ctx, void
> *arg, int job, int nb_jobs)
>
> step = s->max_step[plane];
>
> -outrow = out->data[plane] + start * out->linesize[plane];
> -inrow = in ->data[plane] + start * in->linesize[plane] + (width
> - 1) * step;
> +if (vflip) {
> +outrow = out->data[plane] + (height - start - 1)*
> out->linesize[plane];
> +outlinesize = -out->linesize[plane];
> +} else {
> +outrow = out->data[plane] + start * out->linesize[plane];
> +outlinesize = out->linesize[plane];
> +}
> +
> +inrow = in->data[plane] + start * in->linesize[plane] + (width -
> 1) * step;
> +
> for (i = start; i < end; i++) {
> s->flip_line[plane](inrow, outrow, width);
>
> inrow += in ->linesize[plane];
> -outrow += out->linesize[plane];
> +outrow += outlinesize;
> }
> }
>
> return 0;
> }
>
> +static int filter_slice(AVFilterContext *ctx, void *arg, int job, int
> nb_jobs)
> +{
> +FlipContext *s = ctx->priv;
> +ThreadData *td = arg;
> +AVFrame *in = td->in;
> +AVFrame *out = td->out;
> +return ff_hflip_filter_slice(s, in, out, job, nb_jobs, 0);
> +}
> +
> static int filter_frame(AVFilterLink *inlink, AVFrame *in)
> {
> AVFilterContext *ctx = inlink->dst;
> diff --git a/libavfilter/vf_transpose.c b/libavfilter/vf_transpose.c
> index dd54947bd9..05dc04a89f 100644
> --- a/libavfilter/vf_transpose.c
> +++ b/libavfilter/vf_transpose.c
> @@ -39,6 +39,7 @@
> #include "internal.h"
> #include "video.h"
> #include "transpose.h"
> +#include "hflip.h"
>
> typedef struct TransVtable {
> void (*transpose_8x8)(uint8_t *src,
