Re: [FFmpeg-devel] [PATCH v9 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper

[Sun, Jing A]

Friday, March 22, 2019 5:54 PM, Carl Eugen Hoyos:

>What I meant is:
>I don't understand the comment (and your mail), it says above the 
>functionality has to be disabled but you write it works fine.
>The comment is (still) unclear imo.

>Carl Eugen

Hi Carl, it works functionally, but there is something that can be done, and 
will be done in the further, to improve its performance a little.

- Jing 
___
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/2] vf_crop: Add support for cropping hardware frames

[Philip Langdale via ffmpeg-devel]

On Sat, 23 Mar 2019 16:18:48 +
Mark Thompson  wrote:

> Set the cropping fields in the AVFrame.
> ---
>  libavfilter/vf_crop.c | 74
> +-- 1 file changed, 51
> insertions(+), 23 deletions(-)
> 
> There is the slightly unfortunate effect the filter links don't carry
> the cropping information, so we don't know how big the cropped output
> is in following links until we actually get a frame.
> 
> For example, to get the middle ninth of a stream:
> 
> ./ffmpeg_g -y -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
> -hwaccel_output_format vaapi -i in.mp4 -an -vf
> "crop=iw/3:ih/3:iw/3:ih/3,scale_vaapi=iw/3:ih/3" -c:v h264_vaapi
> out.mp4
> 
> Without the extra arguments to scale it will take the cropped part
> correctly but then scale it to the original size.
> 
> diff --git a/libavfilter/vf_crop.c b/libavfilter/vf_crop.c
> index 84be4c7d0d..7f6b0f03d3 100644
> --- a/libavfilter/vf_crop.c
> +++ b/libavfilter/vf_crop.c
> @@ -98,9 +98,17 @@ static int query_formats(AVFilterContext *ctx)
>  
>  for (fmt = 0; av_pix_fmt_desc_get(fmt); fmt++) {
>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
> -if (!(desc->flags & (AV_PIX_FMT_FLAG_HWACCEL |
> AV_PIX_FMT_FLAG_BITSTREAM)) &&
> -!((desc->log2_chroma_w || desc->log2_chroma_h)
> && !(desc->flags & AV_PIX_FMT_FLAG_PLANAR)) &&
> -(ret = ff_add_format(, fmt)) < 0)
> +if (desc->flags & AV_PIX_FMT_FLAG_BITSTREAM)
> +continue;
> +if (!(desc->flags & AV_PIX_FMT_FLAG_HWACCEL)) {
> +// Not usable if there is any subsampling but the format
> is
> +// not planar (e.g. YUYV422).
> +if ((desc->log2_chroma_w || desc->log2_chroma_h) &&
> +!(desc->flags & AV_PIX_FMT_FLAG_PLANAR))
> +continue;
> +}
> +ret = ff_add_format(, fmt);
> +if (ret < 0)
>  return ret;
>  }
>  
> @@ -157,8 +165,14 @@ static int config_input(AVFilterLink *link)
>  s->var_values[VAR_POS]   = NAN;
>  
>  av_image_fill_max_pixsteps(s->max_step, NULL, pix_desc);
> -s->hsub = pix_desc->log2_chroma_w;
> -s->vsub = pix_desc->log2_chroma_h;
> +
> +if (pix_desc->flags & AV_PIX_FMT_FLAG_HWACCEL) {
> +s->hsub = 1;
> +s->vsub = 1;
> +} else {
> +s->hsub = pix_desc->log2_chroma_w;
> +s->vsub = pix_desc->log2_chroma_h;
> +}
>  
>  if ((ret = av_expr_parse_and_eval(, (expr = s->w_expr),
>var_names, s->var_values,
> @@ -237,9 +251,15 @@ fail_expr:
>  static int config_output(AVFilterLink *link)
>  {
>  CropContext *s = link->src->priv;
> +const AVPixFmtDescriptor *desc =
> av_pix_fmt_desc_get(link->format); 
> -link->w = s->w;
> -link->h = s->h;
> +if (desc->flags & AV_PIX_FMT_FLAG_HWACCEL) {
> +// Hardware frames adjust the cropping regions rather than
> +// changing the frame size.
> +} else {
> +link->w = s->w;
> +link->h = s->h;
> +}
>  link->sample_aspect_ratio = s->out_sar;
>  
>  return 0;
> @@ -252,9 +272,6 @@ static int filter_frame(AVFilterLink *link,
> AVFrame *frame) const AVPixFmtDescriptor *desc =
> av_pix_fmt_desc_get(link->format); int i;
>  
> -frame->width  = s->w;
> -frame->height = s->h;
> -
>  s->var_values[VAR_N] = link->frame_count_out;
>  s->var_values[VAR_T] = frame->pts == AV_NOPTS_VALUE ?
>  NAN : frame->pts * av_q2d(link->time_base);
> @@ -285,22 +302,33 @@ static int filter_frame(AVFilterLink *link,
> AVFrame *frame) (int)s->var_values[VAR_N], s->var_values[VAR_T],
> s->var_values[VAR_POS], s->x, s->y, s->x+s->w, s->y+s->h);
>  
> -frame->data[0] += s->y * frame->linesize[0];
> -frame->data[0] += s->x * s->max_step[0];
> -
> -if (!(desc->flags & AV_PIX_FMT_FLAG_PAL || desc->flags &
> FF_PSEUDOPAL)) {
> -for (i = 1; i < 3; i ++) {
> -if (frame->data[i]) {
> -frame->data[i] += (s->y >> s->vsub) *
> frame->linesize[i];
> -frame->data[i] += (s->x * s->max_step[i]) >> s->hsub;
> +if (desc->flags & AV_PIX_FMT_FLAG_HWACCEL) {
> +frame->crop_top   += s->y;
> +frame->crop_left  += s->x;
> +frame->crop_bottom = frame->height - frame->crop_top -
> frame->crop_bottom - s->h;
> +frame->crop_right  = frame->width  - frame->crop_left -
> frame->crop_right - s->w; +
> +} else {
> +frame->width  = s->w;
> +frame->height = s->h;
> +
> +frame->data[0] += s->y * frame->linesize[0];
> +frame->data[0] += s->x * s->max_step[0];
> +
> +if (!(desc->flags & AV_PIX_FMT_FLAG_PAL || desc->flags &
> FF_PSEUDOPAL)) {
> +for (i = 1; i < 3; i ++) {
> +if (frame->data[i]) {
> +frame->data[i] += (s->y >> s->vsub) *
> frame->linesize[i];
> +frame->data[i] += (s->x * s->max_step[i]) >>
> s->hsub;
> +   

Re: [FFmpeg-devel] [PATCH][FFmpeg-devel v2] Add GPU accelerated video crop filter

[Philip Langdale via ffmpeg-devel]

On Sat, 23 Mar 2019 23:51:10 +0800
UsingtcNower  wrote:

> Signed-off-by: UsingtcNower 
> ---
>  Changelog   |   1 +
>  configure   |   1 +
>  doc/filters.texi|  31 +++
>  libavfilter/Makefile|   1 +
>  libavfilter/allfilters.c|   1 +
>  libavfilter/version.h   |   2 +-
>  libavfilter/vf_crop_cuda.c  | 638
> 
> libavfilter/vf_crop_cuda.cu | 109  8 files changed, 783
> insertions(+), 1 deletion(-) create mode 100644
> libavfilter/vf_crop_cuda.c create mode 100644
> libavfilter/vf_crop_cuda.cu
> 
> diff --git a/Changelog b/Changelog
> index ad7e82f..f224fc8 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -20,6 +20,7 @@ version :
>  - libaribb24 based ARIB STD-B24 caption support (profiles A and C)
>  - Support decoding of HEVC 4:4:4 content in nvdec and cuviddec
>  - removed libndi-newtek
> +- crop_cuda GPU accelerated video crop filter

Hi,

Timo and Mark and I have been discussing this, and we think the right
thing to do is add support to vf_scale_cuda to respect the crop
properties on an input AVFrame. Mark posted a patch to vf_crop to
ensure that the properties are set, and then the scale filter should
respect those properties if they are set. You can look at
vf_scale_vaapi for how the properties are read, but they will require
explicit handling to adjust the src dimensions passed to the scale
filter.

This will be a more efficient way of handling crops, in terms of total
lines of code and also allowing crop/scale with one less copy.

I know this is quite different from the approach you've taken here, and
we appreciate the work you've done, but it should be better overall to
implement this integrated method.

Thanks,

>  
>  version 4.1:
> diff --git a/configure b/configure
> index 331393f..3f3ac2f 100755
> --- a/configure
> +++ b/configure
> @@ -2973,6 +2973,7 @@ qsvvpp_select="qsv"
>  vaapi_encode_deps="vaapi"
>  v4l2_m2m_deps="linux_videodev2_h sem_timedwait"
>  
> +crop_cuda_filter_deps="ffnvcodec cuda_nvcc"
>  hwupload_cuda_filter_deps="ffnvcodec"
>  scale_npp_filter_deps="ffnvcodec libnpp"
>  scale_cuda_filter_deps="ffnvcodec cuda_nvcc"
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 4ffb392..ee16a2d 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -7415,6 +7415,37 @@ If the specified expression is not valid, it
> is kept at its current value.
>  @end table
>  
> +@section crop_cuda
> +
> +Crop the input video to given dimensions, implemented in CUDA.
> +
> +It accepts the following parameters:
> +
> +@table @option
> +
> +@item w
> +The width of the output video. It defaults to @code{iw}.
> +This expression is evaluated only once during the filter
> +configuration.
> +
> +@item h
> +The height of the output video. It defaults to @code{ih}.
> +This expression is evaluated only once during the filter
> +configuration.
> +
> +@item x
> +The horizontal position, in the input video, of the left edge of the
> output +video. It defaults to @code{(in_w-out_w)/2}.
> +This expression is evaluated only once during the filter
> +configuration.
> +
> +@item y
> +The vertical position, in the input video, of the top edge of the
> output video. +It defaults to @code{(in_h-out_h)/2}.
> +This expression is evaluated only once during the filter
> +configuration.
> +@end table
> +
>  @section cropdetect
>  
>  Auto-detect the crop size.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index fef6ec5..84df037 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -187,6 +187,7 @@ OBJS-$(CONFIG_COPY_FILTER)   +=
> vf_copy.o OBJS-$(CONFIG_COREIMAGE_FILTER)  +=
> vf_coreimage.o OBJS-$(CONFIG_COVER_RECT_FILTER) +=
> vf_cover_rect.o lavfutils.o
> OBJS-$(CONFIG_CROP_FILTER)   += vf_crop.o
> +OBJS-$(CONFIG_CROP_CUDA_FILTER)  += vf_crop_cuda.o
> vf_crop_cuda.ptx.o OBJS-$(CONFIG_CROPDETECT_FILTER) +=
> vf_cropdetect.o OBJS-$(CONFIG_CUE_FILTER)+=
> f_cue.o OBJS-$(CONFIG_CURVES_FILTER) += vf_curves.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index c51ae0f..550e545 100644 --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -175,6 +175,7 @@ extern AVFilter ff_vf_copy;
>  extern AVFilter ff_vf_coreimage;
>  extern AVFilter ff_vf_cover_rect;
>  extern AVFilter ff_vf_crop;
> +extern AVFilter ff_vf_crop_cuda;
>  extern AVFilter ff_vf_cropdetect;
>  extern AVFilter ff_vf_cue;
>  extern AVFilter ff_vf_curves;
> diff --git a/libavfilter/version.h b/libavfilter/version.h
> index c71282c..5aa95f4 100644
> --- a/libavfilter/version.h
> +++ b/libavfilter/version.h
> @@ -31,7 +31,7 @@
>  
>  #define LIBAVFILTER_VERSION_MAJOR   7
>  #define LIBAVFILTER_VERSION_MINOR  48
> -#define LIBAVFILTER_VERSION_MICRO 100
> +#define LIBAVFILTER_VERSION_MICRO 101
>  
>  #define LIBAVFILTER_VERSION_INT
> 

Re: [FFmpeg-devel] Added support for XV video files

[Shivam Goyal]

On 3/25/19 4:47 AM, Moritz Barsnick wrote:

On Sun, Mar 24, 2019 at 13:39:09 +0100, Moritz Barsnick wrote:

Another thing:


On Sun, Mar 24, 2019 at 16:35:40 +0530, Shivam Goyal wrote:

  libavformat/xvdec.c  | 1395 ++
  libavformat/xvtools.h|   95 +++

You shouldn't put actual code in header files, that's really bad style.
If you need complementary functions, they should be defined in e.g.
xvtools.c and declared in xvtools.h.


I would saperate the two file, would send another patch with all the 
change.


Thanks



Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel 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] Added support for XV video files

[Shivam Goyal]

On 3/24/19 6:09 PM, Moritz Barsnick wrote:

On Sun, Mar 24, 2019 at 16:35:40 +0530, Shivam Goyal wrote:

  libavformat/xvdec.c  | 1395 ++
  libavformat/xvtools.h|   95 +++

This looks like a 90% copy of flvdec, with some modifications. I
believe it should be merged into flvdec as an additional supported
format, thereby sharing the code.



Yeah as XV file is an flv file i used the same demuxer with improvements 
specific for xv video. It can be merged with flvdec.c, but than i 
thought that the problem is with input functions which are present in 
the entire flvdec.c file. So, if i to merge it, i have to check which 
file is it xv or flv (or to store it in a variable in the FLVContext, 
which would be intialised at the time of reading header) whenever we 
need to read from the input file, Which would recquire more processing 
and would make the program slow for both xv  and flv files, and the 
total no. of occurences of the functions avio_r8, avio_rb16, avio_rb24, 
avio_rb32, avio_rb64 is around 39 . So, should i merge it with flvdec.c.



+// /*
+//  * XV demuxer
+//  * Copyright (c) 2003 The FFmpeg Project

Crazy comment style. ;-)


Sorry, i commented it twice and forgot to remove it. I would improve it.

Thanks



Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel 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] Add scale parameter to lensfun filter

[daniel . playfair . cal]

From: Daniel Playfair Cal 

The lensfun filter wraps the lensfun library which performs
transformations on videos to correct for lens distortion. Often this
results in areas in the input being mapped to areas that fall outside
the boundaries of the output. The library has a parameter called scale
which is a scale factor applied to the output video. By decreasing it it
is possible to regain the areas of the video which would otherwise have
been lost. There is a special value of 0 which indicates that the
library should automatically determine a scale factor that results in
the output frame being filled (i.e. little or no black/unmapped areas).

This patch adds a corresponding scale option to the lensfun filter which
is passed through to the library. The existing behaviour of using the
automatic value of 0 is retained as the default behaviour, while other
values will be passed through to the library.

Signed-off-by: Daniel Playfair Cal 
---
 doc/filters.texi | 9 +
 libavfilter/vf_lensfun.c | 4 +++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 4ffb392a7f..c04fe3a4b6 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11417,6 +11417,15 @@ focus distance is only used for vignetting and only 
slightly affects the
 vignetting correction process. If unknown, leave it at the default value (which
 is 1000).
 
+@item scale
+The scale factor which is applied after transformation. After correction the
+video is no longer necessarily rectangular. This parameter controls how much of
+the resulting image is visible. The value 0 means that a value will be chosen
+automatically such that there is little or no unmapped area in the output
+image. 1.0 means that no additional scaling is done. Lower values may result
+in more of the corrected image being visible, while higher values may avoid
+unmapped areas in the output.
+
 @item target_geometry
 The target geometry of the output image/video. The following values are valid
 options:
diff --git a/libavfilter/vf_lensfun.c b/libavfilter/vf_lensfun.c
index 901cd9ff90..3b723dd2d0 100644
--- a/libavfilter/vf_lensfun.c
+++ b/libavfilter/vf_lensfun.c
@@ -79,6 +79,7 @@ typedef struct LensfunContext {
 float focal_length;
 float aperture;
 float focus_distance;
+float scale;
 int target_geometry;
 int reverse;
 int interpolation_type;
@@ -108,6 +109,7 @@ static const AVOption lensfun_options[] = {
 { "focal_length", "focal length of video (zoom; constant for the duration 
of the use of this filter)", OFFSET(focal_length), AV_OPT_TYPE_FLOAT, 
{.dbl=18}, 0.0, DBL_MAX, FLAGS },
 { "aperture", "aperture (constant for the duration of the use of this 
filter)", OFFSET(aperture), AV_OPT_TYPE_FLOAT, {.dbl=3.5}, 0.0, DBL_MAX, FLAGS 
},
 { "focus_distance", "focus distance (constant for the duration of the use 
of this filter)", OFFSET(focus_distance), AV_OPT_TYPE_FLOAT, {.dbl=1000.0f}, 
0.0, DBL_MAX, FLAGS },
+{ "scale", "scale factor applied after corrections (0.0 means automatic 
scaling)", OFFSET(scale), AV_OPT_TYPE_FLOAT, {.dbl=0.0}, 0.0, DBL_MAX, FLAGS },
 { "target_geometry", "target geometry of the lens correction (only when 
geometry correction is enabled)", OFFSET(target_geometry), AV_OPT_TYPE_INT, 
{.i64=LF_RECTILINEAR}, 0, INT_MAX, FLAGS, "lens_geometry" },
 { "rectilinear", "rectilinear lens (default)", 0, AV_OPT_TYPE_CONST, 
{.i64=LF_RECTILINEAR}, 0, 0, FLAGS, "lens_geometry" },
 { "fisheye", "fisheye lens", 0, AV_OPT_TYPE_CONST, {.i64=LF_FISHEYE}, 
0, 0, FLAGS, "lens_geometry" },
@@ -228,7 +230,7 @@ static int config_props(AVFilterLink *inlink)
lensfun->focal_length,
lensfun->aperture,
lensfun->focus_distance,
-   0.0,
+   lensfun->scale,
lensfun->target_geometry,
lensfun_mode,
lensfun->reverse);
-- 
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 2/5] libavformat/avisynth: enable additional pix_fmts

[Stephen Hutchinson]

On 3/24/2019 7:07 PM, Carl Eugen Hoyos wrote:

2019-03-24 21:25 GMT+01:00, Stephen Hutchinson :

These pix_fmts have been added to FFmpeg in the 31 months since
commit 92916e8542e425ca20daddb490261a5818643206 added support for
the larger number of pix_fmts that AviSynth+ can use. They were
present in AviSynth+ even then, just not in libavutil.
+/* Single precision floating point Planar RGB (AviSynth+) */
+case AVS_CS_RGBPS:
+st->codecpar->format = AV_PIX_FMT_GBRPF32;
+/* Single precision floating point Planar RGB with Alpha (AviSynth+) */
+case AVS_CS_RGBAPS:
+st->codecpar->format = AV_PIX_FMT_GBRAPF32;

Were you able to test these two in any way?
Is there absolutely no danger that they mean something
completely different in avisynth?
There shouldn't be any danger whatsoever.  AviSynth+ supports 32bpp 
video only as being floating point¹,
and the plane order is exactly the same as the other RGB(A)P formats 
libavformat already support in

AviSynth scripts².

AviSynth+-side, they can be tested with relatively simple scripts that 
generate content in these pix_fmts.

Planar RGB Float:
Version().ConvertToPlanarRGB().ConvertBits(32) # ConvertToFloat() is an 
older, more specific alternative to the ConvertBits call

or
BlankClip(pixel_type="RGBPS")


Planar RGBA Float:
Version().ConvertToPlanarRGB().ConvertBits(32).AddAlphaPlane()
or
BlankClip(pixel_type="RGBAPS")

I also tested with real video input. I don't have any natively-float 
RGB(A) samples,

so I used the above conversion functions on a standard 8bpp 4:2:0 input, and
verified that the script is detected as gbr(a)pf32 in FFmpeg, and the actual
output was correct when previewed with a build of mpv linked against the 
patched
libavformat (and it also detected the video as gbr(a)pf32).  I wasn't 
able to preview
either of those formats in ffplay, but I think that may simply be a 
problem with the
way I built SDL2, unless SDL2 itself doesn't support floating-point 
RGB(A); the

Y32/GRAYF32 test worked in ffplay.

¹http://avisynth.nl/index.php/Avisynthplus_color_formats (see footnote 
2, linked from the Bit Depth column in the table)


²http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/avisynth.c;h=250a489321edc6b150e079d2c960c47be48f6b37;hb=c3b517dac2bbd3007c5ac8fc61efe87661dda5c0#l100,
the formats themselves defined in avisynth_c.h (using the 
AVS_GENERIC_RGBP and AVS_GENERIC_RGBAP values):

http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/avisynth/avisynth_c.h;h=605b92ae62f94e374242dc90f1e4f2ea1f7ac864;hb=c3b517dac2bbd3007c5ac8fc61efe87661dda5c0#l186
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/avisynth/avisynth_c.h;h=605b92ae62f94e374242dc90f1e4f2ea1f7ac864;hb=c3b517dac2bbd3007c5ac8fc61efe87661dda5c0#l194

___
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] avformat/rtsp: Add https tunneling support

[Carl Eugen Hoyos]

2019-03-22 0:58 GMT+01:00, Jun Li :
> Add https based tunneling for RTSP/RTP. Tested on Axis and Bosch cameras.
> Https is widely used for security consideration.

Patch applied.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avformat/rtsp: Add https tunneling support

[Jun Li]

On Thu, Mar 21, 2019 at 4:58 PM Jun Li  wrote:

> Add https based tunneling for RTSP/RTP. Tested on Axis and Bosch cameras.
> Https is widely used for security consideration.
> ---
>  libavformat/rtsp.c | 8 ++--
>  libavformat/rtsp.h | 1 +
>  2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index ae8811234a..4661654967 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -87,6 +87,7 @@ const AVOption ff_rtsp_options[] = {
>  { "tcp", "TCP", 0, AV_OPT_TYPE_CONST, {.i64 = 1 <<
> RTSP_LOWER_TRANSPORT_TCP}, 0, 0, DEC|ENC, "rtsp_transport" }, \
>  { "udp_multicast", "UDP multicast", 0, AV_OPT_TYPE_CONST, {.i64 = 1
> << RTSP_LOWER_TRANSPORT_UDP_MULTICAST}, 0, 0, DEC, "rtsp_transport" },
>  { "http", "HTTP tunneling", 0, AV_OPT_TYPE_CONST, {.i64 = (1 <<
> RTSP_LOWER_TRANSPORT_HTTP)}, 0, 0, DEC, "rtsp_transport" },
> +{ "https", "HTTPS tunneling", 0, AV_OPT_TYPE_CONST, {.i64 = (1 <<
> RTSP_LOWER_TRANSPORT_HTTPS )}, 0, 0, DEC, "rtsp_transport" },
>  RTSP_FLAG_OPTS("rtsp_flags", "set RTSP flags"),
>  { "listen", "wait for incoming connections", 0, AV_OPT_TYPE_CONST,
> {.i64 = RTSP_FLAG_LISTEN}, 0, 0, DEC, "rtsp_flags" },
>  { "prefer_tcp", "try RTP via TCP first, if available", 0,
> AV_OPT_TYPE_CONST, {.i64 = RTSP_FLAG_PREFER_TCP}, 0, 0, DEC|ENC,
> "rtsp_flags" },
> @@ -1669,6 +1670,7 @@ int ff_rtsp_connect(AVFormatContext *s)
>  RTSPMessageHeader reply1, *reply = 
>  int lower_transport_mask = 0;
>  int default_port = RTSP_DEFAULT_PORT;
> +int https_tunnel = 0;
>  char real_challenge[64] = "";
>  struct sockaddr_storage peer;
>  socklen_t peer_len = sizeof(peer);
> @@ -1687,7 +1689,9 @@ int ff_rtsp_connect(AVFormatContext *s)
>  s->max_delay = s->iformat ? DEFAULT_REORDERING_DELAY : 0;
>
>  rt->control_transport = RTSP_MODE_PLAIN;
> -if (rt->lower_transport_mask & (1 << RTSP_LOWER_TRANSPORT_HTTP)) {
> +if (rt->lower_transport_mask & ((1 << RTSP_LOWER_TRANSPORT_HTTP) |
> +(1 << RTSP_LOWER_TRANSPORT_HTTPS))) {
> +https_tunnel = !!(rt->lower_transport_mask & (1 <<
> RTSP_LOWER_TRANSPORT_HTTPS));
>  rt->lower_transport_mask = 1 << RTSP_LOWER_TRANSPORT_TCP;
>  rt->control_transport = RTSP_MODE_TUNNEL;
>  }
> @@ -1741,7 +1745,7 @@ redirect:
>  char sessioncookie[17];
>  char headers[1024];
>
> -ff_url_join(httpname, sizeof(httpname), "http", auth, host, port,
> "%s", path);
> +ff_url_join(httpname, sizeof(httpname), https_tunnel ? "https" :
> "http", auth, host, port, "%s", path);
>  snprintf(sessioncookie, sizeof(sessioncookie), "%08x%08x",
>   av_get_random_seed(), av_get_random_seed());
>
> diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
> index 9a7f366b39..b49278fc20 100644
> --- a/libavformat/rtsp.h
> +++ b/libavformat/rtsp.h
> @@ -42,6 +42,7 @@ enum RTSPLowerTransport {
>  RTSP_LOWER_TRANSPORT_HTTP = 8,  /**< HTTP tunneled - not a
> proper
>   transport mode as such,
>   only for use via
> AVOptions */
> +RTSP_LOWER_TRANSPORT_HTTPS, /**< HTTPS tunneled */
>  RTSP_LOWER_TRANSPORT_CUSTOM = 16,   /**< Custom IO - not a public
>   option for
> lower_transport_mask,
>   but set in the SDP
> demuxer based
> --
> 2.17.1
>


Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Added support for XV video files

[Moritz Barsnick]

On Sun, Mar 24, 2019 at 13:39:09 +0100, Moritz Barsnick wrote:

Another thing:

> On Sun, Mar 24, 2019 at 16:35:40 +0530, Shivam Goyal wrote:
> >  libavformat/xvdec.c  | 1395 ++
> >  libavformat/xvtools.h|   95 +++

You shouldn't put actual code in header files, that's really bad style.
If you need complementary functions, they should be defined in e.g.
xvtools.c and declared in xvtools.h.

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/5] libavformat/avisynth: enable additional pix_fmts

[Carl Eugen Hoyos]

2019-03-24 21:25 GMT+01:00, Stephen Hutchinson :
> These pix_fmts have been added to FFmpeg in the 31 months since
> commit 92916e8542e425ca20daddb490261a5818643206 added support for
> the larger number of pix_fmts that AviSynth+ can use. They were
> present in AviSynth+ even then, just not in libavutil.

> +/* Single precision floating point Planar RGB (AviSynth+) */
> +case AVS_CS_RGBPS:
> +st->codecpar->format = AV_PIX_FMT_GBRPF32;

> +/* Single precision floating point Planar RGB with Alpha (AviSynth+) */
> +case AVS_CS_RGBAPS:
> +st->codecpar->format = AV_PIX_FMT_GBRAPF32;

Were you able to test these two in any way?
Is there absolutely no danger that they mean something
completely different in avisynth?

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/5] avcodec/ivi: Factor ref_mb check out

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/ivi.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/libavcodec/ivi.c b/libavcodec/ivi.c
index 71bf0e6e1c..1a496d9b2d 100644
--- a/libavcodec/ivi.c
+++ b/libavcodec/ivi.c
@@ -806,10 +806,11 @@ static int ivi_process_empty_tile(AVCodecContext *avctx, 
IVIBandDesc *band,
 mb->mv_y= 0;
 }
 
-if (band->inherit_qdelta && ref_mb)
+if (ref_mb) {
+if (band->inherit_qdelta)
 mb->q_delta = ref_mb->q_delta;
 
-if (band->inherit_mv && ref_mb) {
+if (band->inherit_mv) {
 /* motion vector inheritance */
 if (mv_scale) {
 mb->mv_x = ivi_scale_mv(ref_mb->mv_x, mv_scale);
@@ -836,10 +837,10 @@ static int ivi_process_empty_tile(AVCodecContext *avctx, 
IVIBandDesc *band,
 }
 }
 }
+ref_mb++;
+}
 
 mb++;
-if (ref_mb)
-ref_mb++;
 mb_offset += band->mb_size;
 } // for x
 offs += row_offset;
-- 
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/5] avcodec/proresdec2: decode picture header before frame allocation

[Michael Niedermayer]

Fixes: Timeout (21sec -> 0.3sec)
Fixes: 
13716/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PRORES_fuzzer-575559145600

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/proresdec2.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index 6209c229c9..2652a31c81 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -778,9 +778,6 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 buf += frame_hdr_size;
 buf_size -= frame_hdr_size;
 
-if ((ret = ff_thread_get_buffer(avctx, , 0)) < 0)
-return ret;
-
  decode_picture:
 pic_size = decode_picture_header(avctx, buf, buf_size);
 if (pic_size < 0) {
@@ -788,6 +785,10 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 return pic_size;
 }
 
+if (ctx->first_field)
+if ((ret = ff_thread_get_buffer(avctx, , 0)) < 0)
+return ret;
+
 if ((ret = decode_picture(avctx)) < 0) {
 av_log(avctx, AV_LOG_ERROR, "error decoding picture\n");
 return ret;
-- 
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/5] avcodec/ivi: Reduce dereferencing structs in inner loop of ivi_process_empty_tile()

[Michael Niedermayer]

This speeds the code up by about 15%
Testcase: 
13779/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_INDEO4_fuzzer-5699589711069184

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/ivi.c | 45 +
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/libavcodec/ivi.c b/libavcodec/ivi.c
index f87964afd4..0f77873a83 100644
--- a/libavcodec/ivi.c
+++ b/libavcodec/ivi.c
@@ -775,24 +775,29 @@ static int ivi_process_empty_tile(AVCodecContext *avctx, 
const IVIBandDesc *band
 const int16_t   *src;
 int16_t *dst;
 ivi_mc_func mc_no_delta_func;
+int clear_first = !band->qdelta_present && !band->plane && 
!band->band_num;
+int mb_size = band->mb_size;
+int xend= tile->xpos + tile->width;
+int is_halfpel  = band->is_halfpel;
+int pitch   = band->pitch;
 
-if (tile->num_MBs != IVI_MBs_PER_TILE(tile->width, tile->height, 
band->mb_size)) {
+if (tile->num_MBs != IVI_MBs_PER_TILE(tile->width, tile->height, mb_size)) 
{
 av_log(avctx, AV_LOG_ERROR, "Allocated tile size %d mismatches "
"parameters %d in ivi_process_empty_tile()\n",
-   tile->num_MBs, IVI_MBs_PER_TILE(tile->width, tile->height, 
band->mb_size));
+   tile->num_MBs, IVI_MBs_PER_TILE(tile->width, tile->height, 
mb_size));
 return AVERROR_INVALIDDATA;
 }
 
-offs   = tile->ypos * band->pitch + tile->xpos;
+offs   = tile->ypos * pitch + tile->xpos;
 mb = tile->mbs;
 ref_mb = tile->ref_mbs;
-row_offset = band->mb_size * band->pitch;
+row_offset = mb_size * pitch;
 need_mc= 0; /* reset the mc tracking flag */
 
-for (y = tile->ypos; y < (tile->ypos + tile->height); y += band->mb_size) {
+for (y = tile->ypos; y < (tile->ypos + tile->height); y += mb_size) {
 mb_offset = offs;
 
-for (x = tile->xpos; x < (tile->xpos + tile->width); x += 
band->mb_size) {
+for (x = tile->xpos; x < xend; x += mb_size) {
 mb->xpos = x;
 mb->ypos = y;
 mb->buf_offs = mb_offset;
@@ -800,7 +805,7 @@ static int ivi_process_empty_tile(AVCodecContext *avctx, 
const IVIBandDesc *band
 mb->type = 1; /* set the macroblocks type = INTER */
 mb->cbp  = 0; /* all blocks are empty */
 
-if (!band->qdelta_present && !band->plane && !band->band_num) {
+if (clear_first) {
 mb->q_delta = band->glob_quant;
 mb->mv_x= 0;
 mb->mv_y= 0;
@@ -823,15 +828,15 @@ static int ivi_process_empty_tile(AVCodecContext *avctx, 
const IVIBandDesc *band
 {
 int dmv_x, dmv_y, cx, cy;
 
-dmv_x = mb->mv_x >> band->is_halfpel;
-dmv_y = mb->mv_y >> band->is_halfpel;
-cx= mb->mv_x &  band->is_halfpel;
-cy= mb->mv_y &  band->is_halfpel;
+dmv_x = mb->mv_x >> is_halfpel;
+dmv_y = mb->mv_y >> is_halfpel;
+cx= mb->mv_x &  is_halfpel;
+cy= mb->mv_y &  is_halfpel;
 
 if (   mb->xpos + dmv_x < 0
-|| mb->xpos + dmv_x + band->mb_size + cx > 
band->pitch
+|| mb->xpos + dmv_x + mb_size + cx > pitch
 || mb->ypos + dmv_y < 0
-|| mb->ypos + dmv_y + band->mb_size + cy > 
band->aheight) {
+|| mb->ypos + dmv_y + mb_size + cy > 
band->aheight) {
 av_log(avctx, AV_LOG_ERROR, "MV out of bounds\n");
 return AVERROR_INVALIDDATA;
 }
@@ -841,13 +846,13 @@ static int ivi_process_empty_tile(AVCodecContext *avctx, 
const IVIBandDesc *band
 }
 
 mb++;
-mb_offset += band->mb_size;
+mb_offset += mb_size;
 } // for x
 offs += row_offset;
 } // for y
 
 if (band->inherit_mv && need_mc) { /* apply motion compensation if there 
is at least one non-zero motion vector */
-num_blocks = (band->mb_size != band->blk_size) ? 4 : 1; /* number of 
blocks per mb */
+num_blocks = (mb_size != band->blk_size) ? 4 : 1; /* number of blocks 
per mb */
 mc_no_delta_func = (band->blk_size == 8) ? ff_ivi_mc_8x8_no_delta
  : ff_ivi_mc_4x4_no_delta;
 
@@ -864,7 +869,7 @@ static int ivi_process_empty_tile(AVCodecContext *avctx, 
const IVIBandDesc *band
 
 for (blk = 0; blk < num_blocks; blk++) {
 /* adjust block position in the buffer according with its 

[FFmpeg-devel] [PATCH 3/5] avcodec/ivi: fix indention for previous commit

[Michael Niedermayer]

---
 libavcodec/ivi.c | 56 
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/libavcodec/ivi.c b/libavcodec/ivi.c
index 1a496d9b2d..79147a42cd 100644
--- a/libavcodec/ivi.c
+++ b/libavcodec/ivi.c
@@ -807,36 +807,36 @@ static int ivi_process_empty_tile(AVCodecContext *avctx, 
IVIBandDesc *band,
 }
 
 if (ref_mb) {
-if (band->inherit_qdelta)
-mb->q_delta = ref_mb->q_delta;
-
-if (band->inherit_mv) {
-/* motion vector inheritance */
-if (mv_scale) {
-mb->mv_x = ivi_scale_mv(ref_mb->mv_x, mv_scale);
-mb->mv_y = ivi_scale_mv(ref_mb->mv_y, mv_scale);
-} else {
-mb->mv_x = ref_mb->mv_x;
-mb->mv_y = ref_mb->mv_y;
-}
-need_mc |= mb->mv_x || mb->mv_y; /* tracking non-zero motion 
vectors */
-{
-int dmv_x, dmv_y, cx, cy;
-
-dmv_x = mb->mv_x >> band->is_halfpel;
-dmv_y = mb->mv_y >> band->is_halfpel;
-cx= mb->mv_x &  band->is_halfpel;
-cy= mb->mv_y &  band->is_halfpel;
-
-if (   mb->xpos + dmv_x < 0
-|| mb->xpos + dmv_x + band->mb_size + cx > band->pitch
-|| mb->ypos + dmv_y < 0
-|| mb->ypos + dmv_y + band->mb_size + cy > 
band->aheight) {
-av_log(avctx, AV_LOG_ERROR, "MV out of bounds\n");
-return AVERROR_INVALIDDATA;
+if (band->inherit_qdelta)
+mb->q_delta = ref_mb->q_delta;
+
+if (band->inherit_mv) {
+/* motion vector inheritance */
+if (mv_scale) {
+mb->mv_x = ivi_scale_mv(ref_mb->mv_x, mv_scale);
+mb->mv_y = ivi_scale_mv(ref_mb->mv_y, mv_scale);
+} else {
+mb->mv_x = ref_mb->mv_x;
+mb->mv_y = ref_mb->mv_y;
+}
+need_mc |= mb->mv_x || mb->mv_y; /* tracking non-zero 
motion vectors */
+{
+int dmv_x, dmv_y, cx, cy;
+
+dmv_x = mb->mv_x >> band->is_halfpel;
+dmv_y = mb->mv_y >> band->is_halfpel;
+cx= mb->mv_x &  band->is_halfpel;
+cy= mb->mv_y &  band->is_halfpel;
+
+if (   mb->xpos + dmv_x < 0
+|| mb->xpos + dmv_x + band->mb_size + cx > 
band->pitch
+|| mb->ypos + dmv_y < 0
+|| mb->ypos + dmv_y + band->mb_size + cy > 
band->aheight) {
+av_log(avctx, AV_LOG_ERROR, "MV out of bounds\n");
+return AVERROR_INVALIDDATA;
+}
 }
 }
-}
 ref_mb++;
 }
 
-- 
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 4/5] avcodec/ivi: Mark band parameter as const

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/ivi.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavcodec/ivi.c b/libavcodec/ivi.c
index 79147a42cd..f87964afd4 100644
--- a/libavcodec/ivi.c
+++ b/libavcodec/ivi.c
@@ -79,7 +79,7 @@ typedef void (*ivi_mc_avg_func) (int16_t *buf, const int16_t 
*ref_buf1,
  const int16_t *ref_buf2,
  ptrdiff_t pitch, int mc_type, int mc_type2);
 
-static int ivi_mc(IVIBandDesc *band, ivi_mc_func mc, ivi_mc_avg_func mc_avg,
+static int ivi_mc(const IVIBandDesc *band, ivi_mc_func mc, ivi_mc_avg_func 
mc_avg,
   int offs, int mv_x, int mv_y, int mv_x2, int mv_y2,
   int mc_type, int mc_type2)
 {
@@ -379,7 +379,7 @@ av_cold int ff_ivi_init_planes(AVCodecContext *avctx, 
IVIPlaneDesc *planes, cons
 return 0;
 }
 
-static int ivi_init_tiles(IVIBandDesc *band, IVITile *ref_tile,
+static int ivi_init_tiles(const IVIBandDesc *band, IVITile *ref_tile,
   int p, int b, int t_height, int t_width)
 {
 int x, y;
@@ -493,7 +493,7 @@ static int ivi_dec_tile_data_size(GetBitContext *gb)
 return len;
 }
 
-static int ivi_dc_transform(IVIBandDesc *band, int *prev_dc, int buf_offs,
+static int ivi_dc_transform(const IVIBandDesc *band, int *prev_dc, int 
buf_offs,
 int blk_size)
 {
 int buf_size = band->pitch * band->aheight - buf_offs;
@@ -508,7 +508,7 @@ static int ivi_dc_transform(IVIBandDesc *band, int 
*prev_dc, int buf_offs,
 return 0;
 }
 
-static int ivi_decode_coded_blocks(GetBitContext *gb, IVIBandDesc *band,
+static int ivi_decode_coded_blocks(GetBitContext *gb, const IVIBandDesc *band,
ivi_mc_func mc, ivi_mc_avg_func mc_avg,
int mv_x, int mv_y,
int mv_x2, int mv_y2,
@@ -619,7 +619,7 @@ static int ivi_decode_coded_blocks(GetBitContext *gb, 
IVIBandDesc *band,
  *  @param[in]  tile  pointer to the tile descriptor
  *  @return result code: 0 - OK, -1 = error (corrupted blocks data)
  */
-static int ivi_decode_blocks(GetBitContext *gb, IVIBandDesc *band,
+static int ivi_decode_blocks(GetBitContext *gb, const IVIBandDesc *band,
  IVITile *tile, AVCodecContext *avctx)
 {
 int mbn, blk, num_blocks, blk_size, ret, is_intra;
@@ -766,7 +766,7 @@ static int ivi_decode_blocks(GetBitContext *gb, IVIBandDesc 
*band,
  *  @param[in]  tile  pointer to the tile descriptor
  *  @param[in]  mv_scale  scaling factor for motion vectors
  */
-static int ivi_process_empty_tile(AVCodecContext *avctx, IVIBandDesc *band,
+static int ivi_process_empty_tile(AVCodecContext *avctx, const IVIBandDesc 
*band,
   IVITile *tile, int32_t mv_scale)
 {
 int x, y, need_mc, mbn, blk, num_blocks, mv_x, mv_y, mc_type;
@@ -887,7 +887,7 @@ static int ivi_process_empty_tile(AVCodecContext *avctx, 
IVIBandDesc *band,
 
 
 #ifdef DEBUG
-static uint16_t ivi_calc_band_checksum(IVIBandDesc *band)
+static uint16_t ivi_calc_band_checksum(const IVIBandDesc *band)
 {
 int x, y;
 int16_t *src, checksum;
-- 
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] avcodec/cbs_av1: fix range of allowed values for obu_type

[James Almer]

0 is a reserved value.

Signed-off-by: James Almer 
---
 libavcodec/cbs_av1_syntax_template.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/cbs_av1_syntax_template.c 
b/libavcodec/cbs_av1_syntax_template.c
index 76eb90b279..35b030208b 100644
--- a/libavcodec/cbs_av1_syntax_template.c
+++ b/libavcodec/cbs_av1_syntax_template.c
@@ -26,7 +26,7 @@ static int FUNC(obu_header)(CodedBitstreamContext *ctx, 
RWContext *rw,
 
 fc(1, obu_forbidden_bit, 0, 0);
 
-fc(4, obu_type, 0, AV1_OBU_PADDING);
+fc(4, obu_type, AV1_OBU_SEQUENCE_HEADER, AV1_OBU_PADDING);
 flag(obu_extension_flag);
 flag(obu_has_size_field);
 
-- 
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/5] doc/general.texi: remove note about regressed AviSynth+ header

[Stephen Hutchinson]

It's been fixed both AviSynth+-side and locally.
---
 doc/general.texi | 13 -
 1 file changed, 13 deletions(-)

diff --git a/doc/general.texi b/doc/general.texi
index fe94c40386..6ec52962ff 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -51,19 +51,6 @@ For Windows, supported AviSynth variants are
 For Linux and OS X, the supported AviSynth variant is
 @url{https://github.com/avxsynth/avxsynth, AvxSynth}.
 
-@float NOTE
-There is currently a regression in AviSynth+'s @code{capi.h} header as of
-October 2016, which interferes with the ability for builds of FFmpeg to use
-MSVC-built binaries of AviSynth. Until this is resolved, you can make sure
-a known good version is installed by checking out a version from before
-the regression occurred:
-
-@code{git clone -b MT git://github.com/AviSynth/AviSynthPlus.git @*
-cd AviSynthPlus @*
-git checkout -b oldheader b4f292b4dbfad149697fb65c6a037bb3810813f9 @*
-make install PREFIX=/install/prefix}
-@end float
-
 @float NOTE
 AviSynth and AvxSynth are loaded dynamically.  Distributors can build FFmpeg
 with @code{--enable-avisynth}, and the binaries will work regardless of the
-- 
2.19.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 0/5] avisynth: update headers, pix_fmts, and docs

[Stephen Hutchinson]

Some essential fixes to the AviSynth+ headers regarding
GCC and general organization have happened recently, making
it necessary to update the headers we keep in compat.

Additionally, the location of AviSynth+'s upstream has
effectively changed, making the old link to avs-plus.net
misleading, and FFmpeg has added several pix_fmts that
avsplus can use (these pix_fmts were available in avsplus
in 2016 as well, there just wasn't support for them on
our side yet).

Stephen Hutchinson (5):
  compat/avisynth: update headers
  libavformat/avisynth: enable additional pix_fmts
  doc/general.texi: remove note about regressed AviSynth+ header
  doc/general.texi: update AviSynth+ reference page
  doc/general.texi: add note about 32-bit GCC builds of AviSynth+

 compat/avisynth/avisynth_c.h | 503 ---
 compat/avisynth/avs/capi.h   |  44 ++-
 compat/avisynth/avs/config.h |  17 +-
 compat/avisynth/avs/types.h  |   6 +
 doc/general.texi |  19 +-
 libavformat/avisynth.c   |  33 ++-
 6 files changed, 448 insertions(+), 174 deletions(-)

-- 
2.19.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/5] doc/general.texi: remove note about regressed AviSynth+ header

[Stephen Hutchinson]

It's been fixed both AviSynth+-side and locally.
---
 doc/general.texi | 13 -
 1 file changed, 13 deletions(-)

diff --git a/doc/general.texi b/doc/general.texi
index fe94c40386..6ec52962ff 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -51,19 +51,6 @@ For Windows, supported AviSynth variants are
 For Linux and OS X, the supported AviSynth variant is
 @url{https://github.com/avxsynth/avxsynth, AvxSynth}.
 
-@float NOTE
-There is currently a regression in AviSynth+'s @code{capi.h} header as of
-October 2016, which interferes with the ability for builds of FFmpeg to use
-MSVC-built binaries of AviSynth. Until this is resolved, you can make sure
-a known good version is installed by checking out a version from before
-the regression occurred:
-
-@code{git clone -b MT git://github.com/AviSynth/AviSynthPlus.git @*
-cd AviSynthPlus @*
-git checkout -b oldheader b4f292b4dbfad149697fb65c6a037bb3810813f9 @*
-make install PREFIX=/install/prefix}
-@end float
-
 @float NOTE
 AviSynth and AvxSynth are loaded dynamically.  Distributors can build FFmpeg
 with @code{--enable-avisynth}, and the binaries will work regardless of the
-- 
2.19.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 0/5] avisynth: update headers, pix_fmts, and docs

[Stephen Hutchinson]

Some essential fixes to the AviSynth+ headers regarding
GCC and general organization have happened recently, making
it necessary to update the headers we keep in compat.

Additionally, the location of AviSynth+'s upstream has
effectively changed, making the old link to avs-plus.net
misleading, and FFmpeg has added several pix_fmts that
avsplus can use (these pix_fmts were available in avsplus
in 2016 as well, there just wasn't support for them on
our side yet).

Stephen Hutchinson (5):
  compat/avisynth: update headers
  libavformat/avisynth: enable additional pix_fmts
  doc/general.texi: remove note about regressed AviSynth+ header
  doc/general.texi: update AviSynth+ reference page
  doc/general.texi: add note about 32-bit GCC builds of AviSynth+

 compat/avisynth/avisynth_c.h | 503 ---
 compat/avisynth/avs/capi.h   |  44 ++-
 compat/avisynth/avs/config.h |  17 +-
 compat/avisynth/avs/types.h  |   6 +
 doc/general.texi |  19 +-
 libavformat/avisynth.c   |  33 ++-
 6 files changed, 448 insertions(+), 174 deletions(-)

-- 
2.19.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/5] compat/avisynth: update headers

[Stephen Hutchinson]

As part of the update, it is now possible to test 32-bit GCC builds
of AviSynth+ with FFmpeg by using the AVS_WIN32_GCC32 define. Due to
different calling conventions between MSVC and GCC regarding 32-bit
Windows, this is unfortunately necessary.
---
 compat/avisynth/avisynth_c.h | 503 ---
 compat/avisynth/avs/capi.h   |  44 ++-
 compat/avisynth/avs/config.h |  17 +-
 compat/avisynth/avs/types.h  |   6 +
 4 files changed, 408 insertions(+), 162 deletions(-)

diff --git a/compat/avisynth/avisynth_c.h b/compat/avisynth/avisynth_c.h
index 605b92ae62..f0f1948902 100644
--- a/compat/avisynth/avisynth_c.h
+++ b/compat/avisynth/avisynth_c.h
@@ -34,6 +34,22 @@
 // NOTE: this is a partial update of the Avisynth C interface to recognize
 // new color spaces added in Avisynth 2.60. By no means is this document
 // completely Avisynth 2.60 compliant.
+// 170103: added new CPU constants (FMA4, AVX512xx)
+// 171102: define SIZETMOD. do not use yet, experimental. Offsets are size_t 
instead of int. Affects x64.
+// 171106: avs_get_row_size calls into avs_get_row_size_p, instead of direct 
field access
+// 171106: avs_get_height calls into avs_get_row_size_p, instead of direct 
field access
+// 180524: AVSC_EXPORT to dllexport in capi.h for avisynth_c_plugin_init
+// 180524: avs_is_same_colorspace VideoInfo parameters to const
+// 181230: Readability: functions regrouped to mix less AVSC_API and 
AVSC_INLINE, put together Avisynth+ specific stuff
+// 181230: use #ifndef AVSC_NO_DECLSPEC for AVSC_INLINE functions which are 
calling API functions
+// 181230: comments on avs_load_library (helper for loading API entries 
dynamically into a struct using AVSC_NO_DECLSPEC define)
+// 181230: define alias AVS_FRAME_ALIGN as FRAME_ALIGN
+// 181230: remove unused form of avs_get_rowsize and avs_get_height (kept 
earlier for reference)
+// 190104: avs_load_library: smart fallback mechanism for Avisynth+ specific 
functions:
+// if they are not loadable, they will work in a classic Avisynth 
compatible mode
+// Example#1: e.g. avs_is_444 will call the existing avs_is_yv24 
instead
+// Example#2: avs_bits_per_component will return 8 for all colorspaces 
(Classic Avisynth supports only 8 bits/pixel)
+// Thus the Avisynth+ specific API functions are safely callable even 
when connected to classic Avisynth DLL
 
 #ifndef __AVISYNTH_C__
 #define __AVISYNTH_C__
@@ -42,7 +58,7 @@
 #include "avs/capi.h"
 #include "avs/types.h"
 
-
+#define AVS_FRAME_ALIGN FRAME_ALIGN
 /
 //
 // Constants
@@ -124,7 +140,7 @@ enum {
 AVS_CS_GENERIC_YUVA444 = AVS_CS_PLANAR | AVS_CS_YUVA | AVS_CS_VPLANEFIRST 
| AVS_CS_SUB_HEIGHT_1 | AVS_CS_SUB_WIDTH_1 }; // 4:4:4:A planar
 
 
-  // Specific colorformats
+  // Specific color formats
 enum {
   AVS_CS_UNKNOWN = 0,
   AVS_CS_BGR24 = AVS_CS_RGB_TYPE  | AVS_CS_BGR | AVS_CS_INTERLEAVED,
@@ -134,18 +150,18 @@ enum {
   //  AVS_CS_I420  = 1<<4  Reserved
   AVS_CS_RAW32 = 1<<5 | AVS_CS_INTERLEAVED,
 
-  AVS_CS_YV24  = AVS_CS_GENERIC_YUV444 | AVS_CS_SAMPLE_BITS_8,  // YVU 4:4:4 
planar
-  AVS_CS_YV16  = AVS_CS_GENERIC_YUV422 | AVS_CS_SAMPLE_BITS_8,  // YVU 4:2:2 
planar
-  AVS_CS_YV12  = AVS_CS_GENERIC_YUV420 | AVS_CS_SAMPLE_BITS_8,  // YVU 4:2:0 
planar
+  AVS_CS_YV24  = AVS_CS_GENERIC_YUV444 | AVS_CS_SAMPLE_BITS_8,  // YUV 4:4:4 
planar
+  AVS_CS_YV16  = AVS_CS_GENERIC_YUV422 | AVS_CS_SAMPLE_BITS_8,  // YUV 4:2:2 
planar
+  AVS_CS_YV12  = AVS_CS_GENERIC_YUV420 | AVS_CS_SAMPLE_BITS_8,  // YUV 4:2:0 
planar
   AVS_CS_I420  = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 | 
AVS_CS_UPLANEFIRST | AVS_CS_SUB_HEIGHT_2 | AVS_CS_SUB_WIDTH_2,  // YUV 4:2:0 
planar
   AVS_CS_IYUV  = AVS_CS_I420,
-  AVS_CS_YV411 = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 | 
AVS_CS_VPLANEFIRST | AVS_CS_SUB_HEIGHT_1 | AVS_CS_SUB_WIDTH_4,  // YVU 4:1:1 
planar
-  AVS_CS_YUV9  = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 | 
AVS_CS_VPLANEFIRST | AVS_CS_SUB_HEIGHT_4 | AVS_CS_SUB_WIDTH_4,  // YVU 4:1:0 
planar
+  AVS_CS_YV411 = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 | 
AVS_CS_VPLANEFIRST | AVS_CS_SUB_HEIGHT_1 | AVS_CS_SUB_WIDTH_4,  // YUV 4:1:1 
planar
+  AVS_CS_YUV9  = AVS_CS_PLANAR | AVS_CS_YUV | AVS_CS_SAMPLE_BITS_8 | 
AVS_CS_VPLANEFIRST | AVS_CS_SUB_HEIGHT_4 | AVS_CS_SUB_WIDTH_4,  // YUV 4:1:0 
planar
   AVS_CS_Y8= AVS_CS_GENERIC_Y | AVS_CS_SAMPLE_BITS_8,   // Y   4:0:0 
planar
 
   //-
   // AVS16: new planar constants go live! Experimental PF 160613
-  // 10-12-14 bit + planar RGB + BRG48/64 160725
+  // 10-12-14-16 bit + planar RGB + BGR48/64 160725
   AVS_CS_YUV444P10 = AVS_CS_GENERIC_YUV444 | AVS_CS_SAMPLE_BITS_10, // YUV 
4:4:4 10bit samples
   AVS_CS_YUV422P10 = AVS_CS_GENERIC_YUV422 | AVS_CS_SAMPLE_BITS_10, // YUV 
4:2:2 10bit samples
   AVS_CS_YUV420P10 = AVS_CS_GENERIC_YUV420 | AVS_CS_SAMPLE_BITS_10, // YUV 
4:2:0 10bit samples
@@ -246,9 +262,9 

[FFmpeg-devel] [PATCH 4/5] doc/general.texi: update AviSynth+ reference page

[Stephen Hutchinson]

Directed to the AviSynth+ entry on AviSynth Wiki rather than to
the github repository, since the wiki page is both more informative
and has the relevant Git/download links.  The github releases page
is little more than a changelog.
---
 doc/general.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/general.texi b/doc/general.texi
index 6ec52962ff..bafa1e2ea2 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -46,7 +46,7 @@ without needing to search for these headers themselves.
 
 For Windows, supported AviSynth variants are
 @url{http://avisynth.nl, AviSynth 2.6 RC1 or higher} for 32-bit builds and
-@url{http://avs-plus.net, AviSynth+ r1718 or higher} for 32-bit and 64-bit 
builds.
+@url{http://avisynth.nl/index.php/AviSynth+, AviSynth+ r1718 or higher} for 
32-bit and 64-bit builds.
 
 For Linux and OS X, the supported AviSynth variant is
 @url{https://github.com/avxsynth/avxsynth, AvxSynth}.
-- 
2.19.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 5/5] doc/general.texi: add note about 32-bit GCC builds of AviSynth+

[Stephen Hutchinson]

---
 doc/general.texi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/doc/general.texi b/doc/general.texi
index bafa1e2ea2..98e4704d86 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -51,6 +51,16 @@ For Windows, supported AviSynth variants are
 For Linux and OS X, the supported AviSynth variant is
 @url{https://github.com/avxsynth/avxsynth, AvxSynth}.
 
+@float NOTE
+Due to the eccentricities of Windows' calling conventions, 32-bit GCC builds
+of AviSynth+ are not compatible with typical 32-bit GCC builds of FFmpeg.
+
+Support for 32-bit GCC builds of AviSynth+ can be enabled by passing
+@code{-DAVSC_WIN32_GCC32} to @code{--extra-cflags}. However, doing so will
+make the resulting build of FFmpeg incompatible with typical 32-bit MSVC
+builds of AviSynth+.
+@end float
+
 @float NOTE
 AviSynth and AvxSynth are loaded dynamically.  Distributors can build FFmpeg
 with @code{--enable-avisynth}, and the binaries will work regardless of the
-- 
2.19.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/5] libavformat/avisynth: enable additional pix_fmts

[Stephen Hutchinson]

These pix_fmts have been added to FFmpeg in the 31 months since
commit 92916e8542e425ca20daddb490261a5818643206 added support for
the larger number of pix_fmts that AviSynth+ can use. They were
present in AviSynth+ even then, just not in libavutil.
---
 libavformat/avisynth.c | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 250a489321..2181510c2f 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -323,6 +323,10 @@ static int avisynth_create_stream_video(AVFormatContext 
*s, AVStream *st)
 st->codecpar->format = AV_PIX_FMT_YUVA420P10;
 planar   = 4;
 break;
+case AVS_CS_YUVA422P12:
+st->codecpar->format = AV_PIX_FMT_YUVA422P12;
+planar   = 4;
+break;
 case AVS_CS_YUVA444P16:
 st->codecpar->format = AV_PIX_FMT_YUVA444P16;
 planar   = 4;
@@ -356,6 +360,11 @@ static int avisynth_create_stream_video(AVFormatContext 
*s, AVStream *st)
 st->codecpar->format = AV_PIX_FMT_GBRP16;
 planar   = 3;
 break;
+/* Single precision floating point Planar RGB (AviSynth+) */
+case AVS_CS_RGBPS:
+st->codecpar->format = AV_PIX_FMT_GBRPF32;
+planar   = 3;
+break;
 /* Planar RGB pix_fmts with Alpha (AviSynth+) */
 case AVS_CS_RGBAP:
 st->codecpar->format = AV_PIX_FMT_GBRAP;
@@ -373,11 +382,33 @@ static int avisynth_create_stream_video(AVFormatContext 
*s, AVStream *st)
 st->codecpar->format = AV_PIX_FMT_GBRAP16;
 planar   = 5;
 break;
-/* GRAY16 (AviSynth+) */
+/* Single precision floating point Planar RGB with Alpha (AviSynth+) */
+case AVS_CS_RGBAPS:
+st->codecpar->format = AV_PIX_FMT_GBRAPF32;
+planar   = 5;
+break;
+/* 10~16-bit gray pix_fmts (AviSynth+) */
+case AVS_CS_Y10:
+st->codecpar->format = AV_PIX_FMT_GRAY10;
+planar   = 2;
+break;
+case AVS_CS_Y12:
+st->codecpar->format = AV_PIX_FMT_GRAY12;
+planar   = 2;
+break;
+case AVS_CS_Y14:
+st->codecpar->format = AV_PIX_FMT_GRAY14;
+planar   = 2;
+break;
 case AVS_CS_Y16:
 st->codecpar->format = AV_PIX_FMT_GRAY16;
 planar   = 2;
 break;
+/* Single precision floating point gray (AviSynth+) */
+case AVS_CS_Y32:
+st->codecpar->format = AV_PIX_FMT_GRAYF32;
+planar   = 2;
+break;
 /* pix_fmts added in AviSynth 2.6 */
 case AVS_CS_YV24:
 st->codecpar->format = AV_PIX_FMT_YUV444P;
-- 
2.19.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] News: Removal of libndi

[Jean-Baptiste Kempf]

On Sun, 24 Mar 2019, at 20:10, Ronald S. Bultje wrote: 
> The GPL does not mention hardware (instead, they use the word "system
> library"). Going from here, I don't consider enterprise-level hardware like
> Matrox $$$ priced stuff to be a system library at all. My system certainly
> has no hardware or drivers or system-level libraries that are
> API+ABI+functionally compatible with Matrox' tools and wares - under any
> license, not open-source and not closed-source. How can the system library
> exception possibly apply here?

Drivers have always been considered part of the OS, whatever the price of the 
hardware.
The Linux kernel has drivers for pieces of hardware that are way more expensive 
than Matrox hardware.

So, if the library is part of the driver (installed at the same time), it is 
considered part of the "major components of the OS", because if you don't 
install the driver, you cannot use the hardware.
This is the opinion of the Linux Foundation, the FSF, FSFE and so many others.

Usually, the "major components" (as mentioned in the GPL and not "system 
libraries", which is the shortcut) explicitly mention 3 parts: kernel, compiler 
and  "others."
The common understanding is that everything that runs in Kernel-Land, aka 
kernel + drivers is the kernel part of the "major components". libc, compiler 
and libraries linked by compilers, if distributed with the OS, are the second 
part of the "major components"; and the last part, "others" cover the other 
core parts of the OS (usually the "base" in linux distributions), and covers 
init and the shell, and the basic services normally installed by default (at, 
cron, etc..).

Yes, this meaning is very dated, but GPLv2 is from 1991.


Most of those hardware libraries are glorified ioctls around the driver and 
shipped with the drivers.
And I see this with nVidia, Intel MFX and Decklink (lots of "acquire C++ 
interface, set param" there, release the C++ interface).

Matrox seems to do something else, though, introducing a special library for 
FFmpeg consumption, and I doubt that feels like a driver...


-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
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] News: Removal of libndi

[Ronald S. Bultje]

Hi,

On Sun, Mar 24, 2019 at 2:21 PM Jean-Baptiste Kempf  wrote:

> On Sun, 24 Mar 2019, at 18:50, Marton Balint wrote:
> > > - do we want to keep any components requiring linking with non-system,
> > > closed-source software? (this might or might not include blackmagic)
> > >
> > > or some other variant that also includes system software like nvidia
> stuff?
> > > Or ask a simple yes/no for each component separately? (Although that
> > > wouldn't set a more general policy.)
> >
> > I prefer votes on a case by case basis, because it is hard to categorize
> > closed source components.
>
> I disagree.
> First you should vote for the global concept of non-hardware closed source
> libraries.
> It will avoid doing 20 votes for each time this action will come.
>
> > (ok, maybe not NDI, but for
> > M264/Nvidia/Blackmagic it is definitely not trivial).
>
> Those are hardware based libraries, done to access hardware.
> They are very easy to differentiate from non-hardware libraries.


I disagree with the whole hardware concept.

The GPL does not mention hardware (instead, they use the word "system
library"). Going from here, I don't consider enterprise-level hardware like
Matrox $$$ priced stuff to be a system library at all. My system certainly
has no hardware or drivers or system-level libraries that are
API+ABI+functionally compatible with Matrox' tools and wares - under any
license, not open-source and not closed-source. How can the system library
exception possibly apply here?

(I understand nvidia may be a special case because the interface is
actually entirely through ioctl()s and there are opensource drivers and the
userland compatibility library is enitrely opensource - maybe the
system-library exception actually applies here - even though binary blobs
are loaded, I don't know. But matrox and blackmagic? This seems crazy.)

Ronald

(Also, aside from all of this, my concern is philosophical as much as it's
legal. But I'll leave that for some other email.)
___
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] News: Removal of libndi

[Marton Balint]

On Sat, 23 Mar 2019, Ronald S. Bultje wrote:


Hi,

On Sat, Mar 23, 2019 at 11:03 AM Thilo Borgmann 
wrote:


Am 21.03.19 um 11:55 schrieb Michael Niedermayer:
> On Wed, Mar 20, 2019 at 05:41:31PM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Wed, Mar 20, 2019 at 4:15 PM Gyan  wrote:
>>
>>>
>>>
>>> On 21-03-2019 01:32 AM, Marton Balint wrote:


 On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote:

> On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote:
>> On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote:
>>
>>> On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote:
 As I described in similar threads before, whether or not the
>> project want >> closed source support for NDI is a subjective issue,
>> please start a vote >> about the removal of libndi if you want to
>> seek this through.
>>>
>>> The removal of libndi is actually done and committed.
>>
>> That is just sad an unfair.
>
> Sad, maybe.
> Unfair, I disagree. If NDI wants to be in, they know what to do.

 It is unfair towards the people who expressied disapproval, yet this
 change was committed without neither vote nor consensus.
>>>
>>> +1. This was a political decision, not a technical one. A formal(-ish)
>>> survey should have happened on the ML.
>>>
>>
>> I agree we need a formal vote on this. I would like to set a wider
project
>> policy w.r.t. closed-source software integration, this is just one
instance
>> of a more general issue.

> I think there should have been a vote before pushing a commit as there
where
> FFmpeg developers objecting to it.
> Ignoring people causes nothing good. Had there been a vote people would
be
> alot less upset about it as everyones oppinion would be counted equally
>
> It makes me unhappy that one FFmpeg developer apparently decided to leave
> the project already because of this.
> I think we should fix this, make a proper policy, with a proper vote
> and then hopefully noone feels the need to leave.

+1

>>
>> Who wants to organize it?
>
> Thilo organized the last vote, maybe he wants to do it ?
> but if noone else wants to do it i can do one too if people want and
> there is consensus who can vote
> If i search for "open source vote free" on google it points to
> vote.heliosvoting.org as first hit
> this seems rather basic but for simple yes/no questions it could work
> maybe someone has a better suggestion we could use for more complex
future
> cases that is multiple choice votes in teh future (schulze STV / CPO-STV
> for multiwinner or ScottishSTV (used by SPI), schulze method (used by
debian)
> for one winner of N choices would be nice to have)

Including for simple yes/no votes we can use the same LimeSurvey host we
got provided from KDE for the survey. Also for anonymous votes.



I think what we have to figure out is whether we want to ask:

- do we want to keep (or remove) NDI?


I think this is definitely needed to justify the recent events.



or

- do we want to keep any components requiring linking with non-system,
closed-source software? (this might or might not include blackmagic)

or some other variant that also includes system software like nvidia stuff?
Or ask a simple yes/no for each component separately? (Although that
wouldn't set a more general policy.)


I prefer votes on a case by case basis, because it is hard to categorize 
closed source components. (ok, maybe not NDI, but for 
M264/Nvidia/Blackmagic it is definitely not trivial).


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] News: Removal of libndi

[Marton Balint]

On Sat, 23 Mar 2019, Thilo Borgmann wrote:


Am 21.03.19 um 11:55 schrieb Michael Niedermayer:

On Wed, Mar 20, 2019 at 05:41:31PM -0400, Ronald S. Bultje wrote:

Hi,

On Wed, Mar 20, 2019 at 4:15 PM Gyan  wrote:




On 21-03-2019 01:32 AM, Marton Balint wrote:



On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote:


On Wed, 20 Mar 2019, at 20:52, Marton Balint wrote:

On Wed, 20 Mar 2019, Jean-Baptiste Kempf wrote:


On Wed, 20 Mar 2019, at 19:34, Marton Balint wrote:

As I described in similar threads before, whether or not the

project want >> closed source support for NDI is a subjective issue,
please start a vote >> about the removal of libndi if you want to
seek this through.


The removal of libndi is actually done and committed.


That is just sad an unfair.


Sad, maybe.
Unfair, I disagree. If NDI wants to be in, they know what to do.


It is unfair towards the people who expressied disapproval, yet this
change was committed without neither vote nor consensus.


+1. This was a political decision, not a technical one. A formal(-ish)
survey should have happened on the ML.



I agree we need a formal vote on this. I would like to set a wider project
policy w.r.t. closed-source software integration, this is just one instance
of a more general issue.



I think there should have been a vote before pushing a commit as there where
FFmpeg developers objecting to it.
Ignoring people causes nothing good. Had there been a vote people would be
alot less upset about it as everyones oppinion would be counted equally

It makes me unhappy that one FFmpeg developer apparently decided to leave
the project already because of this. 
I think we should fix this, make a proper policy, with a proper vote

and then hopefully noone feels the need to leave.


+1



Who wants to organize it?


Thilo organized the last vote, maybe he wants to do it ?
but if noone else wants to do it i can do one too if people want and
there is consensus who can vote
If i search for "open source vote free" on google it points to 
vote.heliosvoting.org as first hit

this seems rather basic but for simple yes/no questions it could work
maybe someone has a better suggestion we could use for more complex future
cases that is multiple choice votes in teh future (schulze STV / CPO-STV
for multiwinner or ScottishSTV (used by SPI), schulze method (used by debian)
for one winner of N choices would be nice to have) 


Including for simple yes/no votes we can use the same LimeSurvey host we got 
provided from KDE for the survey. Also for anonymous votes.

If people want it, we can setup a poll anytime. Most important would be a list 
of people allowed to vote (as of mail subscribed to FFmpeg-devel).


The last time we used the Voting Committe these people were on it:

Original committe:
Michael Niedermayer
Clément Bœsch
James Almer
Paul B Mahol
Carl Eugen Hoyos
Andreas Cadhalpun
Ronald S. Bultje
wm4
Lukasz Marek
Rostislav Pehlivanov
Hendrik Leppkes
Christophe Gisquet
Reynaldo H. Verdejo Pinochet
First extension:
Nicolas George
Rodger Combs
Stefano Sabatini
Timothy Gu
Second extension:
Ganesh Ajjanagadde
Lou Logan
Marton Balint
Philip Langdale
Reimar Döffinger
(There was a 3rd extension attempt but that was rejected in the 
discussion phase)


Emails can be generated from git log relatively easily for each member 
(the last 50 commits are queried to be able to notice ambiguities):


git log -n 50 --pretty=format:%ce --committer='Author Name <' |sort | uniq

I suggest we first do a vote one the extension. Michael used this in the 
past to propose the list of people to add:


git log libav/master..master --no-merges  --since=2014-10-25T00:00:00Z --until 
2015-10-25T00:00:00Z --pretty=fuller | grep '^Commit:' | sed 's/<.*//' |sort | 
uniq -c | sort -nr

(https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/182057.html)

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/hevcdec: Avoid duplicate test about first slices

[James Almer]

On 3/24/2019 7:55 AM, Michael Niedermayer wrote:
> This should be more robust as it avoids 2 conditions in seperate places which
> need to stay the same
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/hevcdec.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 4d149f4d9f..fe4b5fdb5b 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -489,7 +489,7 @@ static int hls_slice_header(HEVCContext *s)
>  // Coded parameters
>  sh->first_slice_in_pic_flag = get_bits1(gb);
>  if (s->ref && sh->first_slice_in_pic_flag)
> -return 0; // This slice will be skiped later, do not corrupt state
> +return 1; // This slice will be skiped later, do not corrupt state
>  
>  if ((IS_IDR(s) || IS_BLA(s)) && sh->first_slice_in_pic_flag) {
>  s->seq_decode = (s->seq_decode + 1) & 0xff;
> @@ -2921,6 +2921,11 @@ static int decode_nal_unit(HEVCContext *s, const 
> H2645NAL *nal)
>  ret = hls_slice_header(s);
>  if (ret < 0)
>  return ret;
> +if (ret == 1) {
> +av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being the 
> first in the same frame.\n");

I think it makes more sense to print this in hls_slice_header(). We
could in the future intend to return 1 for some other error that only
needs to hard fail in explode mode, and this log message wouldn't apply
to it.
Alternatively, error code generation could also be handled in
hls_slice_header(), returning 0 or AVERROR_INVALIDDATA depending on
explode mode or not, and just let the ret < 0 check above do its thing.

> +goto fail;
> +}
> +
>  
>  if (
>  (s->avctx->skip_frame >= AVDISCARD_BIDIR && s->sh.slice_type == 
> HEVC_SLICE_B) ||
> @@ -2930,10 +2935,6 @@ static int decode_nal_unit(HEVCContext *s, const 
> H2645NAL *nal)
>  }
>  
>  if (s->sh.first_slice_in_pic_flag) {
> -if (s->ref) {
> -av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being 
> the first in the same frame.\n");
> -goto fail;
> -}
>  if (s->max_ra == INT_MAX) {
>  if (s->nal_unit_type == HEVC_NAL_CRA_NUT || IS_BLA(s)) {
>  s->max_ra = s->poc;
> 

___
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 2/2] avcodec/hevcdec: Fix return code for explode mode

[James Almer]

On 3/24/2019 7:55 AM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/hevcdec.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index fe4b5fdb5b..b7e2d68f5e 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -2923,6 +2923,7 @@ static int decode_nal_unit(HEVCContext *s, const 
> H2645NAL *nal)
>  return ret;
>  if (ret == 1) {
>  av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being the 
> first in the same frame.\n");
> +ret = AVERROR_INVALIDDATA;
>  goto fail;
>  }

I'd prefer if you squash all the patches before pushing, with or without
my suggested changes for patch 1/2.
___
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][FFmpeg-devel v2] Add GPU accelerated video crop filter

[Song, Ruiling]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> UsingtcNower
> Sent: Saturday, March 23, 2019 11:51 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH][FFmpeg-devel v2] Add GPU accelerated video
> crop filter
> 
> Signed-off-by: UsingtcNower 
> ---
>  Changelog   |   1 +
>  configure   |   1 +
>  doc/filters.texi|  31 +++
>  libavfilter/Makefile|   1 +
>  libavfilter/allfilters.c|   1 +
>  libavfilter/version.h   |   2 +-
>  libavfilter/vf_crop_cuda.c  | 638
> 
>  libavfilter/vf_crop_cuda.cu | 109 
>  8 files changed, 783 insertions(+), 1 deletion(-)
>  create mode 100644 libavfilter/vf_crop_cuda.c
>  create mode 100644 libavfilter/vf_crop_cuda.cu
> 
> diff --git a/Changelog b/Changelog
> index ad7e82f..f224fc8 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -20,6 +20,7 @@ version :
>  - libaribb24 based ARIB STD-B24 caption support (profiles A and C)
>  - Support decoding of HEVC 4:4:4 content in nvdec and cuviddec
>  - removed libndi-newtek
> +- crop_cuda GPU accelerated video crop filter
> 
> 
>  version 4.1:
> diff --git a/configure b/configure
> index 331393f..3f3ac2f 100755
> --- a/configure
> +++ b/configure
> @@ -2973,6 +2973,7 @@ qsvvpp_select="qsv"
>  vaapi_encode_deps="vaapi"
>  v4l2_m2m_deps="linux_videodev2_h sem_timedwait"
> 
> +crop_cuda_filter_deps="ffnvcodec cuda_nvcc"
Seems you are using NAN, you may also need to check dependency against 
"const_nan"

>  hwupload_cuda_filter_deps="ffnvcodec"
>  scale_npp_filter_deps="ffnvcodec libnpp"
>  scale_cuda_filter_deps="ffnvcodec cuda_nvcc"
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 4ffb392..ee16a2d 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -7415,6 +7415,37 @@ If the specified expression is not valid, it is kept 
> at its
> current
>  value.
>  @end table
> 
> +@section crop_cuda
> +
> +Crop the input video to given dimensions, implemented in CUDA.
> +
> +It accepts the following parameters:
> +
> +@table @option
> +
> +@item w
> +The width of the output video. It defaults to @code{iw}.
> +This expression is evaluated only once during the filter
> +configuration.
> +
> +@item h
> +The height of the output video. It defaults to @code{ih}.
> +This expression is evaluated only once during the filter
> +configuration.
> +
> +@item x
> +The horizontal position, in the input video, of the left edge of the output
> +video. It defaults to @code{(in_w-out_w)/2}.
> +This expression is evaluated only once during the filter
> +configuration.
> +
> +@item y
> +The vertical position, in the input video, of the top edge of the output 
> video.
> +It defaults to @code{(in_h-out_h)/2}.
> +This expression is evaluated only once during the filter
> +configuration.
> +@end table
> +
>  @section cropdetect
> 
>  Auto-detect the crop size.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index fef6ec5..84df037 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -187,6 +187,7 @@ OBJS-$(CONFIG_COPY_FILTER)   += vf_copy.o
>  OBJS-$(CONFIG_COREIMAGE_FILTER)  += vf_coreimage.o
>  OBJS-$(CONFIG_COVER_RECT_FILTER) += vf_cover_rect.o lavfutils.o
>  OBJS-$(CONFIG_CROP_FILTER)   += vf_crop.o
> +OBJS-$(CONFIG_CROP_CUDA_FILTER)  += vf_crop_cuda.o
> vf_crop_cuda.ptx.o
>  OBJS-$(CONFIG_CROPDETECT_FILTER) += vf_cropdetect.o
>  OBJS-$(CONFIG_CUE_FILTER)+= f_cue.o
>  OBJS-$(CONFIG_CURVES_FILTER) += vf_curves.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index c51ae0f..550e545 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -175,6 +175,7 @@ extern AVFilter ff_vf_copy;
>  extern AVFilter ff_vf_coreimage;
>  extern AVFilter ff_vf_cover_rect;
>  extern AVFilter ff_vf_crop;
> +extern AVFilter ff_vf_crop_cuda;
>  extern AVFilter ff_vf_cropdetect;
>  extern AVFilter ff_vf_cue;
>  extern AVFilter ff_vf_curves;
> diff --git a/libavfilter/version.h b/libavfilter/version.h
> index c71282c..5aa95f4 100644
> --- a/libavfilter/version.h
> +++ b/libavfilter/version.h
> @@ -31,7 +31,7 @@
> 
>  #define LIBAVFILTER_VERSION_MAJOR   7
>  #define LIBAVFILTER_VERSION_MINOR  48
> -#define LIBAVFILTER_VERSION_MICRO 100
> +#define LIBAVFILTER_VERSION_MICRO 101
> 
>  #define LIBAVFILTER_VERSION_INT
> AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
> LIBAVFILTER_VERSION_MINOR, \
> diff --git a/libavfilter/vf_crop_cuda.c b/libavfilter/vf_crop_cuda.c
> new file mode 100644
> index 000..fc6a2a6
> --- /dev/null
> +++ b/libavfilter/vf_crop_cuda.c
> @@ -0,0 +1,638 @@
> +/*
> +* Copyright (c) 2019, iQIYI CORPORATION. All rights reserved.
> +*
> +* Permission is hereby granted, free of charge, to any person obtaining a
> +* copy of this software and 

Re: [FFmpeg-devel] [PATCH 5/5] aarch64/opusdsp: implement NEON accerelated postfilter and deemphasis

[Carl Eugen Hoyos]

2019-03-24 13:26 GMT+01:00, Lynne :

>> Which toolchain did you test?

>> make libavcodec/aarch64/opusdsp_neon.o
>> AS  libavcodec/aarch64/opusdsp_neon.o
>> /tmp/opusdsp_neon-ac304f.s:86:33: error: invalid operand for instruction
>>  fmul v0.4s, v4.4s, v0.4s[0]
>>  ^
>>
>
> Does the toolchain you use compile fft_neon.S?

(Yes)
This is the Android toolchain (that I thought you had already
tested), please consider it a requirement for this patchset
that you install it and test yourself.
(I absolutely understand that you cannot test arm64 Windows
and if you have no macos system, you also cannot test ios
but testing Android compilation is necessary and reasonable.)

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/7] Improve CBS unit content alloc/free/clone behaviour

[Andreas Rheinhardt via ffmpeg-devel]

Mark Thompson:
> On 26/11/2018 13:39, Andreas Rheinhardt wrote:
>> This will enable us to change e.g. the parameter sets of H.2645 in ways
>> that would change the parsing process of future units. An example of
>> this is the h264_redundant_pps bsf.
> 
> I thought quite a bit more about how the alloc/free/clone should fit together 
> here.  Following is a patch series implementing it using tables defining how 
> each unit works, which I think ends up being nicer than the previous setup 
> with ad-hoc functions for each case.  The existing ad-hoc functions for the 
> hardest cases (that is, SEI) stay, but everything else in H.26[45] can be 
> handled without any new functions at all.
> 
> It ends up implementing pretty the same make_unit_writable() function that 
> you proposed, so the last patch is your one to h264_redundant_pps.
> 
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

Ticket #7807 has just been opened about this, so ping for this whole
patchset.

(Of course, a reference to ticket #7807 should be added to the commit
message of the last commit when it is merged.)

- Andreas
___
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/3] swscale/ppc: VSX-optimize yuv2422_2

[Lauri Kasanen]

./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 -sws_flags area \
-s 1200x720 -f null -vframes 100 -pix_fmt $i -nostats \
-cpuflags 0 -v error -

5.1x speedup:

yuyv422
  19339 UNITS in yuv2packed2,   16384 runs,  0 skips
   3718 UNITS in yuv2packed2,   16383 runs,  1 skips
yvyu422
  19438 UNITS in yuv2packed2,   16384 runs,  0 skips
   3800 UNITS in yuv2packed2,   16380 runs,  4 skips
uyvy422
  19128 UNITS in yuv2packed2,   16384 runs,  0 skips
   3721 UNITS in yuv2packed2,   16380 runs,  4 skips

Signed-off-by: Lauri Kasanen 
---
 libswscale/ppc/swscale_vsx.c | 69 
 1 file changed, 69 insertions(+)

diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 0bb82ac..1c4051b 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -726,6 +726,61 @@ write422(const vector int16_t vy1, const vector int16_t 
vy2,
 }
 }

+#define SETUP(x, buf0, buf1, alpha) { \
+x = vec_ld(0, buf0); \
+tmp = vec_mule(x, alpha); \
+tmp2 = vec_mulo(x, alpha); \
+tmp3 = vec_mergeh(tmp, tmp2); \
+tmp4 = vec_mergel(tmp, tmp2); \
+\
+x = vec_ld(0, buf1); \
+tmp = vec_mule(x, alpha); \
+tmp2 = vec_mulo(x, alpha); \
+tmp5 = vec_mergeh(tmp, tmp2); \
+tmp6 = vec_mergel(tmp, tmp2); \
+\
+tmp3 = vec_add(tmp3, tmp5); \
+tmp4 = vec_add(tmp4, tmp6); \
+\
+tmp3 = vec_sra(tmp3, shift19); \
+tmp4 = vec_sra(tmp4, shift19); \
+x = vec_packs(tmp3, tmp4); \
+}
+
+static av_always_inline void
+yuv2422_2_vsx_template(SwsContext *c, const int16_t *buf[2],
+ const int16_t *ubuf[2], const int16_t *vbuf[2],
+ const int16_t *abuf[2], uint8_t *dest, int dstW,
+ int yalpha, int uvalpha, int y,
+ enum AVPixelFormat target)
+{
+const int16_t *buf0  = buf[0],  *buf1  = buf[1],
+  *ubuf0 = ubuf[0], *ubuf1 = ubuf[1],
+  *vbuf0 = vbuf[0], *vbuf1 = vbuf[1];
+const int16_t  yalpha1 = 4096 - yalpha;
+const int16_t uvalpha1 = 4096 - uvalpha;
+vector int16_t vy1, vy2, vu, vv;
+vector int32_t tmp, tmp2, tmp3, tmp4, tmp5, tmp6;
+const vector int16_t vyalpha1 = vec_splats(yalpha1);
+const vector int16_t vuvalpha1 = vec_splats(uvalpha1);
+const vector uint32_t shift19 = vec_splats(19U);
+int i;
+av_assert2(yalpha  <= 4096U);
+av_assert2(uvalpha <= 4096U);
+
+for (i = 0; i < ((dstW + 1) >> 1); i += 8) {
+
+SETUP(vy1, [i * 2], [i * 2], vyalpha1)
+SETUP(vy2, [(i + 4) * 2], [(i + 4) * 2], vyalpha1)
+SETUP(vu, [i], [i], vuvalpha1)
+SETUP(vv, [i], [i], vuvalpha1)
+
+write422(vy1, vy2, vu, vv, [i * 4], target);
+}
+}
+
+#undef SETUP
+
 static av_always_inline void
 yuv2422_1_vsx_template(SwsContext *c, const int16_t *buf0,
  const int16_t *ubuf[2], const int16_t *vbuf[2],
@@ -786,7 +841,18 @@ yuv2422_1_vsx_template(SwsContext *c, const int16_t *buf0,
 }
 }

+#define YUV2PACKEDWRAPPER2(name, base, ext, fmt) \
+static void name ## ext ## _2_vsx(SwsContext *c, const int16_t *buf[2], \
+const int16_t *ubuf[2], const int16_t 
*vbuf[2], \
+const int16_t *abuf[2], uint8_t *dest, int 
dstW, \
+int yalpha, int uvalpha, int y) \
+{ \
+name ## base ## _2_vsx_template(c, buf, ubuf, vbuf, abuf, \
+  dest, dstW, yalpha, uvalpha, y, fmt); \
+}
+
 #define YUV2PACKEDWRAPPER(name, base, ext, fmt) \
+YUV2PACKEDWRAPPER2(name, base, ext, fmt) \
 static void name ## ext ## _1_vsx(SwsContext *c, const int16_t *buf0, \
 const int16_t *ubuf[2], const int16_t 
*vbuf[2], \
 const int16_t *abuf0, uint8_t *dest, int dstW, 
\
@@ -909,12 +975,15 @@ av_cold void ff_sws_init_swscale_vsx(SwsContext *c)
 switch (dstFormat) {
 case AV_PIX_FMT_YUYV422:
 c->yuv2packed1 = yuv2yuyv422_1_vsx;
+c->yuv2packed2 = yuv2yuyv422_2_vsx;
 break;
 case AV_PIX_FMT_YVYU422:
 c->yuv2packed1 = yuv2yvyu422_1_vsx;
+c->yuv2packed2 = yuv2yvyu422_2_vsx;
 break;
 case AV_PIX_FMT_UYVY422:
 c->yuv2packed1 = yuv2uyvy422_1_vsx;
+c->yuv2packed2 = yuv2uyvy422_2_vsx;
 break;
 }
 }
--
2.6.2

___
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/3] swscale/ppc: VSX-optimize yuv2422_X

[Lauri Kasanen]

./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \
-s 1200x720 -f null -vframes 100 -pix_fmt $i -nostats \
-cpuflags 0 -v error -

7.2x speedup:

yuyv422
 126354 UNITS in yuv2packedX,   16384 runs,  0 skips
  16383 UNITS in yuv2packedX,   16382 runs,  2 skips
yvyu422
 117669 UNITS in yuv2packedX,   16384 runs,  0 skips
  16271 UNITS in yuv2packedX,   16379 runs,  5 skips
uyvy422
 117310 UNITS in yuv2packedX,   16384 runs,  0 skips
  16226 UNITS in yuv2packedX,   16382 runs,  2 skips

Signed-off-by: Lauri Kasanen 
---
 libswscale/ppc/swscale_vsx.c | 104 +++
 1 file changed, 104 insertions(+)

diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 1c4051b..36b4c33 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -726,6 +726,93 @@ write422(const vector int16_t vy1, const vector int16_t 
vy2,
 }
 }

+static av_always_inline void
+yuv2422_X_vsx_template(SwsContext *c, const int16_t *lumFilter,
+ const int16_t **lumSrc, int lumFilterSize,
+ const int16_t *chrFilter, const int16_t **chrUSrc,
+ const int16_t **chrVSrc, int chrFilterSize,
+ const int16_t **alpSrc, uint8_t *dest, int dstW,
+ int y, enum AVPixelFormat target)
+{
+int i, j;
+vector int16_t vy1, vy2, vu, vv;
+vector int32_t vy32[4], vu32[2], vv32[2], tmp, tmp2, tmp3, tmp4;
+vector int16_t vlumFilter[MAX_FILTER_SIZE], vchrFilter[MAX_FILTER_SIZE];
+const vector int32_t start = vec_splats(1 << 18);
+const vector uint32_t shift19 = vec_splats(19U);
+
+for (i = 0; i < lumFilterSize; i++)
+vlumFilter[i] = vec_splats(lumFilter[i]);
+for (i = 0; i < chrFilterSize; i++)
+vchrFilter[i] = vec_splats(chrFilter[i]);
+
+for (i = 0; i < ((dstW + 1) >> 1); i += 8) {
+vy32[0] =
+vy32[1] =
+vy32[2] =
+vy32[3] =
+vu32[0] =
+vu32[1] =
+vv32[0] =
+vv32[1] = start;
+
+for (j = 0; j < lumFilterSize; j++) {
+vv = vec_ld(0, [j][i * 2]);
+tmp = vec_mule(vv, vlumFilter[j]);
+tmp2 = vec_mulo(vv, vlumFilter[j]);
+tmp3 = vec_mergeh(tmp, tmp2);
+tmp4 = vec_mergel(tmp, tmp2);
+
+vy32[0] = vec_adds(vy32[0], tmp3);
+vy32[1] = vec_adds(vy32[1], tmp4);
+
+vv = vec_ld(0, [j][(i + 4) * 2]);
+tmp = vec_mule(vv, vlumFilter[j]);
+tmp2 = vec_mulo(vv, vlumFilter[j]);
+tmp3 = vec_mergeh(tmp, tmp2);
+tmp4 = vec_mergel(tmp, tmp2);
+
+vy32[2] = vec_adds(vy32[2], tmp3);
+vy32[3] = vec_adds(vy32[3], tmp4);
+}
+
+for (j = 0; j < chrFilterSize; j++) {
+vv = vec_ld(0, [j][i]);
+tmp = vec_mule(vv, vchrFilter[j]);
+tmp2 = vec_mulo(vv, vchrFilter[j]);
+tmp3 = vec_mergeh(tmp, tmp2);
+tmp4 = vec_mergel(tmp, tmp2);
+
+vu32[0] = vec_adds(vu32[0], tmp3);
+vu32[1] = vec_adds(vu32[1], tmp4);
+
+vv = vec_ld(0, [j][i]);
+tmp = vec_mule(vv, vchrFilter[j]);
+tmp2 = vec_mulo(vv, vchrFilter[j]);
+tmp3 = vec_mergeh(tmp, tmp2);
+tmp4 = vec_mergel(tmp, tmp2);
+
+vv32[0] = vec_adds(vv32[0], tmp3);
+vv32[1] = vec_adds(vv32[1], tmp4);
+}
+
+   for (j = 0; j < 4; j++) {
+   vy32[j] = vec_sra(vy32[j], shift19);
+   }
+   for (j = 0; j < 2; j++) {
+   vu32[j] = vec_sra(vu32[j], shift19);
+   vv32[j] = vec_sra(vv32[j], shift19);
+   }
+
+vy1 = vec_packs(vy32[0], vy32[1]);
+vy2 = vec_packs(vy32[2], vy32[3]);
+vu = vec_packs(vu32[0], vu32[1]);
+vv = vec_packs(vv32[0], vv32[1]);
+
+write422(vy1, vy2, vu, vv, [i * 4], target);
+}
+}
+
 #define SETUP(x, buf0, buf1, alpha) { \
 x = vec_ld(0, buf0); \
 tmp = vec_mule(x, alpha); \
@@ -841,7 +928,21 @@ yuv2422_1_vsx_template(SwsContext *c, const int16_t *buf0,
 }
 }

+#define YUV2PACKEDWRAPPERX(name, base, ext, fmt) \
+static void name ## ext ## _X_vsx(SwsContext *c, const int16_t *lumFilter, \
+const int16_t **lumSrc, int lumFilterSize, \
+const int16_t *chrFilter, const int16_t 
**chrUSrc, \
+const int16_t **chrVSrc, int chrFilterSize, \
+const int16_t **alpSrc, uint8_t *dest, int 
dstW, \
+int y) \
+{ \
+name ## base ## _X_vsx_template(c, lumFilter, lumSrc, lumFilterSize, \
+  chrFilter, chrUSrc, chrVSrc, chrFilterSize, \
+  alpSrc, dest, dstW, y, fmt); \
+}
+
 #define YUV2PACKEDWRAPPER2(name, base, ext, fmt) \

[FFmpeg-devel] [PATCH 1/3] swscale/ppc: VSX-optimize yuv2422_1

[Lauri Kasanen]

./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \
-s 1200x1440 -f null -vframes 100 -pix_fmt $i -nostats \
-cpuflags 0 -v error -

15.3x speedup:

yuyv422
  14513 UNITS in yuv2packed1,   32768 runs,  0 skips
949 UNITS in yuv2packed1,   32767 runs,  1 skips
yvyu422
  14516 UNITS in yuv2packed1,   32767 runs,  1 skips
943 UNITS in yuv2packed1,   32767 runs,  1 skips
uyvy422
  14530 UNITS in yuv2packed1,   32767 runs,  1 skips
941 UNITS in yuv2packed1,   32766 runs,  2 skips

Signed-off-by: Lauri Kasanen 
---
 libswscale/ppc/swscale_vsx.c | 149 +++
 1 file changed, 149 insertions(+)

Series on top of "swscale/ppc: VSX-optimize yuv2rgb_full".

diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 062ab0d..0bb82ac 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -664,6 +664,143 @@ YUV2RGBWRAPPER(yuv2, rgb_full, xbgr32_full, 
AV_PIX_FMT_ABGR,  0)
 YUV2RGBWRAPPER(yuv2, rgb_full, rgb24_full,  AV_PIX_FMT_RGB24, 0)
 YUV2RGBWRAPPER(yuv2, rgb_full, bgr24_full,  AV_PIX_FMT_BGR24, 0)

+static av_always_inline void
+write422(const vector int16_t vy1, const vector int16_t vy2,
+ const vector int16_t vu, const vector int16_t vv,
+ uint8_t *dest, const enum AVPixelFormat target)
+{
+vector uint8_t vd1, vd2, tmp;
+const vector uint8_t yuyv1 = (vector uint8_t) {
+ 0x0, 0x10, 0x1, 0x18,
+ 0x2, 0x11, 0x3, 0x19,
+ 0x4, 0x12, 0x5, 0x1a,
+ 0x6, 0x13, 0x7, 0x1b };
+const vector uint8_t yuyv2 = (vector uint8_t) {
+ 0x8, 0x14, 0x9, 0x1c,
+ 0xa, 0x15, 0xb, 0x1d,
+ 0xc, 0x16, 0xd, 0x1e,
+ 0xe, 0x17, 0xf, 0x1f };
+const vector uint8_t yvyu1 = (vector uint8_t) {
+ 0x0, 0x18, 0x1, 0x10,
+ 0x2, 0x19, 0x3, 0x11,
+ 0x4, 0x1a, 0x5, 0x12,
+ 0x6, 0x1b, 0x7, 0x13 };
+const vector uint8_t yvyu2 = (vector uint8_t) {
+ 0x8, 0x1c, 0x9, 0x14,
+ 0xa, 0x1d, 0xb, 0x15,
+ 0xc, 0x1e, 0xd, 0x16,
+ 0xe, 0x1f, 0xf, 0x17 };
+const vector uint8_t uyvy1 = (vector uint8_t) {
+ 0x10, 0x0, 0x18, 0x1,
+ 0x11, 0x2, 0x19, 0x3,
+ 0x12, 0x4, 0x1a, 0x5,
+ 0x13, 0x6, 0x1b, 0x7 };
+const vector uint8_t uyvy2 = (vector uint8_t) {
+ 0x14, 0x8, 0x1c, 0x9,
+ 0x15, 0xa, 0x1d, 0xb,
+ 0x16, 0xc, 0x1e, 0xd,
+ 0x17, 0xe, 0x1f, 0xf };
+
+vd1 = vec_packsu(vy1, vy2);
+vd2 = vec_packsu(vu, vv);
+
+switch (target) {
+case AV_PIX_FMT_YUYV422:
+tmp = vec_perm(vd1, vd2, yuyv1);
+vec_st(tmp, 0, dest);
+tmp = vec_perm(vd1, vd2, yuyv2);
+vec_st(tmp, 16, dest);
+break;
+case AV_PIX_FMT_YVYU422:
+tmp = vec_perm(vd1, vd2, yvyu1);
+vec_st(tmp, 0, dest);
+tmp = vec_perm(vd1, vd2, yvyu2);
+vec_st(tmp, 16, dest);
+break;
+case AV_PIX_FMT_UYVY422:
+tmp = vec_perm(vd1, vd2, uyvy1);
+vec_st(tmp, 0, dest);
+tmp = vec_perm(vd1, vd2, uyvy2);
+vec_st(tmp, 16, dest);
+break;
+}
+}
+
+static av_always_inline void
+yuv2422_1_vsx_template(SwsContext *c, const int16_t *buf0,
+ const int16_t *ubuf[2], const int16_t *vbuf[2],
+ const int16_t *abuf0, uint8_t *dest, int dstW,
+ int uvalpha, int y, enum AVPixelFormat target)
+{
+const int16_t *ubuf0 = ubuf[0], *vbuf0 = vbuf[0];
+vector int16_t vy1, vy2, vu, vv, tmp;
+const vector int16_t add64 = vec_splats((int16_t) 64);
+const vector int16_t add128 = vec_splats((int16_t) 128);
+const vector uint16_t shift7 = vec_splat_u16(7);
+const vector uint16_t shift8 = vec_splat_u16(8);
+int i;
+
+if (uvalpha < 2048) {
+for (i = 0; i < ((dstW + 1) >> 1); i += 8) {
+vy1 = vec_ld(0, [i * 2]);
+vy2 = vec_ld(0, [(i + 4) * 2]);
+vu = vec_ld(0, [i]);
+vv = vec_ld(0, [i]);
+
+vy1 = vec_add(vy1, add64);
+vy2 = vec_add(vy2, add64);
+vu = vec_add(vu, add64);
+vv = vec_add(vv, add64);
+
+vy1 = vec_sra(vy1, shift7);
+vy2 = vec_sra(vy2, shift7);
+vu = vec_sra(vu, shift7);
+vv = vec_sra(vv, shift7);
+
+write422(vy1, vy2, vu, vv, [i * 4], 

Re: [FFmpeg-devel] Added support for XV video files

[Moritz Barsnick]

On Sun, Mar 24, 2019 at 16:35:40 +0530, Shivam Goyal wrote:
>  libavformat/xvdec.c  | 1395 ++
>  libavformat/xvtools.h|   95 +++

This looks like a 90% copy of flvdec, with some modifications. I
believe it should be merged into flvdec as an additional supported
format, thereby sharing the code.

> +// /*
> +//  * XV demuxer
> +//  * Copyright (c) 2003 The FFmpeg Project

Crazy comment style. ;-)

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] avformat/dashenc: Add support for Global SIDX

[Karthick J via ffmpeg-devel]

---
 doc/muxers.texi   |   3 ++
 libavformat/dashenc.c | 119 --
 2 files changed, 84 insertions(+), 38 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index aac7d94edf..83ae017d6c 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -293,6 +293,9 @@ Set container format (mp4/webm) options using a @code{:} 
separated list of
 key=value parameters. Values containing @code{:} special characters must be
 escaped.
 
+@item -global_sidx @var{global_sidx}
+Write global SIDX atom. Applicable only for single file, mp4 output, 
non-streaming mode.
+
 @item -dash_segment_type @var{dash_segment_type}
 Possible values:
 @item auto
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 1b74bce060..f8d71166d4 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -140,6 +140,7 @@ typedef struct DASHContext {
 int64_t timeout;
 int index_correction;
 char *format_options_str;
+int global_sidx;
 SegmentType segment_type_option;  /* segment type as specified in options 
*/
 int ignore_io_errors;
 int lhls;
@@ -368,7 +369,7 @@ static void set_codec_str(AVFormatContext *s, 
AVCodecParameters *par,
 }
 }
 
-static int flush_dynbuf(OutputStream *os, int *range_length)
+static int flush_dynbuf(DASHContext *c, OutputStream *os, int *range_length)
 {
 uint8_t *buffer;
 
@@ -380,16 +381,21 @@ static int flush_dynbuf(OutputStream *os, int 
*range_length)
 av_write_frame(os->ctx, NULL);
 avio_flush(os->ctx->pb);
 
-// write out to file
-*range_length = avio_close_dyn_buf(os->ctx->pb, );
-os->ctx->pb = NULL;
-if (os->out)
-avio_write(os->out, buffer + os->written_len, *range_length - 
os->written_len);
-os->written_len = 0;
-av_free(buffer);
-
-// re-open buffer
-return avio_open_dyn_buf(>ctx->pb);
+if (!c->single_file) {
+// write out to file
+*range_length = avio_close_dyn_buf(os->ctx->pb, );
+os->ctx->pb = NULL;
+if (os->out)
+avio_write(os->out, buffer + os->written_len, *range_length - 
os->written_len);
+os->written_len = 0;
+av_free(buffer);
+
+// re-open buffer
+return avio_open_dyn_buf(>ctx->pb);
+} else {
+*range_length = avio_tell(os->ctx->pb) - os->pos;
+return 0;
+}
 }
 
 static void set_http_options(AVDictionary **options, DASHContext *c)
@@ -508,7 +514,7 @@ static int flush_init_segment(AVFormatContext *s, 
OutputStream *os)
 DASHContext *c = s->priv_data;
 int ret, range_length;
 
-ret = flush_dynbuf(os, _length);
+ret = flush_dynbuf(c, os, _length);
 if (ret < 0)
 return ret;
 
@@ -537,8 +543,12 @@ static void dash_free(AVFormatContext *s)
 return;
 for (i = 0; i < s->nb_streams; i++) {
 OutputStream *os = >streams[i];
-if (os->ctx && os->ctx->pb)
-ffio_free_dyn_buf(>ctx->pb);
+if (os->ctx && os->ctx->pb) {
+if (!c->single_file)
+ffio_free_dyn_buf(>ctx->pb);
+else
+avio_close(os->ctx->pb);
+}
 ff_format_io_close(s, >out);
 if (os->ctx)
 avformat_free_context(os->ctx);
@@ -1106,6 +1116,16 @@ static int dash_init(AVFormatContext *s)
 c->lhls = 0;
 }
 
+if (c->global_sidx && !c->single_file) {
+av_log(s, AV_LOG_WARNING, "Global SIDX option will be ignored as 
single_file is not enabled\n");
+c->global_sidx = 0;
+}
+
+if (c->global_sidx && c->streaming) {
+av_log(s, AV_LOG_WARNING, "Global SIDX option will be ignored as 
streaming is enabled\n");
+c->global_sidx = 0;
+}
+
 av_strlcpy(c->dirname, s->url, sizeof(c->dirname));
 ptr = strrchr(c->dirname, '/');
 if (ptr) {
@@ -1201,9 +1221,6 @@ static int dash_init(AVFormatContext *s)
 ctx->avoid_negative_ts = s->avoid_negative_ts;
 ctx->flags = s->flags;
 
-if ((ret = avio_open_dyn_buf(>pb)) < 0)
-return ret;
-
 if (c->single_file) {
 if (os->single_file_name)
 ff_dash_fill_tmpl_params(os->initfile, sizeof(os->initfile), 
os->single_file_name, i, 0, os->bit_rate, 0);
@@ -1214,7 +1231,14 @@ static int dash_init(AVFormatContext *s)
 }
 snprintf(filename, sizeof(filename), "%s%s", c->dirname, os->initfile);
 set_http_options(, c);
-ret = s->io_open(s, >out, filename, AVIO_FLAG_WRITE, );
+if (!c->single_file) {
+if ((ret = avio_open_dyn_buf(>pb)) < 0)
+return ret;
+ret = s->io_open(s, >out, filename, AVIO_FLAG_WRITE, );
+} else {
+ctx->url = av_strdup(filename);
+ret = avio_open2(>pb, filename, AVIO_FLAG_WRITE, NULL, );
+}
 av_dict_free();
 if (ret < 0)
 return ret;
@@ -1232,8 +1256,12 @@ static int dash_init(AVFormatContext *s)
 // skip_sidx : 

[FFmpeg-devel] [PATCH 1/2] avformat/movenc: Fix skip_trailer when global_sidx is enabled

[Karthick J via ffmpeg-devel]

---
 libavformat/movenc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 8969d5b170..f46cbc5ea5 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6745,9 +6745,8 @@ static int mov_write_trailer(AVFormatContext *s)
 avio_seek(pb, mov->reserved_header_pos, SEEK_SET);
 mov_write_sidx_tags(pb, mov, -1, 0);
 avio_seek(pb, end, SEEK_SET);
-avio_write_marker(s->pb, AV_NOPTS_VALUE, AVIO_DATA_MARKER_TRAILER);
-mov_write_mfra_tag(pb, mov);
-} else if (!(mov->flags & FF_MOV_FLAG_SKIP_TRAILER)) {
+}
+if (!(mov->flags & FF_MOV_FLAG_SKIP_TRAILER)) {
 avio_write_marker(s->pb, AV_NOPTS_VALUE, AVIO_DATA_MARKER_TRAILER);
 mov_write_mfra_tag(pb, mov);
 }
-- 
2.17.2 (Apple Git-113)

___
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 5/5] aarch64/opusdsp: implement NEON accerelated postfilter and deemphasis

[Lynne]

24 Mar 2019, 00:25 by ceffm...@gmail.com:

> 2019-03-24 0:26 GMT+01:00, Lynne <> d...@lynne.ee > >:
>
>>
>> 23 Mar 2019, 22:27 by >> ceffm...@gmail.com >> :
>>
>>> 2019-03-23 19:20 GMT+01:00, Lynne <> >>> d...@lynne.ee 
>>> > d...@lynne.ee 
>>> >
>>> >:
>>>
>>> Which toolchains did you test?
>>> (For compilation, not performance.)
>>>
>>
>> gcc 8.2.1 on both aarch64 and x86-64
>>
>
> Please also test Android and tell us if you
> can test ios compilation.
> (Assuming you cannot test arm64 for Windows.)
>

 I can't install aarch64 android on the raspberry pi 3
 so I can't test that.

>>>
>>> Please test compilation for Android (there is no native
>>> toolchain afaik).
>>>
>>
>> Cross compilation works fine.
>>
>
> Which toolchain did you test?
>
> Carl Eugen
>
> make libavcodec/aarch64/opusdsp_neon.o
> AS  libavcodec/aarch64/opusdsp_neon.o
> /tmp/opusdsp_neon-ac304f.s:86:33: error: invalid operand for instruction
>  fmul v0.4s, v4.4s, v0.4s[0]
>  ^
>

Does the toolchain you use compile fft_neon.S? It uses the same syntax.
___
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] swscale: Remove duplicated code

[Lauri Kasanen]

In this function, the exact same clamping happens both in the if and 
unconditionally.

Signed-off-by: Lauri Kasanen 
---
 libswscale/output.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/libswscale/output.c b/libswscale/output.c
index d7c53e6..8441ddd 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -846,13 +846,6 @@ yuv2422_1_c_template(SwsContext *c, const int16_t *buf0,
 int U  = (ubuf0[i]   +64) >> 7;
 int V  = (vbuf0[i]   +64) >> 7;

-if ((Y1 | Y2 | U | V) & 0x100) {
-Y1 = av_clip_uint8(Y1);
-Y2 = av_clip_uint8(Y2);
-U  = av_clip_uint8(U);
-V  = av_clip_uint8(V);
-}
-
 Y1 = av_clip_uint8(Y1);
 Y2 = av_clip_uint8(Y2);
 U  = av_clip_uint8(U);
@@ -868,13 +861,6 @@ yuv2422_1_c_template(SwsContext *c, const int16_t *buf0,
 int U  = (ubuf0[i] + ubuf1[i]+128) >> 8;
 int V  = (vbuf0[i] + vbuf1[i]+128) >> 8;

-if ((Y1 | Y2 | U | V) & 0x100) {
-Y1 = av_clip_uint8(Y1);
-Y2 = av_clip_uint8(Y2);
-U  = av_clip_uint8(U);
-V  = av_clip_uint8(V);
-}
-
 Y1 = av_clip_uint8(Y1);
 Y2 = av_clip_uint8(Y2);
 U  = av_clip_uint8(U);
--
2.6.2

___
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] Added support for XV video files

[Shivam Goyal]

The attached patch is for ticket #3720

    https://trac.ffmpeg.org/ticket/3720

I have tested this demuxer on the files 1.xv and 5.xv attached with the 
ticket


http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3720/


 It is working on both of these files.

As XV video files are flv files with some encrypted data. These can be 
converted to flv without loosing video quality (and it would be really 
fast). I have also tried this and it is working "ffmpeg -i 1.xv -c copy 
converted.flv".



Please suggest any improvements


>From 84418c7dd384e9b3e42a2c43f4823ff4816e634e Mon Sep 17 00:00:00 2001
From: Shivam Goyal 
Date: Sun, 24 Mar 2019 16:19:05 +0530
Subject: [PATCH] Added XV file support

---
 libavformat/Makefile |1 +
 libavformat/allformats.c |1 +
 libavformat/xvdec.c  | 1395 ++
 libavformat/xvtools.h|   95 +++
 4 files changed, 1492 insertions(+)
 create mode 100644 libavformat/xvdec.c
 create mode 100644 libavformat/xvtools.h

diff --git a/libavformat/Makefile b/libavformat/Makefile
index c010fc83f9..9fc1288ed3 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -187,6 +187,7 @@ OBJS-$(CONFIG_FLAC_MUXER)+= flacenc.o flacenc_header.o \
 vorbiscomment.o
 OBJS-$(CONFIG_FLIC_DEMUXER)  += flic.o
 OBJS-$(CONFIG_FLV_DEMUXER)   += flvdec.o
+OBJS-$(CONFIG_XV_DEMUXER)+= xvdec.o
 OBJS-$(CONFIG_LIVE_FLV_DEMUXER)  += flvdec.o
 OBJS-$(CONFIG_FLV_MUXER) += flvenc.o avc.o
 OBJS-$(CONFIG_FOURXM_DEMUXER)+= 4xm.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 73d69cda99..7a6a26328f 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -144,6 +144,7 @@ extern AVInputFormat  ff_flac_demuxer;
 extern AVOutputFormat ff_flac_muxer;
 extern AVInputFormat  ff_flic_demuxer;
 extern AVInputFormat  ff_flv_demuxer;
+extern AVInputFormat  ff_xv_demuxer;
 extern AVOutputFormat ff_flv_muxer;
 extern AVInputFormat  ff_live_flv_demuxer;
 extern AVInputFormat  ff_fourxm_demuxer;
diff --git a/libavformat/xvdec.c b/libavformat/xvdec.c
new file mode 100644
index 00..70683635b3
--- /dev/null
+++ b/libavformat/xvdec.c
@@ -0,0 +1,1395 @@
+// /*
+//  * XV demuxer
+//  * Copyright (c) 2003 The FFmpeg Project
+//  *
+//  * This demuxer will generate a 1 byte extradata for VP6F content.
+//  * It is composed of:
+//  *  - upper 4 bits: difference between encoded width and visible width
+//  *  - lower 4 bits: difference between encoded height and visible height
+//  *
+//  * 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 "libavutil/avstring.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/dict.h"
+#include "libavutil/opt.h"
+#include "libavutil/intfloat.h"
+#include "libavutil/mathematics.h"
+#include "libavcodec/bytestream.h"
+#include "libavcodec/mpeg4audio.h"
+#include "avformat.h"
+#include "internal.h"
+#include "avio_internal.h"
+#include "flv.h"
+#include "xvtools.h"
+#define VALIDATE_INDEX_TS_THRESH 2500
+
+#define RESYNC_BUFFER_SIZE (1<<20)
+
+typedef struct XVContext {
+const AVClass *class; ///< Class for private options.
+int trust_metadata;   ///< configure streams according onMetaData
+int trust_datasize;   ///< trust data size of FLVTag
+int dump_full_metadata;   ///< Dump full metadata of the onMetadata
+int wrong_dts;///< wrong dts due to negative cts
+uint8_t *new_extradata[FLV_STREAM_TYPE_NB];
+int new_extradata_size[FLV_STREAM_TYPE_NB];
+int last_sample_rate;
+int last_channels;
+struct {
+int64_t dts;
+int64_t pos;
+} validate_index[2];
+int validate_next;
+int validate_count;
+int searched_for_end;
+
+uint8_t resync_buffer[2*RESYNC_BUFFER_SIZE];
+
+int broken_sizes;
+int sum_flv_tag_size;
+
+int last_keyframe_stream_index;
+int keyframe_count;
+int64_t video_bit_rate;
+int64_t audio_bit_rate;
+int64_t *keyframe_times;
+int64_t *keyframe_filepositions;
+int missing_streams;
+AVRational framerate;
+int64_t last_ts;
+int64_t time_offset;
+int64_t time_pos;
+

[FFmpeg-devel] [PATCH 2/2] avcodec/hevcdec: Fix return code for explode mode

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/hevcdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index fe4b5fdb5b..b7e2d68f5e 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2923,6 +2923,7 @@ static int decode_nal_unit(HEVCContext *s, const H2645NAL 
*nal)
 return ret;
 if (ret == 1) {
 av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being the 
first in the same frame.\n");
+ret = AVERROR_INVALIDDATA;
 goto fail;
 }
 
-- 
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/2] avcodec/hevcdec: Avoid duplicate test about first slices

[Michael Niedermayer]

This should be more robust as it avoids 2 conditions in seperate places which
need to stay the same

Signed-off-by: Michael Niedermayer 
---
 libavcodec/hevcdec.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 4d149f4d9f..fe4b5fdb5b 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -489,7 +489,7 @@ static int hls_slice_header(HEVCContext *s)
 // Coded parameters
 sh->first_slice_in_pic_flag = get_bits1(gb);
 if (s->ref && sh->first_slice_in_pic_flag)
-return 0; // This slice will be skiped later, do not corrupt state
+return 1; // This slice will be skiped later, do not corrupt state
 
 if ((IS_IDR(s) || IS_BLA(s)) && sh->first_slice_in_pic_flag) {
 s->seq_decode = (s->seq_decode + 1) & 0xff;
@@ -2921,6 +2921,11 @@ static int decode_nal_unit(HEVCContext *s, const 
H2645NAL *nal)
 ret = hls_slice_header(s);
 if (ret < 0)
 return ret;
+if (ret == 1) {
+av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being the 
first in the same frame.\n");
+goto fail;
+}
+
 
 if (
 (s->avctx->skip_frame >= AVDISCARD_BIDIR && s->sh.slice_type == 
HEVC_SLICE_B) ||
@@ -2930,10 +2935,6 @@ static int decode_nal_unit(HEVCContext *s, const 
H2645NAL *nal)
 }
 
 if (s->sh.first_slice_in_pic_flag) {
-if (s->ref) {
-av_log(s->avctx, AV_LOG_ERROR, "Two slices reporting being the 
first in the same frame.\n");
-goto fail;
-}
 if (s->max_ra == INT_MAX) {
 if (s->nal_unit_type == HEVC_NAL_CRA_NUT || IS_BLA(s)) {
 s->max_ra = s->poc;
-- 
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] avcodec/hevcdec: Avoid only partly skiping duplicate first slices

[Michael Niedermayer]

On Sat, Mar 23, 2019 at 05:33:25PM -0300, James Almer wrote:
> On 3/23/2019 5:25 PM, Michael Niedermayer wrote:
> > Fixes: NULL pointer dereference and out of array access
> > Fixes: 
> > 13871/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5746167087890432
> > Fixes: 
> > 13845/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5650370728034304
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/hevcdec.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> > index 86adab0ae1..4d149f4d9f 100644
> > --- a/libavcodec/hevcdec.c
> > +++ b/libavcodec/hevcdec.c
> > @@ -488,6 +488,9 @@ static int hls_slice_header(HEVCContext *s)
> >  
> >  // Coded parameters
> >  sh->first_slice_in_pic_flag = get_bits1(gb);
> > +if (s->ref && sh->first_slice_in_pic_flag)
> > +return 0; // This slice will be skiped later, do not corrupt state
> 
> I assume this is a regression after 70c8c8a818? If so, please also
> backport this patch to branches 2.8 to 4.1.

yes, will do

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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".