Re: [FFmpeg-devel] [PATCH] lavfi/tonemap_opencl: reuse matrix calculation from vf_colorspace

[Song, Ruiling]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Ruiling Song
> Sent: Wednesday, November 28, 2018 2:09 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Song, Ruiling 
> Subject: [FFmpeg-devel] [PATCH] lavfi/tonemap_opencl: reuse matrix
> calculation from vf_colorspace
> 
> As these functions are moved to shared file, other colorspace-related
> filters could also leverage the code.
> 
> Signed-off-by: Ruiling Song 
> ---
>  libavfilter/colorspace.c| 71 +
>  libavfilter/colorspace.h|  4 ++
>  libavfilter/opencl/colorspace_common.cl | 25 ---
>  libavfilter/vf_colorspace.c | 80 
> ++---
>  libavfilter/vf_tonemap_opencl.c | 62 +++--
>  5 files changed, 106 insertions(+), 136 deletions(-)
> 
> diff --git a/libavfilter/colorspace.c b/libavfilter/colorspace.c
> index c668221..19616e4 100644
> --- a/libavfilter/colorspace.c
> +++ b/libavfilter/colorspace.c
> @@ -93,6 +93,77 @@ void ff_fill_rgb2xyz_table(const struct
> PrimaryCoefficients *coeffs,
>  rgb2xyz[2][1] *= sg;
>  rgb2xyz[2][2] *= sb;
>  }
> +static const double ycgco_matrix[3][3] =
> +{
> +{  0.25, 0.5,  0.25 },
> +{ -0.25, 0.5, -0.25 },
> +{  0.5,  0,   -0.5  },
> +};
> +
> +static const double gbr_matrix[3][3] =
> +{
> +{ 0,1,   0   },
> +{ 0,   -0.5, 0.5 },
> +{ 0.5, -0.5, 0   },
> +};
> +
> +/*
> + * All constants explained in e.g. https://linuxtv.org/downloads/v4l-dvb-
> apis/ch02s06.html
> + * The older ones (bt470bg/m) are also explained in their respective ITU docs
> + * (e.g. https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.470-5-199802-
> S!!PDF-E.pdf)
> + * whereas the newer ones can typically be copied directly from wikipedia :)
> + */
> +static const struct LumaCoefficients luma_coefficients[AVCOL_SPC_NB] = {
> +[AVCOL_SPC_FCC]= { 0.30,   0.59,   0.11   },
> +[AVCOL_SPC_BT470BG]= { 0.299,  0.587,  0.114  },
> +[AVCOL_SPC_SMPTE170M]  = { 0.299,  0.587,  0.114  },
> +[AVCOL_SPC_BT709]  = { 0.2126, 0.7152, 0.0722 },
> +[AVCOL_SPC_SMPTE240M]  = { 0.212,  0.701,  0.087  },
> +[AVCOL_SPC_YCOCG]  = { 0.25,   0.5,0.25   },
> +[AVCOL_SPC_RGB]= { 1,  1,  1  },
> +[AVCOL_SPC_BT2020_NCL] = { 0.2627, 0.6780, 0.0593 },
> +[AVCOL_SPC_BT2020_CL]  = { 0.2627, 0.6780, 0.0593 },
> +};
> +
> +const struct LumaCoefficients *ff_get_luma_coefficients(enum AVColorSpace
> csp)
> +{
> +const struct LumaCoefficients *coeffs;
> +
> +if (csp >= AVCOL_SPC_NB)
> +return NULL;
> +coeffs = _coefficients[csp];
> +if (!coeffs->cr)
> +return NULL;
> +
> +return coeffs;
> +}
> +
> +void ff_fill_rgb2yuv_table(const struct LumaCoefficients *coeffs,
> +   double rgb2yuv[3][3])
> +{
> +double bscale, rscale;
> +
> +// special ycgco matrix
> +if (coeffs->cr == 0.25 && coeffs->cg == 0.5 && coeffs->cb == 0.25) {
> +memcpy(rgb2yuv, ycgco_matrix, sizeof(double) * 9);
> +return;
> +} else if (coeffs->cr == 1 && coeffs->cg == 1 && coeffs->cb == 1) {
> +memcpy(rgb2yuv, gbr_matrix, sizeof(double) * 9);
> +return;
> +}
> +
> +rgb2yuv[0][0] = coeffs->cr;
> +rgb2yuv[0][1] = coeffs->cg;
> +rgb2yuv[0][2] = coeffs->cb;
> +bscale = 0.5 / (coeffs->cb - 1.0);
> +rscale = 0.5 / (coeffs->cr - 1.0);
> +rgb2yuv[1][0] = bscale * coeffs->cr;
> +rgb2yuv[1][1] = bscale * coeffs->cg;
> +rgb2yuv[1][2] = 0.5;
> +rgb2yuv[2][0] = 0.5;
> +rgb2yuv[2][1] = rscale * coeffs->cg;
> +rgb2yuv[2][2] = rscale * coeffs->cb;
> +}
> 
>  double ff_determine_signal_peak(AVFrame *in)
>  {
> diff --git a/libavfilter/colorspace.h b/libavfilter/colorspace.h
> index 9366818..459a5df 100644
> --- a/libavfilter/colorspace.h
> +++ b/libavfilter/colorspace.h
> @@ -44,6 +44,10 @@ void ff_fill_rgb2xyz_table(const struct
> PrimaryCoefficients *coeffs,
> const struct WhitepointCoefficients *wp,
> double rgb2xyz[3][3]);
> 
> +const struct LumaCoefficients *ff_get_luma_coefficients(enum AVColorSpace
> csp);
> +void ff_fill_rgb2yuv_table(const struct LumaCoefficients *coeffs,
> +   double rgb2yuv[3][3]);
> +
>  double ff_determine_signal_peak(AVFrame *in);
>  void ff_update_hdr_metadata(AVFrame *in, double peak);
> 
> diff --git a/libavfilter/opencl/colorspace_common.cl
> b/libavfilter/opencl/colorspace_common.cl
> index 94a4dd0..1d68a54 100644
> --- a/libavfilter/opencl/colorspace_common.cl
> +++ b/libavfilter/opencl/colorspace_common.cl
> @@ -39,31 +39,6 @@ constant const float ST2084_C1 = 0.8359375f;
>  constant const float ST2084_C2 = 18.8515625f;
>  constant const float ST2084_C3 = 18.6875f;
> 
> -__constant float yuv2rgb_bt2020[] = {
> -1.0f, 0.0f, 1.4746f,
> -1.0f, -0.16455f, -0.57135f,
> -

Re: [FFmpeg-devel] [PATCH V2] lavf: add transpose_opencl filter

[Song, Ruiling]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Monday, December 3, 2018 8:10 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH V2] lavf: add transpose_opencl filter
> 
> On 28/11/2018 02:27, Ruiling Song wrote:
> > Signed-off-by: Ruiling Song 
> > ---
> >  configure |   1 +
> >  libavfilter/Makefile  |   1 +
> >  libavfilter/allfilters.c  |   1 +
> >  libavfilter/opencl/transpose.cl   |  35 +
> >  libavfilter/opencl_source.h   |   1 +
> >  libavfilter/transpose.h   |  34 +
> >  libavfilter/vf_transpose.c|  14 +-
> >  libavfilter/vf_transpose_opencl.c | 288
> ++
> >  8 files changed, 362 insertions(+), 13 deletions(-)
> >  create mode 100644 libavfilter/opencl/transpose.cl
> >  create mode 100644 libavfilter/transpose.h
> >  create mode 100644 libavfilter/vf_transpose_opencl.c
> 
> Testing the passthrough option here reveals a slightly unfortunate interaction
> with mapping - if this is the only filter in use, then not doing a redundant 
> copy
> can fall over.
> 
> For example, on Rockchip (Mali) decoding with rkmpp then using:
> 
> -vf
> hwmap=derive_device=opencl,transpose_opencl=dir=clock:passthrough=landsc
> ape,hwdownload,format=nv12
> 
> fails at the download in the passthrough case because it doesn't allow the 
> read
> (the extension does explicitly document this constraint -
>  emory.txt>).
> 
> VAAPI has a similar problem with a decode followed by:
> 
> -vf
> hwmap=derive_device=opencl,transpose_opencl,hwmap=derive_device=vaapi:r
> everse=1
> 
> because the reverse mapping tries to replace the inlink hw_frames_ctx in a way
> which doesn't actually work.
> 
> All of these cases do of course work if anything else is in the way - any 
> additional
> opencl filter on either side makes it work.  I think it's fine to ignore this 
> (after all,
> the hwmap immediately followed by hwdownload case can already fail in the
> same way), but any thoughts you have on making that better are welcome.
I also noticed that when I did testing. Currently have no idea on how to fix it.
But I do have interest to look for a better fix for this issue.
Right now I am still struggling to understand the source code of hwmap.
I didn't figure out how the hwmap will be used to map from software to hardware 
format.
That is the piece of code starting from line 200 in vf_hwmap.c
https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_hwmap.c#L200
Could you show me some example command that would go into this branch?

Thanks!
Ruiling
> 
> 
> >> Does the dependency on dir have any effect on speed here?  Any call is only
> ever
> >> going to use one side of each of the dir cases, so it feels like it might 
> >> be nicer
> to
> >> hard-code that so they aren't included in the compiled code at all.
> > For such memory bound OpenCL kernel, some little more arithmetic operation
> would not affect the overall performance.
> > I did some more testing, and see no obvious performance difference for
> different 'dir' parameter. So I just keep it as now.
> 
> That makes sense, thank you for checking.
> 
> 
> So, LGTM and applied.
> 
> Thanks,
> 
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swscale/ppc: Move VSX-using code to its own file

[Lauri Kasanen]

On Tue, 4 Dec 2018 03:21:30 +0100
Michael Niedermayer  wrote:

> On Mon, Dec 03, 2018 at 09:24:47AM +0200, Lauri Kasanen wrote:
> > Also ping on "swscale/output: VSX-optimize
> > nbps yuv2plane1".
> 
> This IIUC has not been tested on BE yet
> 
> my ppc emulation setup is a bit broken and my ppc hw ive not tried using
> since years and it was not in good shape last i used it.
> So i cant just quickly test this ...

Raptor offers free POWER9 VMs to open source projects. Since you're the
leader of ffmpeg, if you asked, I'm sure they'd give one or two for
ffmpeg build and fate testing.

Ref
https://mobile.twitter.com/RaptorCompSys/status/1067018060777832449?p=v
https://mobile.twitter.com/RaptorCompSys/status/1067029086273486848?p=v

"We offer free access to cloud VPS for libre software projects in
partnership with @Integricloud, would that help?"

"Contact sa...@integricloud.com and tell them what you want to use a
VPS or two for. They will generally grant access to the resources."

(I'm developing on a POWER8 VM intended for devs, but ordered a
Blackbird from the cyber monday sale ;))

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

Re: [FFmpeg-devel] [PATCH v3] lavf/dashenc: Write media trailers when DASH trailer is written.

[Jeyapal, Karthick]

On 12/3/18 4:48 PM, Andrey Semashev wrote:
> This commit ensures that all (potentially, long) filesystem activity is
> performed when the user calls av_write_trailer on the DASH libavformat
> context, not when freeing the context. Also, this defers media segment
> deletion until after the media trailers are written.
> ---
>  libavformat/dashenc.c | 85 ++-
>  1 file changed, 60 insertions(+), 25 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 279a9bec54..4d9b564a94 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -441,8 +441,6 @@ static void dash_free(AVFormatContext *s)
>  return;
>  for (i = 0; i < s->nb_streams; i++) {
>  OutputStream *os = >streams[i];
> -if (os->ctx && os->ctx_inited)
> -av_write_trailer(os->ctx);
>  if (os->ctx && os->ctx->pb)
>  ffio_free_dyn_buf(>ctx->pb);
>  ff_format_io_close(s, >out);
> @@ -1359,6 +1357,47 @@ static void dashenc_delete_file(AVFormatContext *s, 
> char *filename) {
>  }
>  }
>  
> +static int dashenc_delete_segment_file(AVFormatContext *s, const char* file)
> +{
> +DASHContext *c = s->priv_data;
> +size_t dirname_len, file_len;
> +char filename[1024];
> +
> +dirname_len = strlen(c->dirname);
> +if (dirname_len >= sizeof(filename)) {
> +av_log(s, AV_LOG_WARNING, "Cannot delete segments as the directory 
> path is too long: %"PRIu64" characters: %s\n",
> +(uint64_t)dirname_len, c->dirname);
> +return AVERROR(ENAMETOOLONG);
> +}
> +
> +memcpy(filename, c->dirname, dirname_len);
> +
> +file_len = strlen(file);
> +if ((dirname_len + file_len) >= sizeof(filename)) {
> +av_log(s, AV_LOG_WARNING, "Cannot delete segments as the path is too 
> long: %"PRIu64" characters: %s%s\n",
> +(uint64_t)(dirname_len + file_len), c->dirname, file);
> +return AVERROR(ENAMETOOLONG);
> +}
> +
> +memcpy(filename + dirname_len, file, file_len + 1); // include the 
> terminating zero
> +dashenc_delete_file(s, filename);
> +
> +return 0;
> +}
> +
> +static inline void dashenc_delete_media_segments(AVFormatContext *s, 
> OutputStream *os, int remove_count)
> +{
> +for (int i = 0; i < remove_count; ++i) {
> +dashenc_delete_segment_file(s, os->segments[i]->file);
> +
> +// Delete the segment regardless of whether the file was 
> successfully deleted
> +av_free(os->segments[i]);
> +}
> +
> +os->nb_segments -= remove_count;
> +memmove(os->segments, os->segments + remove_count, os->nb_segments * 
> sizeof(*os->segments));
> +}
> +
>  static int dash_flush(AVFormatContext *s, int final, int stream)
>  {
>  DASHContext *c = s->priv_data;
> @@ -1448,23 +1487,12 @@ static int dash_flush(AVFormatContext *s, int final, 
> int stream)
>  os->pos += range_length;
>  }
>  
> -if (c->window_size || (final && c->remove_at_exit)) {
> +if (c->window_size) {
>  for (i = 0; i < s->nb_streams; i++) {
>  OutputStream *os = >streams[i];
> -int j;
> -int remove = os->nb_segments - c->window_size - 
> c->extra_window_size;
> -if (final && c->remove_at_exit)
> -remove = os->nb_segments;
> -if (remove > 0) {
> -for (j = 0; j < remove; j++) {
> -char filename[1024];
> -snprintf(filename, sizeof(filename), "%s%s", c->dirname, 
> os->segments[j]->file);
> -dashenc_delete_file(s, filename);
> -av_free(os->segments[j]);
> -}
> -os->nb_segments -= remove;
> -memmove(os->segments, os->segments + remove, os->nb_segments 
> * sizeof(*os->segments));
> -}
> +int remove_count = os->nb_segments - c->window_size - 
> c->extra_window_size;
> +if (remove_count > 0)
> +dashenc_delete_media_segments(s, os, remove_count);
>  }
>  }
>  
> @@ -1615,6 +1643,7 @@ static int dash_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  static int dash_write_trailer(AVFormatContext *s)
>  {
>  DASHContext *c = s->priv_data;
> +int i;
>  
>  if (s->nb_streams > 0) {
>  OutputStream *os = >streams[0];
> @@ -1630,18 +1659,24 @@ static int dash_write_trailer(AVFormatContext *s)
>  }
>  dash_flush(s, 1, -1);
>  
> -if (c->remove_at_exit) {
> -char filename[1024];
> -int i;
> -for (i = 0; i < s->nb_streams; i++) {
> -OutputStream *os = >streams[i];
> -snprintf(filename, sizeof(filename), "%s%s", c->dirname, 
> os->initfile);
> -dashenc_delete_file(s, filename);
> +for (i = 0; i < s->nb_streams; ++i) {
> +OutputStream *os = >streams[i];
> +if (os->ctx && os->ctx_inited) {
> +av_write_trailer(os->ctx);
> 

Re: [FFmpeg-devel] [PATCH] swscale/ppc: Move VSX-using code to its own file

[Michael Niedermayer]

On Mon, Dec 03, 2018 at 09:24:47AM +0200, Lauri Kasanen wrote:
> On Fri, 30 Nov 2018 14:05:26 +0200
[...]
> Also ping on "swscale/output: VSX-optimize
> nbps yuv2plane1".

This IIUC has not been tested on BE yet

my ppc emulation setup is a bit broken and my ppc hw ive not tried using
since years and it was not in good shape last i used it.
So i cant just quickly test this ...

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swscale/ppc: Move VSX-using code to its own file

[Michael Niedermayer]

On Mon, Dec 03, 2018 at 09:24:47AM +0200, Lauri Kasanen wrote:
> On Fri, 30 Nov 2018 14:05:26 +0200
> Lauri Kasanen  wrote:
> 
> > On Fri, 30 Nov 2018 12:30:58 +0300
> > Michael Kostylev  wrote:
> > > 
> > > >> Passes fate on LE (with "lavc/jrevdct: Avoid an aliasing violation" 
> > > >> applied). Can anyone test BE?
> > > >
> > > > Ping.
> > > 
> > > FATE becomes green as much as possible, I haven't performed any 
> > > benchmarking though.
> > 
> > Thanks for testing. This patch is not expected to change performance,
> > it's just moving functions around and putting them under proper VSX
> > guards.
> 
> Could this patch be applied? 

will apply

thx


> Also ping on "swscale/output: VSX-optimize
> nbps yuv2plane1".
> 
> - Lauri
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]tests/api-flac-test: Rename NUMBER_OF_FRAMES as NUMBER_OF_AUDIO_FRAMES

[Michael Niedermayer]

On Mon, Dec 03, 2018 at 01:17:42AM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Both aix and sunos define NUMBER_OF_FRAMES in a system header (as
> _NUMBER_OF_FRAMES), attached patch fixes a warning when running fate.
> 
> Please comment, Carl Eugen

>  api-flac-test.c |   10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 389d56ef407b6d7d7c8c023e6ebb41abbbd36a62  
> 0001-tests-api-flac-test-Rename-NUMBER_OF_FRAMES-as-NUMBE.patch
> From 7360f2e9721b88bb58e55f05911b16222c249e59 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Mon, 3 Dec 2018 01:14:24 +0100
> Subject: [PATCH] tests/api-flac-test: Rename NUMBER_OF_FRAMES as
>  NUMBER_OF_AUDIO_FRAMES.
> 
> Both sunos and aix define NUMBER_OF_FRAMES in a system header,
> causing redefinition warnings.
> ---
>  tests/api/api-flac-test.c |   10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

this is probably a bug in the system header ...

but renaming does no harm so this patch should be ok

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add frame-skip func

[Sun, Jing A]

Hi Mark,

Is there any issue that I need to fix for this patch please? 

Regards,
SUN, Jing


-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Sun, 
Jing A
Sent: Friday, November 23, 2018 5:37 PM
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add frame-skip 
func

Hi Mark,

In some cases, that is useful. For example, an online content distributer, who 
keeps encoding the captured video frames by ffmpeg and sending them out. At 
times, there is no update of source, which makes one or several captured source 
frames are exactly the same as the last one, and the distributer wants to just 
skip such frames, without stopping the encoding process.

Regards,
SUN, Jing


-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
Thompson
Sent: Tuesday, November 20, 2018 4:07 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add frame-skip 
func

On 19/11/18 09:04, Jing SUN wrote:
> frame-skip is required to implement network bandwidth self-adaptive 
> vaapi encoding.
> To make a frame skipped, allocate its frame side data of 
> AV_FRAME_DATA_SKIP_FRAME type and set its value to 1.

So if I'm reading this correctly the idea is to implement partial VFR by having 
a special new side-data type which indicates where frames would have been had 
the input actually matched the configured CFR behaviour?

Why is the user meant to create these special frames?  It seems to me that the 
existing method of looking at the timestamps would be a better way to find any 
gaps.

(Or, even better, add timestamps to VAAPI so that it can support VFR in a 
sensible way rather than adding hacks like this to allow partial VFR with weird 
constraints.)

> Signed-off-by: Jing SUN 
> ---
>  libavcodec/vaapi_encode.c | 142 
> --
>  libavcodec/vaapi_encode.h |   5 ++
>  libavutil/frame.c |   1 +
>  libavutil/frame.h |   5 ++
>  4 files changed, 149 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c 
> index 2fe8501..a401d61 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -23,6 +23,7 @@
>  #include "libavutil/common.h"
>  #include "libavutil/log.h"
>  #include "libavutil/pixdesc.h"
> +#include "libavutil/intreadwrite.h"
>  
>  #include "vaapi_encode.h"
>  #include "avcodec.h"
> @@ -103,6 +104,47 @@ static int vaapi_encode_make_param_buffer(AVCodecContext 
> *avctx,
>  return 0;
>  }
>  
> +static int vaapi_encode_check_if_skip(AVCodecContext *avctx,
> +  VAAPIEncodePicture *pic) {
> +AVFrameSideData *fside = NULL;
> +VAAPIEncodeContext *ctx = avctx->priv_data;
> +VAAPIEncodePicture *cur = NULL;
> +int i = 0;
> +
> +if (!pic || !pic->input_image)
> +return AVERROR(EINVAL);
> +
> +fside = av_frame_get_side_data(pic->input_image, 
> AV_FRAME_DATA_SKIP_FRAME);
> +if (fside)
> +pic->skipped_flag = AV_RL8(fside->data);
> +else
> +pic->skipped_flag = 0;
> +
> +if (0 == pic->skipped_flag)
> +return 0;
> +
> +if ((pic->type == PICTURE_TYPE_IDR) || (pic->type == PICTURE_TYPE_I)) {
> +av_log(avctx, AV_LOG_INFO, "Can't skip IDR/I pic 
> %"PRId64"/%"PRId64".\n",
> +   pic->display_order, pic->encode_order);
> +pic->skipped_flag = 0;
> +return 0;
> +}
> +
> +for (cur = ctx->pic_start; cur; cur = cur->next) {
> +for (i=0; i < cur->nb_refs; ++i) {
> +if (cur->refs[i] == pic) {
> +av_log(avctx, AV_LOG_INFO, "Can't skip ref pic 
> %"PRId64"/%"PRId64".\n",
> +   pic->display_order, pic->encode_order);
> +pic->skipped_flag = 0;
> +return 0;
> +}
> +}
> +}
> +
> +return 0;
> +}
> +
>  static int vaapi_encode_wait(AVCodecContext *avctx,
>   VAAPIEncodePicture *pic)  { @@ -418,6
> +460,69 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
>  }
>  }
>  
> +err = vaapi_encode_check_if_skip(avctx, pic);
> +if (err != 0)
> +av_log(avctx, AV_LOG_ERROR, "Fail to check if skip.\n");
> +
> +#ifdef VAEncMiscParameterSkipFrame
> +if (pic->skipped_flag) {
> +av_log(avctx, AV_LOG_INFO, "Skip pic %"PRId64"/%"PRId64" as 
> requested.\n",
> +   pic->display_order, pic->encode_order);
> +
> +++ctx->skipped_pic_count;
> +pic->encode_issued = 1;
> +
> +return 0;
> +} else if (ctx->skipped_pic_count > 0) {
> +VABufferID skip_param_id;
> +VAEncMiscParameterBuffer *misc_param;
> +VAEncMiscParameterSkipFrame *skip_param;
> +
> +err = vaapi_encode_make_param_buffer(avctx, pic,
> +  VAEncMiscParameterBufferType, NULL,
> + 

Re: [FFmpeg-devel] [PATCH] web/(old)download: Move 3.0 to olddownloads

[Michael Niedermayer]

On Mon, Dec 03, 2018 at 10:19:55AM -0900, Lou Logan wrote:
> No current downstream appears to be using 3.0:
> https://trac.ffmpeg.org/wiki/Downstreams
> 
> Signed-off-by: Lou Logan 
> ---
>  src/download| 39 ---
>  src/olddownload | 37 +
>  2 files changed, 37 insertions(+), 39 deletions(-)

I agree to move it to olddownload if "unused"
lets wait a bit though in case some downstreams where missed before applying

thx


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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/proresaw_enc : improvment (vendor and color properties, 4444Xq)

[Michael Niedermayer]

Hi

On Sun, Dec 02, 2018 at 09:44:38PM +0100, Martin Vignali wrote:
>  internal.h |   12 
>  utils.c|   19 +++
>  2 files changed, 31 insertions(+)
> 46843c218e2c53b93a283656dc3e89f93775a286  
> 0001-avcodec-utils-add-ff_int_from_list_or_default-func.patch
> From 09477289e48362c81fb25e4ffbf563de1729270a Mon Sep 17 00:00:00 2001
> From: Martin Vignali 
> Date: Sun, 2 Dec 2018 21:36:24 +0100
> Subject: [PATCH 1/4] avcodec/utils : add ff_int_from_list_or_default func
> 
> to check valid value, or return default_value
> ---
>  libavcodec/internal.h | 12 
>  libavcodec/utils.c| 19 +++
>  2 files changed, 31 insertions(+)

LGTM

thanks

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

There will always be a question for which you do not know the correct answer.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/ivi: Fix a Google-reported memleak

[Carl Eugen Hoyos]

Hi!

Attached patch is supposed to fix a memleak from clusterfuzz, untested...

Please review, Carl Eugen
From f94d6415885293351201e74a3760aae7f206515a Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 4 Dec 2018 00:32:25 +0100
Subject: [PATCH] lavc/ivi: Free an allocation on error.

Fixes a memleak reported as Issue 11696 in oss-fuzz.
---
 libavcodec/ivi.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/ivi.c b/libavcodec/ivi.c
index b23d4af..19bb01e 100644
--- a/libavcodec/ivi.c
+++ b/libavcodec/ivi.c
@@ -406,6 +406,7 @@ static int ivi_init_tiles(IVIBandDesc *band, IVITile *ref_tile,
 if (p || b) {
 if (tile->num_MBs != ref_tile->num_MBs) {
 av_log(NULL, AV_LOG_DEBUG, "ref_tile mismatch\n");
+av_freep(>mbs);
 return AVERROR_INVALIDDATA;
 }
 tile->ref_mbs = ref_tile->mbs;
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/r210: use correct pixel format

[Paul B Mahol]

On 12/3/18, Michael Niedermayer  wrote:
> On Mon, Dec 03, 2018 at 04:33:45PM +, Paul B Mahol wrote:
>> ffmpeg | branch: master | Paul B Mahol  | Sun Dec  2
>> 17:49:03 2018 +0100| [3d8d8c7199717a0a31fbe01f8931d96fe8408bd6] |
>> committer: Paul B Mahol
>>
>> avcodec/r210: use correct pixel format
>>
>> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=3d8d8c7199717a0a31fbe01f8931d96fe8408bd6
>> ---
>>
>>  libavcodec/r210dec.c  | 38
>> --
>>  libavcodec/r210enc.c  | 26 --
>>  tests/ref/vsynth/vsynth1-r210 |  6 +++---
>>  tests/ref/vsynth/vsynth2-r210 |  6 +++---
>>  tests/ref/vsynth/vsynth3-r210 |  6 +++---
>>  tests/ref/vsynth/vsynth_lena-r210 |  6 +++---
>>  6 files changed, 48 insertions(+), 40 deletions(-)
>
> breaks: (looks all blue)
> ./ffplay
> https://samples.ffmpeg.org/V-codecs/r10k/10BitRGB444_r10k_5sec_LE.avi
>

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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Jean-Baptiste Kempf]

On Mon, 3 Dec 2018, at 23:14, Marton Balint wrote:
> On Mon, 3 Dec 2018, Jean-Baptiste Kempf wrote:
> > On Mon, 3 Dec 2018, at 19:48, Paul B Mahol wrote:
> > Libraries to access hardware, notably those that are talking directly with 
> > something that was shipped with the drivers, are usually considered part of 
> > the OS. This is a bit weird, but this extend the Linux way to other 
> > (broken) OSes.
> >
> > That would make nvenc and such acceptable.
> >
> > NDI is not hardware. (Nor is faac)
> 
> I really don't want to troll here, but there is an NDI PTZ camera:
> 
> https://www.newtek.com/camera/ndihx-ptz1/
> 
> So is it really that different to a USB camera just because the 
> singalling is going through ethernet and not USB?

Yes, because NDI is a network protocol. Those cameras exposes streams, like 
RTSP.
They are servers, so they are not part of your machine.


-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v3] lavfi/vf_colorconstancy: add weighted_greyedge

[Mina]

Hi,

  This patch was part of GSoC Color Constancy filter. It introduces an 
improved color constancy filter(weighted_greyedge) based on the already 
pushed greyedge. I'm sending it again after updating it against latest 
version of master.


V3 changes:
- fixed inconsistency in filters.texi


Regards,
Mina Sami

>From f4891ca38470893d29864821cd1988bb026cf160 Mon Sep 17 00:00:00 2001
From: Mina 
Date: Tue, 4 Dec 2018 00:22:23 +0200
Subject: [PATCH] lavfi/vf_colorconstancy: add weighted_greyedge

Signed-off-by: Mina 
---
 doc/filters.texi|  39 
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_colorconstancy.c | 322 
 4 files changed, 288 insertions(+), 75 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 41fbbc5329..1cad919ba7 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -18038,6 +18038,45 @@ separatefields,select=eq(mod(n,4),0)+eq(mod(n,4),3),weave
 @end example
 @end itemize
 
+@section weighted_greyedge
+A color constancy variation filter which estimates scene illumination via weighted grey edge
+algorithm and corrects the scene colors accordingly.
+
+See: @url{http://refbase.cvc.uab.es/files/GGW2012.pdf}
+
+The filter accepts the following options:
+
+@table @option
+@item minknorm
+The Minkowski parameter to be used for calculating the Minkowski distance. Must
+be chosen in the range [1,20] and default value = 1.
+
+@item sigma
+The standard deviation of Gaussian blur to be applied to the scene. Must be
+chosen in the range [0.2,1024.0] and default value = 1.
+
+@item wmap_k
+The power applied to the weight map to emphasize heigher weights. Must be chosen
+in the range [1,20] and default value = 2.
+
+@item iters
+The maximum number of iterations for performing the algorithm. Must be chosen in the
+range [1,20] and default value = 5.
+
+@item angerr
+The angular error threshold in degrees for stopping the algorithm. Must be chosen
+in the range [0,360] and default value = 0.001.
+@end table
+
+@subsection Examples
+@itemize
+
+@item
+@example
+weighted_greyedge=minknorm=5:sigma=2:wmap_k=10:iters=10:angerr=0.0005
+@end example
+@end itemize
+
 @section xbr
 Apply the xBR high-quality magnification filter which is designed for pixel
 art. It follows a set of edge-detection rules, see
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6e2658186d..d77ca697b2 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -414,6 +414,7 @@ OBJS-$(CONFIG_VSTACK_FILTER) += vf_stack.o framesync.o
 OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
 OBJS-$(CONFIG_WAVEFORM_FILTER)   += vf_waveform.o
 OBJS-$(CONFIG_WEAVE_FILTER)  += vf_weave.o
+OBJS-$(CONFIG_WEIGHTED_GREYEDGE_FILTER)  += vf_colorconstancy.o
 OBJS-$(CONFIG_XBR_FILTER)+= vf_xbr.o
 OBJS-$(CONFIG_XSTACK_FILTER) += vf_stack.o framesync.o
 OBJS-$(CONFIG_YADIF_FILTER)  += vf_yadif.o yadif_common.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index a600069500..7dbfccb393 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -392,6 +392,7 @@ extern AVFilter ff_vf_vstack;
 extern AVFilter ff_vf_w3fdif;
 extern AVFilter ff_vf_waveform;
 extern AVFilter ff_vf_weave;
+extern AVFilter ff_vf_weighted_greyedge;
 extern AVFilter ff_vf_xbr;
 extern AVFilter ff_vf_xstack;
 extern AVFilter ff_vf_yadif;
diff --git a/libavfilter/vf_colorconstancy.c b/libavfilter/vf_colorconstancy.c
index e3bb39e51b..3b84a637c7 100644
--- a/libavfilter/vf_colorconstancy.c
+++ b/libavfilter/vf_colorconstancy.c
@@ -26,6 +26,14 @@
  *
  * @cite
  * J. van de Weijer, Th. Gevers, A. Gijsenij "Edge-Based Color Constancy".
+ *
+ * @cite
+ *  J. van de Weijer, Th. Gevers, and J. Geusebroek,
+ * “Edge and corner detection by photometric quasi-invariants”.
+ *
+ * @cite
+ * A. Gijsenij, Th. Gevers, J. van de Weijer,
+ * "Improving Color Constancy by Photometric Edge Weighting".
  */
 
 #include "libavutil/imgutils.h"
@@ -39,7 +47,8 @@
 
 #include 
 
-#define GREY_EDGE "greyedge"
+#define GREY_EDGE  "greyedge"
+#define WEIGHTED_GREY_EDGE "weighted_greyedge"
 
 #define SQRT3 1.73205080757
 
@@ -79,6 +88,10 @@ typedef struct ColorConstancyContext {
 int minknorm; /**< @minknorm = 0 : getMax instead */
 double sigma;
 
+int wmap_k;
+int iters;
+double angerr_thresh;
+
 int nb_threads;
 int planeheight[4];
 int planewidth[4];
@@ -477,53 +490,73 @@ static int filter_slice_grey_edge(AVFilterContext* ctx, void* arg, int jobnr, in
 }
 
 /**
- * Main control function for grey edge algorithm.
+ * Slice function for weighted grey edge algorithm that is called iteratively to
+ * calculate and apply weight scheme.
  *
  * @param ctx the filter context.
- * @param in frame to perfrom grey edge on.
+ * @param arg data to be passed between threads.
+ * @param jobnr current job 

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Ali KIZIL]

On Tue, Dec 4, 2018, 1:14 AM Marton Balint 
>
> On Mon, 3 Dec 2018, Jean-Baptiste Kempf wrote:
>
> > On Mon, 3 Dec 2018, at 19:48, Paul B Mahol wrote:
> >> > On the general idea of this - agreed.
> >> >
> >> > Separately I think we should at least bring up a possible rethink of
> >> > our policy about non-open source nonfree components.
> >> >
> >> > If it's:
> >> > - Not part of the OS
> >> > or
> >> > - Not open source
> >> >
> >> > ...maybe we should not include such a component upstream?
> >>
> >> Yes, remove all hardware stuff +1.
> >
> > Libraries to access hardware, notably those that are talking directly
> with something that was shipped with the drivers, are usually considered
> part of the OS. This is a bit weird, but this extend the Linux way to other
> (broken) OSes.
> >
> > That would make nvenc and such acceptable.
> >
> > NDI is not hardware. (Nor is faac)
>
> I really don't want to troll here, but there is an NDI PTZ camera:
>
> https://www.newtek.com/camera/ndihx-ptz1/
>
> So is it really that different to a USB camera just because the
> singalling is going through ethernet and not USB?
>
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


+1 or PCIe

Just a suggestion: there can be a request from well known brands who are
making contributions to FFmpeg to donate for hiring a lawyer who has
proficiency on OSS subject for both US and EU laws. It will be for their
and community's benefit, as there will be an independent point of view. I
believe there can be donators from community too. Time to time, it is
noticable users as asking for non-free compile subject.

This approach can bring a proper action for similar cases and avoid in
further. The lawyer can be supportive on CoC subject either.

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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Marton Balint]

On Mon, 3 Dec 2018, Jean-Baptiste Kempf wrote:


On Mon, 3 Dec 2018, at 19:48, Paul B Mahol wrote:

> On the general idea of this - agreed.
>
> Separately I think we should at least bring up a possible rethink of
> our policy about non-open source nonfree components.
>
> If it's:
> - Not part of the OS
> or
> - Not open source
>
> ...maybe we should not include such a component upstream?

Yes, remove all hardware stuff +1.


Libraries to access hardware, notably those that are talking directly with 
something that was shipped with the drivers, are usually considered part of the 
OS. This is a bit weird, but this extend the Linux way to other (broken) OSes.

That would make nvenc and such acceptable.

NDI is not hardware. (Nor is faac)


I really don't want to troll here, but there is an NDI PTZ camera:

https://www.newtek.com/camera/ndihx-ptz1/

So is it really that different to a USB camera just because the 
singalling is going through ethernet and not USB?


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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Jean-Baptiste Kempf]

> Again: What message would this send to future license violators?

A bad one.

I would remove this.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Jean-Baptiste Kempf]

On Mon, 3 Dec 2018, at 19:48, Paul B Mahol wrote:
> > On the general idea of this - agreed.
> >
> > Separately I think we should at least bring up a possible rethink of
> > our policy about non-open source nonfree components.
> >
> > If it's:
> > - Not part of the OS
> > or
> > - Not open source
> >
> > ...maybe we should not include such a component upstream?
> 
> Yes, remove all hardware stuff +1.

Libraries to access hardware, notably those that are talking directly with 
something that was shipped with the drivers, are usually considered part of the 
OS. This is a bit weird, but this extend the Linux way to other (broken) OSes.

That would make nvenc and such acceptable.

NDI is not hardware. (Nor is faac)

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/r210: use correct pixel format

[Michael Niedermayer]

On Mon, Dec 03, 2018 at 04:33:45PM +, Paul B Mahol wrote:
> ffmpeg | branch: master | Paul B Mahol  | Sun Dec  2 
> 17:49:03 2018 +0100| [3d8d8c7199717a0a31fbe01f8931d96fe8408bd6] | committer: 
> Paul B Mahol
> 
> avcodec/r210: use correct pixel format
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=3d8d8c7199717a0a31fbe01f8931d96fe8408bd6
> ---
> 
>  libavcodec/r210dec.c  | 38 --
>  libavcodec/r210enc.c  | 26 --
>  tests/ref/vsynth/vsynth1-r210 |  6 +++---
>  tests/ref/vsynth/vsynth2-r210 |  6 +++---
>  tests/ref/vsynth/vsynth3-r210 |  6 +++---
>  tests/ref/vsynth/vsynth_lena-r210 |  6 +++---
>  6 files changed, 48 insertions(+), 40 deletions(-)

breaks: (looks all blue)
./ffplay https://samples.ffmpeg.org/V-codecs/r10k/10BitRGB444_r10k_5sec_LE.avi



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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Jean-Baptiste Kempf]

On Mon, 3 Dec 2018, at 17:05, Carl Eugen Hoyos wrote:
> It appears to me that NewTek abused our willingness to add an optional
> external nonfree library, I don't see many better options. See Ticket
> #7589 and a blog post by a NewTek engineer confirming the issue.

+1, please apply.

Newtek is a big bully against open source developers, threatening to sue.

This is a violation, done on purpose (see the message when running the binary, 
and see the blogpost where they knew about it for months), of both FFmpeg and 
maybe x264.

Keeping this wrapper just helps people violate the FFmpeg license and the GPL.

Best,

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] lavfi/vf_colorconstancy: add weighted_greyedge

[Mina]

On 11/28/18 11:24 PM, Moritz Barsnick wrote:

On Mon, Oct 01, 2018 at 18:09:46 +0200, Mina wrote:

Nit:



Thanks for your feedback and sorry for late response.





+be chosen in the range [1,20] and default value is 1.

[...]



Not sure what is here.



+chosen in the range [0.2,1024.0] and default value = 1.

A bit inconsistent here, with "is" vs. "=".



Done, changed to "=".



+The max number of iterations for performing the algorithm. Must be chosen in 
the

^ maximum



Done, changed to "maximum".




I can't comment on the rest.

Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Marton Balint]

On Mon, 3 Dec 2018, Carl Eugen Hoyos wrote:


Hi!

It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.


You should think about our users who compile and use ffmpeg with 
NDI. This change affects them negatively, so I don't support it.


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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Ali KIZIL]

On Tue, Dec 4, 2018, 12:07 AM Carl Eugen Hoyos  2018-12-03 22:00 GMT+01:00, Ali KIZIL :
>
> > Newtek representative says, they will remove the binary from SDK right
> away
>
> Could you please read the sentence you sent?
> Particularly the words "says" and "will".
>
> They did not remove the binariy when informed about the
> license violations!
> (At least, there is no indication they did.)
>
> > Personally, I do not believe they break the license on purpose.
>
> Did you read the post on their support forum where the very
> person claiming now he had no idea it is wrong answered to
> the information that distributing such binaries is illegal?
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

Sent by across:
...
If we have offended anyone then I sincerely apologize and please accept
that it was not our intent. We will remove FFMPEG entirely from our SDK and
get it patched online today.
...

>
> I didn't read the forums, yet I take care of what he is saying and if they
> are going to remove compiled binary from their SDK with an official
> apology.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Jan Ekström]

On Mon, Dec 3, 2018 at 10:29 PM Martin Vignali  wrote:
>
> This patch looks wrong to me.
>
> It's seems like removing features for personal opinion.
>
> Ticket 7589, mention an incorrect build redistribution.
>
> So, right way to fix this ticket, will be (for people interesting in this
> kind of thing)
> to indicate, what need to be done, in order to have a licence compliant
> build.
> And if building in LGPL, it's a solution for provide a right binary,
> doesn't really understand, what
> it's not better mention in this ticket.
>

Actually, I'm not 100% sure if a closed source blob is LGPL compatible
this way - although the other way a closed source blob can include an
LGPL component as long as they provide the sources and the means to
replace the LGPL component (aka either shared libraries, or object
files for static linking). I don't remember who exactly was it whom
planted this idea in my mind (unrelated to NDI completely for the
record), but it did pop up in some discussion. Hopefully that someone
can chime in once again if he notices this.

> And if some people have personal issue with this company, i doesn't think
> this mailing list and trac it's really the right place for discussing it.
>

I think rather than having an issue with the company, some people are
having an issue with how it seems to have dealt with people who have
attempted to implement their protocol in open source (legal threats
were mentioned). Whether that is true or not I do not know, but as far
as I last saw on the issue tracker's thread there seems to be an
attempt of making it look better than it is.

I remember looking at their site and seeing their solution being
marketed as a "standard", yet there was no specification and they
clearly were only interested in their blob. But knowing nothing much
else, it was mostly on the "meh" level and thus I did not enough
strength to put enough care into looking into it more (at the time of
the patches).

> I agree with Ali Kizil,
> And the answer of newtek looks not so bad for me.
> The problem is maybe a licence violation (don't know and don't care),
> but it's very far away of selling a software with licence violation in it.
>
> This kind of agressive patch, send a very strange signal to current and
> future contributors/users.
>

Yes, I agree. We should have a more clear policy on non-OSS
contributions. Although to be completely honest the whole FFmpeg
development process is a mess. But I think we should keep this
discussion to NDI.

> FFmpeg keep some options for compatibility in long term, but can remove a
> future useful for some people so fast (just because some people would like
> to send a sanction/message) ?

If you think NDI is useful, I dearly hope you agree that it would be
more useful to you compatible with OSS licenses. Or even more so if it
was open source.

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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Carl Eugen Hoyos]

2018-12-03 22:00 GMT+01:00, Ali KIZIL :

> Newtek representative says, they will remove the binary from SDK right away

Could you please read the sentence you sent?
Particularly the words "says" and "will".

They did not remove the binariy when informed about the
license violations!
(At least, there is no indication they did.)

> Personally, I do not believe they break the license on purpose.

Did you read the post on their support forum where the very
person claiming now he had no idea it is wrong answered to
the information that distributing such binaries is illegal?

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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Paul B Mahol]

On 12/3/18, Carl Eugen Hoyos  wrote:
> 2018-12-03 21:28 GMT+01:00, Martin Vignali :
>> Ticket 7589, mention an incorrect build redistribution.
>>
>> So, right way to fix this ticket, will be (for people interesting in this
>> kind of thing)
>> to indicate, what need to be done, in order to have a licence compliant
>> build.
>
> Again: What message would this send to future license violators?
>
> Since you are throwing accusations:
> Please remind me how many license violations you have worked on.

What is this now? Why are you still here?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Nicolas George]

Ali KIZIL (2018-12-04):
> Personally, I do not believe they break the license on purpose. If so, they

They are a commercial entity, they have a legal department. "Not on
purpose" is not an excuse for them.

> wouldn't announce it. They would fo as some others do, by trying hide. So
> personally, I think removal of  code is a very strong decision for this
> kind of revertible violation, as Newtek also gets in response asap.

The only acceptable response from them now is to comply with the GPL.
This is exactly how the GPL is stated: a failure to comply with the
copyleft clauses rescinds all rights to use the original GPLed code.

Note that they did not only infringe on FFmpeg's license, they also
infringed on x264.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Ali KIZIL]

On Mon, Dec 3, 2018, 11:41 PM Carl Eugen Hoyos  2018-12-03 21:28 GMT+01:00, Martin Vignali :
> >> > >>
> >> > >> It appears to me that NewTek abused our willingness to add an
> >> > >> optional
> >> > >> external nonfree library, I don't see many better options. See
> Ticket
> >> > >> #7589 and a blog post by a NewTek engineer confirming the issue.
> >> > >>
> >> > >> Patch untested.
> >> > >>
> >> > >> Please comment, Carl Eugen
> >> > >
> >>
> >
> > This patch looks wrong to me.
> >
> > It's seems like removing features for personal opinion.
>
> This is a lie.
> (I don't care.)
>
> > Ticket 7589, mention an incorrect build redistribution.
> >
> > So, right way to fix this ticket, will be (for people interesting in this
> > kind of thing)
> > to indicate, what need to be done, in order to have a licence compliant
> > build.
>
> Again: What message would this send to future license violators?
>
> Since you are throwing accusations:
> Please remind me how many license violations you have worked on.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Newtek representative says, they will remove the binary from SDK right away
and will stop distributing as its current state with passing their
apologies, while accepting their mistake.

I do not understand that how it is being decided to remove a complete work
against a non-free distribution.

I suggest to not to take immediate harsh actions without fully discussing
the side effects.

Personally, I do not believe they break the license on purpose. If so, they
wouldn't announce it. They would fo as some others do, by trying hide. So
personally, I think removal of  code is a very strong decision for this
kind of revertible violation, as Newtek also gets in response asap.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Nicolas George]

Jan Ekström (2018-12-03):
> Separately I think we should at least bring up a possible rethink of
> our policy about non-open source nonfree components.
> 
> If it's:
> - Not part of the OS
> or
> - Not open source
> 
> ...maybe we should not include such a component upstream?

I agree.

Maybe we can make an exception when the non-free upstream is dead yet
useful, like faac was for some time. But for contributors like this NDI
thing, either they make the build components (L)GPL-compatible or they
do not enjoy the benefit of being included.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Carl Eugen Hoyos]

2018-12-03 21:28 GMT+01:00, Martin Vignali :
>> > >>
>> > >> It appears to me that NewTek abused our willingness to add an
>> > >> optional
>> > >> external nonfree library, I don't see many better options. See Ticket
>> > >> #7589 and a blog post by a NewTek engineer confirming the issue.
>> > >>
>> > >> Patch untested.
>> > >>
>> > >> Please comment, Carl Eugen
>> > >
>>
>
> This patch looks wrong to me.
>
> It's seems like removing features for personal opinion.

This is a lie.
(I don't care.)

> Ticket 7589, mention an incorrect build redistribution.
>
> So, right way to fix this ticket, will be (for people interesting in this
> kind of thing)
> to indicate, what need to be done, in order to have a licence compliant
> build.

Again: What message would this send to future license violators?

Since you are throwing accusations:
Please remind me how many license violations you have worked on.

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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Martin Vignali]

> > >>
> > >> It appears to me that NewTek abused our willingness to add an optional
> > >> external nonfree library, I don't see many better options. See Ticket
> > >> #7589 and a blog post by a NewTek engineer confirming the issue.
> > >>
> > >> Patch untested.
> > >>
> > >> Please comment, Carl Eugen
> > >
>

This patch looks wrong to me.

It's seems like removing features for personal opinion.

Ticket 7589, mention an incorrect build redistribution.

So, right way to fix this ticket, will be (for people interesting in this
kind of thing)
to indicate, what need to be done, in order to have a licence compliant
build.
And if building in LGPL, it's a solution for provide a right binary,
doesn't really understand, what
it's not better mention in this ticket.

And if some people have personal issue with this company, i doesn't think
this mailing list and trac it's really the right place for discussing it.

I agree with Ali Kizil,
And the answer of newtek looks not so bad for me.
The problem is maybe a licence violation (don't know and don't care),
but it's very far away of selling a software with licence violation in it.

This kind of agressive patch, send a very strange signal to current and
future contributors/users.

FFmpeg keep some options for compatibility in long term, but can remove a
future useful for some people so fast (just because some people would like
to send a sanction/message) ?

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

[FFmpeg-devel] [PATCH] web/(old)download: Move 3.0 to olddownloads

[Lou Logan]

No current downstream appears to be using 3.0:
https://trac.ffmpeg.org/wiki/Downstreams

Signed-off-by: Lou Logan 
---
 src/download| 39 ---
 src/olddownload | 37 +
 2 files changed, 37 insertions(+), 39 deletions(-)

diff --git a/src/download b/src/download
index cf05273..5268954 100644
--- a/src/download
+++ b/src/download
@@ -457,45 +457,6 @@ libpostproc54.  1.100
  

 
-  FFmpeg 3.0.12 "Einstein"
-
-  
-3.0.12 was released on 2018-10-28. It is the latest stable FFmpeg release
-from the 3.0 release branch, which was cut from master on 2016-02-14.
-  
-  It includes the following library versions:
-  
-  
-libavutil  55. 17.103
-libavcodec 57. 24.102
-libavformat57. 25.100
-libavdevice57.  0.101
-libavfilter 6. 31.100
-libavresample   3.  0.  0
-libswscale  4.  0.100
-libswresample   2.  0.101
-libpostproc54.  0.100
-
-  
-
-  Download 
xz tarball
-  PGP 
signature
- 
-
-  Download bzip2 tarball
-  PGP 
signature
- 
-
-  Download 
gzip tarball
-  PGP 
signature
- 
-
-  https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog/n3.0.12;>Changelog
-  https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/3.0:/RELEASE_NOTES;>Release
 Notes
- 
-   
-
-
   FFmpeg 2.8.15 "Feynman"
 
   
diff --git a/src/olddownload b/src/olddownload
index a8fd6bb..5438397 100644
--- a/src/olddownload
+++ b/src/olddownload
@@ -44,6 +44,43 @@ libpostproc54.  0.100
  

 
+  FFmpeg 3.0.12 "Einstein"
+
+  
+3.0.12 was released on 2018-10-28. It is the latest stable FFmpeg release
+from the 3.0 release branch, which was cut from master on 2016-02-14.
+  
+  It includes the following library versions:
+  
+  
+libavutil  55. 17.103
+libavcodec 57. 24.102
+libavformat57. 25.100
+libavdevice57.  0.101
+libavfilter 6. 31.100
+libavresample   3.  0.  0
+libswscale  4.  0.100
+libswresample   2.  0.101
+libpostproc54.  0.100
+
+  
+
+  Download 
xz tarball
+  PGP 
signature
+ 
+
+  Download bzip2 tarball
+  PGP 
signature
+ 
+
+  Download 
gzip tarball
+  PGP 
signature
+ 
+
+  https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog/n3.0.12;>Changelog
+  https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/3.0:/RELEASE_NOTES;>Release
 Notes
+ 
+   
 
   FFmpeg 2.7.7 "Nash"
 
-- 
2.19.2

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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Jan Ekström]

On Mon, Dec 3, 2018 at 8:48 PM Paul B Mahol  wrote:
>
> On 12/3/18, Jan Ekström  wrote:
> > On Mon, Dec 3, 2018 at 6:06 PM Carl Eugen Hoyos  wrote:
> >>
> >> Hi!
> >>
> >> It appears to me that NewTek abused our willingness to add an optional
> >> external nonfree library, I don't see many better options. See Ticket
> >> #7589 and a blog post by a NewTek engineer confirming the issue.
> >>
> >> Patch untested.
> >>
> >> Please comment, Carl Eugen
> >
> > On the general idea of this - agreed.
> >
> > Separately I think we should at least bring up a possible rethink of
> > our policy about non-open source nonfree components.
> >
> > If it's:
> > - Not part of the OS
> > or
> > - Not open source
> >
> > ...maybe we should not include such a component upstream?
>
> Yes, remove all hardware stuff +1.

That's something different, though.

- dxva2 and d3d11va are Windows APIs, thus fall under "OS"
- VT on mac/iOS does the same
- vaapi and the kernel API seem to be compatible with GPL (at least
currently), so they would stay.
- out of similar things such as NDI, SRT seems to be open source now?

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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Ali KIZIL]

On Mon, Dec 3, 2018, 9:48 PM Paul B Mahol  On 12/3/18, Jan Ekström  wrote:
> > On Mon, Dec 3, 2018 at 6:06 PM Carl Eugen Hoyos 
> wrote:
> >>
> >> Hi!
> >>
> >> It appears to me that NewTek abused our willingness to add an optional
> >> external nonfree library, I don't see many better options. See Ticket
> >> #7589 and a blog post by a NewTek engineer confirming the issue.
> >>
> >> Patch untested.
> >>
> >> Please comment, Carl Eugen
> >
> > On the general idea of this - agreed.
> >
> > Separately I think we should at least bring up a possible rethink of
> > our policy about non-open source nonfree components.
> >
> > If it's:
> > - Not part of the OS
> > or
> > - Not open source
> >
> > ...maybe we should not include such a component upstream?
>
> Yes, remove all hardware stuff +1.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


>
> While there is a non-free option and while there are lots of HW related
> implementations done by developers in such condition for long time, I
> believe it is not right to remove all thesd valuable work. This will
> definitely break to courage to submit new developments to FFmpeg.


I also think, Newtek is not in a way to hide things as they share the post.
I believe they thought their approach is normal, when considering the
current case examples.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Paul B Mahol]

On 12/3/18, Jan Ekström  wrote:
> On Mon, Dec 3, 2018 at 6:06 PM Carl Eugen Hoyos  wrote:
>>
>> Hi!
>>
>> It appears to me that NewTek abused our willingness to add an optional
>> external nonfree library, I don't see many better options. See Ticket
>> #7589 and a blog post by a NewTek engineer confirming the issue.
>>
>> Patch untested.
>>
>> Please comment, Carl Eugen
>
> On the general idea of this - agreed.
>
> Separately I think we should at least bring up a possible rethink of
> our policy about non-open source nonfree components.
>
> If it's:
> - Not part of the OS
> or
> - Not open source
>
> ...maybe we should not include such a component upstream?

Yes, remove all hardware stuff +1.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Jan Ekström]

On Mon, Dec 3, 2018 at 6:06 PM Carl Eugen Hoyos  wrote:
>
> Hi!
>
> It appears to me that NewTek abused our willingness to add an optional
> external nonfree library, I don't see many better options. See Ticket
> #7589 and a blog post by a NewTek engineer confirming the issue.
>
> Patch untested.
>
> Please comment, Carl Eugen

On the general idea of this - agreed.

Separately I think we should at least bring up a possible rethink of
our policy about non-open source nonfree components.

If it's:
- Not part of the OS
or
- Not open source

...maybe we should not include such a component upstream?

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Separated FFserver code

[Harshil Makwana]

Hello All,

I have created separate ffserver code which can be used for rtsp server only 
with no other dependency, 

Have a look into it:

Https://github.com/harshil1991/ffserver.git

Now on I will try to fix bugs and other reliability issues.

Thanks,
Harshil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Carl Eugen Hoyos]

2018-12-03 19:12 GMT+01:00, Timo Rothenpieler :
> I contacted NewTek about this, here's the pretty much immediate response
> I got:
>
> On 03.12.2018 18:55, Andrew Cross  wrote:
>> Yikes, I am pretty surprised by this to be honest I think that our intent
>> might have been entirely misconstrued.

(Note that this is hard to believe but this is not relevant.)

>> We are in no way trying to abuse anything anyone did and if they want us
>> to not distribute FFMPEG then we'd be very happy to stop doing that ... we
>> did this purely as a public service because loads of people complained
>> (hundreds) to use about NDI not being part of the FFMPEG nightly builds.
>> We had initially tried to help make it part of the nightly builds but got
>> a lot of push-back and it did not seem worth the fight (our headers are
>> MIT licensed and you can download our run-times for free, so it is no
>> different than say nvEnc, etc... that are all parts of the builds). At the
>> end of the day, we make no money of NDI and just give it away and support
>> it for free so it is hardly part of an evil ploy to corrupt anyone ;)
>>
>> I'd prefer not to jump in the middle of the thread, but we are happy to
>> work with anyone on this, our only goal is to serve people using NDI and
>> if FFMPEG do not want us to distribute it then we're happy to do that,
>> likewise if they want us to change the options we're also happy to do
>> that. We'd be happy to do what we reasonably can for it to be part of the
>> nightly builds as well ...
>>
>> Feel free to pass this along and anyone can email me directly who wants
>> too.

Don't you agree that there is something missing in this message?

>> Andrew

> I think the easiest way out here would be to make an LGPL build instead?

What kind of message does this send to future license violators?

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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Timo Rothenpieler]

I contacted NewTek about this, here's the pretty much immediate response 
I got:


On 03.12.2018 18:55, Andrew Cross  wrote:

Yikes, I am pretty surprised by this to be honest I think that our intent might 
have been entirely misconstrued.

We are in no way trying to abuse anything anyone did and if they want us to not 
distribute FFMPEG then we'd be very happy to stop doing that ... we did this 
purely as a public service because loads of people complained (hundreds) to use 
about NDI not being part of the FFMPEG nightly builds. We had initially tried 
to help make it part of the nightly builds but got a lot of push-back and it 
did not seem worth the fight (our headers are MIT licensed and you can download 
our run-times for free, so it is no different than say nvEnc, etc... that are 
all parts of the builds). At the end of the day, we make no money of NDI and 
just give it away and support it for free so it is hardly part of an evil ploy 
to corrupt anyone ;)

I'd prefer not to jump in the middle of the thread, but we are happy to work 
with anyone on this, our only goal is to serve people using NDI and if FFMPEG 
do not want us to distribute it then we're happy to do that, likewise if they 
want us to change the options we're also happy to do that. We'd be happy to do 
what we reasonably can for it to be part of the nightly builds as well ...

Feel free to pass this along and anyone can email me directly who wants too.

Andrew



I think the easiest way out here would be to make an LGPL build instead?
libndi can still be enabled then, but the build isn't nonfree.
libx264 would have to go, but that's probably still better for them than 
removing ffmpeg entirely.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] cbs: Add function to make content of a unit writable

[Andreas Rheinhardt]

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.
The actual implementation of the underlying codec-dependent
make_writable functions is not contained in this commit.

Signed-off-by: Andreas Rheinhardt 
---

Unfortunately I messed up the function parameters and made the content
parameter pretty much unusable. This version fixes this.
Notice that it supposes that both pointer to void as well as pointer to
structures have the same size and object representation. Other functions
like several memory-related ones (that use a void * argument for a
pointer to a pointer) make the same assumption, so I guess that it is
ok.

 libavcodec/cbs.c  | 21 +
 libavcodec/cbs.h  | 10 ++
 libavcodec/cbs_internal.h |  4 
 3 files changed, 35 insertions(+)

diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index ecbf57c293..13bcbb722f 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -665,3 +665,24 @@ int ff_cbs_delete_unit(CodedBitstreamContext *ctx,
 
 return 0;
 }
+
+int ff_cbs_make_unit_writable(CodedBitstreamContext *ctx,
+  CodedBitstreamUnit *unit,
+  void *content)
+{
+if (unit->content && (!unit->content_ref ||
+  !av_buffer_is_writable(unit->content_ref))) {
+int err;
+if (!ctx->codec->make_writable)
+return AVERROR_PATCHWELCOME;
+
+err = ctx->codec->make_writable(ctx, unit);
+if (err < 0)
+return err;
+
+if (content)
+memcpy(content, >content, sizeof(content));
+}
+
+return 0;
+}
diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
index 53ac360bb1..a17c43dae4 100644
--- a/libavcodec/cbs.h
+++ b/libavcodec/cbs.h
@@ -352,5 +352,15 @@ int ff_cbs_delete_unit(CodedBitstreamContext *ctx,
CodedBitstreamFragment *frag,
int position);
 
+/**
+ * Make the content of a unit writable.
+ *
+ * If content is supplied, it is supposed to be a pointer to a pointer
+ * and *content will point to the content of the unit on success.
+ */
+int ff_cbs_make_unit_writable(CodedBitstreamContext *ctx,
+  CodedBitstreamUnit *unit,
+  void *content);
+
 
 #endif /* AVCODEC_CBS_H */
diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
index 53f2e5d187..62a836af90 100644
--- a/libavcodec/cbs_internal.h
+++ b/libavcodec/cbs_internal.h
@@ -44,6 +44,10 @@ typedef struct CodedBitstreamType {
 int (*read_unit)(CodedBitstreamContext *ctx,
  CodedBitstreamUnit *unit);
 
+// Make a unit's content writable.
+int (*make_writable)(CodedBitstreamContext *ctx,
+ CodedBitstreamUnit *unit);
+
 // Write the unit->data bitstream from unit->content.
 int (*write_unit)(CodedBitstreamContext *ctx,
   CodedBitstreamUnit *unit);
-- 
2.19.1

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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Nicolas George]

Dennis Mungai (2018-12-03):
> In this case , Carl's decision to strip their code from FFmpeg is valid.
> This is a clear violation of the license terms.

Indeed.

And please stop top-posting. If you do not know what it means, look it
up.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Dennis Mungai]

In this case , Carl's decision to strip their code from FFmpeg is valid.
This is a clear violation of the license terms.

On Mon, Dec 3, 2018, 19:38 Nicolas George  Kyle Schwarz (2018-12-03):
> > https://www.newtek.com/blog/introducing-ndi-3-5/
> >
> > > ... and we even include FFMPEG for Windows with NDI support for your
> convenience, eliminating the hassle of working out how to compile it
> yourself.
>
> That is not how it is supposed to work. If they want to include FFmpeg
> for their users' convenience, they have to make their software
> LGPL-compatible.
>
> Because "their users' convenience" is good publicity for them, they have
> to pay for it, not us.
>
> Regards,
>
> --
>   Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Nicolas George]

Kyle Schwarz (2018-12-03):
> https://www.newtek.com/blog/introducing-ndi-3-5/
> 
> > ... and we even include FFMPEG for Windows with NDI support for your 
> > convenience, eliminating the hassle of working out how to compile it 
> > yourself.

That is not how it is supposed to work. If they want to include FFmpeg
for their users' convenience, they have to make their software
LGPL-compatible.

Because "their users' convenience" is good publicity for them, they have
to pay for it, not us.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Dennis Mungai]

Carl,

If it is indeed an abuse of the license terms, as you've purported, it
would be wise to get their input on this, as Gyan Doshi has elaborated
above. They are contributors to this project, and it falls to reason that
the burden of addressing this falls on them.

Moving forward with such drastic steps only portrays arrogance , which is
uncalled for. I've seen contributors here deal with the likes of Amazon
(the recent NGCodec patch license issue comes to mind) and had that issue
resolved in an amicable manner. So why can't the same be done with Newtek?



On Mon, Dec 3, 2018, 19:24 Carl Eugen Hoyos  2018-12-03 17:13 GMT+01:00, Dennis Mungai :
>
> > Has Newtek NDI been given a chance to rectify this from their end?
>
> Why do you believe that this would be a useful way to go?
>
> > This is clearly a license violation, but taking drastic steps such
> > as stripping support for their protocols is a knee jerk reaction.
>
> Why?
> Have you ever dealt with open-source license violations?
>
> Please do not top-post here, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Kyle Schwarz]

On Mon, Dec 3, 2018 at 11:16 AM Gyan Doshi  wrote:
> On 03-12-2018 09:35 PM, Carl Eugen Hoyos wrote:
> > It appears to me that NewTek abused our willingness to add an optional
> > external nonfree library, I don't see many better options. See Ticket
> > #7589 and a blog post by a NewTek engineer confirming the issue.
>
> What's the link to the blog post?

https://www.newtek.com/blog/introducing-ndi-3-5/

> ... and we even include FFMPEG for Windows with NDI support for your 
> convenience, eliminating the hassle of working out how to compile it yourself.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Carl Eugen Hoyos]

2018-12-03 17:13 GMT+01:00, Dennis Mungai :

> Has Newtek NDI been given a chance to rectify this from their end?

Why do you believe that this would be a useful way to go?

> This is clearly a license violation, but taking drastic steps such
> as stripping support for their protocols is a knee jerk reaction.

Why?
Have you ever dealt with open-source license violations?

Please do not top-post here, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Gyan Doshi]

On 03-12-2018 09:49 PM, Carl Eugen Hoyos wrote:

2018-12-03 17:16 GMT+01:00, Gyan Doshi :





What's the link to the blog post?



Also, is anyone from Newtek on the ML - if not, is there someone we
can invite for input?


What kind of input would seem useful to you in this case?


Insight on what they were thinking. If it's a careless oversight, it can 
be remedied and this patch is not needed. But we should hear from them, 
ideally.


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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Dennis Mungai]

Hello there,

Has Newtek NDI been given a chance to rectify this from their end? This is
clearly a license violation, but taking drastic steps such as stripping
support for their protocols is a knee jerk reaction.

Let them respond before merging this PR.

Regards,

Dennis.

On Mon, Dec 3, 2018, 19:06 Carl Eugen Hoyos  Hi!
>
> It appears to me that NewTek abused our willingness to add an optional
> external nonfree library, I don't see many better options. See Ticket
> #7589 and a blog post by a NewTek engineer confirming the issue.
>
> Patch untested.
>
> Please comment, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Carl Eugen Hoyos]

2018-12-03 17:16 GMT+01:00, Gyan Doshi :
> On 03-12-2018 09:35 PM, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> It appears to me that NewTek abused our willingness to add an optional
>> external nonfree library, I don't see many better options. See Ticket
>> #7589 and a blog post by a NewTek engineer confirming the issue.

I should clarify that I did not verify the issue myself, ie in theory it
could be that NewTek does not distribute non-free binaries based on
FFmpeg source code.

> What's the link to the blog post?

> Also, is anyone from Newtek on the ML - if not, is there someone we
> can invite for input?

What kind of input would seem useful to you in this case?

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

Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Gyan Doshi]

On 03-12-2018 09:35 PM, Carl Eugen Hoyos wrote:

Hi!

It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.


What's the link to the blog post?

Also, is anyone from Newtek on the ML - if not, is there someone we can 
invite for input?



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

[FFmpeg-devel] [PATCH]lavd: Remove libndi newtek

[Carl Eugen Hoyos]

Hi!

It appears to me that NewTek abused our willingness to add an optional
external nonfree library, I don't see many better options. See Ticket
#7589 and a blog post by a NewTek engineer confirming the issue.

Patch untested.

Please comment, Carl Eugen
From 48ecad006fcd9db4558d1d23482e37006805bf1e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Mon, 3 Dec 2018 17:01:59 +0100
Subject: [PATCH] lavd: Remove libndi_newtek

---
 Changelog  |1 +
 configure  |7 -
 libavdevice/Makefile   |2 -
 libavdevice/libndi_newtek_common.h |   30 
 libavdevice/libndi_newtek_dec.c|  342 
 libavdevice/libndi_newtek_enc.c|  299 ---
 libavdevice/version.h  |4 +-
 7 files changed, 3 insertions(+), 682 deletions(-)
 delete mode 100644 libavdevice/libndi_newtek_common.h
 delete mode 100644 libavdevice/libndi_newtek_dec.c
 delete mode 100644 libavdevice/libndi_newtek_enc.c

diff --git a/Changelog b/Changelog
index 1f53ff4..ad03f43 100644
--- a/Changelog
+++ b/Changelog
@@ -10,6 +10,7 @@ version :
 - truehd_core bitstream filter
 - dhav demuxer
 - PCM-DVD encoder
+- removed libndi-newtek
 
 
 version 4.1:
diff --git a/configure b/configure
index 2af6c0d..4e86a3b 100755
--- a/configure
+++ b/configure
@@ -297,7 +297,6 @@ External library support:
   --enable-lv2 enable LV2 audio filtering [no]
   --disable-lzma   disable lzma [autodetect]
   --enable-decklinkenable Blackmagic DeckLink I/O support [no]
-  --enable-libndi_newtek   enable Newteck NDI I/O support [no]
   --enable-mbedtls enable mbedTLS, needed for https support
if openssl, gnutls or libtls is not used [no]
   --enable-mediacodec  enable Android MediaCodec support [no]
@@ -1675,7 +1674,6 @@ EXTERNAL_LIBRARY_GPL_LIST="
 
 EXTERNAL_LIBRARY_NONFREE_LIST="
 decklink
-libndi_newtek
 libfdk_aac
 openssl
 libtls
@@ -3256,10 +3254,6 @@ decklink_indev_extralibs="-lstdc++"
 decklink_outdev_deps="decklink threads"
 decklink_outdev_suggest="libklvanc"
 decklink_outdev_extralibs="-lstdc++"
-libndi_newtek_indev_deps="libndi_newtek"
-libndi_newtek_indev_extralibs="-lndi"
-libndi_newtek_outdev_deps="libndi_newtek"
-libndi_newtek_outdev_extralibs="-lndi"
 dshow_indev_deps="IBaseFilter"
 dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32 -lshlwapi"
 fbdev_indev_deps="linux_fb_h"
@@ -6064,7 +6058,6 @@ enabled cuda_sdk  && require cuda_sdk cuda.h cuCtxCreate -lcuda
 enabled chromaprint   && require chromaprint chromaprint.h chromaprint_get_version -lchromaprint
 enabled decklink  && { require_headers DeckLinkAPI.h &&
{ test_cpp_condition DeckLinkAPIVersion.h "BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a090500" || die "ERROR: Decklink API version must be >= 10.9.5."; } }
-enabled libndi_newtek && require_headers Processing.NDI.Lib.h
 enabled frei0r&& require_headers frei0r.h
 enabled gmp   && require gmp gmp.h mpz_export -lgmp
 enabled gnutls&& require_pkg_config gnutls gnutls gnutls/gnutls.h gnutls_global_init
diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index f11a6f2..5a907aa 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile
@@ -20,8 +20,6 @@ OBJS-$(CONFIG_BKTR_INDEV)+= bktr.o
 OBJS-$(CONFIG_CACA_OUTDEV)   += caca.o
 OBJS-$(CONFIG_DECKLINK_OUTDEV)   += decklink_enc.o decklink_enc_c.o decklink_common.o
 OBJS-$(CONFIG_DECKLINK_INDEV)+= decklink_dec.o decklink_dec_c.o decklink_common.o
-OBJS-$(CONFIG_LIBNDI_NEWTEK_OUTDEV)  += libndi_newtek_enc.o
-OBJS-$(CONFIG_LIBNDI_NEWTEK_INDEV)   += libndi_newtek_dec.o
 OBJS-$(CONFIG_DSHOW_INDEV)   += dshow_crossbar.o dshow.o dshow_enummediatypes.o \
 dshow_enumpins.o dshow_filter.o \
 dshow_pin.o dshow_common.o
diff --git a/libavdevice/libndi_newtek_common.h b/libavdevice/libndi_newtek_common.h
deleted file mode 100644
index 8990317..000
--- a/libavdevice/libndi_newtek_common.h
+++ /dev/null
@@ -1,30 +0,0 @@
-/*
- * NewTek NDI common code
- * Copyright (c) 2017 Maksym Veremeyenko
- *
- * 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 

Re: [FFmpeg-devel] [PATCH 2/2] lavf/file: Add support for file syncing.

[Andrey Semashev]

On 12/3/18 3:46 PM, Nicolas George wrote:

Andrey Semashev (2018-12-03):

This commit adds support for IO synchronization API to the file backend.
---
  libavformat/file.c   | 10 ++
  libavformat/os_support.h |  2 ++
  2 files changed, 12 insertions(+)

diff --git a/libavformat/file.c b/libavformat/file.c
index 1d321c4205..9765fd76c7 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -254,6 +254,15 @@ static int64_t file_seek(URLContext *h, int64_t pos, int 
whence)
  return ret < 0 ? AVERROR(errno) : ret;
  }
  
+static int file_sync(URLContext *h)

+{
+if (h->flags & AVIO_FLAG_WRITE) {
+FileContext *c = h->priv_data;



+return fsync(c->fd);


In case of error, it needs to convert errno to an AVERROR code.


+}
+return 0;
+}
+
  static int file_close(URLContext *h)
  {
  FileContext *c = h->priv_data;
@@ -353,6 +362,7 @@ const URLProtocol ff_file_protocol = {
  .url_close   = file_close,
  .url_get_file_handle = file_get_handle,
  .url_check   = file_check,
+.url_sync= file_sync,
  .url_delete  = file_delete,
  .url_move= file_move,
  .priv_data_size  = sizeof(FileContext),
diff --git a/libavformat/os_support.h b/libavformat/os_support.h
index 7a56dc9a7c..fcbdc884ba 100644
--- a/libavformat/os_support.h
+++ b/libavformat/os_support.h
@@ -93,6 +93,8 @@ static inline int is_dos_path(const char *path)
  #ifndef S_IWUSR
  #define S_IWUSR S_IWRITE
  #endif
+



+#define fsync _commit


Defining with the arguments would be more robust. A few occasions in the
same file do not do that, they should.


  #endif
  
  #if CONFIG_NETWORK


Agreed to both comments.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavf: Add general API for IO buffer synchtonization.

[Andrey Semashev]

On 12/3/18 3:43 PM, Nicolas George wrote:

Andrey Semashev (2018-12-03):

This commit adds a new set of functions to avio and url subsystems, which
allow users to invoke IO buffer synchronization with the underlying media.
The most obvious target for this extension if the filesystem streams. Invoking
IO synchronization allows user applications to ensure that all written content
has reached the filesystem on the media and can be observed by other processes.

The public API for this is avio_sync() function, which can be called on
AVIOContext. The internal, lower layer API is ffurl_sync(), which works
directly on the underlying URLContext. URLContext backends can add support for
this new API by setting the sync handler to the new url_sync member of
URLProtocol. When no handler is set then the sync operation is a no-op.
---
  libavformat/avio.c|  7 +++
  libavformat/avio.h| 16 
  libavformat/aviobuf.c | 17 +
  libavformat/url.h | 12 
  4 files changed, 52 insertions(+)

diff --git a/libavformat/avio.c b/libavformat/avio.c
index 663789ec02..19413ac586 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -623,6 +623,13 @@ int64_t ffurl_size(URLContext *h)
  return size;
  }
  
+int ffurl_sync(URLContext *h)

+{
+if (h->prot->url_sync)
+return h->prot->url_sync(h);



+return 0;


I think it should be an error, probably ENOSUP. Otherwise, the
application will assume it was done.


I don't think this would be useful to users. I mean, the application can 
already check whether the operations is supported or not by inspecting 
url_sync. When the application doesn't care (which, I think, will be the 
majority of cases), they will treat ENOTSUP the same way as a success, 
so it only adds more burden to test for this error code.


I could use some separate "success" code for the "not supported" result, 
if there is one. Is there?

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

Re: [FFmpeg-devel] [PATCH 2/2] lavf/file: Add support for file syncing.

[Nicolas George]

Andrey Semashev (2018-12-03):
> This commit adds support for IO synchronization API to the file backend.
> ---
>  libavformat/file.c   | 10 ++
>  libavformat/os_support.h |  2 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/libavformat/file.c b/libavformat/file.c
> index 1d321c4205..9765fd76c7 100644
> --- a/libavformat/file.c
> +++ b/libavformat/file.c
> @@ -254,6 +254,15 @@ static int64_t file_seek(URLContext *h, int64_t pos, int 
> whence)
>  return ret < 0 ? AVERROR(errno) : ret;
>  }
>  
> +static int file_sync(URLContext *h)
> +{
> +if (h->flags & AVIO_FLAG_WRITE) {
> +FileContext *c = h->priv_data;

> +return fsync(c->fd);

In case of error, it needs to convert errno to an AVERROR code.

> +}
> +return 0;
> +}
> +
>  static int file_close(URLContext *h)
>  {
>  FileContext *c = h->priv_data;
> @@ -353,6 +362,7 @@ const URLProtocol ff_file_protocol = {
>  .url_close   = file_close,
>  .url_get_file_handle = file_get_handle,
>  .url_check   = file_check,
> +.url_sync= file_sync,
>  .url_delete  = file_delete,
>  .url_move= file_move,
>  .priv_data_size  = sizeof(FileContext),
> diff --git a/libavformat/os_support.h b/libavformat/os_support.h
> index 7a56dc9a7c..fcbdc884ba 100644
> --- a/libavformat/os_support.h
> +++ b/libavformat/os_support.h
> @@ -93,6 +93,8 @@ static inline int is_dos_path(const char *path)
>  #ifndef S_IWUSR
>  #define S_IWUSR S_IWRITE
>  #endif
> +

> +#define fsync _commit

Defining with the arguments would be more robust. A few occasions in the
same file do not do that, they should.

>  #endif
>  
>  #if CONFIG_NETWORK

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavf: Add general API for IO buffer synchtonization.

[Nicolas George]

Andrey Semashev (2018-12-03):
> This commit adds a new set of functions to avio and url subsystems, which
> allow users to invoke IO buffer synchronization with the underlying media.
> The most obvious target for this extension if the filesystem streams. Invoking
> IO synchronization allows user applications to ensure that all written content
> has reached the filesystem on the media and can be observed by other 
> processes.
> 
> The public API for this is avio_sync() function, which can be called on
> AVIOContext. The internal, lower layer API is ffurl_sync(), which works
> directly on the underlying URLContext. URLContext backends can add support for
> this new API by setting the sync handler to the new url_sync member of
> URLProtocol. When no handler is set then the sync operation is a no-op.
> ---
>  libavformat/avio.c|  7 +++
>  libavformat/avio.h| 16 
>  libavformat/aviobuf.c | 17 +
>  libavformat/url.h | 12 
>  4 files changed, 52 insertions(+)
> 
> diff --git a/libavformat/avio.c b/libavformat/avio.c
> index 663789ec02..19413ac586 100644
> --- a/libavformat/avio.c
> +++ b/libavformat/avio.c
> @@ -623,6 +623,13 @@ int64_t ffurl_size(URLContext *h)
>  return size;
>  }
>  
> +int ffurl_sync(URLContext *h)
> +{
> +if (h->prot->url_sync)
> +return h->prot->url_sync(h);

> +return 0;

I think it should be an error, probably ENOSUP. Otherwise, the
application will assume it was done.

The doc needs to be changed accordingly of course.

> +}
> +
>  int ffurl_get_file_handle(URLContext *h)
>  {
>  if (!h || !h->prot || !h->prot->url_get_file_handle)
> diff --git a/libavformat/avio.h b/libavformat/avio.h
> index 75912ce6be..784cd1b509 100644
> --- a/libavformat/avio.h
> +++ b/libavformat/avio.h
> @@ -349,6 +349,11 @@ typedef struct AVIOContext {
>   * Try to buffer at least this amount of data before flushing it
>   */
>  int min_packet_size;
> +
> +/**
> + * A callback for synchronizing buffers with the media state.
> + */
> +int (*sync)(void *opaque);
>  } AVIOContext;
>  
>  /**
> @@ -586,6 +591,17 @@ int avio_printf(AVIOContext *s, const char *fmt, ...) 
> av_printf_format(2, 3);
>   */
>  void avio_flush(AVIOContext *s);
>  
> +/**
> + * Flush internal buffers and ensure the synchronized state of the
> + * resource associated with the context s. This call may be expensive.
> + * Not all resources support syncing, this operation is a no-op
> + * if sync is not supported or needed.
> + * This function can only be used if s was opened by avio_open().
> + *
> + * @return 0 on success, an AVERROR < 0 on error.
> + */
> +int avio_sync(AVIOContext *s);
> +
>  /**
>   * Read size bytes from AVIOContext into buf.
>   * @return number of bytes read or AVERROR
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index 5a33f82950..10be372bce 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -243,6 +243,14 @@ void avio_flush(AVIOContext *s)
>  avio_seek(s, seekback, SEEK_CUR);
>  }
>  
> +int avio_sync(AVIOContext *s)
> +{
> +avio_flush(s);
> +if (s->sync)
> +return s->sync(s->opaque);
> +return 0;
> +}
> +
>  int64_t avio_seek(AVIOContext *s, int64_t offset, int whence)
>  {
>  int64_t offset1;
> @@ -978,6 +986,12 @@ static int64_t io_read_seek(void *opaque, int 
> stream_index, int64_t timestamp, i
>  return internal->h->prot->url_read_seek(internal->h, stream_index, 
> timestamp, flags);
>  }
>  
> +static int io_sync(void *opaque)
> +{
> +AVIOInternal *internal = opaque;
> +return ffurl_sync(internal->h);
> +}
> +
>  int ffio_fdopen(AVIOContext **s, URLContext *h)
>  {
>  AVIOInternal *internal = NULL;
> @@ -1026,6 +1040,9 @@ int ffio_fdopen(AVIOContext **s, URLContext *h)
>  
>  if (h->prot->url_read_seek)
>  (*s)->seekable |= AVIO_SEEKABLE_TIME;
> +
> +if (h->prot->url_sync)
> +(*s)->sync = io_sync;
>  }
>  (*s)->short_seek_get = io_short_seek;
>  (*s)->av_class = _avio_class;
> diff --git a/libavformat/url.h b/libavformat/url.h
> index 4750bfff82..26658695b0 100644
> --- a/libavformat/url.h
> +++ b/libavformat/url.h
> @@ -97,6 +97,7 @@ typedef struct URLProtocol {
>  int (*url_delete)(URLContext *h);
>  int (*url_move)(URLContext *h_src, URLContext *h_dst);
>  const char *default_whitelist;
> +int (*url_sync)(URLContext *h);
>  } URLProtocol;
>  
>  /**
> @@ -228,6 +229,17 @@ int64_t ffurl_seek(URLContext *h, int64_t pos, int 
> whence);
>  int ffurl_closep(URLContext **h);
>  int ffurl_close(URLContext *h);
>  
> +/**
> + * Flush any buffered data and synchronize the resource accessed
> + * by the URLContext h. This call may be expensive.
> + * Not all types of resources support syncing, the call is a no-op
> + * if sync is not supported or needed.
> + *
> + * @return a negative value if an error condition occurred, 0
> + * otherwise
> + */
> +int 

[FFmpeg-devel] [PATCH 1/2] lavf: Add general API for IO buffer synchtonization.

[Andrey Semashev]

This commit adds a new set of functions to avio and url subsystems, which
allow users to invoke IO buffer synchronization with the underlying media.
The most obvious target for this extension if the filesystem streams. Invoking
IO synchronization allows user applications to ensure that all written content
has reached the filesystem on the media and can be observed by other processes.

The public API for this is avio_sync() function, which can be called on
AVIOContext. The internal, lower layer API is ffurl_sync(), which works
directly on the underlying URLContext. URLContext backends can add support for
this new API by setting the sync handler to the new url_sync member of
URLProtocol. When no handler is set then the sync operation is a no-op.
---
 libavformat/avio.c|  7 +++
 libavformat/avio.h| 16 
 libavformat/aviobuf.c | 17 +
 libavformat/url.h | 12 
 4 files changed, 52 insertions(+)

diff --git a/libavformat/avio.c b/libavformat/avio.c
index 663789ec02..19413ac586 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -623,6 +623,13 @@ int64_t ffurl_size(URLContext *h)
 return size;
 }
 
+int ffurl_sync(URLContext *h)
+{
+if (h->prot->url_sync)
+return h->prot->url_sync(h);
+return 0;
+}
+
 int ffurl_get_file_handle(URLContext *h)
 {
 if (!h || !h->prot || !h->prot->url_get_file_handle)
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 75912ce6be..784cd1b509 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -349,6 +349,11 @@ typedef struct AVIOContext {
  * Try to buffer at least this amount of data before flushing it
  */
 int min_packet_size;
+
+/**
+ * A callback for synchronizing buffers with the media state.
+ */
+int (*sync)(void *opaque);
 } AVIOContext;
 
 /**
@@ -586,6 +591,17 @@ int avio_printf(AVIOContext *s, const char *fmt, ...) 
av_printf_format(2, 3);
  */
 void avio_flush(AVIOContext *s);
 
+/**
+ * Flush internal buffers and ensure the synchronized state of the
+ * resource associated with the context s. This call may be expensive.
+ * Not all resources support syncing, this operation is a no-op
+ * if sync is not supported or needed.
+ * This function can only be used if s was opened by avio_open().
+ *
+ * @return 0 on success, an AVERROR < 0 on error.
+ */
+int avio_sync(AVIOContext *s);
+
 /**
  * Read size bytes from AVIOContext into buf.
  * @return number of bytes read or AVERROR
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 5a33f82950..10be372bce 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -243,6 +243,14 @@ void avio_flush(AVIOContext *s)
 avio_seek(s, seekback, SEEK_CUR);
 }
 
+int avio_sync(AVIOContext *s)
+{
+avio_flush(s);
+if (s->sync)
+return s->sync(s->opaque);
+return 0;
+}
+
 int64_t avio_seek(AVIOContext *s, int64_t offset, int whence)
 {
 int64_t offset1;
@@ -978,6 +986,12 @@ static int64_t io_read_seek(void *opaque, int 
stream_index, int64_t timestamp, i
 return internal->h->prot->url_read_seek(internal->h, stream_index, 
timestamp, flags);
 }
 
+static int io_sync(void *opaque)
+{
+AVIOInternal *internal = opaque;
+return ffurl_sync(internal->h);
+}
+
 int ffio_fdopen(AVIOContext **s, URLContext *h)
 {
 AVIOInternal *internal = NULL;
@@ -1026,6 +1040,9 @@ int ffio_fdopen(AVIOContext **s, URLContext *h)
 
 if (h->prot->url_read_seek)
 (*s)->seekable |= AVIO_SEEKABLE_TIME;
+
+if (h->prot->url_sync)
+(*s)->sync = io_sync;
 }
 (*s)->short_seek_get = io_short_seek;
 (*s)->av_class = _avio_class;
diff --git a/libavformat/url.h b/libavformat/url.h
index 4750bfff82..26658695b0 100644
--- a/libavformat/url.h
+++ b/libavformat/url.h
@@ -97,6 +97,7 @@ typedef struct URLProtocol {
 int (*url_delete)(URLContext *h);
 int (*url_move)(URLContext *h_src, URLContext *h_dst);
 const char *default_whitelist;
+int (*url_sync)(URLContext *h);
 } URLProtocol;
 
 /**
@@ -228,6 +229,17 @@ int64_t ffurl_seek(URLContext *h, int64_t pos, int whence);
 int ffurl_closep(URLContext **h);
 int ffurl_close(URLContext *h);
 
+/**
+ * Flush any buffered data and synchronize the resource accessed
+ * by the URLContext h. This call may be expensive.
+ * Not all types of resources support syncing, the call is a no-op
+ * if sync is not supported or needed.
+ *
+ * @return a negative value if an error condition occurred, 0
+ * otherwise
+ */
+int ffurl_sync(URLContext *h);
+
 /**
  * Return the filesize of the resource accessed by h, AVERROR(ENOSYS)
  * if the operation is not supported by h, or another negative value
-- 
2.19.1

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

[FFmpeg-devel] [PATCH 2/2] lavf/file: Add support for file syncing.

[Andrey Semashev]

This commit adds support for IO synchronization API to the file backend.
---
 libavformat/file.c   | 10 ++
 libavformat/os_support.h |  2 ++
 2 files changed, 12 insertions(+)

diff --git a/libavformat/file.c b/libavformat/file.c
index 1d321c4205..9765fd76c7 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -254,6 +254,15 @@ static int64_t file_seek(URLContext *h, int64_t pos, int 
whence)
 return ret < 0 ? AVERROR(errno) : ret;
 }
 
+static int file_sync(URLContext *h)
+{
+if (h->flags & AVIO_FLAG_WRITE) {
+FileContext *c = h->priv_data;
+return fsync(c->fd);
+}
+return 0;
+}
+
 static int file_close(URLContext *h)
 {
 FileContext *c = h->priv_data;
@@ -353,6 +362,7 @@ const URLProtocol ff_file_protocol = {
 .url_close   = file_close,
 .url_get_file_handle = file_get_handle,
 .url_check   = file_check,
+.url_sync= file_sync,
 .url_delete  = file_delete,
 .url_move= file_move,
 .priv_data_size  = sizeof(FileContext),
diff --git a/libavformat/os_support.h b/libavformat/os_support.h
index 7a56dc9a7c..fcbdc884ba 100644
--- a/libavformat/os_support.h
+++ b/libavformat/os_support.h
@@ -93,6 +93,8 @@ static inline int is_dos_path(const char *path)
 #ifndef S_IWUSR
 #define S_IWUSR S_IWRITE
 #endif
+
+#define fsync _commit
 #endif
 
 #if CONFIG_NETWORK
-- 
2.19.1

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

[FFmpeg-devel] [PATCH v3] lavf/dashenc: Write media trailers when DASH trailer is written.

[Andrey Semashev]

This commit ensures that all (potentially, long) filesystem activity is
performed when the user calls av_write_trailer on the DASH libavformat
context, not when freeing the context. Also, this defers media segment
deletion until after the media trailers are written.
---
 libavformat/dashenc.c | 85 ++-
 1 file changed, 60 insertions(+), 25 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 279a9bec54..4d9b564a94 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -441,8 +441,6 @@ static void dash_free(AVFormatContext *s)
 return;
 for (i = 0; i < s->nb_streams; i++) {
 OutputStream *os = >streams[i];
-if (os->ctx && os->ctx_inited)
-av_write_trailer(os->ctx);
 if (os->ctx && os->ctx->pb)
 ffio_free_dyn_buf(>ctx->pb);
 ff_format_io_close(s, >out);
@@ -1359,6 +1357,47 @@ static void dashenc_delete_file(AVFormatContext *s, char 
*filename) {
 }
 }
 
+static int dashenc_delete_segment_file(AVFormatContext *s, const char* file)
+{
+DASHContext *c = s->priv_data;
+size_t dirname_len, file_len;
+char filename[1024];
+
+dirname_len = strlen(c->dirname);
+if (dirname_len >= sizeof(filename)) {
+av_log(s, AV_LOG_WARNING, "Cannot delete segments as the directory 
path is too long: %"PRIu64" characters: %s\n",
+(uint64_t)dirname_len, c->dirname);
+return AVERROR(ENAMETOOLONG);
+}
+
+memcpy(filename, c->dirname, dirname_len);
+
+file_len = strlen(file);
+if ((dirname_len + file_len) >= sizeof(filename)) {
+av_log(s, AV_LOG_WARNING, "Cannot delete segments as the path is too 
long: %"PRIu64" characters: %s%s\n",
+(uint64_t)(dirname_len + file_len), c->dirname, file);
+return AVERROR(ENAMETOOLONG);
+}
+
+memcpy(filename + dirname_len, file, file_len + 1); // include the 
terminating zero
+dashenc_delete_file(s, filename);
+
+return 0;
+}
+
+static inline void dashenc_delete_media_segments(AVFormatContext *s, 
OutputStream *os, int remove_count)
+{
+for (int i = 0; i < remove_count; ++i) {
+dashenc_delete_segment_file(s, os->segments[i]->file);
+
+// Delete the segment regardless of whether the file was successfully 
deleted
+av_free(os->segments[i]);
+}
+
+os->nb_segments -= remove_count;
+memmove(os->segments, os->segments + remove_count, os->nb_segments * 
sizeof(*os->segments));
+}
+
 static int dash_flush(AVFormatContext *s, int final, int stream)
 {
 DASHContext *c = s->priv_data;
@@ -1448,23 +1487,12 @@ static int dash_flush(AVFormatContext *s, int final, 
int stream)
 os->pos += range_length;
 }
 
-if (c->window_size || (final && c->remove_at_exit)) {
+if (c->window_size) {
 for (i = 0; i < s->nb_streams; i++) {
 OutputStream *os = >streams[i];
-int j;
-int remove = os->nb_segments - c->window_size - 
c->extra_window_size;
-if (final && c->remove_at_exit)
-remove = os->nb_segments;
-if (remove > 0) {
-for (j = 0; j < remove; j++) {
-char filename[1024];
-snprintf(filename, sizeof(filename), "%s%s", c->dirname, 
os->segments[j]->file);
-dashenc_delete_file(s, filename);
-av_free(os->segments[j]);
-}
-os->nb_segments -= remove;
-memmove(os->segments, os->segments + remove, os->nb_segments * 
sizeof(*os->segments));
-}
+int remove_count = os->nb_segments - c->window_size - 
c->extra_window_size;
+if (remove_count > 0)
+dashenc_delete_media_segments(s, os, remove_count);
 }
 }
 
@@ -1615,6 +1643,7 @@ static int dash_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 static int dash_write_trailer(AVFormatContext *s)
 {
 DASHContext *c = s->priv_data;
+int i;
 
 if (s->nb_streams > 0) {
 OutputStream *os = >streams[0];
@@ -1630,18 +1659,24 @@ static int dash_write_trailer(AVFormatContext *s)
 }
 dash_flush(s, 1, -1);
 
-if (c->remove_at_exit) {
-char filename[1024];
-int i;
-for (i = 0; i < s->nb_streams; i++) {
-OutputStream *os = >streams[i];
-snprintf(filename, sizeof(filename), "%s%s", c->dirname, 
os->initfile);
-dashenc_delete_file(s, filename);
+for (i = 0; i < s->nb_streams; ++i) {
+OutputStream *os = >streams[i];
+if (os->ctx && os->ctx_inited) {
+av_write_trailer(os->ctx);
 }
+
+if (c->remove_at_exit) {
+dashenc_delete_media_segments(s, os, os->nb_segments);
+dashenc_delete_segment_file(s, os->initfile);
+}
+}
+
+if (c->remove_at_exit) {
 dashenc_delete_file(s, s->url);
 
 if (c->hls_playlist && 

Re: [FFmpeg-devel] [PATCH v2] lavf/dashenc: Write media trailers when DASH trailer is written.

[Andrey Semashev]

On 12/3/18 8:45 AM, Jeyapal, Karthick wrote:


On 11/30/18 11:42 AM, Jeyapal, Karthick wrote:


On 11/29/18 11:58 PM, Andrey Semashev wrote:

This commit ensures that all (potentially, long) filesystem activity is
performed when the user calls av_write_trailer on the DASH libavformat
context, not when freeing the context. Also, this defers media segment
deletion until after the media trailers are written.
---
  libavformat/dashenc.c | 82 ++-
  1 file changed, 58 insertions(+), 24 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 6ce70e0076..ecfd84a32c 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -424,8 +424,6 @@ static void dash_free(AVFormatContext *s)
  return;
  for (i = 0; i < s->nb_streams; i++) {
  OutputStream *os = >streams[i];
-if (os->ctx && os->ctx_inited)
-av_write_trailer(os->ctx);
  if (os->ctx && os->ctx->pb)
  ffio_free_dyn_buf(>ctx->pb);
  ff_format_io_close(s, >out);
@@ -1331,6 +1329,47 @@ static void dashenc_delete_file(AVFormatContext *s, char 
*filename) {
  }
  }
  
+static int dashenc_delete_segment_file(AVFormatContext *s, const char* file)

+{
+DASHContext *c = s->priv_data;
+size_t dirname_len, file_len;
+char filename[1024];
+
+dirname_len = strlen(c->dirname);
+if (dirname_len >= sizeof(filename)) {
+av_log(s, AV_LOG_WARNING, "Cannot delete segments as the directory path is too long: 
%"PRIu64" characters: %s\n",
+(uint64_t)dirname_len, c->dirname);
+return AVERROR(ENAMETOOLONG);
+}
+
+memcpy(filename, c->dirname, dirname_len);
+
+file_len = strlen(file);
+if ((dirname_len + file_len) >= sizeof(filename)) {
+av_log(s, AV_LOG_WARNING, "Cannot delete segments as the path is too long: 
%"PRIu64" characters: %s%s\n",
+(uint64_t)(dirname_len + file_len), c->dirname, file);
+return AVERROR(ENAMETOOLONG);
+}
+
+memcpy(filename + dirname_len, file, file_len + 1); // include the 
terminating zero
+dashenc_delete_file(s, filename);
+
+return 0;
+}
+
+static inline void dashenc_delete_media_segments(AVFormatContext *s, 
OutputStream *os, int remove_count)
+{
+for (int i = 0; i < remove_count; ++i) {
+dashenc_delete_segment_file(s, os->segments[i]->file);
+
+// Delete the segment regardless of whether the file was successfully 
deleted
+av_free(os->segments[i]);
+}
+
+os->nb_segments -= remove_count;
+memmove(os->segments, os->segments + remove_count, os->nb_segments * 
sizeof(*os->segments));
+}
+
  static int dash_flush(AVFormatContext *s, int final, int stream)
  {
  DASHContext *c = s->priv_data;
@@ -1420,23 +1459,12 @@ static int dash_flush(AVFormatContext *s, int final, 
int stream)
  os->pos += range_length;
  }
  
-if (c->window_size || (final && c->remove_at_exit)) {

+if (c->window_size) {
  for (i = 0; i < s->nb_streams; i++) {
  OutputStream *os = >streams[i];
-int j;
-int remove = os->nb_segments - c->window_size - 
c->extra_window_size;
-if (final && c->remove_at_exit)
-remove = os->nb_segments;
-if (remove > 0) {
-for (j = 0; j < remove; j++) {
-char filename[1024];
-snprintf(filename, sizeof(filename), "%s%s", c->dirname, 
os->segments[j]->file);
-dashenc_delete_file(s, filename);
-av_free(os->segments[j]);
-}
-os->nb_segments -= remove;
-memmove(os->segments, os->segments + remove, os->nb_segments * 
sizeof(*os->segments));
-}
+int remove_count = os->nb_segments - c->window_size - 
c->extra_window_size;
+if (remove_count > 0)
+dashenc_delete_media_segments(s, os, remove_count);
  }
  }
  
@@ -1584,6 +1612,7 @@ static int dash_write_packet(AVFormatContext *s, AVPacket *pkt)

  static int dash_write_trailer(AVFormatContext *s)
  {
  DASHContext *c = s->priv_data;
+int i;
  
  if (s->nb_streams > 0) {

  OutputStream *os = >streams[0];
@@ -1599,14 +1628,19 @@ static int dash_write_trailer(AVFormatContext *s)
  }
  dash_flush(s, 1, -1);
  
-if (c->remove_at_exit) {

-char filename[1024];
-int i;
-for (i = 0; i < s->nb_streams; i++) {
-OutputStream *os = >streams[i];
-snprintf(filename, sizeof(filename), "%s%s", c->dirname, 
os->initfile);
-dashenc_delete_file(s, filename);
+for (i = 0; i < s->nb_streams; ++i) {
+OutputStream *os = >streams[i];
+if (os->ctx && os->ctx_inited) {
+av_write_trailer(os->ctx);
+}
+
+if (c->remove_at_exit) {
+dashenc_delete_media_segments(s, os, os->nb_segments);
+

Re: [FFmpeg-devel] [PATCH v4] libavfilter: add transpose_vaapi filter

[Zhou, Zachary]

ping? any more comments ?

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Zachary Zhou
> Sent: Thursday, November 29, 2018 2:14 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Zachary Zhou ; Zhou, Zachary
> 
> Subject: [FFmpeg-devel] [PATCH v4] libavfilter: add transpose_vaapi filter
> 
> Swap width and height when do clock/cclock rotation Add 180/180_flip
> options
> 
> ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -
> hwaccel_output_format vaapi -i input.264 -vf "transpose_vaapi=clock_flip"
> -c:v h264_vaapi output.h264
> 
> Signed-off-by: Zachary Zhou 
> ---
>  configure|   2 +
>  libavfilter/Makefile |   1 +
>  libavfilter/allfilters.c |   1 +
>  libavfilter/vf_transpose_vaapi.c | 356 +++
>  4 files changed, 360 insertions(+)
>  create mode 100644 libavfilter/vf_transpose_vaapi.c
> 
> diff --git a/configure b/configure
> index 3e9222ed1b..9e3908ef61 100755
> --- a/configure
> +++ b/configure
> @@ -3480,6 +3480,7 @@ tinterlace_merge_test_deps="tinterlace_filter"
>  tinterlace_pad_test_deps="tinterlace_filter"
>  tonemap_filter_deps="const_nan"
>  tonemap_opencl_filter_deps="opencl const_nan"
> +transpose_vaapi_filter_deps="vaapi VAProcPipelineCaps_rotation_flags"
>  unsharp_opencl_filter_deps="opencl"
>  uspp_filter_deps="gpl avcodec"
>  vaguedenoiser_filter_deps="gpl"
> @@ -5979,6 +5980,7 @@ check_type "d3d9.h dxva2api.h"
> DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602
> 
>  check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
>  check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> +check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
>  check_type "va/va.h va/va_enc_hevc.h"
> "VAEncPictureParameterBufferHEVC"
>  check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
>  check_type "va/va.h va/va_enc_vp8.h"  "VAEncPictureParameterBufferVP8"
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile index
> 1895fa2b0d..ccce4bbb2f 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -393,6 +393,7 @@ OBJS-$(CONFIG_TONEMAP_OPENCL_FILTER) +=
> vf_tonemap_opencl.o colorspace.o
>  OBJS-$(CONFIG_TPAD_FILTER)   += vf_tpad.o
>  OBJS-$(CONFIG_TRANSPOSE_FILTER)  += vf_transpose.o
>  OBJS-$(CONFIG_TRANSPOSE_NPP_FILTER)  += vf_transpose_npp.o
> cuda_check.o
> +OBJS-$(CONFIG_TRANSPOSE_VAAPI_FILTER)+= vf_transpose_vaapi.o
> vaapi_vpp.o
>  OBJS-$(CONFIG_TRIM_FILTER)   += trim.o
>  OBJS-$(CONFIG_UNPREMULTIPLY_FILTER)  += vf_premultiply.o
> framesync.o
>  OBJS-$(CONFIG_UNSHARP_FILTER)+= vf_unsharp.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index
> 837c99eb75..40e5d82b62 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -372,6 +372,7 @@ extern AVFilter ff_vf_tonemap_opencl;  extern
> AVFilter ff_vf_tpad;  extern AVFilter ff_vf_transpose;  extern AVFilter
> ff_vf_transpose_npp;
> +extern AVFilter ff_vf_transpose_vaapi;
>  extern AVFilter ff_vf_trim;
>  extern AVFilter ff_vf_unpremultiply;
>  extern AVFilter ff_vf_unsharp;
> diff --git a/libavfilter/vf_transpose_vaapi.c 
> b/libavfilter/vf_transpose_vaapi.c
> new file mode 100644
> index 00..d0502b7944
> --- /dev/null
> +++ b/libavfilter/vf_transpose_vaapi.c
> @@ -0,0 +1,356 @@
> +/*
> + * 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 
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/mem.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
> +
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "internal.h"
> +#include "vaapi_vpp.h"
> +
> +typedef enum {
> +TRANSPOSE_PT_TYPE_NONE,
> +TRANSPOSE_PT_TYPE_LANDSCAPE,
> +TRANSPOSE_PT_TYPE_PORTRAIT,
> +} PassthroughType;
> +
> +enum TransposeDir {
> +TRANSPOSE_CCLOCK_FLIP,
> +TRANSPOSE_CLOCK,
> +TRANSPOSE_CCLOCK,
> +TRANSPOSE_CLOCK_FLIP,
> +TRANSPOSE_180,
> +TRANSPOSE_180_FLIP,
> +};
> +
> +typedef struct TransposeVAAPIContext {
> +VAAPIVPPContext vpp_ctx; // must be the first field
> +int passthrough; // PassthroughType, 

Re: [FFmpeg-devel] [PATCH] configure: check if dlfcn.h is present for ladspa and frei0r, if not abort early

[Paul B Mahol]

On 12/2/18, James Almer  wrote:
> On 12/2/2018 4:07 PM, Paul B Mahol wrote:
>> On 12/2/18, James Almer  wrote:
>>> On 12/2/2018 3:53 PM, Paul B Mahol wrote:
 On 12/2/18, James Almer  wrote:
> On 12/2/2018 2:51 PM, Paul B Mahol wrote:
>> Fixes #4517.
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  configure | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 2af6c0d797..7c55274efa 100755
>> --- a/configure
>> +++ b/configure
>> @@ -6065,11 +6065,11 @@ enabled chromaprint   && require
>> chromaprint
>> chromaprint.h chromaprint_get_v
>>  enabled decklink  && { require_headers DeckLinkAPI.h &&
>> { test_cpp_condition
>> DeckLinkAPIVersion.h
>> "BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a090500" || die "ERROR:
>> Decklink
>> API version must be >= 10.9.5."; } }
>>  enabled libndi_newtek && require_headers Processing.NDI.Lib.h
>> -enabled frei0r&& require_headers frei0r.h
>> +enabled frei0r&& require_headers frei0r.h &&
>> require_headers
>> dlfcn.h
>>  enabled gmp   && require gmp gmp.h mpz_export -lgmp
>>  enabled gnutls&& require_pkg_config gnutls gnutls
>> gnutls/gnutls.h gnutls_global_init
>>  enabled jni   && { [ $target_os = "android" ] &&
>> check_headers jni.h && enabled pthreads || die "ERROR: jni not found";
>> }
>> -enabled ladspa&& require_headers ladspa.h
>> +enabled ladspa&& require_headers ladspa.h &&
>> require_headers
>> dlfcn.h
>>  enabled libaom&& require_pkg_config libaom "aom >= 1.0.0"
>> aom/aom_codec.h aom_codec_version
>>  enabled lv2   && require_pkg_config lv2 lilv-0
>> "lilv/lilv.h"
>> lilv_world_new
>>  enabled libiec61883   && require libiec61883
>> libiec61883/iec61883.h
>> iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
>>
>
> Both filters already depend on libdl being present, which also implies
> dlfcn.h (The check for libdl uses it). How is that not enough?

 Filters != library support enabled

 Please read bug report I linked, it explains it.

 In short not having dflcn.h header would pass those options but would
 disable filters later.
 Proper way is to abort early.
>>>
>>> Do those libraries need dlfcn.h, or only the filters? If the former,
>>> then the libraries are not meant to depend on the presence of libdl.
>>> Hence the dep being for the filters.
>>>
>>> In any case, since both libraries are only used by one filter each, i
>>> guess this is ok. But instead of adding a new require_headers check just
>>> reuse the existing one to check both headers.
>>
>> How do I do that?
>
> require_headers "frei0r.h dlfcn.h"
> require_headers "ladspa.h dlfcn.h"
>
> Untested, but should work.

OK, will apply soon, with that changed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/r210: use correct pixel format

[Paul B Mahol]

On 12/3/18, Michael Niedermayer  wrote:
> On Sun, Dec 02, 2018 at 06:06:56PM +0100, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/r210dec.c  | 38 ++-
>>  libavcodec/r210enc.c  | 26 +++-
>>  tests/ref/vsynth/vsynth1-r210 |  6 +++---
>>  tests/ref/vsynth/vsynth2-r210 |  6 +++---
>>  tests/ref/vsynth/vsynth3-r210 |  6 +++---
>>  5 files changed, 45 insertions(+), 37 deletions(-)
>
> breaks fate
> make fate-vsynth_lena-r210 -j12
> TESTvsynth_lena-r210
> --- ./tests/ref/vsynth/vsynth_lena-r210   2018-12-01 01:58:25.524430036 
> +0100
> +++ tests/data/fate/vsynth_lena-r210  2018-12-03 01:37:11.312043615 +0100
> @@ -1,4 +1,4 @@
> -94874a48987fd401494f4d7ca8e1273b *tests/data/fate/vsynth_lena-r210.avi
> +61fd53566d99b725e75212747b35893f *tests/data/fate/vsynth_lena-r210.avi
>  22125252 tests/data/fate/vsynth_lena-r210.avi
> -6ea4fcd93fc83defc8770e85b64b60bb
> *tests/data/fate/vsynth_lena-r210.out.rawvideo
> -stddev:0.70 PSNR: 51.12 MAXDIFF:   12 bytes:  7603200/  7603200
> +4b7425191bb6a7fc4ca0dc649d9ba202
> *tests/data/fate/vsynth_lena-r210.out.rawvideo
> +stddev:0.93 PSNR: 48.72 MAXDIFF:   11 bytes:  7603200/  7603200
> Test vsynth_lena-r210 failed. Look at tests/data/fate/vsynth_lena-r210.err
> for details.
> make: *** [fate-vsynth_lena-r210] Error 1

Fixed locally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/qsvenc: replace assert0 with an error return when pict_type is uninitialized

[Linjie Fu]

pict_type may be uninitialized, and assert on a value coming from an external
library is not proper.

Return invalid data error in function ff_qsv_encode to avoid using uninitialized
value.

Signed-off-by: Linjie Fu 
---
 libavcodec/qsvenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 7f4592f878..891253be76 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -1338,7 +1338,7 @@ int ff_qsv_encode(AVCodecContext *avctx, QSVEncContext *q,
 else if (bs->FrameType & MFX_FRAMETYPE_B || bs->FrameType & 
MFX_FRAMETYPE_xB)
 pict_type = AV_PICTURE_TYPE_B;
 else
-av_assert0(!"Uninitialized pict_type!");
+return AVERROR_INVALIDDATA;
 
 #if FF_API_CODED_FRAME
 FF_DISABLE_DEPRECATION_WARNINGS
-- 
2.17.1

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: assert uninitialized pict_type

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Almer
> Sent: Friday, November 30, 2018 23:53
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: assert
> uninitialized pict_type
> 
> On 11/30/2018 12:42 PM, Carl Eugen Hoyos wrote:
> > 2018-11-30 10:54 GMT+01:00, Linjie Fu :
> >> ffmpeg | branch: master | Linjie Fu  | Wed Nov 28
> >> 10:41:55 2018 +0800| [67cdfcf694f840d215be940f82545c45c9be193a] |
> committer:
> >> Zhong Li
> >>
> >> lavc/qsvenc: assert uninitialized pict_type
> >>
> >> Assert in function ff_qsv_encode to avoid using uninitialized value:
> >>
> >> FF_DISABLE_DEPRECATION_WARNINGS
> >> avctx->coded_frame->pict_type = pict_type;
> >> FF_ENABLE_DEPRECATION_WARNINGS
> >>
> >> Signed-off-by: Linjie Fu 
> >> Signed-off-by: Zhong Li 
> >>
> >>>
> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=67cdfcf694f840d
> 215be940f82545c45c9be193a
> >> ---
> >>
> >>  libavcodec/qsvenc.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> >> index 3946c1d837..7f4592f878 100644
> >> --- a/libavcodec/qsvenc.c
> >> +++ b/libavcodec/qsvenc.c
> >> @@ -1337,6 +1337,8 @@ int ff_qsv_encode(AVCodecContext *avctx,
> QSVEncContext
> >> *q,
> >>  pict_type = AV_PICTURE_TYPE_P;
> >>  else if (bs->FrameType & MFX_FRAMETYPE_B || bs->FrameType &
> >> MFX_FRAMETYPE_xB)
> >>  pict_type = AV_PICTURE_TYPE_B;
> >> +else
> >> +av_assert0(!"Uninitialized pict_type!");
> >
> > You generally cannot assert on a value coming from an external library.
> 
> And using string literals in an assert may generate warnings.
> 
> Just error out returning AVERROR_INVALIDDATA.
> 
Will replace the assert with an error return and send a new patch.

Thanks,
- Linjie, Fu

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